System of record matrix

Which system owns each object

Read the second column as the system that should be authoritative in a stack that has all of these components. Where the honest answer for a mid-market brand is a workbook, the row says so — pretending otherwise produces a data model nobody follows.

What breaks when two systems both claim an object

This is the column the matrix above leaves out, split into its own table because it is the one people skip. None of these failures announce themselves.

An object with two writers has no system of record

The rule is short: for every data object, exactly one system may write it, and every other system holds a read-only copy. Copies are the normal condition of a working stack. Two systems that both accept an edit are not — the object then has no owner, and the stack has no answer to the question of what it is.

The failure of a two-writer object is not a conflict error. It is two numbers that are each defensible. Nothing throws, both owners can explain their figure, and the disagreement surfaces only when the two land on the same slide. Cost is the classic case, because the cost is not one object. Take an illustrative style, costed per unit in the brand’s own costing currency: development sets a target of 12.00 against the bill of material and PLM carries it, the vendor quotes 12.60, the PO is cut at 12.60, and once freight, duty and a part-air shipment are in, ERP records 14.10 landed. All three are correct. The merchant quoted IMU from 12.00 because that is what PLM showed; finance reports margin from 14.10 because that is what the goods cost. The numbers are illustrative; the shape is not.

The resolution is not to reconcile harder. It is to notice that target and landed cost are two objects sharing a name, give each one owner — PLM for target and quoted, ERP for landed — and require every consumer to state which it used. A margin figure without a named cost basis is not a margin figure. The same move settles most contested rows: the size scale splits into which sizes exist and how units distribute; the season calendar into a development calendar and a financial one. It is the line the Apparel OS and ERP comparison draws between the decision and the transaction.

Definition — System of record

A system of record is the single system that is authoritative for one data object — the one place a value is written, from which every other system takes a copy. In an apparel stack it is assigned per object rather than per system: PLM is authoritative for the style and its bill of material, ERP for the purchase order and the company inventory position, the planning system for open-to-buy and the buy plan, and the commerce platform or POS for the sales transaction. An object with two writers has no system of record — only two numbers that are each defensible.

Used by: Merchandising, planning, product development, technology, and finance leaders deciding which system owns which object

Related: PLM, ERP, merchandise planning software, WMS, POS, master data, the single-writer rule

Direction matters more than ownership

Naming an owner is the easy half. Direction decides whether the stack holds together: for each object, which way does it move, and is any leg of that path two-way. A single field that both systems may edit will diverge — not might, will — because nothing arbitrates the case where both sides changed since the last sync. The claim is narrow and worth stating precisely: it is about one field with two writers. Two systems exchanging different objects in opposite directions — planning sending a proposed buy, ERP returning a commitment and a confirmed date — is not the same thing, and it is how a connected stack is supposed to work.

Two-way sync of the same field is sold as the sophisticated option and it is the one that fails quietly. It works while only one side is ever edited, which is the condition under which you did not need it. Correct a color name in PIM the same week the colorway is renamed in PLM and one change wins on timestamp while the other disappears without a trace. Nobody gets an error; somebody gets a storefront showing a color the buy sheet has never heard of.

The fix is to name one writer per field, not to reconcile more often. Purchase orders are the clean example: planning proposes a buy, ERP creates the order, and what returns is not an edited buy plan but a commitment and a confirmed date — ERP-owned objects that planning reads. The product record runs on the same distinction. Enrichment adds attributes the upstream system never held, and a value written into a downstream consumer is not a second writer on an upstream-owned field; rewriting changes a value the owner still believes it owns, and only that breaks things. Keeping one product record that is created once and used by every team, rather than re-entered at each stage, is the job of the RetailNorthstar product data foundation.

The line plan and the assortment are genuinely contested

Most rows in the matrix above have an answer merchants, planners and IT would converge on. Two do not, and saying so beats manufacturing certainty for a tidy table. The line plan is contested because it is two things at once — a financial and structural object (option counts, breadth against depth, delivery phasing) that argues for the planning system, and a statement about product that becomes a style with a bill of material, which argues for PLM. Either owner works; both holding an editable option count does not, because the count quoted in a line review then depends on who opened which tool that morning.

