Every field in a business has exactly one system that owns it, meaning the place where a change to it is authoritative. When you build something new, the shortcut is to copy that data in so the new system stands on its own. The copy drifts, and you get two answers to one question with no rule for which wins. The discipline is deciding, field by field, whether the new system owns the value, points at it, or freezes it.
The failure that shows up months after launch
Two systems answer the same question and neither is wrong
The accounting package has one billing address for the customer. The new job system has another. Both were right the day they were entered. Nobody changed the wrong one; one was simply never told about the update.
Nobody wrote down which side wins
A sync gets set up because both systems need the customer list. Then somebody edits a name in the new system, and whether that edit travels back has no documented answer. Whatever the connector happens to do becomes policy by accident.
Two-way sync becomes a permanent obligation
Bidirectional syncing looks safe because nobody has to change where they work. It creates conflicts that need rules, and those rules need maintenance whenever either system changes a field. You have not integrated two systems. You have taken on a third.
The copied list quietly stops matching
Cost codes, service items, and account numbers get pulled in once during the build. Months later three have been retired and two added. The dropdown still shows the old set, so entries post against codes accounting no longer recognizes.
A routine update rewrites history
A customer changes their billing address. A sync refreshes every record referencing that customer, including invoices issued two years ago. Those documents now show an address that was not on them when they were sent.
Own it, point at it, or freeze it
Three storage decisions cover nearly everything. Hold the value because you own it. Point at whoever owns it and read the current value on demand. Or freeze a copy, because the value was acted on and must never change again.
| Data | Who owns it | What the new system should hold | What it should point at | What copying it costs you |
|---|---|---|---|---|
| Customer identity and contact details | The accounting package or CRM, whichever has the edit screen | The owner’s customer identifier, nothing else | Name, address, and terms, read when displayed | Two spellings of one customer, and mail sent where they no longer are |
| Chart of accounts and cost codes | The accounting system | The code identifier chosen on each transaction | The list of codes, read at selection time | Retired codes still on the menu, and entries that post to nothing |
| Current price of a service or item | The pricing rules or the item list | Nothing | The live price when a quote is assembled | Quotes issued at last quarter’s prices, with no way to date the drift |
| The price charged on an issued document | The new system, once it issues the document | The number, frozen, with the rule version behind it | Nothing at all | A reissued invoice that no longer matches what the customer agreed to |
| Employee roster and pay rates | The payroll or HR system | The employee identifier and whether they are assignable | Name, rate, and employment status | A departed employee still schedulable, and two rate tables that disagree |
| Job or project list | Whichever system opens the job first | The job identifier, plus fields only this system captures | Job name, address, and lifecycle status | One job under two numbers, with cost landing on neither |
| Documents this system collected itself | The new system | The file, its version, its dates, and who accepted it | Nothing | Nothing goes wrong here; this is data the new system genuinely owns |
| Tax rate applied to a closed transaction | A tax service or the accounting system | The rate applied, frozen with the transaction | The current rate, read when the calculation runs | A rate change that silently restates what old transactions were taxed at |
Questions that settle ownership before anyone writes code
Ask where the edit screen is
Whichever system has the interface where a human changes the value is the system that owns it. That test beats asking which system is bigger or came first. If two systems both have an edit screen for one field, that is the actual problem, and no integration design fixes it.
Separate a reference from a snapshot
A reference is a pointer. It says go and ask, and shows whatever the owner says today. A snapshot is a frozen record of the value at one moment, stored because a decision was made on it. The two look identical in a database and behave in opposite ways.
Store identifiers, never labels
The identifier survives a rename, a merge, and the correction of somebody’s typo. The label does not. Systems that match on customer name work perfectly until somebody fixes a spelling, at which point the link breaks silently and records go on being created.
Make every sync one-directional and say which way
One writer per field, stated so a non-technical person can check it: the accounting system owns customer contact details and the job system displays them. If somebody wants to edit that field in the job system, move the edit screen rather than adding a return path.
Plan for the copy you cannot avoid
Sometimes you hold a copy because the owner cannot be queried or the network is not always there. That is fine, provided the copy shows when it was last read. Decide as well what happens when the owner is unreachable: block, proceed with a marked last-known value, or queue the work. Stale data that admits it is stale is manageable.
Where this decision usually gets made
- QuickBooks automation, where the accounting system stays the system of record — The accounting package owns customers, items, and accounts in most small businesses, which puts it on the reference side of most of these decisions.
- workflow automation between existing systems — Integration work is where ownership either gets decided on purpose or gets decided by whatever the connector does by default.
Is this a fit for your business?
A good fit when
- You are adding a system alongside an accounting package, CRM, or field app that already holds customer data
- Two teams already quote different numbers from different screens for the same record
- An auditor, insurer, or customer may ask what a record said on a specific date
- You are being sold a two-way sync and nobody has explained what happens on conflict
Probably not a fit when
- Everything runs in one system and nothing is being added alongside it
- The second system is a read-only reporting copy that nothing writes back from
- You are still choosing a platform, which makes ownership a question for later
What to have ready
- A list of the systems people log into weekly, including the spreadsheets
- For each shared field, who changes it and on which screen
- Any question you have already been asked about what a record looked like in the past
Questions we get asked
Our accounting system has no usable interface for reading data. Does that change the answer?
It changes the mechanism, not the ownership. The accounting system still owns the field, so the new system must not become a second place to edit it. Hold a cached copy, stamp it with the time it was last read, and refresh on a schedule you chose. The copy stays read-only.
Is referencing slower than storing a local copy?
Usually yes, and it matters less often than people expect. It bites on list views with hundreds of rows and on field screens with a weak connection. For those, cache the display value and reference the identifier, so a stale name is cosmetic while the link underneath stays correct.
What if two systems both legitimately need to edit the same field?
Then you have an unresolved process question rather than an integration problem, and software will not settle it. Somebody has to decide which team owns that field. If the honest answer is both, split it into two fields with different owners, which is what the process was doing informally.
We already have the same data in four systems. Where do we start?
Start with fields that appear on a customer-facing document, because that is where disagreement costs you credibility. Name an owner for each, turn every other instance into a read-only display of that owner, and leave historical copies frozen. Do not reconcile the past; stop adding to it.
Does this mean a reporting warehouse or data copy is wrong?
No, and this is the exception worth knowing. A warehouse is a derived copy that nobody edits and nothing writes back from. It cannot become a second source of truth because it has no edit screen. The rule is about authority, not about whether bytes are duplicated.
Related
Tell us what the process looks like now and we will map what a system would need to do. No obligation, and you keep the map either way.
