Lot Traceability Software: What It Has to Do Under Pressure
Traceability is only tested on the day a supplier calls. What forward and backward tracing actually require, where most systems break, and how to check yours.
Traceability is a system you buy for one day and evaluate on every other day, which is why most shops discover the gaps at the worst possible moment.
The day is the one where a supplier calls about a nonconforming heat lot, or a customer reports a failure in the field. The question is always some version of the same thing: where did that material go, and what else is affected. The time it takes you to answer determines whether you contain a problem or expand it.
Most manufacturers can answer eventually. The useful question is how long eventually takes and how many people it occupies.
Two directions, and they are not equally hard
Backward tracing starts with a finished part and asks what went into it. Which raw lots, which operations, which operators, which inspection results. Most systems handle this reasonably, because the record was built in that direction.
Forward tracing starts with a raw material lot and asks where it ended up. Which work orders consumed it, which finished parts contain it, which customers received those parts. This is the one that matters during a containment, and it is the one that fails, because it requires querying against the grain of how the data was written.
A shop that can trace backward in minutes and forward in days does not have traceability. It has record-keeping, and there is a difference that only shows up under pressure.
Where it usually breaks
1. The system tracks parts, not lots. Plenty of ERPs handle part numbers well and treat lot as an optional text field somebody fills in inconsistently. If lot identity is not structural, forward tracing becomes a search across free text and the answer is only as good as the discipline of whoever typed it.
2. Identity is lost at an operation. Material comes in with a heat number, gets cut, and the pieces go into a bin. If the link between the bin and the heat is a label somebody wrote, that is where the chain snaps, and it snapped weeks before anyone needed it.
3. Quality records live somewhere else. The inspection result is in the quality system, the consumption is in the ERP, and joining them is a person with two screens. During a containment that person becomes the bottleneck for the entire response.
4. Nothing records the split. One lot gets used across three work orders on two shifts. If the system only records that the lot was issued, and not the quantities against each consumer, forward tracing returns a list too broad to act on. Over-scoping a recall is expensive in a different way from missing one.
5. History is not queryable. The data exists, in the sense that a report could be written against it. Whether it is retrievable in an hour by the quality manager, without a developer, is a different property, and it is the one that matters.
Where the options land
| Approach | Backward trace | Forward trace | Realistic answer time |
|---|---|---|---|
| Paper travelers plus spreadsheets | Possible | Manual reconstruction | Days |
| ERP with lot as a text field | Usually | Unreliable | Hours to days |
| ERP with structural lot tracking | Yes | Yes | Minutes |
| Separate QMS beside an ERP | Yes, in its own scope | Only if integrated | Depends on the join |
| Purpose-built capture on your stack | Yes | Yes | Minutes |
The fourth row is worth dwelling on, because it is a common architecture and a common surprise. Two systems that each pass their own audit can still fail the question that spans them, and forward tracing is exactly that question.
The contrarian part: you probably do not need serialisation
Vendors sell serialisation, where every individual unit carries a unique identity, as the mature end state. For most mid-market manufacturers it is more granularity than the risk justifies and it multiplies the capture burden on the floor, which is where adoption goes to die.
Lot-level traceability answers the containment question for the overwhelming majority of shops. Serialisation earns its cost when a single unit failing has consequences a lot-level recall cannot bound: implantable devices, flight-critical hardware, and similar. If someone is selling you serialisation and you make brackets, ask what question it answers that lot tracking does not.
The other half of that argument: capture burden is the real constraint. A traceability scheme the floor cannot sustain produces gaps, and a chain with gaps is worse than an honest paper trail, because it looks complete.
A five-question audit
Run this as a drill, not a thought experiment. Pick a real lot number from six months ago and time it.
1. Given a raw lot, can you list every finished part that consumed it, in under an hour, without a developer?
2. When one lot is split across several work orders, does the system record quantities against each?
3. Can you join a lot to its inspection results without opening a second system?
4. If material changes form at an operation, does identity survive it?
5. Can the quality manager answer all of the above themselves?
Question 5 is the one that predicts your containment time. If the answer is a specific person who is very good at reconstructing this, you have a key-person dependency wearing the costume of a system.
Questions we get
Is this the same as what AS9100 requires? It overlaps heavily. AS9100 expects traceability appropriate to the risk of the product, and lot-level tracking is usually how shops satisfy it. The wider set of AS9100 software requirements covers the rest, including configuration control and closed-loop corrective action.
Do we need barcodes on the floor? Not necessarily, but you need capture that does not depend on someone transcribing a number. Scanning is the usual answer because it is faster than typing, and speed at the point of capture is what keeps the chain intact. If a scan is slower than a pen, the pen wins.
Our ERP says it does lot tracking. Is that enough? Test it with the drill above rather than the datasheet. Many systems technically store a lot field and cannot answer the forward question at speed, which is the only version of the question that is ever urgent.
What about supplier lots we do not control? You record what arrives and tie it to your receipt. You cannot fix a supplier's internal traceability, but you can make sure their identifier survives into your chain, which is what a containment notice from them will reference.
How does AI fit here? Retrieval helps a person find the relevant records faster, and a graph helps when the question spans several hops, like tracing a nonconformance through lots, suppliers, and work orders. Neither substitutes for the identity being captured correctly in the first place. GraphRAG is the layer for the multi-hop version, and it is only worth building on a chain that is already intact.
Where should a shop start? At the operation where identity currently dies. Every shop has one, usually a cut, a mix, or a bin, and fixing that single point often does more for containment time than a new system would.
What is next
Run the drill. Pick a lot from six months ago, hand it to your quality manager, and time the forward trace. The number you get is your actual containment time, and it is usually the most sobering measurement available for the least effort.
If the answer is days, the fix is generally narrower than a new ERP. Traceability and audit readiness is the engagement that shortens it, and it starts with capture at the point where identity is lost. Or tell us where your chain breaks and we will tell you whether it is a tooling problem or a process one.