One source of truth for stock: what a unified-commerce architecture actually requires

Search this phrase and almost every result hands you the same thing: a component checklist and a platform to buy. Centralized data, unified profiles, real-time inventory, native integrations, sign here. The checklist is not wrong, but it skips the part that actually decides whether your stock count is trustworthy. A unified commerce architecture is less a product you buy than a decision about which system is allowed to be wrong. Its real requirement is a sequence: assign one owner for each piece of data, define how the owned number reaches everything else, and hold that ownership in place as the stack grows. This is that sequence, and the two points where most builds stall.

The reason the checklist is not enough is that a list of components tells you what to assemble, not how to make them agree. Four systems can each be best-in-class and still disagree about how many units are on the shelf, because no component list decides who wins when two of them hold a different number. That decision is the architecture. What follows is the build order that produces one trustworthy stock count across every channel, written for the team that has already decided to build it and wants to know what it takes.

Start here: decide which system is allowed to be wrong

Before any connector, the founding decision is which system holds the authoritative number for each kind of data, so every other system defers to it instead of asserting its own. This is what “single source of truth” actually means in practice. Not a product, a ruling: when two systems disagree, this one wins and that one yields. Everything downstream is the mechanics of enforcing that ruling.

The phrase “allowed to be wrong” is the useful way to frame it. In any real stack, systems will briefly hold different numbers. The architecture’s job is not to make that impossible, which it cannot, but to decide in advance whose number counts when it happens. The system that is allowed to be wrong is every system except the owner, because a non-owner holding a stale number is a read that will correct itself at the next event. The owner being wrong is the only error that ships a bad promise to a customer. Name the owner, and you have named the one number that must always be right.

Make this decision per data domain, not once for the whole stack. Stock, orders, customers, and pricing each need an owner, and they are often different systems. Deciding it globally (“the ERP owns everything”) is how builds inherit an owner that is wrong for a domain it was never suited to hold.

Step one: map the domains and give each an owner

The first build step is to list your data domains and assign exactly one owning system to each, with a written rule for what the others may do with that data. Inventory, orders, customer records, pricing, product catalog. For each, one system writes the truth and the rest read it.

Which system should own stock is the branch that matters most here, and it has three common answers. If your physical count is closest to reality in the ERP or warehouse system, that system owns on-hand stock and the ecommerce platform reads a derived sellable number from it. If your allocation and channel logic is richest in an order management system, the OMS owns availability and both the store and the web read from it. If you are a Shopify-centric retailer whose stock mostly lives and moves inside Shopify, the platform itself can be the owner and the ERP reconciles against it. If you are unsure, the safe default is to let the system where stock physically changes hands own on-hand, and compute sellable availability one layer up from there.

The rule you write down is as important as the choice. “The ERP owns on-hand; Shopify owns nothing about stock except the sellable number it receives” is a rule a developer can build and a team can defend. “The ERP and Shopify both keep stock in sync” is not a rule. It is the absence of one, and it is where drift begins.

Step two: define what “available” means and who computes it

The architecture must define the sellable number as a formula and assign one system to compute it, because “available” is not a raw count. In most commerce systems, available stock is on-hand minus what is committed and unavailable. If each system runs that subtraction against its own view of what is committed, they produce different sellable numbers from the same shelf. One system must own the calculation.

So the requirement is explicit: pick the system that computes sellable availability, define exactly which inputs it subtracts (open orders, reservations, damaged stock, safety buffers), and have every channel display that computed number rather than deriving its own. This is the step that turns “one owner” from a principle into a number a customer can trust. The owner does not just hold on-hand. It publishes the single sellable figure the whole stack sells against.

Getting this wrong quietly is common, because each system’s number looks internally correct. The ERP-to-Shopify inventory layer is exactly where a clear definition prevents the count from fragmenting. Define the formula once, in one place, and the rest of the architecture has something solid to propagate.

Step three: choose how the owned number reaches everything else

With an owner and a formula set, the next requirement is a propagation mechanism: how the authoritative number travels to every read-only system, and how often you check that it arrived. The choice is between event-driven and scheduled, and for a trustworthy count it is not really a choice.

Event-driven propagation, where a change in the owning system immediately pushes an update outward, keeps the read-only systems close to live and is the right default. Scheduled batch propagation, where a job copies numbers on a timer, leaves every system holding stale data between runs and should be reserved for data that genuinely does not move fast. But event-driven alone is not sufficient, which is the part most builds underweight. A message can be delayed, dropped, or throttled, so the architecture also needs a scheduled reconciliation pass: a periodic check that compares the owner’s number against each reader and flags any that has drifted. Events keep the stack current. Reconciliation keeps it honest. You need both, and naming the reconciliation cadence is a build requirement, not a nice-to-have.

The first place builds stall: the movements sync never sees

The first stall point is the moment the happy path meets returns, reservations, and multiple locations, because a build that only syncs completed sales silently ignores every other way stock moves. This is where an architecture that looked finished starts leaking, and it is predictable enough to design for from the start.

Returns are the clearest case. A returned unit exists physically again but is not sellable until it is inspected and moved back into a sellable state in the owning system, so the architecture must define that path rather than assume a return restores stock automatically. Reservations and draft orders are the mirror image: stock held for a customer is spoken for without being sold, and the owning system has to treat it as committed so the sellable number drops. Multiple locations turn “how many” into “how many, and where,” because an order commits against a specific location, not a company-wide pool, and the architecture must decide which locations feed online availability. A build that handles the clean sale and skips these three does not have a stock problem later. It has an unfinished architecture now. Designing the return path, the reservation states, and the location rules is what separates a demo from a system.

