Connecting stock and fulfilment so the numbers stay true
The day a store sells something it does not have is the day the operations conversation finally happens. It is rarely caused by bad counting; it is caused by two systems both believing they own the number.
Integration work is mostly the discipline of deciding, once, who owns what.
Decide the source of truth first#
| Data | Usual owner | Consequence of getting it wrong |
|---|---|---|
| Stock level | Warehouse or ERP | Overselling and cancellations |
| Price | ERP or store, never both | Customers charged the wrong amount |
| Product master data | PIM or ERP | Divergent catalogues nobody trusts |
| Order status | Store | Customers told two different things |
| Customer record | Store or CRM | Duplicate accounts and lost history |
Synchronisation patterns and when each fits#
- Push on change with webhooks: fastest, best for stock; needs retries and a replay path.
- Scheduled full sync: simple and slow; fine for product data overnight, wrong for stock.
- Scheduled delta sync: the common middle ground; requires reliable change timestamps.
- On-demand lookup at checkout: accurate for scarce, high-value goods; adds latency and a dependency.
Buffers beat cleverness#
For most stores the practical answer to overselling is not real-time perfection but a small safety buffer per product plus honest availability language. "In stock" and "Usually ships in 2–3 days" carry different promises, and using them accurately prevents more complaints than any sync ever will.
Set the buffer per product line, not globally. Fast-moving items need more.
Design the failure behaviour#
When the ERP is unreachable, what does the store do? Serve last-known stock, block checkout, or accept and flag for review? Choose deliberately, write it in the runbook, and test it by turning the connection off in staging.
Frequently asked questions
How real-time does stock need to be?
For most catalogues, minutes plus a small buffer. Real-time matters for scarce, high-value or one-of-a-kind goods.
Can two systems both own price?
No. That is the definition of a pricing incident waiting to happen.
Where should the integration logic live?
In one place with a log you can read, not spread across three apps.
inventory integrationerp integrationfulfilmentstock synchronisationoverselling
