Connecting the BOM to the ERP: the 4 possible architectures, and the one that lasts
Published 20 September 2026 — between design and purchasing, the bill of materials changes system. It's the most fragile crossing in the whole chain, and the one projects address last. The four ways to make it, what each really costs, who must be authoritative over what, and the six traps that break an interface six months after go-live.
The problem, put simply
The bill of materials is born in design and consumed in purchasing and production. In between, it crosses a system boundary: PDM or PLM on one side, ERP on the other. That crossing is the most fragile point in the whole product-data chain, for one simple reason: the two systems aren't talking about the same object.
On the design side, the basic object is a file describing a part. On the ERP side, it's an item you buy, stock and cost. An item can exist without a file — a surface-treatment service, for instance — and several files can describe one item. Until that distinction is settled, no interface will hold.
The 4 architectures, worst to best
This progression isn't a maturity ladder you must climb at all costs. An SME with a stable product lives very well on architecture 3, and many exhaust themselves aiming for 4 without needing it. Architecture 1, on the other hand, always ends up costing more than its replacement — the only one I systematically advise against keeping. I describe a real case, with a forgotten line, extra parts purchased and a delayed prototype, in five PLM problems from the field.
Who is authoritative over what
This is the structuring decision, and it's taken before any interface development. Here's the split that works in the vast majority of cases:
One simple rule follows: a piece of data has exactly one owner, and the other system displays it without being able to change it. As soon as two systems can write the same field, divergence is only a matter of time — and nobody will be able to say which value is right.
The 6 traps that break an interface
- 1. Items with no file. Surface treatments, services, raw material by the metre: they exist in the ERP and nowhere in design. The interface must accept them in a BOM without looking for a matching file.
- 2. Units of measure. CAD counts occurrences, the ERP counts grams, metres and litres. Without an explicit conversion table, the first bead of glue corrupts the BOM and, in turn, the requirements calculation.
- 3. Deletions. Every connector can create and update. Many can't cleanly remove a line dropped from the design — it then lingers in the ERP and keeps getting ordered months later.
- 4. Revisions. What does the ERP do when a part moves from revision B to C? A new item, or the same item with a changed revision? Both choices are defensible; not deciding isn't, and it produces parts built to the wrong revision.
- 5. Transfer timing. Pushing a BOM as soon as it's created fills the ERP with drafts. The right trigger is approval, that is a workflow state — not a manual action someone forgets.
- 6. Duplicate items. Without a single shared numbering rule, the same part enters the ERP twice under two references. It's the most visible symptom of uncontrolled part numbering, and the costliest in purchasing.
When I'm asked to fix an interface that "stopped working", the problem is almost always one of these six — and it was there from day one. It only surfaces with the first real case that steps outside the demo scenario.Mohamed Omar Baouch
The implementation sequence
- Align part numbering on both sides. Without a common, reliable identifier, everything else is pointless.
- Write the ownership matrix field by field, and have both departments approve it. One page is enough; it's the page that saves six months of argument.
- Define the trigger for the transfer and what happens on failure. An interface that fails silently is worse than manual re-keying.
- Test on the awkward cases, not on a clean BOM: item without a file, multi-body part, consumable by the gram, deleted line, revision change.
- Start with one product family for a quarter before rolling out, as with any data migration.
FAQ
Should the eBOM or the mBOM go into the ERP?
The ERP needs the manufacturing BOM, since it drives purchasing and production. The real question is where the mBOM is built: on the PLM side then transferred, or on the ERP side from the received eBOM. Both work, provided the choice is written down — see eBOM vs mBOM.
Should the integration be bidirectional?
Rarely. A downward flow from PDM/PLM to the ERP, plus a read-only return of a few items useful to engineering — stock, price, supplier — covers the vast majority of needs without creating write conflicts.
How long does building an interface take?
Technical development is rarely the longest item. What takes time is aligning part numbering and settling the ownership matrix — organisational work counted in weeks, sometimes months.
Can you do this integration without a PLM?
Yes, in architectures 2 and 3: a well-configured PDM is enough to push a reliable eBOM into the ERP. PLM becomes necessary when both BOMs must stay linked and changes must be assessed across departments.
How do I know whether my current interface is reliable?
Take five products at random and compare the BOM on both sides, line by line. Then change a part in design and time how long it takes to appear correctly in the ERP. Those two measurements are worth any audit.
The one-line summary: an interface isn't built, it's decided. The ownership matrix fits on one page, and that page determines whether your project succeeds.Mohamed Omar Baouch