Connecting your online store and warehouse: how to avoid inconsistent stock

The problem doesn't start when the two systems talk to each other: it starts when they report different numbers and no one decided in advance which one to trust. Selling an item you don't have costs a refund, an apology, and sometimes a customer; keeping one you do have locked up costs a sale that no one counts. Connecting an online store to the warehouse is mainly about establishing who's in charge, and what happens when something goes wrong.

The technical part is the easiest. The hard decisions are commercial, and they need to be made before the connection is set up: afterward they become patches.

Stock and sellable availability aren't the same number

The most costly confusion is between how many units are in the warehouse and how many can be sold right now. Between the two lies everything that's already been promised to someone.

• Physical stock: what's counted on the shelves, including returns not yet put back.
• Committed: units from accepted orders not yet shipped, including sales made in-store, by phone, and by reps.
• Incoming: goods ordered from the supplier, with a date that's a forecast, not a fact.
• Reserved: safety stock, sample range, defective units awaiting inspection, material earmarked for a specific customer.

Sellable availability online is what's left over. If the number published is the physical stock, you're also selling what already belongs to someone else.

One official source, decided before the connection

When the two systems diverge, one of them needs to be right by rule, not by discussion. The three possible setups, with the case where each one holds up.

Setups where both systems can modify the availability of the same code generate the incoherencies that are hardest to untangle: two truths and no referee.

The last unit: the sequence that breaks everything

The case to design for isn't the normal sale, it's the simultaneous one. An illustrative sequence, with only one unit available.

1. At 10:31, an online customer puts the item in their cart. If the cart doesn't reserve anything, the item remains sellable to anyone.
2. At 10:32, the owner sells the same item in the store and deducts it from the business management system.
3. At 10:33, the online customer pays. The store accepts the order because its copy of the availability is still at the previous value.
4. At 10:35, synchronization aligns the numbers and availability goes below zero. There's one item and two orders.
5. At 10:36, someone has to notice. If there's no alert, the warehouse worker will notice while preparing the order, or the customer will, when they receive nothing.

The three levers that reduce this case: reserve availability at payment rather than at shipping, shorten the sync interval on low-stock codes, and decide in advance who has priority when it happens anyway. None of the three eliminates it: simultaneity is a fact, not a defect to fix.

When synchronization fails, and sooner or later it does

A connection between two systems goes down: maintenance, expired credentials, a modified code, a network outage. The question isn't whether it will happen, but what happens in the meantime.

• Undelivered changes stay queued and get processed in order once the connection is back, instead of being lost.
• A change sent twice must not deduct twice. Either you transmit the resulting value instead of the difference, or every movement carries an identifier that prevents it from being applied twice.
• If synchronization has been down for a defined amount of time, someone gets alerted. A connection broken silently is worse than one that's absent, because the numbers keep looking valid.
• A periodic reconciliation compares the two systems code by code and produces a list of differences to review, not an automatic correction that hides the cause.

Buffer or sell to zero: it's a business choice

Keeping a few units unavailable online reduces cancellations but ties up stock; selling down to the last unit makes full use of the warehouse and increases exceptions. There's no technical answer: it depends on what each of the two costs you.

• A buffer makes sense on codes that sell across multiple channels and turn over quickly.
• On slow-moving, high-value codes, a buffer is dead money: it's better to sell down to zero and handle the exception when it happens.
• For made-to-order products, availability isn't the right number: the promise is a delivery time, and it should be written as such.
• Inventory never matches the system perfectly, due to breakage, shortages, and misplaced stock: a buffer absorbs this too.

Edge-case orders to test before launch

Before connecting the store to the public, test the cases that never come up during a demo, with real goods and real people.

1. Simultaneous sale of the last unit on two channels, with synchronization active.
2. An order canceled by the customer and one canceled by you: the item becomes sellable again, and you verify how long it takes.
3. A return received: the item goes back in as sellable, pending inspection, or as scrap, and you establish who decides.
4. A product with size, color, or packaging variants: availability is managed per variant, not per parent product.
5. Kits and bundled products: what happens to the kit when one of its components runs out.
6. Connection down for an hour during sales and then restored: no movement lost, none applied twice.
7. A new code created in the business management system: when it appears online and with what minimum data.

What this guide doesn't cover

This guide covers the consistency of availability across systems. How the warehouse is physically organized, with locations, movements, and inventories, is a different problem, and sometimes it's the real cause of the wrong numbers. The checks to run before promising an integration between two pieces of software, when one of them wasn't designed to be connected, are also covered separately.