Decide Which System Holds the Truth, Before You Integrate Anything

The credit limit in the CRM says one figure. The credit limit in the ERP says another. Both were entered by somebody with the authority to enter it, on a date that made sense, for a reason they could defend. The sales manager raised it after a good quarter. Finance lowered it after a slow payment.

Somebody is now asked to "integrate the two systems so this stops happening", and that request contains an assumption that is not true: that the two figures disagree because the data was not copied. They disagree because two people were allowed to decide the same thing, and no mechanism ever existed to stop them. Copy the field in either direction and you have not resolved the conflict — you have automated one party's ability to overwrite the other, silently, on a schedule.

This is the decision that has to be made before an integration is designed, and it is almost never made explicitly. It is the operational form of the argument that connecting every system to every other one makes the estate harder rather than easier, and it is one of the most common structural findings in an independent look at a company's systems — not because the integrations are badly built, but because nobody wrote down what they were supposed to mean.

What a system of record actually is

A system of record is the system whose value is correct by definition for a given piece of data. Not the most accurate one. Not the newest one. The one that, when two copies disagree, is right because it is the one entitled to decide.

That word — entitled — is what makes this a governance question rather than a technical one. The choice is not "which database is better". It is "which business process is authorised to change this, and therefore which system is where that process happens".

Two things follow immediately, and both are frequently violated.

Every field has exactly one system of record. Not every system. Every field. The same customer record can have its name mastered in one place, its credit limit in another, and its delivery address in a third, and that is a perfectly coherent design provided somebody wrote it down.

Everything else holds a copy, and knows it. A copy is allowed to be read, reported on, and displayed. It is not allowed to be edited. If a user can edit a copy, it is not a copy — it is a second record of truth, and you now have the credit limit problem again in a different field.

Grain matters more than system

The instinct is to answer this at the level of the system: the ERP is our system of record. That sentence is comfortable and it decides almost nothing, because the systems in a real estate overlap on dozens of fields and not one of them is decided by a statement about the whole system.

Answer it per data domain, and inside a domain, per field where the domain splits. The useful unit is small.

The middle row is worth pausing on. Selling price is the field most often mastered in two places at once — a price list in the ERP and a quotation tool or spreadsheet in sales — and the resulting divergence is not a data quality issue, it is the same customer paying four prices across three branches because there is no single answer to what the price is.

The four tests

When two systems genuinely both have a claim, these settle it in order. Stop at the first one that gives a clear answer.

Where does the fact originate? The system into which a human first records the event is the natural master. A goods receipt originates in the warehouse. A hire originates in HR. A quotation originates in sales. Mastering data somewhere other than where it originates means the origin has to push it, and every push is a failure mode.

Which system's process governs the change? If changing the value requires an approval, the master is where the approval lives. A credit limit that finance must approve belongs in the system where finance works, regardless of who looks at it most.

Who is accountable when it is wrong? Follow the consequence. If a wrong tax registration number produces an invalid invoice and the finance manager answers for it, the field is finance's and the system is theirs. This is the same rule that puts ownership of a data domain with the function that carries the consequence rather than with the one that types most often.

Which system will still be here in five years? The tie-breaker, and only a tie-breaker. Master data in the system with the longest expected life and the best export story, because a system of record is the thing you cannot easily move later.

Notice that "which system has the better user interface" is not on the list. It is the reason most often given in the room, and it argues for mastering data where it is pleasant to type rather than where it is authorised to change — which is how a spreadsheet becomes a system of record without anyone deciding it should be.

Two-way sync is a symptom

When a design calls for bidirectional synchronisation of a field, it is worth stopping, because in almost every case it means the system-of-record question was not answered and the integration is being asked to paper over it.

Consider what two-way sync actually promises. Both systems may change the value. When both change it between synchronisation runs, one of them wins. The rule for who wins is usually last-write, which means the winner is decided by clock order — by which of two people happened to click later — and neither of them is told they were overruled.

That is not an integration. It is a randomiser with a schedule, and it produces the worst class of data error: one that is intermittent, unattributable, and invisible until a downstream number is wrong.

There are legitimate bidirectional flows, and they are worth distinguishing. They are always different fields moving in different directions rather than the same field moving both ways. The CRM sends the opportunity to the ERP; the ERP sends the invoice status back. Nothing is contested. Each field has one writer. That is two one-way flows sharing a pipe, and it is a good design.

The honest fix when a genuine contest exists is to make one side read-only in the user interface. It is unpopular, because somebody loses the ability to type in a box they are used to typing in, and it is the only thing that works. A field that is displayed but not editable, with a note saying where it is maintained, ends the argument permanently.

Reporting is a third case, and it is not a system of record

A data warehouse, a reporting database or a BI tool holds copies of everything and masters nothing. It is worth stating explicitly because the confusion is common and expensive.

The reporting layer's job is to agree with the systems of record, and when it does not, the reporting layer is wrong. Which means a number that appears only in the reporting layer — a margin, a utilisation rate, a days-sales-outstanding figure — is a derived value, and its definition is the thing that has to be governed, not its storage.

That distinction is exactly where dashboards go bad. Clean data in every source system, one authoritative copy of every field, and two reports still disagreeing, because the two reports defined "revenue" differently and neither definition is written down anywhere a business user can find. That is a dashboard lying to you with impeccable data underneath it, and no amount of integration work touches it.

Writing it down

The artefact is small enough that its absence is not really about effort. One table, one row per contested data element, four columns: the field, the system of record, the systems that hold a copy, and where the copy is read-only. Add a fifth column for the exception path, because there is always one field where a named person may override, and it should be written rather than discovered.

Two practical notes on producing it.

Do it before the integration is built, not during. During the build, the question surfaces as an implementation detail at the moment somebody is mapping fields, gets answered by whoever is in the room, and becomes a permanent architectural decision made by a developer under time pressure. That is how a spreadsheet ends up mastering the price list.

And do it with the people who edit the fields present, not only with IT. The question "who is allowed to change this" is answered accurately by the person who changes it and inaccurately by everybody else. Half the value of this exercise is discovering that a field two departments believed was governed is edited by four people, none of whom knew the others could.

The short version

An integration copies data. It does not decide who is allowed to change data, and every disagreement between two systems is a disagreement about that.

So decide it first, per field rather than per system, using origin, then approval, then accountability, then longevity. Give every field exactly one writer and make every other copy read-only in the interface — not by policy, by the interface, because a policy against typing in an editable box is not a control.

Treat a request for two-way sync of the same field as a signal that the question was skipped. And keep the reporting layer out of it entirely: it masters nothing, it must agree with the sources, and the numbers that exist only there are governed by their definitions rather than by their storage.

The table this produces is a page long and it is the single cheapest artefact in systems architecture. Where it does not exist, producing it is usually the first thing an independent review does, because almost every other finding in the estate turns out to be a consequence of it.