Syncing ERP inventory with your store without overselling

Every store that sells from shared inventory eventually oversells. A popular product goes live, a marketplace listing and the website both take orders for the last units, and customer service spends a week apologizing. The instinct is to blame the connector or the ERP, but overselling is almost always a design problem: two systems that each believe they know the stock level, synchronized on a schedule that was chosen by default rather than by intent. Here is how we approach inventory sync when the stakes are real.

Decide what each system owns

The first decision is not technical. For every piece of data, one system must be the source of truth and the others must treat their copy as a cache. For inventory, the ERP or warehouse management system is usually authoritative for on-hand quantities, because receiving, returns and adjustments happen there. The storefront is authoritative for what has been sold but not yet fulfilled, because that is where orders originate.

Problems start when both systems write the same number. If staff adjust stock in the store admin and in the ERP, sync will eventually overwrite one with the other, and you will not know which was right. Lock down store-side stock editing, or at least make it a documented exception.

Understand available-to-sell

The number shown to customers should not be raw on-hand stock. It should be available-to-sell, which is on-hand minus reserved minus safety stock. Reserved covers orders placed but not yet picked, across every channel. Safety stock covers the uncertainty of sync lag and counting errors.

available_to_sell = on_hand - reserved_all_channels - safety_stock

Safety stock does not need to be the same for every SKU. For slow movers, zero or one unit is fine. For products that sell dozens of units an hour during a launch, it should cover at least the expected sales during one sync interval. That simple rule eliminates most overselling without any change to infrastructure.

Overselling is not a bug in one system. It is a timing gap between two systems that both think they know the stock level.

Choose sync timing by SKU velocity

Many integrations sync all inventory on a fixed schedule, often every 15 or 60 minutes, because that is the connector default. That is fine for a catalog of slow-moving goods and dangerous for anything with bursts of demand. Better options, in rising order of complexity:

1. Event-driven decrements. When an order is placed on any channel, push the decrement to the ERP immediately rather than waiting for the next batch.
2. Tiered schedules. Sync fast movers every minute or two and the long tail hourly. Most ERPs can handle this if the calls are scoped.
3. Real-time reservation at checkout. For true limited drops, reserve units in a central service when checkout starts and release them on timeout. This is the only approach that fully prevents overselling under heavy concurrency, and it is rarely needed outside drops and ticketing.

For most mid-size stores, event-driven decrements plus sensible safety stock gets overselling close to zero. We typically see oversell incidents fall from several per week to a handful per quarter after that change alone.

Make order posting idempotent

Inventory sync gets the attention, but order posting causes just as many problems. Networks fail, webhooks are retried and ERPs time out while still processing. If the integration retries a failed call without a unique key, the ERP may create the same order twice, reserve double stock and ship two parcels.

• Send the store's order ID as an external reference and have the integration check for it before creating a new record.
• Store the integration state per order: received, posted, acknowledged, failed.
• Retry failures with backoff, and alert a human after a set number of attempts rather than retrying forever.

This is standard practice in good API development, but connectors built quickly often skip it. It is worth checking yours.

Monitor the gap, not just the uptime

An integration can be up and still wrong. Useful monitoring compares the two systems rather than checking whether each is alive. We usually add three checks:

• A nightly reconciliation that compares available-to-sell in the store against the ERP for every active SKU and reports differences above a threshold.
• A queue depth alert if more than a set number of orders are waiting to post.
• An age alert if the oldest unposted order is more than, say, 30 minutes old.

These checks surface drift before customers do. In one project for a home goods retailer, the nightly reconciliation caught a warehouse location that had silently been excluded from the sync for three weeks, a problem nobody had noticed because the website kept working.

Give someone clear ownership of these alerts. Integration monitoring that emails a shared inbox nobody reads is the same as no monitoring. A named owner in operations, with a short runbook for the three or four most common failures, turns alerts into fixes within hours instead of discoveries weeks later.

Where to build it

Off-the-shelf connectors are a good starting point when your ERP and platform are both mainstream and your rules are simple. Once you need multi-location logic, bundles, channel-specific allocation or custom reservation, a purpose-built integration layer is usually cheaper to maintain than stacking configuration onto a generic tool. Our ERP and inventory integration projects often start by auditing the existing connector and only replace the parts that are actually causing drift. For stores that sell across several storefronts, a small middleware service built with our Node.js development team gives you one place to apply allocation rules and log every change.

Stop overselling for good

If inventory drift is costing you refunds and goodwill, we can audit the current flow and propose fixes with a clear scope. Reach out and we will send a fixed-price quote within 24 hours.