Inventory Synchronization

Almost every warehouse automation project I have worked on eventually arrives at the same unglamorous crisis. The robots pick, the conveyors sort, the dashboards glow, and then a customer orders the last unit of a product that three different systems each believed was still in stock. The sale goes through. The warehouse cannot fulfil it. Someone in customer service writes an apology, and someone in finance writes off the goodwill credit. Nobody wrote a line of bad code. The failure was that the warehouse management system, the ERP and the e-commerce store were each keeping their own copy of the same stock number, and those copies had quietly drifted apart. That drift is what inventory synchronization exists to prevent, and it is the subject of this guide. This article is one piece of the broader warehouse automation complete guide, which frames where synchronization sits among the other moving parts of an automated operation.

The message up front: inventory synchronization is not a feature you switch on, it is a discipline you design. The goal is that one physical unit of stock is represented by one authoritative number, and that every system which needs to know that number sees the same value within a latency window you have chosen on purpose. Get the source of truth and the propagation right and overselling largely disappears. Get it wrong and no amount of automation downstream can save you.

1. Why inventory sync is hard

On the surface, keeping a stock count consistent across a few systems sounds trivial. It is a single integer. How hard can it be to copy an integer from one place to another? The difficulty is not the copying. It is that inventory is not a static value sitting still while you replicate it. It is a live quantity being changed simultaneously by many independent actors, each of which has a legitimate reason to move it, and each of which touches a different system first.

Consider a single stock keeping unit on an ordinary trading day. A customer places an online order, and the webstore wants to decrement availability immediately so the next shopper does not buy the same unit. A warehouse operator picks stock for a wholesale order, and the warehouse management system decrements the on-hand count when the pick is confirmed. A goods receipt lands at the dock, and the ERP increments the count when the purchase order is received. A cycle count finds two fewer units than the record claimed, and an adjustment corrects the ERP. A return comes back, is inspected, and is put away, incrementing the warehouse count again. Five events, three systems, one number, all in the space of an hour. Synchronization is the problem of making sure that after all five events, every system agrees on what is actually on the shelf.

Several forces make this genuinely hard rather than merely fiddly. The first is timing. Events do not arrive in a tidy queue; they overlap, and two systems can both act on the same unit before either has heard about the other. The second is representation. The webstore usually cares about a single number, availability, while the warehouse cares about a richer picture: on hand, allocated, in transit, quarantined, damaged. Reducing that richer picture down to the one number the store needs is a lossy translation, and lossy translations are where errors breed. The third is latency. There is always a delay between a change happening and every other system knowing about it, and during that delay the systems disagree by definition. The only question is how long the window of disagreement lasts and whether it is short enough that nobody notices. The fourth is failure. Networks drop, queues back up, and services restart mid-update, so the sync mechanism has to be correct not only when everything works but also when messages arrive late, twice, or out of order.

2. The single source of truth

Every durable inventory synchronization design rests on one decision made early and defended stubbornly: which system owns the authoritative stock number. This is the single source of truth. It is the system whose count is correct by definition, the one every other system is trying to agree with rather than argue against. When people skip this decision, they end up with several systems each convinced it is right, and reconciliation becomes an endless negotiation between equals with no referee.

In a warehouse-centred operation, the warehouse management system is usually the right owner of the physical on-hand quantity, because it is closest to the shelf. It knows what was picked, received, put away and counted, in real physical space. The ERP typically owns the financial and planning view of inventory, and the e-commerce store owns nothing authoritative at all; it holds a published, cached view of availability that is derived from the source of truth and pushed outward. The store should never be allowed to become an origin of stock truth, only a consumer of it, because a store that decrements its own copy without confirming against the source is exactly how oversells happen.

The diagram below shows the pattern I aim for. One system holds the authoritative count. Change events, a pick, a receipt, an adjustment, originate wherever the physical or financial reality changes, are applied to the source of truth, and then propagate outward as published updates to every system that needs a view. Truth flows from one place; views flow to many.