The second place builds stall: governance and drift detection

The second stall point is governance: deciding who is permitted to write to the owned number and how drift is caught, because without it the source of truth erodes one manual edit at a time. A build can ship correct and still degrade over months, as staff make well-meaning direct adjustments in systems that were supposed to be read-only, and each one reopens the gap the architecture closed.

Two requirements hold the line. First, write access to the owned number is restricted to the owning system and the defined paths into it, so a reader cannot quietly become a second writer. Second, the reconciliation pass from step three is wired to alert a human when it finds drift, so a divergence is caught by a dashboard rather than by a customer buying something that is gone. Governance is the requirement that is easiest to skip because nothing breaks the day you skip it. It breaks slowly, which is worse, because by the time the count is untrustworthy again nobody remembers which edit started it. An architecture without governance is not a lighter version of a unified one. It is a unified one with an expiry date.

Common contingencies to design for

Beyond the two stall points, a durable build plans for the ways a build breaks later. A sync token expires and orders stop flowing with no visible crash, only a growing data gap, so the architecture needs alerting on authentication and sync health, not just on the data itself. A promotion on one channel intentionally diverges stock allocation, so the rules must distinguish deliberate difference from accidental drift. And a new system joins the stack in year two, which is trivial if it connects to the owner and reads the published number, and expensive if it gets wired point-to-point to everything already running.

This last one is why the ownership model matters beyond stock accuracy. A well-formed unified architecture makes the next integration cheap, because there is a defined centre to connect into. Flatline has built exactly this kind of centre across engagements like OGÉR’s Shopify Plus, POS, ERP, and WMS unification and North Actionsports’ middleware connecting webshops to ERP and fulfilment, where the value was less any single connector than the coordinated structure the systems defer to.

Readiness check: are you ready to build this?

You are ready to build when you can answer four questions: which system owns stock, what formula defines sellable availability, how the number propagates and how often you reconcile it, and who is allowed to write to it. If those four have clear answers, the build is mostly execution. If any is still “both systems keep it in sync,” that is the gap to close before a single connector is scoped, because it is the gap every later problem traces back to.

Most teams can answer one or two of the four confidently and go quiet on the rest, and that is a normal place to start rather than a shortfall. The four questions are the actual specification of a unified commerce architecture, more than any component list, because they define the behavior the components have to produce.

If you are mapping your source-of-truth options, this is the decision to get right before you buy connectors. Flatline is a Shopify Platinum Partner with a long integration and middleware track record, from custom connector and ERP integration work to full unified-commerce builds. If you want a second set of eyes on where your stock’s source of truth should live, we offer a scoping conversation on your architecture with no obligation. Get in touch and we will walk through the four questions with you.

Frequently asked questions

What is a unified commerce architecture?

A unified commerce architecture is a system design in which one authoritative record holds each type of data, and every sales channel and back-end system reads from and writes to it rather than keeping its own copy. Its defining feature is a single source of truth per domain, so stock, orders, and customer data stay consistent across online and in-store channels in real time.

What does a unified commerce architecture require?

It requires four things: one owning system per data domain, a defined formula for sellable availability computed in one place, an event-driven propagation mechanism paired with scheduled reconciliation, and governance that restricts who can write to the owned number. Component tools matter less than these decisions, because they define the behavior the components have to produce.

Do you need one platform for unified commerce, or can you integrate systems?

You do not need a single native platform. Unified commerce is defined by one source of truth per domain, which you can achieve either on a native platform or by integrating best-of-breed systems around a central owning record or integration layer. The requirement is that every system defers to one authoritative number, not that they all live in one product.

Where should the source of truth for inventory live?

It should live in the system closest to where stock physically changes, with sellable availability computed one layer up. If physical counts are most accurate in the ERP or warehouse system, that system owns on-hand and the storefront reads a derived number. If allocation logic is richest in an order management system, that can own availability. The rule matters more than the specific system.

Where do most unified commerce builds stall?

At two points. First, when the build meets returns, reservations, and multi-location stock, which move inventory in ways a sync watching only completed sales never sees. Second, at governance, when no rule restricts who can write to the owned number, so the source of truth erodes through well-meaning manual edits over time. Both are designed for, not discovered later.

Key takeaways

• A unified commerce architecture is a build sequence, not a product checklist. Its core requirement is deciding which system is allowed to be wrong, per data domain.
• Assign one owning system per domain and write the rule down. “Both systems keep it in sync” is the absence of a rule and the origin of drift.
• Sellable availability is a formula, not a raw count. One system must compute it and publish the single number every channel sells against.
• Propagation needs both halves: event-driven updates to stay current, and scheduled reconciliation to stay honest.
• Builds stall in two predictable places: the movements a sync never sees (returns, reservations, locations) and the absence of governance over who may write to the owned number. Design for both from the start.

A unified commerce architecture earns the phrase “one source of truth” only when the whole stack agrees to defer to a single number it can all read. That is a decision first and a build second, and getting the decision right is what makes the build worth commissioning. If you can answer the four questions, you are most of the way there. If you cannot yet, that is exactly the conversation worth having before the first connector is bought.