The decision that comes before any connector

System of Record and Data Ownership

Almost every painful integration we are asked to rescue has the same root cause, and it is not a technical one. Nobody ever decided which system owns which piece of data. Two systems both believe they are right about a price, a stock figure or a customer record, they overwrite each other on a loop, and the business slowly learns to distrust all of it.

This page is about settling that before you connect anything. Which system creates a product and which merely displays it. Who owns the selling price, the cost, the customer record, the order status. Where two way sync is genuinely justified and where it is a trap. How conflicts get resolved when they inevitably occur, and what has to be logged so you can answer the question six months later.

Book a Data Architecture Session (03) 9003 0111

What Happens Without a Clear Owner

Two right answers

Which is nobody knowing

The first symptom is people checking a second system before they trust the first

Update loops

Systems overwriting each other

Each change triggers a change back, and the record oscillates

Per field, not per system

Ownership is finer grained than people expect

One record commonly has fields owned by three different systems

Manual reconciliation

The cost you never budgeted

Somebody quietly spends hours a week making the numbers agree

Four Things Ownership Actually Decides

This is not an academic exercise. Each of these has a direct operational consequence you will feel within weeks of going live.

Ownership belongs to a field, not a system

People start by asking whether the ERP or the website is the master, and the question is already too coarse. Take a single product: the item code and unit of measure almost certainly belong to the operational system, the marketing description and imagery usually belong wherever merchandising actually happens, the selling price may belong to one system for retail and another for trade, and the available quantity belongs to whichever system records physical movement. A useful ownership map is a grid of data domains against fields, with one owner named for each, rather than a single arrow between two boxes.

Two way sync is a last resort, not a default

Bidirectional synchronisation sounds like the generous option and is where most integration instability comes from. It requires conflict resolution, loop prevention, and a shared understanding of which change is newer that is surprisingly hard to guarantee across systems with different clocks and different update semantics. Wherever a single system can be made the owner and everything else a subscriber, take that option. Genuine two way cases exist, order status being the classic one, but they should be deliberate, few, and designed with conflict rules written down in advance.

Identifiers are the foundation everything rests on

Ownership only works if both systems agree on what a record is. That needs a stable identifier strategy: which system mints the key, how foreign keys are stored on the other side, what happens for records that predate the integration, and how you match when no shared key exists. Matching customers on email address alone will merge a household and split a person who changed jobs. Matching products on description will eventually match the wrong thing. Decide the identifier rules explicitly, store the cross reference, and never rely on a fuzzy match without a review step.

You will be asked what changed and when

Sooner or later somebody will insist a price was wrong, an order was altered or a customer record was overwritten, and the value of the integration in that moment is whether you can answer. That means recording, for each synchronised change, which system originated it, what the previous and new values were, what time it happened and what triggered it. This is also what turns a disputed conversation into a two minute query, and it is what makes the difference between fixing a bad data flow and arguing about whether it exists.

Six Domains to Settle Before You Build

Work through these one at a time with the people who actually maintain the data. The exercise usually takes a day and saves months.

One creation point

Product and item data

Decide where an item is created and who may create one. Typically the operational or finance system mints the code and holds unit of measure, pack configuration, tax treatment and supplier linkage, while merchandising systems own titles, copy, imagery and channel categorisation. The failure mode to avoid is products being created in two places, which produces duplicates that are painful to merge once transactions exist against both.

Priced from one place

Pricing

Separate the price types before assigning owners: cost, recommended retail, actual selling price per channel, promotional price, and contract or trade pricing per customer. These frequently have different owners, and the promotional layer especially tends to live where marketing works rather than where finance works. Agree how GST inclusive and exclusive figures are stored and converted, because mixing the two conventions across a boundary is a common and expensive error.

One counted truth

Inventory and availability

Physical stock is owned by whatever system records movements, receipts and adjustments. Everything else consumes a derived sellable figure after buffers and allocations. The distinction between counted stock and sellable availability is worth being pedantic about, because they are different numbers with different owners and conflating them is how oversells begin. The mechanics of distributing that figure are covered in depth on our multichannel inventory page.

A single identity

Customers and contacts

Decide where a customer record is created, how a retail shopper and a trade account relate, and what the matching rules are. Also decide what does not flow: marketing consent state, payment details and internal notes frequently should not be copied everywhere, both for good practice and because the Privacy Act 1988 and the Australian Privacy Principles make every additional copy a thing you must secure, disclose and be able to delete.

Controlled two way

Orders and their status

Orders are the most legitimate two way case. The sales channel creates the order and owns the customer facing record, while the fulfilment system owns dispatch, tracking and completion state, writing that back. Make the rule explicit about which fields each side may alter after creation, and what happens to an amendment made in one system after the other has already acted on it, because partial dispatch and partial cancellation are where thin designs break.

