A Polish retailer sells the same outdoor equipment through its website, a trade desk and two warehouses. An item appears physically present in Poznań. A customer in Gdańsk places an order with a delivery promise. The warehouse then discovers that the unit was already committed to another transaction, while incoming replacement stock will arrive after the dispatch cutoff. The stock counter was accurate in one sense and commercially misleading in another.
Available-to-promise software must combine inventory state, location eligibility and fulfilment timing. For a retailer adding channels or connecting Shopify to an ERP, a single quantity copied between systems cannot express those decisions. The integration needs a clear account of what is physically present, what is committed and what can actually reach the customer.
A 2026 platform change makes the distinction timely
Shopify's 5 August 2026 inventory announcement explains that active holds associated with draft orders and transfer shipments are moving from the reserved state to committed. It states that available and on-hand quantities are unchanged. This is a semantic integration change, not evidence that every affected retailer suddenly has incorrect stock.
The risk sits in custom assumptions. An old connector might subtract both quantities, treat committed stock as belonging exclusively to customer orders, or build an exception report around a state that no longer contains the expected records. Review the meaning of the fields your system uses before changing formulas or replaying inventory updates.
Create a state mapping that names each source, its authority and the business interpretation. Make it understandable to a warehouse manager as well as an API developer. If two systems disagree, somebody must know which record determines whether an order can proceed.
Model the promise separately from the physical count
Imagine six units at one warehouse. Two belong to confirmed customer orders, one is damaged, one is awaiting inspection and two are freely sellable. The website should not advertise six ready-to-dispatch units. Nor should it automatically offer both free units if a local trade customer is reserving one through another channel at the same moment.
An available-to-promise decision also depends on the order's destination, cutoff, carrier and eligible fulfilment locations. Stock in a location that cannot fulfil that channel is not an interchangeable substitute. Shopify's inventory state documentation distinguishes these states and explains that committed quantities follow Shopify operations rather than direct quantity adjustments.
Keep the customer promise as a recorded decision with its inputs and timestamp. If a later warehouse correction changes the plan, customer service should see why the promise changed. A history of overwritten numbers cannot explain that conversation.
Reservations need an owner and an end
A reservation is a temporary claim with explicit rules. Decide which system creates it, how long it lasts and which event converts it into an order commitment. A payment timeout, abandoned trade quote or cancelled transfer should have a defined release path.
Race conditions matter more than dashboard polish. Two checkout processes can read the same final unit before either writes a reservation. The system responsible for allocation must perform a concurrency-safe operation, such as a transaction or a supported conditional update. Re-reading a quantity immediately before writing it does not, by itself, make the whole sequence atomic.
Retries need the same discipline. If an integration repeats an order event after a network timeout, it should recover the existing reservation rather than allocate another unit. Link the business operation to a durable identifier and record its outcome. Treat an uncertain response as something to reconcile, not a reason to blindly repeat every mutation.
Warehouse transfers are a journey, not instant replenishment
Moving stock from Wrocław to Poznań creates several moments: planned, picked, dispatched, received and accepted. The destination should not promise goods as immediately available merely because the origin marked them dispatched. Partial receipt and damage can alter the final quantity.
Represent that journey explicitly and decide when incoming stock may support a future delivery promise. That decision should use the retailer's own lead-time evidence and tolerance for uncertainty. A promised date that depends on an unconfirmed arrival should be labelled and handled differently from stock already ready for picking.
Returns create a similar distinction. A returned item may be physically inside the building but require inspection, repacking or disposal. Make the condition transition visible. Otherwise, the integration can sell an item before warehouse staff have established that it is suitable for sale.
Commission a reconciliation desk before another connector
The first useful screen may be a queue of disagreements: stale channel updates, missing acknowledgements, unexplained negative quantities and reservations past their expected end. Give each exception a responsible team and a safe resolution action.
Avoid a repair button that simply overwrites every channel with the largest number. Show the source records, timing and proposed adjustment. Preserve an audit trail so operations can separate a legitimate stocktake correction from a duplicate integration event. Reconciliation should restore a known business state, not merely make two numbers match.
Start a pilot with a limited SKU set and two locations. Include the last-unit race, duplicate order delivery, payment expiry, split shipment, partial transfer receipt, return inspection and a temporary API outage. Measure unexplained discrepancies and exception resolution time against the existing process. Agree success thresholds before the pilot begins.
Our guides to integration project scope and event-driven architecture explain how ownership and delivery semantics affect this work. The platform connection is useful only when the underlying stock decisions remain consistent.
TuniCyberLabs develops retail integrations and custom operational software. Send us one example of a stock promise your current system gets wrong. We can map the states, contention points and acceptance scenarios before proposing a wider implementation.