Technology • June 23, 2026
Most procurement teams find issues with their industrial equipment after it has been deployed. A CNC machine that does not function as expected. A control panel with a wiring issue that only occurs when under load. A pressure vessel whose calibration was never completely accurate. By that point, the manufacturer’s engineers are no longer on site, your production schedule is based on the assumption that the equipment works, and what should have been a two-hour fix at the factory has turned into a multi-day problem.
The factory acceptance test (FAT) exists specifically to avoid this scenario. It is a formal verification process used in the manufacturer’s plant before equipment leaves. What makes a factory acceptance test useful is the factory acceptance test template that supports it. Not a generic checklist, but a structured document that outlines measurable performance expectations and schedules functional testing. The results are recorded in enough detail to support future discussions if questions arise months later about warranty coverage. When done properly, it protects both parties. When done incorrectly or not at all, it simply shifts the problem downstream.
This article describes what goes into a complete FAT template, how each section works in practice, and what the testing process looks like on a real-world industrial project. If you are involved in equipment acquisition, commissioning, or vendor certification, the distinction between a FAT that detects problems and one that simply generates paperwork is usually determined by how the document was created.
A factory acceptance test is a formal verification procedure conducted at the manufacturer’s facility, typically with the customer or their appointed representative present. Its purpose is to confirm that the equipment or system meets the agreed-upon specifications, functional requirements, and contractual specifications before it ships.
FAT is not the same as the manufacturer’s internal QA process, and conflating the two is a common and costly mistake. Internal quality checks verify that components were assembled correctly. A factory acceptance test verifies that the complete system behaves the way the customer actually expects it to under realistic operating conditions. One is about build quality; the other is about whether the right thing was built.
What makes FAT meaningful, as opposed to a shipping inspection or a quick demo, is the testing procedure itself: agreed upon by both parties in advance, executed in a controlled environment, and documented in enough detail that the results mean something six months later when something goes wrong.
FAT and site acceptance test (SAT) are frequently confused, but they serve different purposes and take place at different stages of the project. Understanding the distinction matters because the risks associated with each are completely different.
Both tests follow a structured checklist approach and share a broadly similar format. But the contract specifications and testing scope are not interchangeable. SAT typically includes integration tests with existing infrastructure connecting to live systems, verifying data flows, confirming performance under real operating loads that cannot be replicated at the supplier’s facility. What FAT can catch is component-level and system-level behavior in isolation. What it cannot catch is how that system performs once it is embedded in your environment.
There is no single universal factory acceptance test format that applies across all industries. But any FAT document worth using will share certain core elements. Here is a detailed guide to what a complete, professional template looks like and why each section earns its place.
The cover page establishes the formal identity of the document. It needs to capture the following:
This section tends to get treated as boilerplate. It is not. When a warranty claim surfaces eight months after delivery and no one can agree on which revision of the specification was in force during the FAT, a properly completed cover page is the thing that settles the dispute.
Every FAT document needs a clear list of the reference documents that govern the test:
This section serves two functions. First, it defines what the testing procedure is measuring against. Second, it pins down which version of each document is authoritative. A disproportionate number of post-FAT disputes come down to one party having tested against a superseded drawing. Getting document revision numbers on record before the test starts costs almost nothing; not having them on record can cost a great deal.
Before any functional tests begin, certain preconditions need to be confirmed. These are the conditions that must be in place for the test to produce valid results.
If a precondition fails, the FAT process should pause. Equipment that has not met its pre-conditions does not produce useful data, it produces noise. Both parties waste time, and any results generated are of questionable value regardless of whether they look good on paper.
A dedicated documentation verification section confirms that the paperwork side of the delivery is complete before physical testing starts:
Document verification gets treated as a formality more often than it should. Missing technical docs are one of the most consistently recurring issue list items found at SAT after the equipment has shipped, after it is on-site, after fixing the gap requires international logistics instead of a printer.
This is the core of any FAT. The functional tests section is where you verify that equipment functions correctly under each operating condition specified in the contract. It should be organized by system or function rather than by individual component, so the test flow reflects how the equipment will actually be used.
Each test entry in the FAT checklist should capture:
Here is a simplified example for an industrial control panel:
The functional tests section is where precise performance requirements pay off. ‘Operates normally’ is not a criterion, it is a placeholder for an argument. If equipment meets a defined, measurable standard, there is nothing to dispute. If it does not, the FAT report tells you exactly what failed and what was expected. Vague criteria give neither party anything useful to stand on.
Safety checks belong in their own dedicated section, not folded into the functional tests. Equipment that passes every performance test but fails a safety verification cannot be accepted and the FAT protocol needs to make that clear structurally, not just as a footnote.
The issue list is the section that generates the most anxiety during a FAT and the most value after it. Every item found to be incomplete, incorrect, or requiring further attention during the FAT process gets captured here. An honest, detailed issue list is not a sign that the FAT went badly. It is the sign that the FAT worked.
Each issue entry should include:
Critical items are failures that prevent acceptance outright, the system does not meet its core functional requirements, or it presents a safety risk. Major items need to be resolved before shipment but do not necessarily block a conditional acceptance. Minor items: cosmetic issues, minor documentation gaps can typically be resolved before or shortly after delivery without holding up the process.
The final section pulls everything together: completed tests, passed tests, failed tests, and the current status of all issues. Three outcomes are possible:
The acceptance statement should be signed by the customer representative and the manufacturer’s authorized signatory. This is the moment the FAT is formally completed successfully or not. Both parties should leave with a signed copy in hand, not with the understanding that one will be sent later.
Templates make more sense when you see them in motion. Here is a condensed walkthrough of a FAT for a real-world industrial scenario a centrifugal pump skid procurement for a water treatment facility.
The facility has ordered three identical pump skids. Each includes the pump, motor, variable frequency drive (VFD), local control panel, instrumentation, and piping to the skid boundary. The FAT takes place at the supplier’s facility over two days, with the customer’s project engineer attending in person.
Before anyone starts the testing process, both sides align on scope: which tests will be run, in what order, who witnesses each step, and how results get recorded. This alignment conversation is not a formality, it is the thing that prevents scope disputes mid-test.
Day one starts with documentation verification. The customer’s engineer works through the as-built wiring diagrams against the approved revision, checks calibration certificates for the pressure gauges and flow meters, and confirms VFD motor parameters.
Three issues surface before testing even starts: an expired calibration certificate, a wiring diagram on an older revision, and a missing spare parts list. All three go on the issue list immediately. This is exactly the kind of thing documentation verification is for, catching gaps while fixing them is still straightforward.
The preconditions check clears without issue. All three skids are fully assembled, utilities are connected, safety guards are in place. Functional tests begin.
The pump starts cleanly, ramps to speed through the VFD without fault, and hits specified flow and pressure within 2% of design specifications. Instrumentation reads correctly. The local control panel responds as designed.
One test fails: the high-temperature shutdown does not trigger at the specified set point. Investigation finds the temperature switch was misconfigured at the factory. This is a meaningful catch, a switch set wrong in a controlled test environment is a nuisance; the same switch set wrong in a live facility is a potential equipment loss. The switch is adjusted on the spot, retested, and signed off by both parties before moving on.
The remaining two skids clear testing without significant issues. The expired calibration report is replaced, the current version was on file, just not included in the package. The wiring schematic is corrected and reissued. The spare parts list arrives in the required format.
By end of Day 2, every issue is either resolved or has a committed corrective action with a specific date. The customer’s engineer signs the acceptance statement. Equipment is cleared for shipment.
This is what a FAT is supposed to look like: a misconfigured switch and three documentation gaps caught in a controlled environment rather than after installation. The cost of fixing all four issues at the factory was measured in hours. The same issues discovered post-delivery would have been measured in days and project schedule risk.
Even well-planned FATs run into trouble. These are the most common problems and what actually helps.
The most reliably contentious element of any FAT is poorly defined performance requirements that were never precise enough to be tested. If the FAT protocol says the system should operate as specified without defining what specified means in measurable terms, flow rate, pressure, response time, noise level, then every borderline result becomes a negotiation. And those negotiations happen on the factory floor, under time pressure, with travel already booked.
The fix is simple in principle: define success criteria during the specification phase, alongside the technical requirements, not the week before the test. Both parties need to agree in writing on what a passing result looks like for each individual test before the FAT begins. Once that agreement exists, the test either meets the standard or it does not. There is nothing to argue about.
It is not unusual for a customer’s representative to arrive at the FAT with additional tests in mind, or concerns about performance areas that were never in the original scope. Handled informally, this leads to delays, resentment, and disputes about what the test was actually supposed to cover.
The FAT protocol, finalized and signed off before testing begins, is the agreed scope of the procedure. Specific tests, specific acceptance criteria, defined in advance. If the scope needs to change, a formal change order is the mechanism. It is not a bureaucratic obstacle; it is the thing that keeps the FAT from expanding indefinitely and protects both parties when there is a disagreement about what was tested.
Sometimes a test fails and the root cause takes longer to diagnose than anyone planned for. The FAT stretches. Travel costs accumulate. Delivery schedules come under pressure. Without any agreed-upon framework for handling this, it can get adversarial quickly.
The right time to define what happens when a test fails is before the test, not during it. The contract should address which party absorbs extended travel and accommodation costs, and how delivery schedule adjustments are handled if the FAT cannot be completed within the original window. Neither party enjoys that conversation upfront, but both parties benefit from having had it.
FAT reports that are incomplete, unsigned, or simply hard to locate six months later create real problems during audits, warranty claims, and maintenance activities. The documentation that felt trivial to chase down at the end of a long test day turns out to be exactly what is needed when something goes wrong.
Using a consistent format for all FAT protocols, ensuring everything is signed before anyone leaves the facility, and distributing the final report within a defined timeframe, typically within a week, are straightforward practices that make a significant difference. Both the supplier and the customer need a complete set of signed documentation. Not a draft. Not a promise that one is coming.
In organizations where FAT has become purely procedural (show up, watch a brief demonstration, sign the report, leave) the test provides the appearance of verification without the substance. This is not a documentation problem; it is a resourcing problem. Sending someone to witness a FAT who does not have the technical background to evaluate what they are seeing produces nothing of value except a signature.
The customer’s representative at a FAT should be an engineer, or at minimum someone with enough technical familiarity with the equipment to recognize when something is off. That is the whole point of having a witness present.
For teams building FAT test documentation from scratch, the following is a standard format reference adaptable to specific project requirements. The structure below covers the vast majority of industrial equipment FATs.
Complex systems, large SCADA implementations, process plants, multi-skid installations, may require additional sections or sub-sections within functional tests. The same format scales from a straightforward pump skid to a complete manufacturing line; what changes is depth, not structure.
FAT requirements are heavily industry-dependent. Some sectors have mandated testing procedures, specific documentation requirements, and regulatory representatives whose attendance at certain tests is not optional. Understanding which framework applies to a given project is a critical step not something to work out after the purchase order is placed.
In pharmaceutical, nuclear, and aerospace applications, FAT documentation is part of the formal quality control record. Regulatory standards define what must be tested, who must witness it, and how long the records must be retained. In these environments, designing the FAT document to meet compliance standards from the outset is not optional. It is a fundamental project requirement.
All inspection tools used during a FAT must have current calibration records traceable to national standards. This requirement is non-negotiable under most quality assurance frameworks: if traceability cannot be established, the test results are invalid. FAT documentation should list every instrument used, including instrument ID numbers and calibration references, so the measurement chain can be reconstructed if it is ever questioned.
Certain tests in regulated industries require the presence of an independent third-party witness: an accredited inspection body or regulatory representative whose sign-off carries legal or compliance weight. These arrangements need to be confirmed well in advance. Independent inspection schedules do not bend to accommodate last-minute requests, and a FAT that cannot proceed because a required witness is unavailable is an expensive and entirely avoidable problem.
A template is only as good as the process around it. Here is what actually makes the difference between a FAT program that catches problems and one that generates paperwork nobody ever revisits.
Start the FAT Protocol Early
The FAT template should not be something you pull together the week before the test. Build it during the contract and specification phase, alongside the technical requirements. The reason is simple: acceptance criteria are much easier to agree on before the supplier has built anything. Once the equipment exists, both sides have positions to defend. Before it exists, you are just writing down what the thing needs to do.
Share the Draft with the Manufacturer Early
Send the draft FAT checklist to the supplier shortly after the purchase order is placed not as a courtesy, but because they will often flag things you missed. A test that requires special test rigs, a criterion that the specified configuration physically cannot meet, a sequence that assumes capabilities not in scope. Better to find those gaps at the draft stage than on the day, when fixing them costs everyone time and money.
Designate a FAT Coordinator
On complex or multi-day FATs, someone on the customer side needs to own the process end to end. Not just attend but own it. Track the issue list in real time, chase documentation, make sure nothing gets left unsigned before the team disperses. Without that person, the last two hours of a long test day tend to get messy: items go unrecorded, signatures get promised rather than collected, and the follow-up drags on for weeks.
Photograph Everything
Most FAT frameworks do not require photographs. Take them anyway. Nameplate data, wiring configurations, instrument readings, test setups — things that are obvious on the day and completely ambiguous six months later when a warranty question comes up. A photo taken in thirty seconds at the factory can settle an argument that would otherwise take weeks.
Do Not Skip the Closing Debrief
Before anyone leaves the facility, get thirty minutes with the supplier’s team. Go through the open punch list items, confirm who owns each one, agree on dates, and establish when the final FAT report will be issued. It feels like an optional wrap-up. It is not. The alternative is weeks of follow-up emails where everyone has a slightly different recollection of what was agreed.
Yes, by mutual agreement, as specified in the contract. It happens most often with standard off-the-shelf industrial equipment with a well-documented reliability record, or when schedule pressure is severe enough that both parties accept the risk. The problem is straightforward: any issue that would have been caught in a controlled environment will instead surface after installation, where it is harder to diagnose and significantly more expensive to resolve. For critical systems or high-value new equipment, waiving the FAT is a bet that the supplier’s internal QA caught everything. That bet occasionally pays off. When it does not, the costs tend to be memorable.
Both parties should hold a complete signed copy. The supplier typically issues the final doc, but the customer’s representative should not leave the facility without a full set of signed documentation not a draft, not a verbal commitment that one will follow. Electronic distribution is acceptable. What matters is that both sides have the complete set in an accessible location, not filed somewhere that requires archaeology to locate six months later.
Simpler equipment can often be covered in half a day. A complex control system, large process skid, or system with extensive safety logic may take several days of testing. As a planning assumption, build in a buffer of around 30% over the estimated duration. FATs reliably uncover something that needs attention. Insufficient time creates pressure to rush through tests or accept marginal results neither of which is the point.
The main components of an inspection are visual and dimensional: does the equipment appear proper, are all parts present, and do the measurements match the drawings? A FAT is a performance verification, which determines whether the equipment truly performs as intended while powered on and under load. Both are needed at different phases in the majority of industrial undertakings. The FAT verifies the behavior, while the inspection verifies the construct.
They can, to a certain extent. During 2020–2021, remote FATs became much more prevalent and have continued to be used in situations when travel is logistically challenging. Remote FAT is frequently feasible for equipment where visual verification covers the majority of the testing process. In-person interaction is hard to replace for systems that need careful observation of fleeting behavior, hands-on intervention, or real-time debugging when something unexpected occurs. Demand thorough real-time video coverage of all test activities and digital transfer of documentation as it is created, not a summary delivered later, if a remote FAT is the only available alternative.
Since this is a contract question, it must be addressed in the contract prior to the test. The usual choices are either rejection of the item and replacement, delivery schedule extension with corresponding penalty terms, or conditional acceptance with a recorded commitment to corrective action. The degree of the failures and what the parties have already agreed upon will determine which course is best. Negotiating these parameters under time pressure after a test failure, when everyone’s expenses are mounting, yields worse results than having the discussion at the contract stage.
Sufficiently thorough to eliminate the possibility of interpretation. If the order specifications require 500 GPM at 150 PSI, the FAT protocol should test against those defined values. It should also have a defined measuring method and stated measurement constraints, such as ±2%. Interpretive criteria allow performance issues to be discussed rather than resolved. When something goes wrong after installation, you must rely on the benchmarks created during the FAT. That benchmark isn’t a benchmark unless it’s accurate.
Although ISO 9001 does not directly specify factory acceptance testing, it does require organizations to ensure that externally supplied goods and services meet their specifications. FAT is one of the most used approaches for demonstrating verification. This type of gap is discovered during audits of ISO 9001-certified organizations that routinely acquire critical equipment without comprehensive acceptance testing. FAT is particularly needed as part of the quality assurance framework in various industry-specific ISO 9001 standards, including those for oil and gas, pharmaceuticals, and automobiles.
Continuous improvement (kaizen) has changed manufacturing with its focus on ongoing, small improvements. Derived from ‘kai’...
Technology
Defects in production are found everywhere and are a big problem for workers, production and,...
If you’ve ever walked onto a shop floor and thought “something is not aligned” but...