An audit request arrives. A customer — pharmaceutical, food, personal care — needs you to reconstruct the material and cost history for a job that ran six weeks ago. They want to know which substrate lot was on press, what the actual yield was, whether there was a mid-run roll swap, and what happened to the partial roll that came off at the end of the shift. They want it in a day.
You open three systems.
What you find in the next few hours will tell you less about that job and more about which of your three records your shop has quietly agreed to treat as the truth — and whether the other two systems know that.
The job, on paper
Start with what the MIS knows. In CERM or a comparable system, the job record is detailed: substrate spec, roll IDs if they were assigned, press parameters, planned versus actual run length, waste percentage, and the cost rollup that closes the job. This is the record built by and for production. It models the job the way a converter thinks about a job.
Now open the ERP — NetSuite, Business Central, Dynamics, whichever. The ERP knows a different version of the same job. It sees a work order, material consumption postings, and a finished-goods receipt. The substrate was consumed. An inventory transaction moved it from raw material to WIP. A cost posting closed against the job. The numbers may even match the MIS totals.
Then open the warehouse system, or whatever serves that function - a WMS module, a spreadsheet log, a clipboard at the dock. Here the substrate started its life in your facility: received against a purchase order, assigned a lot number, possibly scanned to a rack location.
Three systems. Three versions of the same material moving through your building. Now try to answer the customer's question.
Where the chain breaks, and why
The gap between records rarely announces itself. No error message fires. No dashboard turns red. The divergence happens quietly at the handoffs between systems, and it accumulates.
The roll that was never fully closed out
The press run consumed four rolls of substrate. Three were consumed completely. The fourth was split mid-run — not because anything went wrong, but because the shift ended, the press was set up for a different job, and the partial came back to the floor. In the MIS, the job was closed with planned consumption figures adjusted for the actual count. In the ERP, the backflush posted the full planned quantity because no one triggered a partial-return transaction at the time. In the warehouse log, the roll may or may not have been scanned back to a location — that depends on whether the floor crew had a scanner, whether the WMS was reachable from the press area, and whether anyone remembered.
Six weeks later, the ERP says that roll was consumed on this job. The warehouse log may show it was later issued to a different job. The MIS has a yield figure that doesn't quite reconcile with either. None of the three systems flagged a discrepancy, because none of them had full visibility into the other two.
The substrate swap no one documented
Mid-run substrate swaps happen. A roll ends unexpectedly short. The specified lot isn't on the floor. The press operator grabs a roll from the same stock, same spec, different supplier lot. This is a judgment call made at the press, not a system event. In the MIS, the job record still shows the originally planned substrate. In the ERP, consumption was posted against the planned material. In the warehouse, the substitute roll may or may not have been scanned out against this job.
The audit question — which substrate lot was on press? — now has an answer that no system can give you with confidence. The person who made the swap may remember. They may not. The lot linkage, once broken, is not recoverable from the records alone.
The rework job that wasn't a job
A portion of the finished goods came back from QC. Label version error — a minor text change had not made it to the approved artwork file used on press. The affected labels were re-reeled and held. Corrections were made. The re-reeled stock was re-inspected and released.
This is rework. In the ERP, the finished-goods receipt for the original job still stands. No new job number was opened in the MIS because the rework was handled informally, as a floor correction rather than a production event. The inventory record reflects the corrected quantity, but there is no documented path from the original press batch to the rework event to the released goods. The audit trail from approved artwork version to specific substrate lot to press batch to finished pallet — the chain an auditor for a pharmaceutical folding carton customer will expect to walk — ends at the original job close.
When the scope of a potential recall depends on resolving these genealogy links precisely, unresolved links force the assumption that every lot potentially touched is affected. The containment boundary expands. Days, not hours.
The two ERP failure modes that need different fixes
It's worth separating two problems that look similar but aren't.
The first is missing data lineage. When data moves between modules — from inventory to WIP to finished goods, or from MIS cost posting to ERP journal entry — the logic applied in the transformation is often not recorded. You can see the input and the output, but not the rule that connected them. Even when all the individual logs exist and nothing has been deleted, you cannot reconstruct the reconciliation between an MIS job cost posting and the corresponding ERP inventory transaction. The records are there. The path between them is not.
The second is record overwriting. Some ERP configurations preserve the current state of a transaction but not its edit history. A lot quantity that was adjusted post-production, a yield figure corrected after the job closed — the number visible today may not be the number that was posted originally. There is no indication an edit occurred.
These require different interventions. The first is an integration design problem — the mapping logic needs to be recorded, not just executed. The second is a configuration and access-control problem. Diagnosing which one you're facing matters before you start building a fix.
Where Business Central localises the problem
If your ERP is Business Central, two failure points are worth understanding specifically.
Mixed item tracking configurations can cause warehouse activity to fail silently. A substrate lot tracked at receipt may trigger a tracking-mode mismatch when moved to a production floor location or returned as a partial. The system may require a manual override — and that override leaves no scan record. The lot link exists at receipt and at consumption, but the movement between them is invisible.
Receiving-dock label incompleteness is the upstream version of the same problem. If the roll label at receipt does not carry the supplier lot number in machine-readable form, every downstream lot reference depends on human entry. Human entry introduces the possibility of error at the one point where the chain starts. Everything downstream inherits that uncertainty.
The audit reveals which record you trust
Here is the more useful framing: the audit request is not the problem. It is a test of something that was already true before the request arrived — which of the three records is treated, in practice, as the authoritative version of what happened.
In most converter operations, the answer is implicit and inconsistent. The MIS job record is authoritative for production and costing. The ERP is authoritative for finance and inventory. The warehouse system is authoritative for location and lot at receipt. No one has decided which wins when they disagree, because the disagreement was never visible until someone asked.
That question — which record is the truth? — is the one worth answering before the next audit request, not during it.
For plant managers, the practical implication is in floor procedures: partial-roll returns, mid-run material swaps, and rework events need to be treated as system transactions, not floor accommodations. If it doesn't create a record, it didn't happen, as far as every future question is concerned.
For quality leads, rework in particular deserves explicit process design. A re-reel, a repack, a label correction — each one is a genealogy branch. Without a documented branch, the recall boundary cannot be drawn precisely. The cost of imprecision is a wider containment scope and a longer resolution.
For IT and integration owners, the gap between a MIS system built to model a converter job and an ERP built to model a financial transaction is not a configuration problem that gets closed once. It is a structural difference in how the two systems think about the same event. The integration layer — wherever that handoff happens — is where the business's actual traceability either holds together or doesn't. The logic applied there needs to be recorded, not assumed.
A note on regulatory direction
Converters printing food, pharmaceutical, and personal care packaging are already fielding traceability questions from their customers as FSMA 204 expectations and equivalent EU frameworks move toward event-level records. The expectation is not that converters become the record-keeper for their customers' compliance — it is that the records a converter can produce about a job are consistent, connected, and quickly accessible. Audit requests that take days instead of hours are a signal, not a one-time inconvenience.
The gap between what the three systems hold and what a connected chain of records would look like is measurable. Understanding where your specific breaks are is the starting point for closing them.
If you're not sure which of your three systems wins when they disagree, that's worth a conversation. We're happy to look at a specific integration point or audit scenario with you — no commitment required, just a direct discussion of what you're working with.