Finance owns finance

Financial records

Invoices, credit notes, payments, tax codes and the general ledger belong to the accounting or ERP system, and other systems should read them rather than write them. Sales channels post transactions in, finance produces the authoritative documents out. Keeping this boundary clean is what makes BAS preparation and audit straightforward, and blurring it is how businesses end up with two sets of numbers and no confidence in either.

Ownership Questions and Sensible Defaults

Task	Traditional	Ownership Defined	Notes
Who creates a new product?	Whoever needs it first	One system mints the code	Duplicates created in two places are painful to merge once transactions exist.
Who owns the selling price?	Both, overwriting nightly	One owner per price type	Cost, RRP, channel price and promotional price often have different owners.
Who owns the stock figure?	Whichever was updated last	The system recording movements	Counted stock and sellable availability are different numbers, not synonyms.
Customer changes their address	Updated in one system only	Owned centrally, propagated	Decide whether an order already placed keeps its captured address. It should.
Order cancelled after dispatch started	Two systems disagree	Explicit precedence rule	The physical event wins. Systems cannot unship a parcel.
Marketing consent flag	Copied everywhere	One owner, read only elsewhere	Multiple writable copies of consent is a compliance problem waiting to happen.
Two records look like the same customer	Merged on email, sometimes wrongly	Matched on rules, reviewed	Shared household emails and job changes both defeat naive matching.
A field disagrees between systems	Someone notices eventually	Detected, logged, resolved by rule	Silent divergence is worse than a visible error, because trust erodes invisibly.

Where Ownership Decisions Go Wrong

Declaring one system the master for everything

It is tempting to end the debate by naming the ERP or the commerce platform as the single source of truth for all data. In practice this forces teams to maintain data in a system that suits them poorly, so they work around it in spreadsheets and the real master quietly moves somewhere you cannot see. Assign ownership per domain and per field, choosing the system where the data is genuinely maintained by the people responsible for it, and accept that the resulting map will have several owners on it.

Two way sync chosen to avoid an awkward conversation

Bidirectional sync is often adopted because two departments each want to keep working the way they do and nobody wants to tell either of them no. The cost arrives later as update loops, conflicting values and a support burden that never ends. If you find yourself specifying two way sync for a field, check whether the real requirement is that a second team needs to see the data and occasionally request a change, which is a read plus a workflow rather than a second writer. Reserve genuine two way flows for cases like order status where both sides truly own different parts of the record.

No conflict rule, so last write wins by accident

When two systems can both change a value, something decides which change survives, and if you have not specified it the answer is whichever arrived last, which is not a policy but an outcome. Timestamps across systems are not reliably comparable, clocks drift, and batch jobs can deliver an older change after a newer one. Write down the precedence rule for each contested field, prefer rules based on source and event type rather than time, and make unresolvable conflicts raise an exception for a person instead of being silently resolved.

Copying personal information everywhere by default

It is easy to sync the whole customer record to every connected system because it is simpler than deciding what each one needs. Each copy then becomes personal information you hold, must protect and must be able to locate and delete on request under the Privacy Act 1988 and the Australian Privacy Principles. Map which fields each system genuinely requires, leave the rest where it is, and make sure your deletion and correction processes reach every copy that does exist. Minimising what flows is both better practice and less work to maintain.

Ownership decided by whoever spoke loudest

These decisions have real consequences for daily work, so they need the people who actually maintain each data set in the room, not just the project sponsor and the integrator. The finance team knows why tax codes must stay where they are, the merchandising team knows why product copy cannot live in the ERP, and the warehouse knows what a stock adjustment really means. An ownership map produced without them will be technically valid and operationally ignored, which is the worst combination.

Treating the map as permanent

Ownership decisions reflect the systems and teams you have now. Replatform the website, implement a new ERP, acquire a business or move merchandising into a dedicated tool, and parts of the map change. Keep it as a living document that is reviewed when systems change and referenced whenever someone proposes a new connection. An ownership map that nobody has opened in two years will not match reality, and the integrations built against it will have drifted with it.

How Yes AI Approaches Data Ownership

A workshop, then a document

We run the ownership mapping with the people who maintain each data set and produce a grid naming one owner per field, the direction of flow, the conflict rule and what is deliberately not synchronised. It is written for your team to use, not as a technical artefact.

We look at what is happening now

Before designing anything we examine where data is actually maintained, which often differs from the official answer. Shadow spreadsheets and manual corrections are evidence about where the real master sits, and they inform the map rather than being tidied away.

Enforced in the build, not just documented

The ownership rules are implemented in the flows themselves on a managed cloud automation layer we operate, with change level logging showing origin, previous value and trigger for every synchronised update, so the document and the behaviour cannot drift apart.

