The system-of-record matrix

What it is, and what it is not

The system-of-record matrix is a table with one row per object and four columns: which system masters it, which direction it moves, what triggers the move, and what happens when both systems hold different values. It is configuration, it is visible in the product, and it is published on this site per connector.

It is not an integration diagram. A diagram showing PLM and ERP with a two-headed arrow between them communicates nothing that matters, because the whole difficulty lives in the direction of that arrow field by field.

It is also not a one-time decision made during implementation and then forgotten. The matrix is the connector's configuration at run time. Change a row and the behaviour changes; there is no second copy of the intent living in someone's implementation notes.

The four columns, and why each exists

Master names the system of truth for that object. Exactly one, never both. An object with two masters is a data-loss incident waiting for a scheduling coincidence.

Direction says which way values move. It is not implied by the master: an ERP-mastered field still flows into Manufacturing PLM so engineers can see cost on a BOM, it flows read-only.

Trigger says when. On release, on a schedule, on demand, or on a webhook. “Continuously” is not a trigger — it is a way of avoiding the question, and it is how integrations end up firing during a month-end close.

Conflict rule says what happens when the two systems disagree despite all of the above. Somebody will edit the published BOM in the ERP; the question is only whether the system tells you, or overwrites it at 2am and lets you find out from a shortage report.

The failure it prevents

The classic failure looks like this. PLM publishes the released BOM to the ERP on Monday. On Wednesday a planner adds a packaging line directly in the ERP, because that is where packaging has always been maintained and nobody wrote down that it moved. On Friday, PLM republishes after a minor change and the packaging line disappears.

Nothing errored. Both systems did what they were configured to do. The line reappears the following week when someone re-adds it, disappears again, and after the third cycle the site stops trusting the integration and starts maintaining the ERP BOM by hand — which is the outcome the project existed to prevent.

A published matrix makes that conversation happen in week one, when it is a configuration decision, rather than in month four, when it is a rollback.

How it meets the rest of the product

Fields the matrix marks as ERP-mastered render read-only everywhere in Manufacturing PLM — greyed, labelled with the owning system, and not editable even by an administrator. The interface does not offer an action that the next sync will undo.

The audit trail records every sync as an attributed write, so “who changed this cost” has an answer that names a system and a run rather than trailing off. Reconciliation tasks appear in the same work queue as everything else, not in a separate integration console nobody opens.

Agents read the matrix too. The Cost Agent knows that cost is ERP-mastered and will not propose editing it; it proposes a change to the structure that drives the cost instead. An agent that did not know the ownership rules would cheerfully recommend impossible actions.

How it meets your ERP

The default matrix is the same across all six connectors, because the underlying question does not change between vendors. Item identity and the released BOM master in Manufacturing PLM. Cost, on-hand, lead time and the supplier record master in the ERP. CAD geometry masters in the CAD system. MBOM ownership is the one genuinely contested row, and it is decided per tenant rather than assumed.

What differs per connector is shape, not ownership: NetSuite takes a dated BOM revision, SAP S/4HANA takes an engineering change with a valid-from, Dynamics 365 Business Central takes a revision record, Epicor and Acumatica take their own equivalents. Each connector page publishes its own field map alongside the shared matrix.

Item identity matching is the row that causes the most work in practice, because the ERP will hold items Manufacturing PLM never created — purchased consumables, packaging, services. Matching runs on manufacturer part number first, internal number second, and unmatched items are surfaced for a human rather than merged on a fuzzy score.

Where the boundary is

Manufacturing PLM has no ERP functionality and is not trying to acquire any. No general ledger, no accounts payable or receivable, no invoices, no sales orders, no purchasing transactions, no inventory movements. Those belong to the ERP and the matrix exists to keep that line legible.

The matrix also does not resolve organisational disagreements. If engineering and operations both believe they own the MBOM, Manufacturing PLM will make the disagreement explicit and refuse to guess — which is useful, but it is not the same as settling it.