# The multi-system inventory discrepancy problem
Flieber says 500 units. Skubana says 487. Seller Central says 510. Which number do you order against?
This is not a hypothetical. For any brand managing inventory across Amazon FBA, one or more 3PL warehouses, and a planning tool, some version of this discrepancy is happening right now. The numbers don't match because they were never designed to match in real time. Each system maintains its own inventory model, updates on its own schedule, and counts the same units differently depending on their current status in the fulfillment process.
The downstream effect of unreconciled discrepancies is ordering decisions made against wrong numbers. Ordering too little leads to stockouts. Ordering too much ties up working capital. Both have happened on accounts I've worked on because the inventory count someone used as the input to a reorder decision was pulled from the wrong system.
Why the numbers diverge
Integration lag is the most common cause. Seller Central updates when Amazon receives a shipment. Skubana or Extensiv may update when the shipment is confirmed as sent. Flieber updates on its own sync schedule. At the same moment, they may be representing three different states of the same physical transaction. The data isn't wrong — it's just describing different points in a process.
Sometimes it is an error. SKUs missing from sales specifications in a planning tool, filtering configurations that exclude certain order types, integration settings that don't correctly map a product identifier across systems. These create persistent discrepancies that don't self-correct. The persistent ones are the dangerous ones because the gap widens over time and compounds with each ordering decision made against the wrong number.
Finding the authoritative source
The first step in resolving a discrepancy is identifying which system should be treated as correct for which purpose.
For physical units in a 3PL warehouse: the warehouse management system or your 3PL's portal is the authoritative source. If Skubana says 487 and the warehouse portal shows 490, the warehouse portal is right. Skubana's count may lag a receiving transaction.
For FBA units: Seller Central is the authoritative source. Flieber and any other planning tool should be treated as secondary for FBA counts. If they diverge, investigate what Seller Central shows first.
For total inventory position across all locations: no single system is automatically authoritative. You need to build an aggregation that pulls the right number from the right source for each location type and sums them. This is what a master tracking sheet should do, with explicit source mapping.
A $100,000 Canada overstock was completely invisible in a total overstock report because the dashboard was aggregating all locations into a single number. The Canada inventory was there. It just wasn't being reported separately. Segmented reporting by location is not optional for multi-warehouse brands; it's how you avoid making decisions against a number that's hiding a major inventory problem in a secondary market.
The diagnostic process
When a discrepancy appears, run through this in order:
First, check whether the discrepancy is in an in-transit state. Units that have left a warehouse but haven't been received by FBA will often show double-counted or missing depending on which system you're looking at. If the numbers resolve when you account for in-transit units, the systems are working correctly and the discrepancy is temporal.
Second, check for recently received shipments that haven't fully processed. Amazon can take days to receive and count inbound shipments. A recently landed pallet may already be physically in an FC but not yet counted in Seller Central's available inventory. This is normal. It's still worth noting because it means your Seller Central count is temporarily understated.
Third, check for filtering or mapping issues in your planning tool. In one case, Army Painter orders weren't filtering correctly through the OMS, which caused downstream count errors. Filtering bugs in planning tools create phantom inventory or missing inventory depending on what the filter is excluding.
Fourth, if none of those explain the gap, trace back to the last point where the numbers agreed and identify every transaction between that point and now. One of those transactions is counted differently across systems.
Building a daily sync check
The goal is to stop debugging inventory discrepancies as emergencies and turn them into a routine check.
A daily sync process doesn't need to be complex. Pull the count from each authoritative source for your top 20 to 30 SKUs by revenue. Flag any discrepancy above a threshold (say, 3% variance or 10 units, whichever is larger). Investigate flagged items before the day's ordering decisions are made.
This takes 15 to 20 minutes when the process is systematized. It takes 4 hours when you discover the problem after you've already placed a purchase order based on the wrong number.
The bigger operational point is that inventory discrepancies across multi-system stacks are not a problem you solve once. Integration lag is ongoing. Sync issues recur. New products get misconfigured. The practice of checking for discrepancies has to be as regular as the practice of reviewing reorder recommendations, because one without the other produces confident decisions based on unreliable data.