The value of naming a single source of truth is that it turns every disagreement into a resolvable question rather than a standoff. When two counts differ, you do not debate which is right; you ask what the source of truth says and treat everything else as a stale view to be refreshed. That principle is not unique to inventory. It is the same discipline that underpins any master-data or replication design, which I cover more generally in what is data synchronization.

3. Sync approaches compared

Once you know which system owns the truth, the next choice is how updates travel from it to everything else. There are four broad approaches, and the right one depends on how much latency your business can tolerate and how much conflict risk you are willing to manage. They are not mutually exclusive; most mature operations mix them, using event-driven sync for the high-value, fast-moving flows and scheduled batch for the slower, tolerant ones. The table below lays out the trade-offs.

The single most common mistake I see is reaching for two-way sync when one-way would do. Two-way sync is seductive because it feels complete, but it is the approach that invites conflict, and every conflict needs a resolution rule that someone has to design, test and maintain. If a system only ever needs to read the availability number, publish to it one way and forbid it from writing back. Reserve two-way sync for the genuinely rare cases where two systems each own a legitimate slice of the truth and neither can be demoted to a read-only consumer.

4. Real-time events versus scheduled batch

The choice between real-time event-driven sync and scheduled batch sync is the one that most shapes how the operation feels day to day, so it deserves its own treatment. They are not competitors so much as tools for different jobs, and the practitioner's skill is knowing which flow belongs to which.

Real-time event-driven sync means that the moment a stock-changing event happens, a message describing that change is emitted and delivered to every interested system within seconds. A pick is confirmed, a message flows, the webstore availability drops. This is what you want for fast-selling online products where the cost of a stale count is an oversell and an unhappy customer. The strength is freshness. The cost is operational complexity: you now run a message broker or event pipeline, you have to make delivery reliable, and you have to handle the awkward cases of duplicate and out-of-order messages. Done properly, real-time sync keeps the window of disagreement down to seconds, which for most storefronts is short enough that the race conditions almost never surface.

Scheduled batch sync means that changes are collected and applied on a timer: every five minutes, every hour, overnight. Nothing is emitted at the instant of change; instead a job wakes up, gathers everything that moved since the last run, and pushes it across. The strength is simplicity and robustness. There is no broker to run, the load is predictable, and a failed run just retries on the next cycle. The cost is latency, and with latency comes drift. Between two batch runs the systems disagree by exactly the volume of activity in that window, and on a fast-moving product that window can be long enough to oversell many times over. Batch sync is the right tool for slow movers, for reconciliation sweeps that catch anything the real-time path missed, and for feeds where minutes or hours of staleness genuinely do not matter, like nightly reporting.

The honest limitation: real-time sync reduces the window of disagreement, it never eliminates it. There is always a moment, however brief, when a change has happened in one system and not yet reached another. On a very high-velocity item, two shoppers can still both hit "buy" inside that window and both succeed against a count that only had one unit. Real-time sync makes this rare, but only a safety buffer or an availability check at the point of order confirmation makes it safe. Treat freshness and correctness as two separate problems.

My default architecture combines both. Real-time events carry the urgent, high-value changes so the storefront stays fresh, and a periodic batch reconciliation runs underneath as a safety net, comparing every system against the source of truth and correcting any drift the event path let slip. The batch job is not a competitor to the event stream; it is the auditor that keeps it honest. For the storefront side of this freshness problem specifically, I go deeper in real-time inventory tracking.

5. One-way versus two-way and conflict handling

Direction is where inventory sync designs quietly succeed or fail. A one-way sync has a single writer and one or more read-only consumers. Truth flows out from the source; nothing flows back. This is by far the safest arrangement, because there is only ever one authority for a given field, so there is nothing to reconcile. When the source says the count is forty, every consumer becomes forty, full stop. Most inventory relationships should be one-way: the source of truth publishes availability, and the webstore, the marketplace channels and the reporting systems all consume it without ever writing back.

