FAT vs SAT
FAT vs SAT comes down to where the test happens and what is real when it runs. A factory acceptance test (FAT) is run at the vendor's works before a control or safety system ships to site, using simulated inputs to prove the system was built and behaves per the specification. A site acceptance test (SAT) is run after that same system is installed on site, using the real field wiring, the real instruments, and the real plant it now sits inside. FAT proves the build. SAT proves the installation. Neither replaces the other, and each is only as strong as the document it was checked against, the part most explanations skip and this one covers in detail below.
Key takeaways
- FAT happens at the vendor's works before shipment, on simulated inputs. SAT happens on site after installation, on real field wiring and real instruments.
- FAT proves the system was built to specification. SAT proves the installed system works with the plant it now sits in.
- A FAT is only meaningful checked against the functional design specification and the I/O list the vendor was given.
- A SAT is only meaningful checked against the as-installed P&ID and the current I/O list, not the original design intent.
- An I/O list that changed after the vendor's cutoff means FAT passed against a superseded scope, and the gap surfaces at SAT, not before.
- A FAT punch item accepted to be closed at site becomes a SAT problem the moment it is not closed before SAT begins.
- An SIS FAT is checked against the safety requirement specification and the cause-and-effect matrix, and should not be signed off on the same basis as BPCS scope.
- Exact witness requirements, sign-off authority, and test scope are set by the project's own contract and test procedure, and vary between projects.
FAT and SAT side by side
The two tests differ on almost every practical dimension, from where they happen to what a failure costs. The table below lines them up dimension by dimension.
| Dimension | FAT | SAT |
|---|---|---|
| Where it happens | The vendor's works or system integrator's shop | The plant site, in the final installed location |
| When in the schedule | Before the system ships, ahead of mechanical completion | After installation and wiring, once the system is physically in place |
| What is real vs simulated | Field signals are simulated at the vendor's test bench | Field wiring, instruments, and final elements are the real, installed devices |
| What it proves | The system was built and configured to specification | The installed system performs correctly with the real plant around it |
| What it is checked against | The functional design specification and the I/O list issued to the vendor | The as-installed P&ID, the current I/O list, and the physical field devices |
| Who witnesses it | The buyer's engineer, sometimes a third party, at the vendor's facility | Site commissioning staff, the buyer's engineer, and often the end operator |
| What it produces | A signed FAT report and a punch list of open items | A signed SAT report, a closed punch list, and the record handed to operations |
| What a failure costs | Rework at the vendor's shop, before shipment, comparatively contained | Rework in the field, against a live schedule, comparatively expensive |
What each test is checked against
A FAT and a SAT are not free-floating exercises. Each one is meaningful only in relation to a document, and it is the document, not the test itself, that decides whether a pass actually means anything.
A FAT is run against the functional design specification and the I/O list the vendor was given at the time the system was built. If the I/O list changed after the vendor's cutoff date, a point added, removed, or renumbered, the FAT still runs, and it still passes, but it proves the system matches a scope that no longer exists. Nobody catches this at FAT, because FAT has no way to know about a change made after the vendor's copy of the I/O list was frozen. The gap sits quietly until SAT, where the current I/O list and the real field wiring finally meet the system, and the point that changed shows up unwired, misnumbered, or simply missing.
A SAT closes that gap by testing against the as-installed condition rather than the original design intent. It is checked against the as-installed P&ID, the I/O list as it stands at the time of the test, and the physical instruments and cabling in the field. This is why document drift between FAT and SAT is not a paperwork inconvenience. It is a common reason a system that passed FAT cleanly still fails points at SAT, and validating the I/O list against the P&ID before SAT is the check that catches drift early rather than during the test itself.
| Test | Checked against | The drift that bites |
|---|---|---|
| FAT | The functional design specification and the I/O list at the vendor's cutoff | A point changed, added, or removed after the vendor's copy was frozen never shows up as a failure at FAT |
| SAT | The as-installed P&ID, the current I/O list, and the physical field devices | A point that changed since FAT surfaces here first, often read as a field wiring fault rather than a document gap |
Punch items that follow you to site
Both FAT and SAT close with a punch list, the open items that did not pass cleanly and need attention before the report is signed. The punch list is where the two tests connect in practice, not only on paper.
An item found at FAT is cheap to fix while the system is still at the vendor's works, and most are. But some are accepted with a note along the lines of "to be closed at site," usually because the fix depends on something that only exists after installation, a cable length, a local panel, an interface with equipment the vendor never had in the shop. That note is reasonable at the time it is written. What it quietly does is move a FAT problem into SAT scope without anyone re-labeling it as such.
If that carried-over item is not tracked and closed before SAT begins, it resurfaces there, except now it competes for time against the SAT's own punch items and against a live installation schedule. A FAT punch item that was accepted rather than fixed does not disappear. It waits, and it tends to show up again at the worst point in the schedule to deal with it.
SIS FAT carries extra weight
Safety instrumented system scope needs its own FAT, checked against its own documents. An SIS FAT, sometimes called SIS factory acceptance testing, is checked against the safety requirement specification and the cause-and-effect matrix, not the general functional design specification that governs the basic control system. The trip logic, the voting arrangement, and the safe-state actions defined in those documents are what the SIS FAT has to demonstrate, point by point.
The reason this matters as its own line item is separation. A BPCS FAT proves the control system behaves as configured. An SIS FAT has to prove the safety functions behave as designed against the safety case, a different standard of proof against a different document set. Folding SIS points into a general FAT sign-off, or accepting them on the strength of the same walkthrough used for control scope, blurs a distinction the safety documentation exists to keep separate. Keep the SIS FAT scoped to its own specification and its own matrix, signed off on its own basis.
Why the scope a FAT proved has to survive to site
FAT and SAT are two points where a system gets checked against a document, but the plant keeps changing after both are signed off. A revision to the P&ID, a change to the I/O list, a modification made months after commissioning, none of it re-runs itself through FAT or SAT automatically. The record only stays true if whoever holds the I/O list and the drawing set keeps checking one against the other every time something changes, the same discipline that made the original FAT and SAT results mean something in the first place.
FAT and SAT sit inside a longer sequence. Mechanical completion to commissioning covers where these two tests fall in that sequence, and the commissioning loop check plan covers the loop-by-loop work that follows once the system is accepted on site.