The auditor places a part on the table. He asks: 'Show me that this part has been manufactured correctly. You open the system. Data is there. Lots of data. Machine log data, shift logs, a folder with Excel exports, a bundle of paper from the archive.
But the auditor shakes his head. Not because there is no data - but because the data that is available does not provide any evidence. They show that something was documented. They do not show what happened to this specific part.
That is the difference between documentation and traceability. And it's bigger than most manufacturing companies realize - until the first critical audit or recall.
THE MOST IMPORTANT THING IN A NUTSHELL
|
BRIEFLY SUMMARIZED
|
Both terms sound similar. In quality management, they are often used interchangeably. This is a mistake with concrete consequences.
| DOCUMENTATION | TRACEABILITY |
|---|---|
|
|
The decisive sentence: Documentation proves that a process has taken place. Traceability proves what happened to a specific part in this process. For an auditor, a lawyer or a recall coordinator, only the latter is relevant.
These five patterns look like traceability. They are not. In each of these cases, companies have the feeling that they have documented everything - until the worst comes to the worst.
The shift log documents: Machine X produced 623 parts in shift 2 on Tuesday. All test values were within the tolerance range. The log is signed, archived and can be retrieved.
What it does not do: It cannot say which of the 623 parts from this shift arrived at customer A, which arrived at customer B - and which of the parts is specifically the part with the complaint number KR-2026-0441. The shift log is an aggregated statement about a period of time. It is not proof of an individual part.
The gap: As soon as a quality event needs to be investigated at individual part level, the shift log is of no help.
The test report lists: 50 measured values, all within the tolerance range, date and signature of the inspector. What is missing: Which 50 parts were measured? The serial numbers or batch numbers are not in the report.
The log proves that parts were tested on the day in question and that the results were OK. It does not prove that the specific part with the serial number SN-00432817 was tested and was OK. In a legal dispute, this is a crucial difference.
The gap: The protocol does not contain a clear assignment of measured value to component ID. This makes it unusable as proof of traceability for an individual part.
The control system of the bolting machine saves each bolting process with torque, angle, time stamp and result. The data is available and complete. But: The time stamp is 14:23:47. The part with serial number SN-00432817 was installed at this time - but only the worker knows this, and he no longer remembers. The workpiece carrier tracking was not connected.
The result: complete process data that cannot be assigned to a specific part. Practically worthless for traceability purposes - the evidence is up in the air.
The gap: Process data and component ID were never linked. Without this link, even complete machine data is no proof of traceability.
A torque wrench is recognized as out of tolerance during regular calibration. The calibration is documented, the device is corrected and reused. Mandatory question: With which parts has this screwdriver been used since the last calibration? Which of these parts need to be checked or blocked?
If the link between the test equipment ID and the parts tested with it has not been established in the system, this question cannot be answered. Calibration documentation exists. Traceability to the affected parts population is missing.
The gap: Each piece of test equipment needs a unique ID that is saved with each test procedure. Only then is a recalibration evaluation possible.
The ERP knows the batch number. The MES knows the machine data at this time. The QMS knows the inspection results from the quality system. But all three systems use different internal designations for the same batch. A cross-system query is not possible - not because the data is missing, but because there is no common key that holds it together.
The gap: Three systems with complete data, but without a link, do not result in traceability. They result in three separate documentations.
SHORT SELF-CHECK: DOCUMENTATION OR TRACEABILITY?
Question: Can you open the complete component file for any delivery lot from the last year in under 15 minutes?
Component file = material batch + process parameters at the time of production + test result with test equipment ID + release + proof of delivery.
If yes: you have traceability.
If no: you have documentation. Well meant - but no proof.
Documentation becomes proof of traceability if it fulfills two conditions at the same time: It is assigned to a unique reference object (serial number, batch number) and it can be linked to the evidence of other systems via this object.
|
Documentation type |
Suitable for traceability? |
Condition |
|
Shift log with quantity and collective value |
No |
No reference to the individual part or the specific batch |
|
Test report with measured value + batch number |
Yes - at batch level |
Batch traceability possible, not individual part |
|
Test report with measured value + serial number + test equipment ID |
Yes - complete |
Serial traceability with recalibration option |
|
Machine data with time stamp, without component ID |
No |
Cannot be assigned to a part without external key |
|
Machine data with time stamp + linked part ID |
Yes |
Direct assignment to individual part possible |
|
ERP delivery bill with batch number |
Yes - for forward tracking |
Shows where delivered to, but no production data |
|
ERP + MES + QMS with shared batch key |
Yes - complete across systems |
Complete component file can be reconstructed across system boundaries |
|
Excel export without component reference |
No |
Aggregated data, no traceability proof |
The most common sentence I hear in quality meetings is: 'We document everything. The second most common sentence, five minutes later, is: 'But we can't say which part that was specifically. That's not a contradiction. That's the difference between documentation and traceability - and it costs companies six-figure sums in an emergency.
- Amadeus Chief Technology Evangelist, CSP Intelligence GmbH
There are three non-negotiable characteristics for traceability evidence that stands up to audit, recall and legal disputes.
The proof must be assigned to a specific reference object: a serial number, a batch number, a lot ID. Proof that is assigned to a time period, a shift or a machine, but not to the specific part being inspected, is not traceability proof.
In practice, this means that every production step, every inspection and every use of material must be stored with the ID of the object on which it took place - in real time, not reconstructed retrospectively.
'Checked on 03.03.' is not sufficient proof of time. '03.03.2026, 14:23:47, station 7, inspector ID-0042' is a proof of time. The difference is not academic: If 800 parts were tested in one day and one part was tested two hours after the last calibration of the test equipment, the second time stamp is the difference between compliance and recall.
Time-stamp based recording is now standard in any digital inspection and manufacturing environment. The problem is often that the time stamp exists in one system but is not synchronized with the part ID in another system.
A traceability record is only complete if it covers all relevant levels: material origin (ERP/supplier system), production parameters (MES/control system), inspection results (QMS/inspection software) and proof of delivery (ERP/logistics). If these four levels each have complete data but are not linked to each other, a complete component file cannot be created.
The technical solution is simpler than most people fear: A common data key - the batch number or serial number - as a mandatory field in all systems is sufficient to create the basis for cross-system traceability.
These four scenarios show how the difference between documentation and traceability affects real quality events.
1.customer complaint: incorrect screw connection
Problem: Customer reports: Screw X on component SN-00432817 with insufficient torque. Company has shift protocol: All torque values in shift 2 were within tolerance range.
Consequence: The shift report proves nothing for the specific part. No proof possible for SN-00432817. Goodwill regulation without proof, reputational damage.
Solution : With traceability: Tightening data from SN-00432817 can be retrieved in seconds. If the value is correct: proof of exoneration. If not: Cause can be identified immediately.
2nd IATF audit: Recalibration evaluation
Problem: Auditor requests: Show all parts that have been tested with test equipment PM-117 since the last calibration. Test equipment ID is in the calibration record. It is missing in the test results.
Consequence: Verification not possible. Auditor documents critical finding. Potential production stop until shutdown.
Solution: With traceability: Each test result contains test equipment ID. Query reveals the affected parts in seconds. Audit findings avoided.
3rdrecall: Defective supplier part in batch KW07
Problem: Supplier reports faulty material in batch CW07. Company must identify all customers who have received parts from this batch. ERP has delivery data, MES has batch data - but the batch number in the MES does not correspond to that in the ERP.
Consequence: Full recall necessary because the affected parts population cannot be narrowed down. Instead of 340 affected parts, 8,000 parts are recalled.
Solution: With a shared batch key in ERP and MES: targeted recall decision based on real data in under 2 hours.
4thproduct liability claim: reversal of the burden of proof according to EU Directive 2024
Problem: Claim for property damage due to suspected product defect. According to the EU Product Liability Directive 2024, the manufacturer must prove that the product was free of defects at the time it was placed on the market.
Consequence: Without component-specific process and test data: No proof of exoneration possible. Liability for damages possible despite correct production.
Solution: With a complete component file: All process parameters and test results can be retrieved as exculpatory evidence. Lawsuit can be dismissed.
The requirements differ depending on the context - but they are identical in one respect: aggregated data without reference to components is not enough.
An experienced IATF auditor typically carries out the so-called component file sample: He selects any delivered part and requests complete documentation from the raw material to the delivery document. This sample is not announced, it takes place live - and the result must be available within minutes, not hours.
The requirements of IATF 16949 section 8.5.2.1 are clear: traceability is required for all parts - and it must be possible at serial number level if this is required by the customer or the safety class of the component.
ISO 9001 is less prescriptive than IATF 16949 - it does not prescribe a specific granularity of traceability, but requires that the organization identifies and meets traceability requirements. In practice, this means: What has the customer contractually agreed? What does the product standard stipulate? What is required for a root cause analysis in the quality event? The implemented traceability must provide answers to these questions.
In the context of the EU Product Liability Directive 2024 and in civil product liability proceedings, the following applies: Evidence must be able to link the specific product that is alleged to have caused the damage to a specific production history. Shift logs, aggregated quality reports and statistical proof of process capability are not exonerating evidence for a specific part - they are evidence of process quality in general. That is not enough.
In this context, lawyers speak of 'specific proof of causality': the manufacturer must show that this part was manufactured under these conditions, tested with these results and delivered without defects. Only component-specific traceability can achieve this.
After the introduction of CSP IPM, we have not only dramatically accelerated our audit preparation - for the first time, we have the feeling of being truly traceable. Before, we had the data. Now we have the connections.
-Michael Wagner Mercedes-Benz Group AG
In most productions, the path from good documentation to genuine traceability is shorter than expected. The biggest levers are not new systems - but the correct linking of existing systems.
Decide which ID in your company will be the connecting key for traceability: Batch number, serial number or both. This ID must be defined as a mandatory field and uniformly formatted in all quality-relevant systems. No system may store relevant quality data without this key.
This is the most difficult organizational decision - and the most effective. Once this step has been taken, the rest follows.
Identify all points in the process where data is generated without simultaneously recording the component ID. Typical gaps: manual inspection stations without a barcode link, machine data without workpiece carrier tracking, paper documentation without a digital link. Close these gaps with minimal effort - a barcode scanner or a field in the existing software is often sufficient.
As soon as ERP, MES and QMS use the same key, cross-system queries are possible. The goal: It must be possible to compile the complete component file of any part from these systems in under 10 minutes - ideally automated by an integrated solution.
|
From ... |
... to ... |
Effort |
Effect |
|
Layer protocol without component reference |
Test report with batch or serial number |
Low - Form customization or system field |
Direct traceability verification at batch level |
|
Test report without gauge ID |
Test report with gauge ID as mandatory field |
Low - mandatory field in inspection software |
Recalibration evaluation possible |
|
Machine data without component linking |
Machine data with automatic ID linking |
Medium - Control/QMS interface |
Process parameters can be assigned to the individual part |
|
ERP batch ID ≠ MES batch ID |
Common batch key in all systems |
Medium - Master data harmonization |
Cross-system query possible |
|
Paper documentation assembly |
Digital worker guidance with automatic logging |
High - system introduction (e.g. CSP PG) |
Complete assembly documentation for each component |
Documentation records that a process or event has taken place - time-related, often aggregated at shift or day level. Traceability proves what happened to a specific part or batch - component-related, with reference to specific process parameters, test results and materials. Documentation is a prerequisite for traceability, but does not replace it. Without a component reference in the documentation, there is no traceability.
An IATF 16949 auditor or a judge in a product liability case requires proof for a specific part - not for a production period. Aggregated shift logs, daily reports and collective test logs show that processes have taken place. They do not prove what happened to a specific component and under what conditions. Documentation without reference to a component is not sufficient to prove exoneration in accordance with the EU Product Liability Directive 2024.
An audit trail in production is a complete, chronological and tamper-proof record of all quality-relevant events for a product or batch. It documents every production step, every inspection, every release decision and every use of material with a time stamp, operator ID and result. A complete audit trail is the technical basis for traceability and is required by IATF 16949, ISO 9001, GMP and EU MDR.
A component file is the complete, structured summary of all quality-relevant data for an individual part or a batch: material certificate and supplier certificate, all production parameters at the time of production, test results with test equipment ID, release decision with operator ID, proof of delivery with customer and date. The component file is requested within minutes during the audit. If it cannot be retrieved immediately, the traceability verification is deemed not to have been provided.
The most important step is to define a common key: the batch number or serial number must be available in all quality-relevant systems (ERP, MES, QMS) as an identical mandatory field. As soon as this common key is established, data from different systems can be merged into a complete component file. Systems such as CSP IPM can automate this link and at the same time enable cross-system queries in real time.
Traceability level describes the granularity of traceability: Level 1 (batch level) links a production batch with materials and process parameters. Level 2 (serial number level) assigns each individual part its specific process data and test results. Level 3 (complete cross-system traceability) links material records, production data, test data and proof of delivery to form a complete component file. IATF 16949 requires Level 2 for safety-relevant Class A components. ISO 9001 requires the appropriate level for your own situation.
The automotive industry in accordance with IATF 16949 has the strictest traceability requirements for series production: serial number traceability for safety-relevant components, retention obligations of at least 15 years, obligation to recalibrate evaluation and inclusion of sub-supplier traceability. Medical technology (EU MDR) has similarly strict requirements with unique device identification. ISO 9001 leaves more leeway, but here too, component-specific traceability is increasingly expected in the case of audits and quality events.