Stock Numbers Do Not Match? Run a One-SKU Audit

Shopify says ten units are available. The warehouse says seven are on the shelf. The accounts or inventory system shows nine. A manual correction makes them agree until the next order, return or app update.

Do not begin with a catalogue-wide reconciliation. Use the stock numbers do not match diagnosis and trace one SKU closely enough to find the first point where its figures diverge.

One SKU is small enough to investigate, but complete enough to reveal unclear ownership, different stock definitions, missing events and competing writers.

Step 1: choose a useful SKU

Pick a SKU that has shown a repeatable mismatch. The best diagnostic example has had several ordinary events recently, such as a sale, return, goods receipt or manual adjustment.

Avoid beginning with the most complicated bundle in the catalogue. Start with a standard stocked item with:

• One stable SKU or variant identifier across systems.
• A known physical location.
• Recent transaction history.
• A visible mismatch you can reproduce.

Record the product and variant IDs as well as the human-readable SKU. Names and descriptions change. Stable IDs make the audit traceable.

Step 2: freeze the comparison time

Write down one timestamp and collect every system's figure as close to it as possible. Include the time zone.

An inventory audit becomes misleading when Shopify is read at 09:00, the warehouse export is from midnight and the accounting report is refreshed at 10:30. A legitimate order between those times looks like a sync failure.

For each value, record:

Field	What to capture
System	Shopify, marketplace, 3PL, inventory platform, accounts or spreadsheet
Location	Warehouse, shop, virtual location or aggregate
Quantity	The exact number shown
Stock state	On hand, available, committed, unavailable, incoming or valuation only
Timestamp	When the screen or export was current
Identifier	SKU, variant ID, item ID and location ID
Writer	App, integration or person allowed to change it

Take screenshots or exports where practical, but remove customer and supplier data that is not needed for the diagnosis.

Step 3: make sure you are comparing the same stock state

“Stock” is not one number.

Shopify currently distinguishes on-hand, available, committed, unavailable and incoming inventory. Its documentation defines on-hand as the combination of committed, unavailable and available units. Comparing Shopify's available quantity with a warehouse's physical on-hand count can therefore produce a difference even when both systems are behaving correctly.

Write a plain-English definition for every quantity:

• Physical: units actually present at a location.
• On hand: units recorded at the location, including stock not currently sellable.
• Available: units that may be sold now.
• Committed: units reserved for orders or another purpose.
• Incoming: units expected but not yet received.
• Valuation: accounting value, which is not necessarily an operational unit count.

Do not force unlike figures to match. Decide which figures genuinely should agree and at what point in the process.

Step 4: name the owner of each fact

For each stock fact, ask which system is allowed to decide it.

Examples:

• The warehouse may own receipts, picks, damage and physical adjustments.
• An inventory platform may own available-to-sell across channels.
• Shopify may display the quantity supplied by that authority.
• Xero may receive valuation or cost-of-goods entries without owning live availability.

This is an architecture example, not a universal rule. The right ownership depends on the systems and operating process.

The dangerous state is accidental co-ownership. If Shopify, a 3PL app and a second connector can all write an absolute quantity, the latest update can overwrite a correct change from another source.

Step 5: list every writer and route

Draw the SKU in the centre of a page. Around it, list every system, app, import and person that can change a quantity.

For every route, record:

• Direction: who sends and who receives.
• Trigger: sale, fulfilment, return, receipt, transfer or schedule.
• Quantity type: absolute total or adjustment.
• Identifier used for product, variant and location.
• Expected delay.
• Retry behaviour.
• What happens when the destination rejects the update.

Include CSV imports, marketplace apps and manual spreadsheet uploads. They are often invisible in the “main” integration diagram but still write live data.

Step 6: replay the event history on paper

Start from the last time the SKU was known to agree. Then list every event in time order:

1. Opening count.
2. Customer orders and cancellations.
3. Fulfilment, pick and dispatch events.
4. Returns and restocking decisions.
5. Purchase receipts.
6. Transfers between locations.
7. Damage, samples and manual adjustments.
8. Bundle or kit component changes.

For each event, write the expected change in every system. Then compare it with the logs, records or exports.

The first event where expected and actual state differ is more valuable than the final mismatch. Later updates may simply carry the wrong quantity forward.

Step 7: classify the first divergence

Most inventory mismatches fit one of these categories:

• Definition: the systems show different stock states.
• Timing: the correct event is delayed or processed out of order.
• Identity: SKU, variant, bundle or location IDs do not match.
• Missing event: a return, cancellation, receipt or adjustment never travelled.
• Competing writer: another app or person overwrote the quantity.
• Direction: the wrong system is treated as the authority.
• Physical process: a real movement was never recorded.
• Accounting: the disagreement is valuation or cost, not units.

This classification prevents a common mistake: making the sync faster when the wrong system or wrong quantity is being synchronised.

Step 8: repair one rule and test ordinary edge cases

Fix the smallest responsible rule first. That may mean:

• Correcting an identifier or location mapping.
• Removing a competing writer.
• Adding a missing return or cancellation route.
• Changing an absolute overwrite into a controlled adjustment.
• Defining which stock state each destination should receive.
• Sending failed updates to a visible exception queue.

Test the repaired flow with a normal sale, cancellation, return, receipt and manual adjustment. If bundles or multiple locations are important, test those explicitly rather than assuming the simple SKU proves every case.

Step 9: turn the one-SKU audit into a control

The audit should leave a repeatable check, not just a corrected number.

Useful controls include:

• A daily or weekly reconciliation of selected SKUs or totals.
• An alert when a sync fails or grows stale.
• A report of unmapped product and location IDs.
• A log of manual adjustments and their owner.
• A threshold for differences that require investigation.

The cadence should match the operational risk. Fast-moving stock may need near-live exception visibility, while slower catalogue reconciliation can run less often.

When APIwise fits

A warehouse process issue or incorrect physical count may need an operations specialist first. A vendor support ticket may fix a fault isolated to one platform.

APIwise fits when the same mismatch returns across Shopify, marketplaces, a 3PL, inventory software and accounts, or when nobody can see which system or integration first changed the number. Our data integration work maps events and ownership before recommending connector configuration, middleware or custom logic.

Bring one SKU, the comparison table and its event history. That creates a specific starting point for an Integration Health Check.

If stock figures keep drifting after manual corrections, use the inventory mismatch checklist or tell APIwise which systems disagree.

Sources used

• Shopify: understanding inventory states