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.

When those discrepancies go unreconciled, you end up making ordering decisions against the wrong numbers. Order too little and you get stockouts. Order too much and you tie up working capital. Both have happened on accounts I've worked on, because the count someone fed into a reorder decision came 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. None of the data is wrong. Each system is just reporting a different point in the process.

Sometimes it is a genuine error: SKUs missing from the sales specifications in a planning tool, filtering rules that exclude certain order types, or integration settings that map a product identifier incorrectly across systems. These create persistent discrepancies that don't self-correct. Those are the dangerous ones, because the gap widens over time and compounds with every order placed 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 rolled every location into a single number. The Canada inventory was there. It just wasn't being reported on its own. For multi-warehouse brands, you have to report by location, or you end up making decisions against a number that can hide 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, a brand's 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.

None of this is a problem you solve once. Integration lag is ongoing, sync issues recur, and new products keep getting misconfigured. Checking for discrepancies has to be as routine as reviewing reorder recommendations, because doing one without the other just gives you confident decisions built on unreliable data.