You sell on Shopify. You sell on Amazon FBA. Marketplace Connect handles the Amazon side: it pulls in your products, takes the Amazon orders, fulfils them through FBA. It does not, by default, decrement your Shopify inventory when an Amazon order ships.
For the first few weeks this seems fine. After a month, the drift shows up. Your Shopify storefront says you have 30 in stock. You have 14. A Shopify order comes in for 22. You promise delivery you cannot make. Customer trust takes a hit. You spend a week chasing what happened.
This article is the engineering reality of Shopify and Amazon FBA inventory drift, why the obvious workarounds are fragile, and how I would build a reconciliation layer that actually works.
The Short Answer
Marketplace Connect creates Amazon orders in Shopify but treats them differently from native orders for inventory purposes. The Amazon side fulfils through FBA; the FBA fulfilment does not write back to Shopify inventory. You end up with two ledgers that look connected and are not.
The fix is a reconciliation layer that runs alongside Marketplace Connect. It periodically queries Amazon (via SP-API) for actual fulfilment activity, calculates the inventory delta, and pushes the corrected state to Shopify. It is not glamorous. It is the work that keeps the two ledgers in sync.
Shopify Flow can handle the simple cases. The reconciliation layer covers the cases Flow cannot.
Why The Obvious Fix Fails
"Marketplace Connect should just sync this." It is not designed to. Marketplace Connect's job is order import and fulfilment routing. Inventory reconciliation across the FBA boundary is a separate problem that Shopify has not solved natively because it depends on Amazon SP-API access and your specific FBA configuration.
"We will use Shopify Flow to subtract inventory when an Amazon order ships." This works for some stores. The cases Flow handles cleanly: Amazon orders for SKUs that are FBA-only, with one warehouse, with no manual adjustments, and no return reversals. The cases Flow does not handle: removed inventory shipments, FBA-to-FBA transfers, lost shipments that come back, manual reconciliations from Amazon's end. The Flow rule that started simple becomes a maze of conditional checks until someone gives up.
"We will sync inventory only from Amazon to Shopify." Now your wholesale orders, your retail-store orders, and your manual adjustments do not flow back to Amazon. The drift moves to the other direction.
"We will use a third-party SaaS like Cin7 or Brightpearl as the source of truth." Sometimes this is the right answer. It is the answer when your inventory complexity is large enough to justify a separate tool. For many stores it is overkill, and the SaaS introduces its own sync issues with both Shopify and Amazon.
"We will hire a virtual assistant to reconcile manually." You have moved the problem to a person. The person makes errors. The person is unavailable on Sundays. The person leaves and the next person takes a month to learn.
How I Would Build The Reconciliation Layer
Phase 1: Discovery (week zero)
Before building, I need to understand your specific FBA configuration, your existing Marketplace Connect setup, your inventory volume, and where the drift is coming from.
What I do. Audit Marketplace Connect's current behaviour. Sample a week of orders and trace each from Amazon through Marketplace Connect into Shopify and out the other side. Identify which orders cause drift and why. Map your inventory volume by SKU, by warehouse, and by sales channel. Identify the reconciliation cases (removal orders, transfers, returns, lost shipments) that need handling.
What you get. A written discovery report covering: where the drift comes from, which cases Flow can handle and which it cannot, the recommended reconciliation strategy, and a baseline measurement of current drift so we can verify the fix works.
Phase 2: SP-API access setup (week one)
The reconciliation layer needs read access to Amazon's actual fulfilment data. SP-API is the path. Setup is non-trivial.
What I do. Register the application in Amazon Seller Central. Configure SP-API credentials. Set up the LWA (Login With Amazon) flow. Test access to the relevant endpoints (getOrders, getOrderItems, getReports, getShipments). Document the credential rotation procedure.
Phase 3: Reconciliation logic (week one to two)
The reconciliation layer is a scheduled job that runs every N minutes (configurable, typically 15 to 60), queries Amazon for fulfilment activity since the last run, calculates the inventory delta per SKU, and pushes the corrected state to Shopify.
What I build.
- Cursor management. The job tracks the last successful sync timestamp. On failure, the next run picks up from where the last left off, idempotently. No double-counting.
- Activity ingestion. The job pulls fulfilment events from SP-API: shipped orders, removal orders, FBA-to-FBA transfers, customer returns. Each event has a known impact on inventory.
- Delta calculation. For each SKU, the job calculates the net inventory change from the activity. Shipped orders decrement. Returns increment. Removals decrement (or increment if returning to seller). Transfers cancel out across warehouses.
- Shopify update. The job applies the delta to Shopify inventory using the Shopify Admin API (
inventoryAdjustQuantitiesmutation). Updates are atomic at the SKU-location level. - Reconciliation log. Every adjustment is logged with the source event, the SKU, the location, the delta, and the resulting on-hand quantity. The log is queryable for finance and for incident response.
Phase 4: Edge case handling (week two)
The simple cases are the cheap part. The edge cases are where reconciliation layers earn their keep.
What I build.
- Removal orders. When you pull inventory out of FBA back to your warehouse, the inventory has to move in Shopify too.
- Returns and refunds. When a customer returns to FBA, the inventory increments back. The reconciliation has to handle the timing (the return appears in SP-API before the inventory becomes resaleable).
- Lost shipments. Sometimes Amazon loses a shipment. The reconciliation has to handle the eventual reimbursement and not double-count.
- Manual adjustments from your team. When someone manually adjusts Shopify inventory, the reconciliation should not overwrite their change. The audit trail makes this provable.
- Drift between Shopify and the actual on-hand. Once a quarter (or after any incident), a full reconciliation run pulls Amazon's
getInventorySummariesand compares to Shopify. Discrepancies are flagged for human review, not auto-corrected.
Phase 5: Observability and alerting (week two to three)
The reconciliation layer is invisible when it works. Observability is what makes incidents detectable.
What I build.
- A dashboard showing the last successful sync time, the number of events processed per run, the number of SKUs adjusted, and the total inventory delta in absolute terms.
- Alerts that fire on: sync failure (no successful run in N hours), large unexpected delta (a SKU adjusted by more than X percent of its on-hand), sustained discrepancy between SP-API and Shopify (repeated failed reconciliations).
- A monthly reconciliation report for finance: total inventory movement, by channel, by SKU class, by warehouse.
Phase 6: Documented handover
You keep the reconciliation layer, the SP-API credentials in your vault, the Shopify API credentials, the dashboard, the alert configuration, and the runbook for support.
Honest Variables That Change The Cost Shape
SKU count. Stores with hundreds of SKUs are a smaller engagement than stores with tens of thousands. The reconciliation layer scales fine; the migration and validation grow with SKU count.
Number of FBA warehouses. Multi-warehouse stores need per-warehouse reconciliation, which is more complex than single-warehouse.
Multi-marketplace. Selling on Amazon US plus EU plus UK adds reconciliation surfaces. Each marketplace is a separate SP-API account.
Existing tools. If you already use a SaaS inventory tool that almost handles this, the build may be a smaller integration with that tool rather than a standalone layer.
Historical drift. If you have months of accumulated drift, the first reconciliation pass takes longer and surfaces more discrepancies.
Plan. Standard Shopify works fine. Plus opens slightly cleaner inventory APIs but is not required.
Why I Wrote This
Most articles on "Shopify Amazon inventory sync" point at SaaS tools or oversimplified Flow rules. This article exists because the engineering work is well-defined, the SP-API integration is documented, and the reconciliation layer is buildable as a focused two-to-four-week engagement. If your store is drifting and the workarounds are not catching up, the technical assessment is the route in.