What this is
A spreadsheet. One row per field that moves between the two systems, and each row carries four things: the field, the owner, the direction it flows, and the rule for what happens when both sides write.
It won’t fill itself in, but it’ll save you designing the sheet from scratch.
Why a matrix, and not a decision
Almost every integration project contains one sentence, usually in the first week: “the ERP is our source of truth.” Everybody nods, because it sounds like a decision. It isn’t one.
Source of truth isn’t a property of a system at all. It’s a property of a field — and answering it at the system level gives you one of two outcomes: a storefront nobody buys from, or orders your ERP won’t accept.
Take the item number. The ERP owns it, and it has to: every downstream process keyed on it — purchasing, receiving, costing, the general ledger — breaks if the storefront invents its own. Now take the product description. If the ERP owns that, here is what a buyer reads on your website: BRG,BALL,DEEP GRV,6205-2RS. Written by a purchasing agent, for a purchasing screen, in the 1990s. Correct, useful internally, and it will not sell anything to anybody.
Two fields, two completely opposite answers, in the same integration.
The matrix, as the video fills it in
| Field | Owner | Direction | Conflict rule |
|---|---|---|---|
| Item number | ERP | ERP → commerce | ERP always wins. Commerce never writes it |
| List price | ERP | ERP → commerce | ERP always wins |
| Contract price | ERP | resolved on demand, cached | Never recomputed in commerce |
| Credit status | ERP | ERP → commerce, checked at checkout | ERP always wins |
| ATP / availability | ERP | ERP → commerce | ERP always wins. Absence is never written as zero |
| Unit of measure and conversions | ERP | ERP → commerce | ERP always wins. First-class data, with change alerts |
| Buyer-facing description | Commerce | seeded once from ERP, then never overwritten | The ERP outbound payload must not contain this field at all |
| Taxonomy and merchandising | Commerce | commerce only | ERP hierarchy is an input, not a source |
| Imagery and rich media | Commerce | commerce only | ERP has none |
| SEO metadata | Commerce | commerce only | — |
| Customer account structure | contested | — | The row every project argues about. A real decision, not an oversight |
Two of those rows carry an extra rule worth saying out loud. Contract price is owned by the ERP and isn’t synced at all — it gets resolved on demand and the answer gets cached, and it is never recomputed on the commerce side. And on available to promise, absence of data is never written as zero: if the sync fails you keep the last known value and raise an alert, because you do not empty your catalogue just because a job didn’t run.
The row every project argues over
One row is genuinely contested, and the video leaves it that way on purpose.
Customer account structure. One person, buying for three companies, with different pricing at each and different approval rules at each. Your ERP models that one way. Your commerce platform models it a different way, usually worse. There isn’t a clean answer — there’s a decision, and it depends on the business. Pretending it has a default would not be doing you any favours.
Why the nightly job beats your merchandiser
Your merchandiser rewrites a product description so a buyer can understand it. That night a sync job writes the ERP’s version back over it, and in the morning it’s wrong again. She fixes it, it happens again, and after about three weeks she stops fixing it. That is the moment your catalogue stopped being maintained — through a default nobody chose, not a decision anybody made.
The asymmetry underneath it doesn’t get talked about. The usual conflict rule is last write wins — but a machine writes at 2am every night forever and a person writes once during the day. It isn’t a tie-breaker, it’s a guarantee. And it’s worse than it looks: ERP timestamps often share one-second granularity across a whole batch, so within that batch “latest” isn’t defined at all.
The fix, and why it isn’t the one people reach for
The instinct is to go into the mapping and set the conflict rule so commerce wins on that field. That’s a checkbox — and in eighteen months a different consultant unticks it while debugging something unrelated, and nobody connects the two events.
The durable fix is structural. The ERP’s outbound payload should not contain the description field at all. Not mapped to nothing. Not present. Remove the path, not the permission.
How to use it
Two hours, a spreadsheet, and every field that crosses between the two systems on its own row. Do it before anybody writes a mapping.
The rows are easy and the arguments are the point — because every argument you have while filling it in is one you’d otherwise have in production, in front of a customer, at a much worse moment.
We’d need to see your own field list to fill this in for you, so take the video as context for the discovery session where it actually gets decided.