Factory Acceptance Testing (FAT) – Proving Functionality, Safety, and Data Integrity Before Shipment

This topic is part of the SG Systems Global regulatory & operations glossary.

Updated October 2025 • Commissioning & Validation • Engineering, QA, CSV

Factory Acceptance Testing (FAT) is a structured, witnessed test performed at the supplier’s facility to verify that a system—equipment, automation skid, or manufacturing software—meets the approved design, functional, and compliance requirements before shipment to the user site. In regulated manufacturing, FAT is a formal quality gate between build and delivery: it demonstrates that critical functions, interlocks, alarms, data capture, electronic records, and interfaces behave as specified; it uncovers defects when remediation is fastest; and it generates objective evidence that feeds downstream commissioning and qualification (see Equipment Qualification (IQ/OQ/PQ) and CSV). A robust FAT is not a demo; it is an execution of an approved protocol with pass/fail criteria, controlled deviations, and signed results under 21 CFR Part 11/Annex 11 expectations when electronic.

“The cheapest place to discover a problem is on the vendor’s floor, with the crate still open and the engineers still there.”

FAT typically covers three dimensions: (1) Functional—does the system perform the required operations across normal and boundary conditions? (2) Safety & interlocks—are protections, stops, and alarms effective and unbypassable without authorization? (3) Data integrity & connectivity—are electronic records attributable, contemporaneous, accurate, and linked to audit trails; do interfaces to MES/ERP/LIMS/labeling behave deterministically with acknowledgements? FAT evidence—checklists, screen captures, instrument printouts, simulated device signals, and signed test steps—becomes an input to site OQ/PQ, reducing duplicate effort and focusing site testing on utilities, integration with local infrastructure, and performance under real recipes.

1) Scope and Objectives

FAT verifies conformance of the delivered system of supply (hardware, firmware, application, and standard integrations) to the approved User Requirements Specification and Functional Design. Typical objectives include: proving key modes (automatic, manual, maintenance), validating interlocks and permissives, challenging alarms and annunciations (including fail-safe behavior), verifying electronic record creation and security (unique users, roles, audit trails, e-signatures), exercising standard data flows (to/from ERP, WMS, LIMS, labeling), and confirming documentation completeness (drawings, wiring schedules, manuals, bill of materials, certificates). FAT also confirms build quality: component IDs, calibration certificates for critical instruments, and software versions match the build book that will ship. Where applicable, stability-relevant features (e.g., temperature control, humidity monitoring) are challenged against acceptance limits to ensure later Environmental Monitoring (EM) hooks will function as intended.

2) Governance, Roles, and Deliverables

FAT is governed under Document Control and Change Control. The buyer approves the protocol; the supplier executes with buyer oversight; QA/CSV witness critical tests; and engineering signs results. Deliverables typically include: the FAT protocol with traceability to requirements; test scripts with objective acceptance criteria; raw data and attachments (photos, HMI captures, audit-trail extracts); instrument calibrations; software BOM and versions; cybersecurity hardening evidence (accounts, password policy, services); a punch list of open items with owners and due dates; and a formal FAT report including deviations and their disposition. When the system produces electronic records, the protocol must define how Part 11/Annex 11 controls will be tested—user mapping, e-signature meaning, time synchronization, audit-trail tamper resistance, backup/restore—and how artifacts will be retained.

3) What FAT Tests (Beyond a Demo)

• Functional sequences. Nominal start-up, changeover, run, and shutdown with recipe steps derived from the approved eMMR or master instruction set.
• Safety & interlocks. E-stops, guards, door switches, load-cell plausibility, torque/temperature limits, permissives, and inhibit logic—provoked intentionally to prove safe state and annunciation.
• Alarm handling. Priorities, colors, sounds, latching/reset rules, alarm shelving, and alarm history retention.
• Data integrity. User accounts/roles, forced logouts, password policies, e-signature challenges (displayed meaning), reason-for-change prompts, immutable audit trails, time-sync, and backup/restore drills.
• Device and I/O simulation. Scales, counters, PLC tags, barcode scanners, printers, and sensors feeding deterministic inputs to validate calculations and Barcode Validation paths.
• Interfaces. Handshakes with ERP/WMS/LIMS/labeling using test orders, lots, CoA stubs, and EPCIS shipping events; acknowledgement, retry, and reconciliation behavior under loss-of-link scenarios.
• Reporting & records. Generation of eBMR artifacts, labels with correct template/version binding, and evidence that records tie back to the master.
• Performance & stress. Representative load, queue depths, trend buffers, and recovery from power loss or controlled restart.

4) Acceptance Criteria, Deviations, and Traceability

