Software · Cloud
Data · AI
Some disagreement between OEM and manufacturing-partner records is legitimate. A practical way to separate timing gaps from real exceptions, and to assign who resolves what and on what evidence.
Back to GuidesAn OEM and its manufacturing partner each keep records of the same orders, materials, production runs, and shipments. When those records disagree, the first mistake is to assume one side is wrong. Some disagreement is legitimate, and the practical task is to tell it apart from a genuine exception, then decide who resolves what and on what evidence.
This guide stays at the level of records, identifiers, rules, and ownership.
The OEM's ERP may hold the order and the expected receipt. The partner's systems may hold the production status, the inventory position, and the shipment. If your network involves them, quality records and transportation records add further views of the same product. Each system can be internally consistent and still disagree with the others.
To see whether this describes your situation, take one recent order and pull the OEM's record and the partner's record side by side. Count the fields that differ, and note whether the difference is a value, a timestamp, a unit, or an identifier that does not match at all.
The consequences to watch for are reconciliation errors, uncertainty about inventory, and rework. Test each against your own history instead of assuming it applies.
In a NIST account of standardizing data exchange among food-supply-chain partners, the work started with extracting and reconciling information exchange requirements from various sources. NIST reported that informal statements about product failure had to be interpreted into software-implementable data specifications. It also described needing to clarify how to codify lot, job and serial numbers in a production run.
Terminology is another constraint. NIST described mismatches with existing terminology and said its experts had to reconcile the differences between usage specifications across industry sectors.
The GS1 Global Traceability Standard frames the underlying need. It describes globally unique identification of products, locations and parties as part of the foundation for standards-based traceability. It also says that user-specific, non-standard extensions should be avoided whenever possible because they add complexity and cost for other parties and reduce interoperability.
Beyond the data itself, you face constraints that no source here can size for you: who owns each record, who may see which fields, how much integration capacity each company has, and how much operating change each team can absorb.
No single approach fits every network. Compare these on your own facts:
GS1's layered framework offers a useful analogy for this choice. It describes a framework whose core covers base requirements, which can be extended with sectoral and regional layers, and it notes that the framework supports hybrid implementation, combining GS1 standards with non-GS1 standards or legacy solutions. It also says the conditions and rules for applying non-GS1 standards must be precisely defined to prevent duplicate solutions for the same business need. In practice, that argues for agreeing on a core set of shared records first and extending only where a specific need requires it.
Each approach shifts effort rather than removing it.
Whichever approach you choose, treat data quality, sensitivity, and access as design questions to settle with your partner.
The three steps below turn a vague "our records don't match" into something your teams can run.
1. Define shared identifiers and comparison rules. Decide which identifiers both companies will use for orders, items, lots, and locations, and which fields get compared. GS1 lists prerequisites for judging a traceability system, including which traceable objects are in scope and what precision level each requires, and which locations, suppliers, and customers are in scope. Ask the same questions of your own network before comparing anything.
2. Distinguish timing differences from true exceptions. Write down which differences are expected to resolve on their own, such as a shipment recorded by one party before the other, and how long you will wait before treating a difference as an exception. Anything outside that window becomes a work item. Set these windows from your own operating cadence; do not borrow someone else's numbers.
3. Assign resolution and evidence responsibilities. For each type of exception, name who investigates, who decides, and what evidence settles it, such as a receiving record, a production log, or an inspection result. Separate the person who sees the signal from the person with authority to correct a record. Define these roles for your own operating model instead of assuming a department owns them by default.
For an owner or operating manager, a useful first pass takes a few weeks of review, not a platform decision:
The sorting tells you which approach to evaluate. If most differences are identifier mismatches, the fix lies in shared identifiers and rules. If they are mostly timing, the need is a clear waiting window and a shared view. If they are real exceptions with unclear ownership, the gap is responsibility and evidence before it is software.