A two-way sync allows both ends to change the same field and expects the mechanism to merge those changes. This is where conflict lives. Imagine the ERP records a goods receipt of ten units at the same moment the warehouse records a cycle-count adjustment of minus two, and both changes target the same on-hand field before either has seen the other. Now you have two competing updates and no obvious winner. Something has to decide, and that something is your conflict-resolution policy. The common strategies each have a failure mode you must understand before choosing:

• Last write wins: whichever update carries the later timestamp is kept. Simple, but it silently discards the other change, which for inventory means you can lose a real receipt or a real adjustment and the count ends up wrong with no error raised.
• Source-of-truth authority: one system is declared the winner for that field regardless of timing, and the other side's write is rejected or converted into a request the source can accept or deny. This is usually the correct answer for stock counts, because it preserves the single-authority principle even inside a two-way channel.
• Delta-based merging: instead of syncing the absolute count, you sync the change itself, plus ten and minus two, and let the source apply both. This avoids losing either change and is the most robust option for genuine two-way inventory, but it requires that every event be expressed as a delta and applied exactly once.
• Manual review queue: irreconcilable conflicts are parked for a human to judge. Necessary as a backstop for the rare cases automation cannot safely resolve, but a queue that fills up faster than anyone drains it is just a slower way to be wrong.

The principle I hold to is that inventory counts should almost never be truly two-way. Model every change as a delta event flowing into the single source of truth, and publish the resulting absolute count outward one way. That way there is no field two systems both own, and the whole category of conflict simply does not arise. Two-way sync with conflict resolution is a tool for the genuinely unavoidable cases, not a default posture. The multi-location version of this problem, where the same SKU sits in several warehouses and "available" depends on which one you ask, deserves its own careful treatment, which I give in inventory visibility across multiple warehouses.

6. Overselling, safety stock and buffers

Everything above is in service of one outcome the business actually cares about: not selling what you cannot ship. Overselling is the visible symptom of a synchronization failure, and it is expensive out of proportion to its frequency, because each incident costs a refund, a lost customer, and sometimes a marketplace penalty. But it is important to be precise about what causes it, because the fix depends on the cause.

Some oversells are pure sync failures: the count was stale because an update did not propagate in time, and a customer bought against a number that no longer reflected reality. The fix for these is tighter synchronization, real-time events on the fast movers, and a reconciliation sweep to catch drift. But some oversells happen even with perfect synchronization, because of the irreducible race window described earlier, where two orders land inside the propagation delay. No sync mechanism closes that window entirely, which is why synchronization alone is not a complete answer to overselling.

The tool that covers the residual risk is the buffer, and it comes in a few forms. A safety-stock buffer publishes a slightly lower availability than the true on-hand count, holding back a few units so that a burst of near-simultaneous orders eats into the buffer rather than into stock you do not have. A per-channel allocation splits the true count into ring-fenced pools so that the webstore, the marketplace and the wholesale desk each draw from a reserved slice and cannot collectively oversell a shared pool. And a point-of-confirmation check re-validates availability against the source of truth at the exact moment an order is confirmed, catching the race that the published number missed. In high-velocity operations I use all three: a small safety buffer for the common case, allocation to keep channels from colliding, and a confirmation-time check as the final guard on the units that matter most.

The trade-off is honest and worth stating plainly. Every unit you hold back in a buffer is a unit you are choosing not to sell in order to avoid the cost of an oversell. Set the buffer too high and you leave revenue and shelf space idle; set it too low and the oversells leak through. The right buffer size is a business decision informed by velocity and by the real cost of an oversell for that product, not a technical constant. Fast, high-margin, reputation-sensitive items justify a generous buffer; slow, forgiving items need almost none.

7. A practical sync architecture

Pulling the threads together, here is the architecture I reach for on a typical warehouse, ERP and webstore setup. It is deliberately unexotic, because inventory synchronization rewards boring reliability over clever design.

