WooCommerce + FBA + NetSuite at a Glance
- Overselling happens when three systems each think they own the authoritative stock count.
- NetSuite should hold total inventory; WooCommerce and FBA hold reserved/committed allocations against it.
- NetSuite’s own native Amazon Connector does not sync FBA inventory by default — only merchant-fulfilled (MFN) inventory syncs automatically; FBA inventory sync is a separate, additional-cost add-on.
- Reconcile all three systems against one number daily, not just store-vs-NetSuite.
Selling through WooCommerce and Fulfilled-by-Amazon at the same time, with NetSuite as the ERP underneath both, means three systems now have an opinion about how many units you have. WooCommerce thinks it knows. Amazon’s Seller Central inventory feed thinks it knows, on its own delayed schedule. NetSuite is supposed to be the truth, but only if every channel actually reports back to it fast enough to matter, as covered in the NetSuite–WooCommerce integration guide. Overselling — the single worst failure mode in multi-channel commerce — happens in the gap between these three clocks, and for FBA specifically that gap is wider than most teams assume.
- NetSuite Holds the Number, Channels Hold Reservations
- Respect Amazon’s Feed Delay — Don’t Assume Real-Time
- The Fulfillable/Reserved Split Amazon Actually Tracks
- What NetSuite’s Native Amazon Connector Actually Syncs
- Reconcile All Three, Not Just Two
- Sizing the Buffer: A Working Checklist
- What to Do When You Oversell Anyway
NetSuite Holds the Number, Channels Hold Reservations
The correct architecture: NetSuite maintains total available inventory per SKU. WooCommerce and Amazon each receive a channel-specific allocation — not the full total — and that allocation shrinks as orders come in on that channel and grows back only when NetSuite explicitly reallocates.
Allocation, not shared total, prevents the race condition.
If both WooCommerce and Amazon are told “50 units available” as a shared total, and both sell 30 in the same hour, you’ve sold 60 units of a 50-unit stock before either sync catches up. Split it into fixed allocations per channel — say 30 to WooCommerce, 20 to Amazon — and the worst case is one channel selling out early, not both channels overselling simultaneously.
Respect Amazon’s Feed Delay — Don’t Assume Real-Time
Amazon does not publish a fixed SLA for how long an inventory feed or listings update takes to reflect on the live listing. Sellers commonly report anywhere from a few minutes up to 30 minutes or more, and processing queues slow down further during exactly the periods that matter most — flash sales, holiday spikes — when Amazon’s own infrastructure is under the heaviest load. Teams that build sync logic assuming near-instant propagation end up overselling during those same busy windows.
| Channel | Typical sync behavior | Buffer recommendation |
|---|---|---|
| WooCommerce (webhook-driven) | Seconds to low minutes | Minimal buffer needed if webhooks are reliable |
| Amazon Seller Central feed | No published SLA; minutes to 30+, worse at peak | Hold back 5-10% of allocation as a safety buffer, more during known peak windows |
| NetSuite reconciliation job | Depends on your sync interval | Should run more frequently during known peak windows |
Flash sales expose Amazon’s delay first.
A WooCommerce flash sale that drains stock in minutes will oversell on Amazon almost every time if your Amazon allocation buffer wasn’t sized for the feed delay. Reduce Amazon’s allocation temporarily during any planned high-velocity sale rather than relying on the standard sync cadence to keep up.
The Fulfillable/Reserved Split Amazon Actually Tracks
“Amazon inventory” is not one number. Amazon’s Selling Partner API exposes inventory through the getInventorySummaries operation, and the response breaks a single SKU’s stock into named states — fulfillable, three reserved sub-types, and three inbound sub-types — none of which are interchangeable for buffer math.
| SP-API field | What it means |
|---|---|
fulfillableQuantity |
Can be picked, packed, and shipped right now — this is the only number that should feed a “sellable” calculation |
pendingCustomerOrderQuantity |
Units reserved for customer orders already placed |
pendingTransshipmentQuantity |
Units being transferred from one Amazon fulfillment center to another |
fcProcessingQuantity |
Units sidelined at the fulfillment center for measurement, sampling, or other internal processing |
inboundWorkingQuantity |
Units in an inbound shipment you’ve notified Amazon about, not yet given a tracking number |
inboundShippedQuantity |
Units in an inbound shipment with a tracking number, in transit to an Amazon fulfillment center |
inboundReceivingQuantity |
Units from a partially-received inbound shipment still awaiting full receipt and processing |
Verdict: every one of the six non-fulfillable states is physically real inventory that a naive “total units” query would count as stock, but none of it is available to sell today. A sync that pulls any field other than fulfillableQuantity for the “can I sell this” check is the most common root cause of FBA-side overselling.
What NetSuite’s Native Amazon Connector Actually Syncs
Teams that already run NetSuite’s own Amazon Connector (the SuiteApp formerly known as FarApp) often assume Amazon inventory is handled the same way WooCommerce inventory is. Oracle’s own Amazon Connector FAQ says otherwise: the connector lists and syncs merchant-fulfilled (MFN) and FBA items under one Amazon account, but for FBA items specifically, “NetSuite Connector does not sync inventory or fulfillment latency” as part of the standard listing sync — it only toggles a fulfillment-center flag to mark the item as FBA. Syncing actual FBA inventory changes back into NetSuite is a separate feature, and per Oracle’s documentation, “additional charges may apply.”
Two more defaults compound the gap. First, even with the paid FBA sync active, in-transit inventory is invisible: Oracle’s FAQ states that once a transfer to Amazon ships, NetSuite removes it from the warehouse’s available quantity but does not add it to the Amazon warehouse until the transfer is received and posted — the units sit in “In Transit status,” uncounted anywhere sellable. Second, by default “NetSuite Connector compares the quantity on hand,” not quantity available, when reconciling — the exact on-hand-vs-available confusion that causes overselling on every other channel, present by default in Oracle’s own connector unless a support ticket changes it. Third, Amazon does not pass customer information through the API for FBA orders at all, so the connector needs a fixed placeholder customer configured in NetSuite for FBA order sync to work.
Reconcile All Three, Not Just Two
Most teams build a solid WooCommerce-to-NetSuite reconciliation report and stop there, treating Amazon as “handled” by the Amazon integration app. That’s the gap the sections above describe in detail: even a working connector may only be comparing quantity on hand, and FBA inventory may not be flowing back at all without the paid add-on. Build one report that pulls current stock from NetSuite, current allocation from WooCommerce, and fulfillableQuantity from Amazon’s SP-API directly — not whatever number the connector happens to be passing — and flags any SKU where the numbers don’t add up to the expected total. Run it at least every 30 minutes during peak periods, daily otherwise, and test it against a sandbox order per channel before go-live, per the staging checklist.
Sizing the Buffer: A Working Checklist
A flat “hold back 5-10%” rule is a starting point, not a finished buffer strategy. Work down this list once per SKU category, and again whenever the FBA add-on status or connector configuration changes:
- Confirm whether the FBA inventory add-on is active in your NetSuite Connector setup — check the configuration, don’t assume it based on MFN working correctly
- Pull
fulfillableQuantityvia SP-APIgetInventorySummariesas the only field that drives the WooCommerce/NetSuite allocation split - Size the Amazon buffer to
totalReservedQuantityplus any inbound quantity not yet receivable, not a flat percentage of total stock - Verify which value your connector compares by default — quantity on hand, not quantity available, unless NetSuite Support has changed it for your account
- Set up the fixed placeholder customer NetSuite Connector requires for FBA orders, since Amazon does not pass customer data for them
- Shorten the reconciliation interval during any planned high-velocity sale rather than trusting the standard cadence
- Confirm the connector’s lookback window (2 days by default for most storefronts) covers any outage window before trusting it to backfill missed updates
Teams moving off hourly batch syncs to close this window further typically move to NetSuite Integration Pro for WooCommerce, which polls in near-real time instead of once an hour — tightening the window the Amazon-side buffer has to cover on the WooCommerce side of the equation.
What to Do When You Oversell Anyway
Even with buffers sized correctly, oversells happen — Amazon’s feed delay has no published floor, and a sidelined FC-processing unit can drop out of “reserved” and back into “fulfillable” without warning. The response that protects the customer relationship: detect it within minutes, not when the customer emails asking where their order is; auto-flag the affected order in NetSuite; and have a pre-written communication template ready — offering a substitute, a discount, or an immediate refund — rather than making customer service improvise under pressure. Treat a confirmed Amazon oversell as an incident, not routine cleanup — the detection, triage, and communication steps are the same ones covered in the NetSuite integration incident response runbook.
Get the working checklists
The runbooks and decision checklists from these guides, as printable PDFs — free in the SoftXone guide library.
Sources & Further Reading
- Oracle NetSuite — Amazon Connector FAQConfirms FBA inventory sync is a separate, additional-cost add-on and that in-transit inventory stays invisible to NetSuite.
- Oracle NetSuite — NetSuite Connector Order Sync FAQDocuments the 2-day default lookback window and the fixed-customer requirement for FBA orders.
- Amazon Selling Partner API — getInventorySummaries referenceField definitions for fulfillable, reserved sub-types, and inbound sub-types.
- Amazon Selling Partner API — FBA Inventory API referenceAmazon Developer Docs — FBA inventory API overview.
- Oracle NetSuite DocumentationNetSuite multi-location and inventory allocation reference.
- WooCommerce Inventory Management DocumentationWooCommerce.com — stock management and reservation settings.
Frequently asked questions
Which system holds the real inventory number?
NetSuite holds the number; channels hold reservations. Treating a channel as authoritative is what causes overselling.
Why can't I treat FBA as real-time?
Amazon publishes no fixed SLA for feed processing, and delays commonly stretch to 30 minutes or more during peak load — assuming instant reflection produces phantom availability.
Does NetSuite’s native Amazon Connector sync FBA inventory automatically?
No. Oracle’s own Amazon Connector FAQ states the connector syncs merchant-fulfilled inventory by default; FBA inventory sync is a separate feature with additional charges, and even then in-transit inventory stays invisible until the transfer is received.
What is Amazon’s fulfillable quantity, and how is it different from reserved?
fulfillableQuantity is what can be picked, packed, and shipped right now. totalReservedQuantity covers units already committed to a customer order, mid-transfer between fulfillment centers, or sidelined for processing — physically in Amazon’s network, but not sellable.
What do I do if I oversell anyway?
Have a defined process: which order is cancelled, who is told, and how the reservation is released. Treat it as an incident with the same triage steps as any other integration failure.
Leave a Reply