A factory acceptance test checklist is a numbered register linking each machine requirement to a test method, acceptance criterion, result and witness. It also records deviations, retests and the items carried forward to site acceptance. The tables below form a copyable template for custom machines and integrated cells.
Motionwell runs machine FATs at our Woodlands Link facility before shipment, followed by site acceptance on the buyer’s floor. Use this register to agree the test scope before the machine is ready, then populate each row with your requirement number and measurable criterion.
The short answer. A FAT checklist has four jobs. It proves that the machine standing on the floor is the machine that was specified. It exercises every function the purchase order paid for, at the limits of the declared range and on parts you supplied. It records every failure with a class, an owner and a retest rule, so the sign-off is a decision. And it says, item by item, what has been deferred to site and why. A register that does those four things can be short. One that does not can fill a binder and prove nothing.
The examples cover assembly machines, filling and sealing platforms, test equipment, robot cells and material handling systems. They test sequence, rate, accuracy, safety functions and production records. The automation project process explains where FAT sits between design approval, shipment and handover, and which people should participate.
What Is a Factory Acceptance Test Checklist, and What Is It Not?
A FAT checklist is a line-item register agreed before the test opens. Each line carries an identifier, the requirement it traces to, the method used to verify it, the acceptance criterion, a space for the observed result, a status, and the initials of the witness. Keep the test instructions detailed enough to repeat, whether they are written in the register or in an attached script. Record the criterion, result and witness against the same item ID.
| Column | What goes in it | Why the column exists |
|---|---|---|
| Item ID | A number that never changes once the protocol is approved | Deviations, retests and the SAT re-run all refer back to it |
| Requirement reference | The URS or specification clause the item proves | An item with no reference is either a demonstration or a missing requirement |
| Method | What is done: run, measure, force a fault, inspect, compare against a document | Two people reading the line should run the same test |
| Acceptance criterion | A value with a tolerance, a count, or a defined behaviour | “Operates correctly” cannot fail, so it cannot pass either |
| Observed result | What was actually seen or measured, written at the time | A result written from memory the next day is a different document |
| Status | Pass, fail, or deferred to site with the reason | Deferred is a legitimate status; blank is not |
| Witness | Initials and date of the person who watched it | The signature block at the end signs for these initials |
Three things it is not. It is not the builder’s internal test. Before your test opens, the machine should already have been run against the same register by the people who built it, with the results kept, so the witnessed test is a confirmation. It is not the installation or operational qualification on a GMP project; those are qualification protocols owned by your quality unit and are dealt with further down. And it is not the site acceptance test, which uses the same register but answers a different question, covered in its own section below.
A working row can be copied directly into a spreadsheet. This example shows a restart test; adapt the method and criterion to the approved safety design.
| Item ID | Requirement | Method | Acceptance criterion | Observed result | Status | Witness/date |
|---|---|---|---|---|---|---|
| EX-01 | Example: URS restart clause | Run the approved emergency-stop test; release the button and observe | Releasing the button does not restart motion; restart follows the approved sequence | Illustrative result: no motion on release; controlled restart completed | Example only | Name / date |
| [ID] | [URS clause] | [Test steps] | [Value, tolerance or behaviour] | [Measured result] | [Pass / fail / deferred] | [Initials / date] |
The register grows out of the requirement list, which is why the numbering on your user requirement specification matters at this stage. Our guide to writing an automation URS shows how a requirement number carries through design to a test reference; the FAT checklist is where that number is finally cashed.
What Has to Be Ready Before the FAT Date Is Fixed?
The readiness review is the part of the FAT that nobody puts in the calendar, and it decides whether the test day is a test. Fix the date when the items below are closed, not when the shipping schedule says the date has arrived.
| Readiness item | Owner | Why it blocks the date |
|---|---|---|
| Internal test complete against the approved register, results retained | Builder | A witnessed test that finds the machine’s first faults is a debugging session with an audience |
| Software version frozen, archived and named on the protocol cover | Builder | Any change after the freeze re-opens the items it touches |
| Protocol approved by both parties, item by item | Both | Arguing the criterion while the machine runs is the failure this document exists to prevent |
| Production parts delivered, in the quantities and variants the protocol names | You | The register names which variants each item runs on, and a variant that never arrived turns its items into deferrals |
| Consumables and packaging materials matching production | You | Labels, films, containers and closures behave differently from samples pulled out of a drawer |
| Utilities at the test bay recorded: supply, compressed air, network | Builder | What the test ran on is part of the result, and the site comparison starts here |
| Simulated interfaces defined in writing | Both | Upstream, downstream and plant system stand-ins have to be declared so the SAT knows what was not real |
| Measuring equipment listed with calibration status | Builder | A rate or an accuracy figure is only as good as the instrument it was measured with |
| Draft documentation pack available at the test | Builder | Drawings and manuals are checked against the machine, which cannot happen after it has shipped |
| Attendees confirmed, with signing authority named | You | The person who can accept a deviation has to be in the room |
Two of these are easy to skip. The software freeze gets skipped because the last change always seems small, and the measuring equipment list gets skipped because nobody thinks of a stopwatch as an instrument. Both come back at site, where a rate that cannot be reproduced is blamed on the building.
Which Items Belong on a Machine Factory Acceptance Test Checklist?
The register below is organised by section, and not by the order the tests are run, because sections are how it gets reviewed. Each section lists the item, how it is verified and what kind of criterion it needs. The values come from your requirement specification, and nothing here should be copied with a number in it.
| Section | Item | How it is verified | Criterion type |
|---|---|---|---|
| Build and identity | Machine matches the approved layout and general arrangement drawing | Walk the drawing against the machine | Deviations listed, or none |
| Build and identity | Major components match the approved bill of materials: controller, drives, sensors, cameras, grippers | Read nameplates against the list | Model and serial recorded |
| Build and identity | Product-contact materials and finishes match the specification | Material certificates against the drawing | Certificate present per part |
| Electrical | Panel built to IEC 60204-1: supply disconnect, protection against electric shock, conductor identification, enclosure | Inspect against the schematic and the standard | Each clause item pass |
| Electrical | Emergency stop category and circuit as designed | Trace the circuit; operate every device | Category as specified; every device stops the machine |
| Functional | Every sequence step in every mode: auto, manual, setup, jog, cleaning, recovery | Run each mode from the HMI, step by step | Behaviour matches the functional description |
| Functional | Every alarm raised on purpose | Create the condition; read the alarm | Text names the device, the condition and the next action |
| Functional | Reject path: a bad part is detected, diverted and logged | Introduce a known bad part | Detected, diverted, record present |
| Rate | Sustained run on your parts at the contracted rate | Timed run of the agreed length, all stations live | Rate held; every stop and its cause recorded |
| Rate | Yield over the run | Count good parts, rejects and unplanned stops | Within the agreed figure |
| Accuracy | Placement, fill, torque, force or measurement accuracy, at the positions and loadings the protocol names | Measured with an instrument from the calibration list | Within tolerance at every named point, each figure written down as read |
| Changeover | Format or recipe change performed by your operator | Timed from last good part to first good part, once for each format on the list | Completed without builder assistance; time recorded against each format |
| Safety | Every safety function on the approved list | Exercise the defined operating and fault conditions using the approved test method | Required stop, limit, access or restart behaviour achieved; result recorded per function |
| Safety | Safety controller configuration checksum | Read from the device | Matches the approved configuration |
| Control | Power loss mid-cycle and recovery | Cut the supply during a cycle; restart | Machine reaches the defined safe state, and the recovery path taken is the one the functional description names |
| Control | User levels and access | Log in at each level; attempt a blocked action | Blocked action refused and logged |
| Control | Plant interface against the simulated partner | Exercise every signal on the list | Direction and meaning as documented |
| Records | Data record content per part, batch or serial number | Run parts; export the record | Every required field present and timestamped |
| Records | Backup and restore of program and data | Perform it | Machine runs after restore |
| Documentation | Drawings, schematics, program archive, I/O list, alarm list, manuals | Check each against the machine | Matches as built; open items listed |
| Spares | Recommended spares list against the final bill of materials | Cross-check part numbers | Every wear part identified with a source |
| Training | Operator and maintenance sessions scheduled | Confirm dates and attendees | Booked before shipment |
A few of these rows carry more argument than the others and are worth a note each.
What to insist on seeing at the test itself is set out on our automation project process page. What belongs here is how those observations become lines on a register. For the rate row that means fixing three things in the protocol before the test opens: the length of the run, the material it uses and what counts as a stop. Each of them changes the figure that lands in the result column, so each of them is argued about beforehand or argued about afterwards.
The changeover row carries the same requirement in a different form. Each format gets its own line in the register with its own recorded time, because a format that was never run on the day was never tested. How that time is actually brought down is in our guide to reducing changeover time.
The plant interface row depends on a stand-in, and the stand-in has to be declared. Where the machine reports upward to a supervisory system, what belongs on the local panel and what belongs on the supervisory screen is covered in our SCADA vs HMI guide; at FAT the item is that every signal on the agreed list has the direction and meaning the interface document says it has, against whatever is standing in for the other end.
The spares line is checked against the final bill of materials, because the list is only knowable once the last component substitution has been made. Ask for wear parts and long-lead items separately, each with its source, and check that anything proprietary to the builder is identified as such.
How Do You Test Safety Functions at FAT Without Just Watching the Machine Stop?
Start from the safety function list. The risk assessment names each safety function, the required performance level it carries under ISO 13849-1, and the devices that implement it. For each function, define its input conditions, permitted response, fault behaviour and reset or restart conditions where applicable. Use the approved test method to verify and record these. Record the edition used for the design, including ISO 13849-1:2023 where applicable. When the design or edition changes, review the gaps and update affected calculations and validation evidence.
The items that belong in that section:
- Each guard interlock, exercised under the approved test conditions. Verify the specified protective response, any guard locking, and the reset and restart conditions for that access point.
- Each emergency stop device, operated in turn. The stop category matches the circuit design under IEC 60204-1, which governs the emergency stop categories and the supply disconnect on the electrical build, and releasing the button restarts nothing.
- Light curtains and area scanners, interrupted with the test piece the device specifies. Where muting is used, it happens only under the designed conditions, and any blanking is documented on the protocol.
- Safety-rated speed or standstill monitoring on robot cells. The robot-specific requirements sit under ISO 10218, and what the 2025 edition asks of a cell is set out in our guide to the ISO 10218 robot safety standard.
- The safety controller configuration. Read the checksum from the device, record it on the protocol, and confirm the safety program cannot be edited from the operator level.
- Stopping performance. Where a safety distance was calculated from a stop time, the stop time is measured on the built machine, and a datasheet figure will not stand in for it. Whether that measurement belongs at FAT or at site depends on whether the final guarding is fitted at Woodlands Link; either way it is a numbered item.
What the FAT cannot do is stand in for the risk assessment. Where the safety function list is missing or the performance level was never stated, the test has nothing to verify against. How that document is produced is set out in our guide to machine safety risk assessment, and the scope we carry on CE marking is on our machine safety and compliance page.
How Should Failures Be Recorded During the Test?
Every failed item becomes a deviation with a number, a description of what was observed, a class, an owner, a due date and a retest rule. The class is what decides whether the machine ships, so agree the classes before the test opens.
| Class | Definition | What happens to shipment | Retest rule |
|---|---|---|---|
| Critical | A safety function, a contracted rate or accuracy figure, or a record the machine must produce fails | The machine does not ship until the item is closed and retested | Retest the item plus every item the fix touches |
| Major | A function fails, but the machine can run production without it or a workaround exists | Ships only with a written conditional acceptance naming the item, the fix, the date and who pays | Retest at site, recorded against the same item ID |
| Minor | Cosmetic, documentation or labelling items with no effect on safety, required product quality, traceability or operation | Ships; the item goes on the punch list with an owner and a date | Closed by inspection at site |
Two rules keep the table meaningful. A fix that changes software re-opens every item that software touches, which is why the version is named on the cover; a corrected sequence retested only on the line that failed has been half tested. And “pass with comments” is not a status. A comment either describes a deviation, in which case it gets a number, or it describes nothing, in which case it is deleted. Punch lists that grow at the FAT and are never closed are where the argument at site about what was accepted comes from.
Who Signs the FAT Certificate, and What Does the Signature Mean?
The certificate is a short document that sits on top of the register and states four things: which protocol version was run, which software version and configuration checksums were on the machine, which deviations are open and in which class, and which items were deferred to site with their reasons. Below that, the signatures.
On the builder side, the engineer who ran the test signs for the results, and someone with authority to commit to the open items signs for the deviations. On your side, the person with authority to release the machine for shipment signs, and the operator and maintenance representatives initial the items they witnessed and will live with. On a regulated machine, a quality unit representative countersigns the record and data items, because those lines are the ones the qualification protocols will later reference.
What the signature means is release to ship against the listed conditions. What it does not mean is that the machine is accepted for production; that is the site acceptance test’s job. Check what your own purchase order ties to the FAT signature. It may be a payment milestone, it may be the start of a warranty period, it may be both, and the candidates for the warranty trigger sit weeks apart on a project calendar, so the certificate should say which event it is.
A signature also fixes the baseline. After it, any change to the machine, its software or its safety configuration is a change against a tested state and should be recorded as one. That is why the version and checksum lines belong on the certificate itself.
Which Checklist Items Move From FAT to SAT, and Which Only Exist at SAT?
The site acceptance test uses the same register. Items fall into three groups: those verified in full at FAT and only re-inspected at site, those re-run at site against the real line, and those that can only exist at site because they depend on the building.
| Item group | At FAT | At SAT | Why the split |
|---|---|---|---|
| Build, identity, electrical inspection | Verified for the factory configuration | Inspect after transport and verify site supply, earthing and reconnected wiring | Site electrical connections and installation conditions need their own verification |
| Functional sequence, alarms, reject path | Verified in full on your parts | Re-run in abbreviated form on production material | Confirms nothing moved in transit and the site utilities behave |
| Sustained rate and accuracy | Verified against stand-ins for upstream and downstream | Re-run with the real line either side | The stand-ins were declared at FAT; this is where they are replaced |
| Safety functions | Verified on the built machine | Re-verified after re-assembly; stop distances confirmed with the final guarding in place | Any guarding fitted at site was not present at FAT |
| Plant interface | Exercised against a simulated partner | Exercised against the live system | Timing and the real console cannot be simulated |
| Utilities, line tie-in, lifting equipment certification | Not applicable | Verified | They belong to the site |
| Operators and procedures | Your operator performs the changeover | Your shift runs the machine to your own procedure | Behaviour under real staffing is a site property |
The items that only exist at SAT are the ones that depend on the room and the line. The tie-in either side is the visible case: a machine destined for a packaging line is tested at Woodlands Link against a stand-in for the conveyor upstream and downstream, and the real handshake, the real accumulation and the real product flow are proved on your floor. What that integration involves, and why the interfaces are specified before the machine, is on our packaging line integration page.
Deferred items are listed on the FAT certificate with the reason for deferral, and the SAT opens by reading that list. An item deferred without a reason invites the suspicion that it failed, and it will be argued about on your floor.
Where Does the FAT Sit When the Machine Needs IQ, OQ and PQ?
On a GMP machine the FAT neither disappears nor becomes the qualification. It stays the builder’s proof that the machine is ready to ship, and the qualification protocols sit on top of it as a separate layer owned by your quality unit. What changes is how the FAT is planned, in three ways.
First, the register is written so that its evidence can be referenced by the qualification protocols. Where your validation plan allows it, an item executed at FAT with a calibrated instrument, a recorded result and a witness signature can be cited in the installation or operational qualification, which is the practical reason for the instrument list and the witness column. Whether your plan allows that is your decision.
Second, software category, intended use, quality risk and the available supplier evidence guide the testing effort. GAMP 5 Second Edition puts more weight on service providers, which is the situation whenever the control software on a machine is written by the machine builder. The consequence for the FAT is that functional items on bespoke sequences are scripted and evidenced.
Third, investigate quality and record-integrity deviations and document their disposition. The quality unit authorises progression under the validation plan. EU GMP Annex 15, section 2.10 permits conditional progression when a documented assessment shows that open items have no significant impact on the next activity.
The stages themselves, what IQ, OQ and PQ each prove and what evidence satisfies each of them, are on our computer system validation page.
Which FAT Mistakes Come Up Again and Again?
These are the failure modes the register is designed against, and the reason its columns exist.
- The protocol was written after the machine worked. A test written when the result is already known is a script for a demonstration. Approve the register before the internal test, then run the internal test against it.
- The criterion is a word. “Runs smoothly”, “acceptable” and “no issues” cannot be failed. Where a value is genuinely unavailable, define the behaviour instead.
- Safety testing had no defined method. Record the required operating conditions, test device, response and restart behaviour for each function. A stop demonstration alone does not validate monitored limits or the complete protective function.
- The simulation was not declared. A plant system stand-in that nobody wrote down leaves the SAT to discover what was never real.
- The deviation had no owner or date. An open item is a promise, and a promise without a name and a date beside it is a hope.
- Documentation was reviewed by email afterwards. Drawings are checked against the machine while both are in one room. After shipment the cheaper of the two to change is the drawing, and it is the one that gets changed.
- The person who could sign was not there. A test attended by observers ends with a report. A test attended by someone with authority ends with a decision.
What Are the Three Parts of a Usable Checklist?
A factory acceptance test checklist is a register, a set of deviation rules and a signature block, and the machine is only as tested as the weakest of the three. Write the register from the requirement numbers before the machine is finished, agree the classes before the test opens, and sign for a listed set of conditions on the afternoon of the test. The site acceptance test then has one job, which is to prove that the same register survives your building.