Agree what the stock feed means before repairing it
Inventory synchronisation errors often begin with two systems using the same label for different values. A warehouse may report physical stock, an ERP may report available stock after allocations, and Magento may calculate availability for a particular sales channel. Sending one of those numbers into the wrong field can create persistent overselling or unnecessary out-of-stock messages even when the connection itself is reliable.
Midoriweb starts by documenting the meaning and owner of each inventory value. Which system is authoritative, when is the quantity measured, and which commitments have already been deducted? The integration should encode those decisions explicitly rather than depend on a spreadsheet convention understood by only one person.
For differences inside Magento’s own inventory model, use the salable quantity guide. This article focuses on the transfer between systems and how to prove that the correct update reaches the correct destination.
Select a small reconciliation sample
Choose a few affected SKUs with clear histories, including one working example. Record source and destination identifiers, source location, website or sales channel and the expected quantity at a specific time. Avoid comparing values captured at different times while orders and warehouse movements continue.
Include different failure shapes where they exist: missing updates, incorrect quantities, updates arriving late and values that briefly correct themselves before reverting. Those patterns can indicate different causes. One retry mechanism will not necessarily repair all of them.
Keep the sample traceable through the systems. Product names can change or be duplicated, so use stable identifiers and document any SKU transformation. If the integration maps variants or bundles, make those relationships explicit rather than assuming a one-to-one product match.
Trace selection, delivery and application separately
An update can fail before it leaves the source, during delivery or when the receiving system applies it. Establish the last confirmed stage for each sample. A successful API response may acknowledge receipt without proving that the business update was applied as intended.
Record the source event or batch identifier, generated payload, delivery attempt and destination outcome. Redact credentials and unnecessary commercial data in general reports. The objective is to correlate one update, not copy entire production databases into a troubleshooting ticket.
Our ecommerce integration service can help define these checkpoints. A reliable interface makes exceptions visible at the correct stage so operations can distinguish a connectivity incident from a rejected or incorrectly mapped record.
Review SKU, source and unit mappings
Check exact identifier handling, including case, whitespace, leading zeros and any supplier-to-store translation. A spreadsheet export can alter identifiers unintentionally. The receiving system may then reject the row or apply it to an unexpected product if the mapping is too permissive.
Review warehouse or source mapping independently of product mapping. A correct SKU assigned to the wrong source can still produce the wrong availability for the storefront. Confirm how disabled locations, returns stock and non-sellable inventory are represented in the agreed business model.
Units need explicit treatment. A carton quantity is not automatically a unit quantity, and a decimal value may not be valid for every product. Define the conversion and rounding rules with operations, then test them using examples that expose the difference.
Protect against older updates arriving late
Delivery order can differ from event order, particularly after retries or a backlog. Establish how the interface recognises a newer update and whether a delayed old record can overwrite it. Arrival time alone may not represent the freshness of the underlying inventory measurement.
Compare event timestamps, version markers or other ordering information supported by the systems. The correct design depends on whether updates are absolute snapshots or incremental changes. Replaying an increment has different consequences from applying the same absolute quantity again.
Illustrative example: a later warehouse count reaches Magento before an earlier queued count. If the integration simply applies whichever message arrives last, the storefront can move backwards to an obsolete value. The repair should address ordering and reconciliation, not repeatedly resend the latest file manually.
Understand retries and partial batches
A batch can partly succeed. Before rerunning it, determine which rows were accepted and whether repeating them is safe. The interface should provide per-record outcomes or another reliable reconciliation method rather than only a single “job failed” message.
Define what makes an update safe to repeat. Stable external identifiers, version checks and explicit operation semantics can help, but the actual implementation must be tested. Do not assume that a transport library’s retry feature understands the business consequences of the request it repeats.
When automatic retries are exhausted, operations needs an actionable exception. Include the affected identifier, stage and reason, with a controlled recovery path. An endless retry loop can hide a mapping defect and consume capacity without making progress.
Coordinate updates with orders and fulfilment
Inventory feeds do not operate in isolation. Orders, cancellations, shipments and returns may change commitments or physical quantities in different systems. Document which event each system owns and how the combined state should reconcile.
A manual adjustment in Magento may be overwritten by the next authoritative feed. That is not necessarily a software fault; it may be the intended ownership rule. Temporary workarounds therefore need a recorded owner, reason and expiry or reconciliation step.
If orders themselves are not reaching the warehouse, use the ERP and WMS order-sync guide. Fixing stock values alone cannot repair a missing fulfilment event that will continue to distort the operational picture.
Recover a bounded set and verify the next cycle
Once the cause is established, agree the affected set and intended corrected values. Preserve the original evidence and test a limited sample before applying a broad repair. Confirm that the receiving system applies the change to the correct SKU, source and channel.
Then observe the next normal feed and relevant order events. A historical correction is incomplete if the routine process immediately reintroduces the discrepancy. Include a delayed update and a repeated delivery in the test plan where those failure modes are relevant.
Measure freshness as well as correctness. An accurate quantity arriving too late for the business’s sales volume may still create operational risk. Agree acceptable delay and monitoring based on the actual trading process rather than a generic promise of “real-time” synchronisation.
What Midoriweb would deliver
The investigation should produce a clear data-flow map, a reconciled sample, the confirmed failure stage and a prioritised correction plan. If implementation is required, the scope should include repeatability, ordering and exception handling rather than only the happy-path API call.
Our ERP integration and WMS integration services connect those technical decisions with warehouse and finance operations. For the first enquiry, provide the systems involved, affected data, update frequency, example identifiers and observed delay or mismatch. We can then agree the minimum access needed to follow the evidence.
Stock integration questions
Should Magento or the warehouse own stock?
There is no universal answer. Define ownership for each value and event, then ensure the integration reflects the agreed operational model.
Is a successful API response enough?
No. Verify the intended value in the destination and the correct product, source and sales-channel context.
Can we solve mismatches with a nightly full feed?
A full feed may help reconciliation, but it does not automatically resolve incorrect semantics, ordering or duplicate deductions. Those causes need explicit correction.