Inventory sync: prevent overselling across store, ERP and warehouse

Which stock quantity should sales channels publish?

Publish the defined sellable quantity, not an unexplained physical total. Document how reservations, holds and incoming goods affect availability.

Write down which system calculates sellable stock and which systems consume that result. Include reservations, stock holds and incoming goods. The definition should be understandable to the people handling orders, not only to the integration developer.

Shopify’s inventory states provide one documented example of these distinctions. Your ERP or warehouse may use different labels, so map the meaning rather than assuming fields with similar names are equivalent. Keep that mapping alongside the operating brief.

Reference: Shopify: Inventory states

How should variants, bundles and locations be mapped?

Use stable variant identifiers and explicit location rules. Define component reservation for bundles rather than assuming a parent quantity is sufficient.

A total across several locations can hide an important delivery constraint. Specify which location may fulfill each channel or order type and how quantities are combined. Stock in transit should not silently become available in two places at once.

Use stable identifiers for variants and an explicit mapping for bundles. When a bundle consumes components, the available bundle quantity needs a defined calculation. Simply copying a parent product quantity does not prove the components are reserved correctly.

Describe how new products and locations enter the connection. An unmapped variant should create a visible exception rather than quietly disappearing from updates. Also define what an archived item means for old orders that still need fulfillment or a return.

Why combine stock events with reconciliation?

Notifications can repeat or be missed. Reconciliation compares current intended and reported states so stale availability can be found and corrected.

Events can make updates timely, but the receiving system still needs to handle interruption and repetition. A missed change can leave a stale quantity without producing a visible error in the destination. Plan a way to compare the actual current state with the intended state.

Shopify documents behaviors that require care when consuming webhooks. In your brief, ask how the integration recognizes old or repeated messages and how it recovers after an outage. Do not assume that arrival time alone determines which stock value is newest.

Reference: Shopify: Webhooks

Set a reconciliation process with a scope, owner and action for discrepancies. It might compare selected locations or products in manageable batches. The schedule and load need to fit the systems involved; “real time” is not a substitute for a measurable operating agreement.

How should last-unit and cancellation cases be tested?

Observe reservation and availability in every connected channel, then cancel and repeat the notification. Verify that stock is released only once and document any competing-sale policy.

Use the last sellable unit as an acceptance case. Place an order, observe the reservation and check every connected channel. Then cancel the order and verify that the release happens once, even when the notification is repeated.

Test two purchase attempts close together and document the expected outcome. A synchronization design cannot promise that every distributed race disappears. Your business needs an explicit policy for overselling exposure, safety buffers and the handling of a remaining conflict.

Check partial fulfillment and returns separately. Shipping part of an order, canceling the rest and later receiving an item back should each produce the intended quantity change. Compare the final stock figures against physical and order records rather than relying only on a successful API response.

How should operators recover from a stock discrepancy?

Provide product, location, expected quantity and known update state. Approve a targeted correction and verify the result instead of blindly replaying old totals.

When a discrepancy appears, the team needs the product, location, expected quantity, reported quantity and last successful update. This context makes a correction reviewable. An unexplained “sync failed” label pushes investigation into manual guesswork.

Define when automatic updates pause and who may authorize a correction or replay. A broad full resync can overwrite valid manual work if the source and timing are unclear. Capture the cause and verify the result after the selected recovery action.

Review recurring discrepancy patterns. An integration that repeatedly needs the same manual correction may have an incorrect ownership rule or an unsupported product case. Fixing that shared rule is more useful than routinely adjusting the visible quantity in one channel.