A straight answer when the answer is smaller

Plenty of businesses need an ownership decision and a one way feed rather than an integration programme. If a clear map plus a simple scheduled flow solves it, that is what we will recommend, and we will happily document the map even if you build the rest yourself.

Settling Ownership Before Anything Is Built

Five steps. The mapping itself is usually one to two workshops, and it pays for itself by removing rework later.

Inventory the data domains

Products, pricing, inventory, customers, orders, financials and anything specific to your operation. For each, list where it is created, where it is edited and who does the editing in practice.

Assign an owner per field

Working through the grid with the teams responsible, naming one owning system for each field, and marking what deliberately does not flow at all. Disagreements get resolved here rather than in production.

Decide direction and conflict rules

One way wherever possible, two way only where genuinely justified, with an explicit precedence rule and an exception path for conflicts that cannot be resolved automatically.

Fix identifiers and matching

Which system mints keys, how cross references are stored, how legacy records are matched and reconciled, and where a human review step is required before a merge is committed.

Build to the map and keep it current

Flows implemented to match the document, with change logging, then the map reviewed whenever a system changes or a new connection is proposed. It stays a working reference rather than a project artefact.

FAQ

What does system of record actually mean?

The system of record for a piece of data is the one place that holds the authoritative version, where changes are made and from which every other system takes its copy. Everything else is a subscriber that displays or uses the data but does not get to redefine it. The important refinement is that this applies at the level of a field or a data domain rather than a whole system. It is completely normal for one product record to have its item code owned by the ERP, its description owned by a merchandising system and its channel price owned by the commerce platform, provided each of those is stated and enforced.

Should the ERP always be the master?

No, and defaulting to that assumption causes real problems. The ERP is usually the right owner for item codes, cost, tax treatment, stock movements and financial records, because that is where those are genuinely maintained and where the controls live. It is often a poor owner for marketing copy, imagery, channel specific categorisation and promotional pricing, because the people responsible for those do not work in it and will not maintain them there. Forcing data into a system whose users avoid it does not create a single source of truth, it creates a stale one alongside a spreadsheet that holds the real answer.

When is two way sync genuinely appropriate?

When both systems legitimately own different parts of the same record and both need to write. Order handling is the clearest example: the sales channel creates the order and owns the customer facing view, while the fulfilment system owns dispatch, tracking and completion and must write those back. Even then the design should state precisely which fields each side may change after creation, and what happens when an amendment arrives after the other side has acted. Outside cases like that, if you are considering two way sync it is worth checking whether the actual need is for a second team to see the data and request changes, which is a read plus a workflow.

How do you resolve conflicts when two systems disagree?

First by removing as many conflicts as possible through single ownership, because the cheapest conflict is the one that cannot occur. For the remainder, write an explicit precedence rule per field, based on the source and the nature of the event rather than on timestamps, since clocks across systems are not reliably comparable and batches can deliver older changes after newer ones. Physical events generally take precedence over administrative ones, because a system cannot unship a parcel. Anything that cannot be resolved by rule should raise an exception for a person to decide, with the record held rather than silently overwritten.

What does this have to do with privacy obligations?

Directly. Every system you copy customer data into becomes somewhere you hold personal information, which under the Privacy Act 1988 and the Australian Privacy Principles you must secure, be able to describe in your privacy policy, and be able to locate, correct and delete when someone asks. Synchronising the entire customer record everywhere because it is simpler is how businesses end up unable to answer a deletion request honestly. Deciding ownership per field naturally limits what spreads, and marketing consent in particular should have exactly one writable owner, with every other system reading it.

How long does the mapping exercise take?

For a business with an ERP or accounting system, a commerce platform, a point of sale and a CRM, the mapping itself is typically one to two workshops with the people who maintain each data set, plus a few days to document it and circulate it for agreement. The variable is not the documentation but the decisions, and when a domain has been contested between two teams for years that conversation can take longer than the rest combined. It is still far cheaper to have it in a workshop than to discover it in production, where the same disagreement appears as data corruption.

We already have integrations running. Is it too late?

Not at all, and existing integrations give you evidence a greenfield project does not have. Start by documenting what the current flows actually do rather than what they were meant to do, which usually reveals fields being written from two directions and reconciliation work someone has been absorbing quietly. From there you can decide the intended ownership, then correct the flows in priority order, generally starting with whatever is causing the most manual checking. It is normal for this to be a sequence of contained fixes rather than a rebuild, and pricing and stock are usually where the first fixes pay back quickest.

Decide Ownership Before You Connect Anything

Book a call. We will map where your data is really maintained, name an owner for each domain, and tell you which of your current flows are fighting each other.