The assortment is contested for a related reason and a practical one. Structurally it is a planning object, at style-color by channel, door cluster and delivery. Practically, that grain is rarely modeled in a mid-market planning tool, so the assortment is a workbook even where a planning tool exists, and the tool holds a coarser version that is not the same object. Two grains of one thing is the two-writer problem in disguise.

A third gap costs the most in a long-lead category: the working delivery date. ERP holds the date the PO promised; the factory holds the date it will ship. Nothing owns the current best estimate, so it lives in vendor email while the plan phases receipts against a date that stopped being true weeks ago. That is a row with no occupant — a different problem from a row with two.

In the mid-market, the answer today is routinely the spreadsheet

Several rows — the line plan, the assortment, the buy plan, open-to-buy, the size curve, the working delivery date — are routinely owned by a workbook in the mid-market. That is not a failure of discipline. Those objects sit between the systems the brand bought, and when those stacks were chosen nobody sold a system whose only job was the space between PLM and ERP, so the space was filled with the tool everyone already had.

A workbook can be a legitimate system of record on one condition: it is the only writer, and everyone knows which file it is. That condition is hard to hold not because spreadsheets are weak but because they are trivially copied. A record survives being read by anyone; it does not survive being duplicated by anyone. The moment a version is emailed for comment the object has two writers, and nobody finds out until the two numbers land on the same slide. That composite stack is set out in the PLM and spreadsheets comparison.

A dashboard is not a candidate owner for any row above. Reporting reads the record and renders it; it has nowhere to put a decision, so an object living only in a dashboard has no writer rather than one — the boundary drawn in the BI and dashboards comparison.

Making a multi-writer object survivable

Re-platforming is usually not on the table, so the useful question is what to do with a two-writer object you are stuck with: a reconciliation discipline that makes divergence visible early and cheap rather than invisible and expensive. Four moves do most of the work.

Name a tiebreaker before you need one — for each contested object, which system wins when the two disagree, and who may overrule that. It costs one meeting and removes the part of the argument that is about authority rather than data. Second, reconcile against the decision rather than the calendar: the buy plan against ERP commitments before every buy review, because a reconciliation that lands after the decision is documentation rather than control.

Third, make the copy visibly a copy — a pulled number should carry its source and the time it was pulled wherever it is shown, because the damage comes from figures that look native to the file they sit in. Fourth, reconcile at the grain the decision is made at; a season total says nothing about a style-color offset in both directions, and offsets that cancel at total level are the ones that become an air freight bill — which level that is for each decision is set out in the planning grain. None of this makes a two-writer object correct. It makes it survivable, and it shows which rows cost enough to fix properly — the input to the connected planning implementation playbook.

How the matrix shifts outside apparel

The matrix is apparel-first and most of it transfers unchanged: the purchase order still belongs to ERP, the sales transaction to the channel, and cost still splits into target and landed wherever goods are imported. What moves is which row is hardest. In footwear the size scale row does more work than any other — size runs and widths multiply the grain, prebooks commit units before the season is read, and the pair rather than the unit is counted, so the split between which sizes exist and how pairs distribute needs a named owner earlier than in apparel.

In accessories and bags the size row often collapses while color and material expands: hero colors, evergreen core and attach rate give the colorway commercial weight the style master does not carry. In home and furniture the size scale row is replaced by a configuration and finish row, the hardest in the matrix — configuration is a structural product decision belonging in PLM, but finishes, container quantities and landed cost interact tightly enough that the object is contested with ERP in a way a size scale never is, and the season calendar row changes shape because an introduction cycle and a model year are not a season. The vertical treatments live on the flagship: footwear, accessories and bags, and home and furniture.

What an apparel operating system takes ownership of

An apparel operating system does not become the system of record for everything, and anything claiming to is describing a migration rather than a connection. PLM stays authoritative for the product record; ERP for the transaction. What an Apparel OS takes is the rows that currently have no occupant — the line plan, the assortment, open-to-buy and the buy plan, the size curve, the working delivery date — and it reads the rest instead of duplicating it. That is compatible with calling it the connected system of record for the commercial workflow, as long as the distinction holds at object level: the Apparel OS owns the plan and the workflow that carry a season through purchase orders, production and allocation, while the purchase order, the production receipt and the shipment stay ERP and WMS objects it reads. The measure of whether it helped is not how many objects it holds; it is whether the number of objects with two writers went down. That boundary against product development is the Apparel OS and PLM comparison, and the category itself is defined on the apparel operating system pillar.

