Inventory sync with your accounting or ERP
How stock, orders and products stay in step between the store and the systems behind it, and where sync goes wrong.
The short answer
A store with a back office, accounting or an ERP has data flowing in both directions: products and prices out to the store, stock levels out to the store, orders in to the back office, fulfilment and returns back to the store, payouts to accounting. Keeping it all in step is an integration, and the single rule that prevents most of its failures is ownership: one system owns stock levels, and everything else reads from it. Two systems both writing stock is how a store sells what it no longer has. The sync itself must be idempotent so retries never duplicate, logged so any record can be traced, and monitored so the order that did not post or the stock update that failed reaches a person the same day.
The flows
| Flow | Direction | Owner | What goes wrong |
|---|---|---|---|
| Products, variants, prices | Back office to store | Back office | Variants matched by name drift; prices updated in the store by hand and overwritten |
| Stock levels | Owner to store | Warehouse or ERP, or the store if there is no back office | Two writers; nightly-only sync; bundles ignored |
| Orders | Store to back office | Store | Duplicates after retry; customer or product not found; tax and discount mapping |
| Fulfilment and tracking | Back office to store | Back office | Status not mapped; partial shipments |
| Returns and refunds | Both, by rule | Defined per case | Stock not restored; refund not posted |
| Payouts and fees | Payment provider to accounting | Provider | Fees not reconciled; multi-currency |
Building it
- Decide the owner for stock, prices, products and customers, in writing.
- Map identifiers: a stable identifier per product and variant shared by both systems, never a name.
- Choose the mechanism: a connector product for standard systems, or a custom integration through both systems’ interfaces for specific needs.
- Make stock updates event-driven with a periodic full reconciliation to catch drift.
- Make order posting idempotent, keyed on the store’s order identifier.
- Log every sync event with identifiers on both sides, and alert on failures and on silence.
- Route exceptions to a person with context: which order, which product, what failed, what to do.
- Test the unhappy paths: a product missing in the back office, a stock update during a sale, a refund of a partial order.
Starting in the right order
Not every flow needs building at once. Start with the one that causes the most manual work or the most errors: usually orders flowing to the back office, which staff otherwise retype, and stock flowing to the store, which otherwise oversells. Products and prices next. Fulfilment, returns and payouts after. Each flow is tested and monitored before the next, and the exception queue is watched from the first day.
What this means for you
Decide who owns stock, prices, products and customers, map identifiers properly, build the flows event-driven with reconciliation, make them idempotent and logged, and route every exception to a person. Start with orders out and stock in. Inventory sync done this way is invisible when it works and visible within the hour when it does not, which is the only acceptable state for the numbers that decide whether you can fulfil what you sold.
Frequently asked questions
Which system should own stock?
The one closest to the physical goods: the warehouse or ERP system for businesses with a back office, the store platform for businesses that only sell online from one location. Decide once, make every other system read stock from the owner, and never let two systems write the same stock level. Most oversells trace back to two writers.
How often should stock sync?
As often as stock changes matter to the customer: near real time through events for fast-moving products, every few minutes as a fallback, with a full reconciliation daily. A nightly-only sync sells stock that left the warehouse this morning. Event-driven updates with a periodic full reconciliation catch both the fast changes and the drift.
What about products with variants and bundles?
Variants must map one to one between systems with a stable identifier, not a name that someone might edit. Bundles need a rule: stock computed from components, and a sale decrementing each component. Both are where syncs silently drift when set up by matching names or ignoring components.
Sources
- Shopify Help Center: Inventory (accessed 2026-09-12)