A lot of plant managers start asking what is FAT testing at the same moment a project starts to feel risky.
The machine is nearly finished at the builder's shop. Your launch date is already on the production calendar. Operations is asking when the line will be ready, quality wants documentation, maintenance wants prints, and IT is asking how the controls will connect to your plant. If the equipment shows up with the wrong sensor package, incomplete software, or unresolved safety issues, the problem doesn't stay in the vendor's building. It lands on your floor, on your schedule, with your team pulled into recovery mode.
That's why FAT matters. Done well, it's not ceremony. It's one of the few points in a capital project where you can still find problems early, force clarity, and keep bad assumptions from getting packaged and shipped to your site. For semi-automated cells, custom fixtures, regulated equipment, and automation projects that mix mechanics, controls, software, and operator interaction, that early discipline is often what separates a clean startup from weeks of field correction.
Table of Contents
- The High Cost of On-Site Surprises in Manufacturing
- What Is Factory Acceptance Testing (FAT)
- Why FAT Is a Critical Investment Not an Optional Expense
- The Key Differences Between FAT and SAT
- The Typical FAT Process from Planning to Sign-Off
- A Practical FAT Checklist and Acceptance Criteria
- Common Pitfalls and Special GMP Considerations
The High Cost of On-Site Surprises in Manufacturing
A custom machine can look complete on the skid and still be far from ready for production.
A common failure pattern goes like this. The equipment arrives on time, rigging goes fine, utilities are connected, and everyone expects startup to move quickly. Then issues surface. The HMI screens don't match the approved sequence. A guarding panel interferes with material loading. The controls package doesn't align with your plant standards. The machine runs, but not in a way your operators can use.
Those aren't isolated technical annoyances. They create project drag across the whole operation.
What breaks when problems are found too late
When a build issue is discovered after delivery, several teams get pulled in at once:
- Production loses focus: Supervisors start reshuffling schedules around an asset that was supposed to add capacity but still isn't ready.
- Engineering gets diverted: Your internal team stops working on improvement projects and starts debugging a vendor build.
- Maintenance inherits uncertainty: Technicians are asked to support equipment they haven't been trained on and may not have final documentation for.
- Quality gets boxed in: If the machine affects inspection, traceability, or product handling, quality can't approve release with open questions.
In regulated or customer-audited environments, the situation gets worse fast. You're not just troubleshooting function. You're defending design intent, change control, and documentation discipline after the equipment is already on-site.
Problems are always cheaper to solve where the machine is built than where the machine is supposed to be producing.
Why plant teams feel this pain so sharply
Field fixes are slow because the environment is messy. The builder no longer has full shop access, spare components may be off-site, the original build team is remote, and every test window competes with plant activity. Even small changes can turn into a chain of approvals, rework, and retesting.
That's the primary purpose behind FAT. It gives the buyer one structured chance to challenge the machine before shipment, while the builder still has tools, people, and parts within reach.
What Is Factory Acceptance Testing (FAT)
Factory Acceptance Testing, or FAT, is a pre-shipment verification performed at the manufacturer's site to confirm that an industrial machine or system meets the customer's technical specifications, design requirements, and contractual acceptance criteria before delivery. In practice, that makes FAT a controlled “dress rehearsal” that reduces the probability of on-site rework, startup delays, and unplanned downtime after installation, as described in DXP's explanation of Factory Acceptance Testing.
If you want a simple way to think about it, FAT is the industrial equivalent of a final walk-through before taking possession of a custom-built house. You don't just check whether the lights turn on. You verify that the installed work matches the approved plan, that the systems operate as intended, and that the builder can prove what was delivered.
What FAT includes in real projects
A useful FAT goes beyond powering up the machine and running one good cycle. It checks whether the delivered system matches what was purchased and approved.
That often means confirming items such as:
- Mechanical build quality: Correct components, assemblies, mounting, guarding, labeling, and workmanship.
- Controls behavior: Inputs, outputs, recipes, alarm handling, sequence logic, and operator interface behavior.
- Safety functions: Emergency stops, interlocks, safe states, and responses to abnormal conditions.
- Documentation readiness: Drawings, manuals, spare parts lists, certificates, and software records.
For semi-automated systems, this matters just as much as it does for large automated lines. In fact, semi-automatic equipment often needs closer scrutiny because operator interaction, fixture repeatability, ergonomics, and manual loading steps can hide practical issues that won't show up in a simple bench test.
What FAT is really doing for the buyer
The biggest mistake I see is treating FAT as a courtesy visit instead of an acceptance event.
A proper FAT gives the customer an advantage. Before shipment, the machine is still in the builder's control. Corrections can still be made without field mobilization. Design questions can still be settled with the original engineering team in the room. That's when you want to discover mismatches between the approved concept and the finished build.
Practical rule: If a requirement matters enough to delay payment or affect startup, it belongs in the FAT scope.
That's why the answer to what is FAT testing shouldn't stop at a definition. It's a formal checkpoint that protects the capital investment, the startup schedule, and the people who will have to live with the machine after handover.
Why FAT Is a Critical Investment Not an Optional Expense
Some companies still try to trim FAT when schedules get tight or travel budgets get challenged. That usually looks efficient on paper and expensive in the plant.
The logic is simple. If a problem is found at the builder's site, the builder has access to its engineers, electricians, programmers, tooling, and stock components. If the same problem is found after shipment, every correction gets harder. Access is constrained, production pressure is higher, and the customer's internal labor gets dragged into work that should have been closed before delivery.
FAT is not a checkbox
A frequently missed angle is that FAT is not just a “pre-shipment checkbox”. Stronger guidance treats it as a structured verification of requirements, test environment, documentation, and corrective actions before handover, with SAT coming afterward, as noted in Operations1's FAT glossary.
That distinction matters in practice. A weak FAT often produces vague statements like “machine ran successfully” or “customer witnessed operation.” Those statements don't protect you when startup exposes open items. A strong FAT creates a record of what was tested, under what conditions, what failed, what was corrected, and what remains open.
Where managers misjudge the trade-off
The usual argument against FAT is time. “We already reviewed the design.” “The builder has done this before.” “We'll sort out the rest during installation.”
That thinking ignores how field problems behave. They don't stay contained.
Here's what usually happens when FAT is minimized:
- Open assumptions turn into schedule slips: Unverified details come back during commissioning, when every delay affects installation sequencing.
- Minor software gaps become startup blockers: A missing alarm, recipe issue, or sequence flaw can prevent release even when the mechanics are complete.
- Responsibility gets blurry: Without a documented acceptance process, the customer and builder can spend days arguing over whether an issue is a defect, change request, or site condition.
- Travel savings disappear: The money saved by skipping FAT is quickly replaced by field visits, remote troubleshooting, and internal overtime.
A capable integrator can reduce that confusion by aligning engineering, controls, and acceptance expectations early. That's one reason many manufacturers look for an automated systems integrator that streamlines operations before build problems become startup problems.
The fastest project isn't the one that ships earliest. It's the one that starts up with the fewest unresolved questions.
Why this matters for smaller and mid-sized projects too
Plant teams often reserve formal FAT discipline for large capital lines and under-manage everything else. That's a mistake. A semi-automated workstation, custom fixture, leak-test station, vision-assisted assembly cell, or GMP-sensitive packaging step can create just as much disruption if it lands incomplete.
The scale of the machine doesn't determine FAT value. The operational risk does.
If the asset affects throughput, labor, safety, quality, traceability, or regulatory control, FAT is not overhead. It's project insurance with technical teeth.
The Key Differences Between FAT and SAT
FAT and SAT get lumped together all the time, but they answer different questions.
FAT asks whether the supplier built the machine correctly before shipment. SAT, or Site Acceptance Testing, asks whether the installed machine works correctly in your facility, with your utilities, your materials, your operators, and your surrounding process conditions.
FAT vs. SAT A Head-to-Head Comparison
| Criteria | Factory Acceptance Test (FAT) | Site Acceptance Test (SAT) |
|---|---|---|
| Location | Manufacturer's factory | Customer's site |
| Timing | Before shipment | After installation |
| Purpose | Verify build quality, functionality, contract compliance | Verify installation, integration, site-specific conditions |
| Participants | Manufacturer, customer representatives | Customer, sometimes manufacturer support |
| Environment | Controlled, ideal conditions | Real-world, operational conditions |
| Scope | Individual equipment or system | Integrated system in the full operating environment |
What FAT proves
FAT is best suited for controlled verification. The supplier can stage the machine, connect temporary utilities, run planned sequences, and walk the customer through the build with prints and software support close at hand.
That makes FAT the right place to verify:
- Build-to-spec conformance: Was the machine built to the approved design?
- Base functionality: Do motion, controls, safety logic, and operator interface work as intended?
- Documentation alignment: Do drawings, labels, and manuals reflect the as-built condition?
If something fails here, the builder still owns the environment. That's a major advantage.
What SAT proves
SAT happens after the machine is installed at the customer's facility. By then, the questions change.
Now you need to know whether the machine works under actual site conditions. That includes network integration, utility stability, floor space constraints, upstream and downstream handoff, real product variation, and operator use on the plant floor. SAT confirms that the asset functions where it matters.
FAT shows the machine was built right. SAT shows the machine works right in your factory.
Why confusing them causes trouble
When teams assume SAT will “catch anything missed,” FAT tends to become shallow. Then SAT becomes overloaded with issues that should never have left the supplier's shop. That's how installation windows get consumed by basic debugging instead of final integration and operator readiness.
The better approach is to separate responsibilities cleanly. FAT should close supplier-side build risk as much as practical. SAT should focus on site-specific verification, not unresolved factory work.
The Typical FAT Process from Planning to Sign-Off
A strong FAT starts long before anyone walks onto the supplier's floor. If the protocol is weak, the test day will be weak too.
The process works best when acceptance is treated as part of project execution, not as an event squeezed in at the end. A technically robust FAT is not just a functional run-through. It typically includes document review, inspection of as-built drawings, calibration and certification checks, execution of an inspection and test plan, raw-data capture, and formal discrepancy reporting, because acceptance depends on traceable evidence that the build matches the approved design and that safety and compliance checks were completed before shipment, as outlined in Alt Energy Magazine's FAT guidance for BESS systems.
Start with the protocol, not the machine demo
A FAT protocol is the script. Without it, people improvise, and improvised FATs usually drift toward whatever is easiest to show rather than what needs proof.
The protocol should define:
- Scope: What systems, modes, recipes, and functions are in or out.
- Acceptance criteria: What counts as pass, fail, conditional acceptance, or open item.
- Responsibilities: Who witnesses, who records, who approves, and who resolves discrepancies.
- Required records: Raw data, screenshots, signed forms, calibration evidence, and marked-up punch lists.
For software-heavy systems, digital coordination matters as much as hardware readiness. Many teams now support this work with structured factory acceptance test software so test scripts, evidence capture, and issue tracking don't disappear into scattered spreadsheets and email threads.
Execute in a sequence that exposes risk early
The best FATs don't begin with the flashy cycle. They begin with fundamentals.
A practical flow usually looks like this:
- Document review first. Confirm drawings, manuals, BOM alignment, and revision status before functional testing starts.
- Static checks next. Inspect labeling, wiring, guarding, hardware installation, pneumatic routing, and workmanship.
- Safety verification before production modes. Challenge interlocks, emergency stops, safe-state behavior, and alarm responses.
- Functional and sequence testing. Run the machine through manual, semi-auto, auto, fault recovery, and changeover conditions as applicable.
- Performance runs last. Only after the basics are stable should the team assess sustained operation, repeatability, or output behavior.
That order matters because it avoids wasting test time on symptoms caused by obvious unfinished work.
Sign-off should never hide open items
Most FATs end with one of three outcomes:
- Accepted for shipment
- Accepted with documented punch-list items
- Not accepted pending corrective action
There's nothing wrong with conditional acceptance if the remaining items are clearly documented, risk-ranked, assigned, and closed through a formal process. What causes trouble is the informal version, where everyone says the machine is “basically done” and hopes the remaining issues will be resolved later.
If an issue is serious enough to mention in the hallway after FAT, it's serious enough to write into the report.
A good sign-off package becomes the reference point for shipping release, SAT planning, training preparation, and any later dispute over whether the delivered machine matched the agreed scope.
A Practical FAT Checklist and Acceptance Criteria
Most FAT failures don't happen because nobody tested anything. They happen because the team tested loosely.
A practical checklist gives structure to the day and prevents the group from chasing whatever the machine builder wants to demonstrate first. It also helps the customer separate cosmetic comments from true acceptance items.
Core checklist categories
Use a checklist that reflects how the machine will be operated, maintained, and approved.
- Documentation review: Verify manuals are current, drawings reflect the as-built condition, and required certificates or records are included.
- Functional performance: Test all operating modes, confirm sequence logic, verify alarms, and challenge fault recovery steps.
- Safety features: Trigger emergency stops, verify interlocks, inspect guarding, and confirm the machine enters a safe state when expected.
- Quality and workmanship: Inspect fabrication, labeling, cable management, finish quality, and assembly consistency.
- Calibration and accuracy: Confirm instruments are calibrated where required and verify that measurement or inspection functions behave as intended.
Acceptance criteria must be unambiguous
Weak criteria create arguments. Strong criteria create decisions.
Bad acceptance language sounds like this: “machine runs well,” “operator screen looks good,” or “output is acceptable.” None of that is testable. If you're buying custom equipment, every critical requirement should be written so a witness can clearly determine pass or fail.
A better approach is to define criteria using concrete conditions such as:
| Area | Weak criterion | Stronger criterion |
|---|---|---|
| HMI | Screen is complete | All approved screens, alarms, and navigation paths are present and match the released sequence |
| Safety | E-stop works | Each emergency stop device brings the system to the defined safe state and requires the approved recovery sequence |
| Changeover | Product change is easy | Fixture, recipe, and operator steps match the approved changeover method and can be demonstrated during FAT |
| Documentation | Manuals provided | Required manuals, drawings, and records are available in the agreed revision state at time of FAT |
| Performance | Machine is fast enough | Machine demonstrates the agreed operating sequence under the stated FAT conditions |
Tailor the checklist to the real risk
Not every machine needs the same FAT depth. A manual fixture with sensors won't need the same protocol as a networked packaging cell or vision-guided assembly station. But every project does need discipline around what matters most.
For semi-automated and regulated systems, I'd prioritize these questions:
- Can the operator use it safely and consistently?
- Do the controls handle faults in a predictable way?
- Does the documentation match what was built?
- Are critical quality-related functions demonstrated, not just described?
- Are open items written clearly enough that nobody can reinterpret them later?
That last point matters more than many teams realize. FAT isn't only about finding defects. It's about removing ambiguity before the machine changes hands.
Common Pitfalls and Special GMP Considerations
The most common FAT mistake is vagueness. The protocol is thin, the wrong people attend, and the team tries to decide acceptance standards on the fly. That almost always leads to uneven testing, missed evidence, and a punch list that doesn't clearly separate major risks from minor cleanup.
Another frequent problem is scope drift during the visit. A buyer notices a convenience feature that wasn't in the approved design, asks for it on the spot, and suddenly the FAT becomes a redesign meeting. That's a bad habit. FAT should verify the agreed build, not become a workshop for uncontrolled late changes.
Why GMP raises the bar
For software-heavy, automation-rich, or safety-critical systems, FAT increasingly includes hardware, software, cybersecurity, and simulation-based testing. The more useful question is no longer just what FAT is, but what must be validated when the system is partly virtual, networked, or regulated, as discussed in Accure's perspective on FAT for complex systems.
In GMP-aware environments, that question gets sharper. Medical device and other regulated manufacturers have to care about traceability, electronic records, controlled documentation, and defensible proof that the equipment was reviewed in a disciplined way. If your operation falls under regulated manufacturing expectations, it helps to understand what GMP in manufacturing means before acceptance testing starts.
Practical rules for regulated equipment
- Lock the protocol early: Approval criteria shouldn't be negotiated in the FAT room.
- Treat software seriously: HMI behavior, user access, alarms, data handling, and revision control need the same attention as hardware.
- Capture evidence as you test: Don't rely on memory for regulated or quality-critical functions.
- Control open items tightly: Every discrepancy should have an owner, disposition, and closure path.
A weak FAT can still let a machine ship. It just transfers risk to your site, your validation effort, and your production schedule.
If you're planning a semi-automated, fully automated, or GMP-aware equipment project, System Engineering & Automation helps manufacturers reduce startup risk with practical engineering, custom equipment design, integrated controls, and acceptance-focused project execution. Their team supports everything from tooling and fixtures to complete production systems, with an emphasis on building the right level of automation for your process, budget, and compliance needs.