Each test step has an objective acceptance criterion (value, tolerance, expected state change, or audit-trail entry). Failures are recorded as Deviations/NCs with evidence and immediate corrective action. If the defect is minor and fully contained, a conditional pass may be granted with a punch-list item to be closed before shipment or at Site Acceptance Testing (SAT); material failures require retest. A requirements traceability matrix links URS/FS items to FAT steps and outcomes, providing a foundation for risk-based site testing and later CAPA if defects recur.

5) Relationship to IQ/OQ/PQ and Computer System Validation

FAT is not a substitute for site qualification, but it reduces OQ/PQ burden by removing vendor-resolvable defects and by producing reusable evidence. IQ will still verify the shipped configuration, utilities, and installation conditions; OQ will confirm functional performance in the site environment (utilities, networks, domain security, labeling endpoints); and PQ will prove fitness for intended use on real products/batches under the approved eMMR. Within CSV, FAT evidence supports risk assessments, helps justify test reduction at site for already-proven vendor logic, and demonstrates supplier quality practices. For electronic records, FAT begins the Part 11/Annex 11 verification chain; site testing completes it by exercising domain policies, backup infrastructure, and enterprise identity.

6) Common Failure Modes & How to Avoid Them

• Demo instead of test. Scripted walk-through without pass/fail evidence. Fix: protocolized steps, measurable criteria, and captured artifacts.
• Paperwork lag. Build book, drawings, or software BOM not aligned to what is tested. Fix: pre-FAT document freeze and spot checks during testing.
• Interfaces untested. “Stubs” that skip error paths. Fix: handshake/ack/retry tests with deliberate drops and duplicate messages.
• Audit-trail gaps. Editable logs or missing time sync. Fix: tamper-evidence checks, NTP alignment, and restore drills.
• Bypass culture. Temporary overrides left in place to pass tests. Fix: override registry with sign-off and end-of-day sweep.
• Scope creep at FAT. Attempting site-specific customizations on vendor floor. Fix: lock scope; defer localizations to SAT/OQ with Change Control.
• Cyber hygiene weak. Default accounts and open services. Fix: hardening checklist as a FAT section with evidence.
• Training ignored. Operators see the system first at SAT. Fix: capture training materials/videos during FAT for pre-SAT readiness.

7) Metrics That Matter

Track first-pass FAT yield (steps passed / total), defects per test hour, interface error recovery success, audit-trail nonconformities, punch-list closure time, site retest reduction (OQ steps waived or simplified), and time-to-SAT readiness. Trend by supplier, system type, and project team; feed into supplier scorecards and management review alongside APR/PQR insights when product-impacting.

8) How This Fits with V5

V5 by SG Systems Global treats FAT as a digital milestone that de-risks commissioning and accelerates go-live. For automation and execution systems, V5 supplies FAT-ready protocol templates linked to the eMMR and standard integration packs (ERP, WMS, LIMS, labeling). Using the same application stack that will run on site, V5 executes FAT steps with live eBMR or workflow screens, capturing attributable evidence (device signals, scans, signatures) into an inspection-ready dossier. Interfaces are exercised with acknowledgement and reconciliation logic; blocked/duplicate messages, timeouts, and retry queues are provoked and recorded. Security policies, role mappings, and Approval Workflows are validated; audit trails are exported and reviewed for tamper-evidence; and backup/restore paths are demonstrated. The resulting FAT package (protocol, results, deviations, punch list) flows forward into site IQ/OQ with references intact, while change requests post-FAT are routed under Change Control so configuration drift never hides in transit.

9) FAQ

Q1. How is FAT different from SAT?
FAT is executed at the supplier’s facility to prove the built system meets functional and compliance requirements. SAT occurs at the user site to verify installation, utilities, local integrations, and performance in the real environment, feeding into OQ/PQ.

Q2. Do we need QA and CSV at FAT?
Yes for regulated systems. QA/CSV witness critical tests, verify data-integrity controls, and ensure the evidence set will stand up in inspections. Their early involvement prevents rework at site.

Q3. Can FAT evidence reduce OQ?
Often. With a solid traceability matrix and supplier quality controls, risk-based CSV can credit vendor testing, focusing site OQ on environment-specific risks, security federation, and interfaces unique to the plant.

Q4. What records from FAT must be retained?
The approved protocol, executed test scripts, raw data and attachments, deviations with dispositions, calibration certificates, software BOM/versions, audit-trail excerpts, and the final FAT report—retained per your Data Retention & Archival policy.

Q5. How do we handle changes discovered during FAT?
Log as deviations and/or engineering change requests. If accepted, control them under Change Control, update documentation, and retest impacted steps. Avoid shipping with undocumented deltas.

Related Reading
• Validation & Records: CSV | Equipment Qualification (IQ/OQ/PQ) | Electronic Batch Record (eBMR) | eMMR | Data Integrity
• Governance & Change: Document Control | Change Control | CAPA
• Release & Traceability: Finished Goods Release | CoA | EPCIS