• Name the source of truth and defend it. The warehouse management system owns physical on-hand. Write it down, socialise it, and make sure no other system is allowed to originate a stock count. Every other view is derived.
• Model changes as events, not states. Emit "picked two", "received ten", "adjusted minus two" rather than syncing absolute totals between peers. Delta events applied to a single authority are naturally conflict-free and naturally auditable.
• Make every event idempotent and ordered. Give each event a unique id so a message delivered twice is applied once, and carry a sequence or version so a late-arriving message cannot overwrite a newer state. These two properties turn an unreliable network into a reliable sync.
• Publish availability one way. The source computes availability, subtracts the safety buffer, and pushes the result to the webstore and channels as read-only. None of them writes back.
• Use real-time events for fast movers, batch for the rest. Carry the urgent, high-velocity changes on the event path, and let slower stock ride a scheduled sync. Match the mechanism to the velocity and the cost of staleness.
• Run a reconciliation sweep underneath. On a regular cadence, compare every consuming system against the source of truth and correct any drift. This is the auditor that catches whatever the event path dropped, and it is the single most valuable safety net in the whole design.
• Check availability at order confirmation. For the items where an oversell hurts most, re-validate against the source at the moment of commitment, so the published number being slightly stale never becomes a promise you cannot keep.

Where this fits the bigger picture: inventory synchronization is one integration among several that an automated warehouse depends on, and it is worth reading it alongside the rest of the stack. The warehouse automation complete guide sets out how synchronization connects to picking, receiving and the wider control layer, and shows why a beautifully automated floor still fails if the numbers feeding it are wrong.

When the source of truth is an ERP such as Microsoft Dynamics 365 Business Central, the practical work of emitting and consuming these events comes down to the platform's own integration surface, its APIs, events and connectors. The mechanics of building that surface cleanly are worth their own study, which I cover in Business Central APIs and integrations. The architecture principles here stay the same regardless of vendor; only the connectors change.

8. References

The following give useful grounding on the patterns behind reliable inventory synchronization:

• Enterprise Integration Patterns, Gregor Hohpe and Bobby Woolf, on messaging, idempotent receivers, and guaranteed delivery, which underpin event-driven sync.
• Designing Data-Intensive Applications, Martin Kleppmann, on replication, ordering, and the concurrency and conflict problems that appear whenever one value is copied across systems.
• Microsoft Dynamics 365 Business Central documentation on API endpoints, webhooks and change tracking, for the ERP side of the integration.
• GS1 standards on the global identification of trade items, which give a stable basis for matching the same product across the WMS, ERP and storefront.
• APICS / ASCM guidance on available-to-promise and safety stock, for the buffer and allocation logic that covers the residual overselling risk.

Final thoughts

Inventory synchronization never shows up as a headline feature. Nobody demonstrates it in a launch deck, and nobody thanks the team when it works, because when it works the only evidence is the absence of a problem: no oversells, no phantom stockouts, no reconciliation meetings arguing over which count is right. It is felt entirely through its failures, which is exactly why it gets underinvested in until the first painful incident forces the conversation.

The discipline that prevents those failures is not complicated, but it does require conviction. Name one source of truth and never let another system quietly become a second one. Model every change as a delta event, make those events idempotent and ordered, and publish availability outward one way. Match real-time sync to the fast movers and batch to the rest, run a reconciliation sweep as your auditor, and cover the irreducible race window with a buffer and a confirmation check. Do that, and one physical unit of stock will mean the same thing in the warehouse, the ERP and the storefront, which is the whole point. Skip it, and you will keep writing apology emails while the dashboards insist everything is fine.

If you are automating a warehouse and the numbers keep disagreeing across your systems, that disagreement is not a mystery to live with; it is a design gap to close. Fix the source of truth, fix the propagation, and the oversells and stockouts that trace back to it fade away.

Related reading: Warehouse automation: the complete guide, Real-time inventory tracking, Inventory visibility across multiple warehouses, What is data synchronization, Business Central APIs and integrations.