• ✓A system of record is assigned per data object, not per system — no single application is the system of record for an apparel brand.
• ✓PLM owns the style, color, bill of material and target cost; ERP owns the purchase order, landed cost, the inventory position and the wholesale account; the planning system owns open-to-buy, the buy plan and the size curve.
• ✓An object with two writers has no system of record, and the failure is not a conflict error — it is two numbers that are each defensible, found in a meeting rather than in a log.
• ✓Cost is the classic split-object case: target and quoted belong to PLM, landed belongs to ERP, and a margin figure without a named cost basis is not a margin figure.
• ✓Direction decides whether a stack holds together. A single field that two systems may both edit will diverge; name one writer per field rather than reconciling more often. Two systems exchanging different objects — planning proposes a buy, ERP returns a commitment — is not the same pattern and is not the failure.
• ✓The line plan and the assortment are genuinely contested and the working delivery date has no occupant at all — in the mid-market all three, plus open-to-buy, routinely live in a workbook.

• Map the modern apparel software stack and where each system fits →
• See which person is accountable for each decision — the decision rights map →
• See which level of the hierarchy each decision belongs at — the planning grain →
• Why an automated actor is not a candidate owner for any row until the record is writable →
• Read the apparel operating system definition and pillar →
• Compare the Apparel OS with ERP — the decision versus the transaction →
• Compare the Apparel OS with PLM — beyond the product record →
• Compare the Apparel OS with BI and dashboards — why reporting owns nothing →
• Walk the connected apparel workflow map, stage by stage →

Frequently asked questions

What is a system of record in an apparel stack?

A system of record is the single system that is authoritative for one data object — the one place a value is written, from which every other system takes a copy. It is assigned per object rather than per system, so no one application is the system of record for an apparel brand. PLM is usually authoritative for the style and its bill of material, ERP for the purchase order and the company inventory position, the planning system for open-to-buy, and the commerce platform or POS for the sales transaction.

Which system should own product cost?

Cost has to be split by cost type, because target cost and landed cost are different objects sharing a name. PLM owns target and quoted cost, which are development decisions made against a bill of material. ERP owns landed cost, because only ERP sees freight, duty and the actual invoice. The mistake is treating them as one field: a merchant quotes IMU from the development cost while finance reports margin from the landed cost, and both figures are defensible even though they disagree.

Can a spreadsheet be a legitimate system of record?

Yes, on one condition: it is the only writer, and everyone knows which file it is. In the mid-market the honest answer for the line plan, the assortment and open-to-buy is routinely a workbook, and calling it anything else makes the stack harder to reason about. A workbook fails as a system of record for an unexpected reason — not because it is a spreadsheet, but because it is trivially copied, so the single-writer condition breaks the first time somebody emails a version out for comment.

Who should own the line plan — PLM or the planning system?

Ownership of the line plan is one of the two genuinely ambiguous assignments in an apparel stack, and manufacturing certainty about it does more harm than admitting it. The line plan is a financial and structural object, which argues for the planning system, but its content is product, which argues for PLM. Either answer works when it is chosen deliberately and the other system takes a read-only copy. What does not work is both systems holding an editable option count, because the count that gets quoted then depends on who is in the room.

What actually happens when two systems both write the same object?

When two systems both write the same object, what happens is not a conflict error. It is two numbers that are each internally correct, produced by systems that each did their job, disagreeing with no signal that anything is wrong. That is what makes the failure expensive: there is nothing to alert on, so the divergence is found in a meeting rather than in a log, and the meeting spends its time establishing which number is real instead of deciding what to do about it. An object with two writers has no system of record.

Does an apparel operating system become the system of record for everything?

No, and anything claiming to is describing a migration rather than a connection. PLM stays authoritative for the product record and ERP stays authoritative for the transaction. An apparel operating system takes ownership of the objects that today have no owner at all — the line plan, the assortment, open-to-buy, the size curve and the working delivery date — and reads the rest rather than duplicating it. It carries the plan and the workflow across purchase orders, production and allocation without owning those objects: the buy plan behind an order is a planning object, the order itself is ERP’s. The goal is to reduce the number of objects with two writers, not to add another writer.