Overselling Is an Integration Problem, Not a Warehouse One
A technical guide to running Amazon Seller Central and NetSuite as one system rather than two. It explains why a one-way inventory feed causes overselling, exactly which records have to move in each direction, where the genuine conflicts are and who should win them, and what a stale listing costs in Amazon account health terms. Covers the record lifecycle across both systems, the checks to run before building it, and how a field-level sync engine keeps stock and orders honest.
- Author
- Ruben Burdin · Founder & CEO
- Published
- July 22, 2026
- Read time
- 9 min read
Ask a seller why they oversold and the answer is usually about the warehouse: a miscount, a late receipt, stock committed to another channel. Occasionally that is true. Far more often the warehouse knew exactly what it had, NetSuite knew exactly what it had, and Amazon was told about it eleven hours ago.
That gap is the whole problem, and it is an integration problem. A listing does not sell what you own, it sells the number you last sent. If that number is pushed once a night, then for most of the trading day Amazon is advertising a quantity that stopped being true at some point after breakfast. Buyers keep buying it. The only exit is cancelling their orders, and Amazon has opinions about sellers who do that.
This guide covers running the two systems as one: why a single direction never covers it, exactly which records move which way, where the real conflicts are and who should win them, and what to check before you build.
Why one direction is never enough
Most Amazon integrations start as an order downloader. Orders arrive in NetSuite, someone picks and ships them, everyone is pleased. It works because at low volume a human closes every loop the integration left open: they update the listing, they confirm the shipment in Seller Central, they retype the tracking number.
Those loops are the integration. Pulling orders is the easy half, and it is the half that does not protect you. What protects you is the traffic going the other way, because that is what keeps Amazon's view of your business accurate.
- Available-to-promise. NetSuite is the system that counts real stock across locations and knows what is committed elsewhere. Amazon should be receiving that number continuously, not holding its own stale copy of it.
- Shipment confirmation and tracking. Amazon expects seller-fulfilled orders to be confirmed with valid tracking, promptly. If that happens by hand at the end of the day, the late shipment rate is a matter of who was still at their desk.
- Prices. A price agreed in the ERP that has to be retyped into a listing will eventually be retyped wrong, or not at all.
- Cancellations and status. When something cannot ship, Amazon needs to know from the system that discovered it, not from a person remembering to log in.
What flows each way
Before building anything, write down the direction of every record. Ambiguity here is what produces the two-systems-disagree problem later, and it takes ten minutes to avoid.
| Record | Direction | Why it has to move |
|---|---|---|
| Orders | Amazon to NetSuite | Become sales orders, so fulfillment, invoicing, and revenue happen in one place |
| Available-to-promise | NetSuite to Amazon | The listing should show what the warehouse can actually ship today |
| FBA quantities | Amazon to NetSuite | That stock physically sits in Amazon's network, so Amazon is the authority |
| Item and price changes | NetSuite to Amazon | A price agreed in the ERP should not depend on someone retyping it |
| Item fulfillment and tracking | NetSuite to Amazon | Confirming shipment on time with valid tracking is what protects account health |
| Returns and refunds | Amazon to NetSuite | Stock comes back and the credit has to exist against the right order |
| Settlements and fees | Amazon to NetSuite | The channel's true margin lives in the fee lines, not in the payout |
Two directions, one connection. Every row here is a loop that otherwise closes by hand.
Note the FBA row, because it is the one people get backwards. For stock you hold, NetSuite is the authority and Amazon receives. For stock sitting in Amazon's fulfillment network, Amazon is the authority and NetSuite receives. Getting that inverted produces a sync that confidently overwrites accurate numbers with guesses.
Where the conflicts actually are
A two-way sync is only as good as its answer to one question: what happens when the same field changes in both systems before either change has propagated. The honest answer is that it happens constantly, and that a policy decided in advance beats whichever job ran last.
| Field | Changes on both sides when | Who should win |
|---|---|---|
| Quantity available | A sale on Amazon and a stock receipt in NetSuite land together | NetSuite, it counts physical stock |
| Price | A repricer moves the listing while finance updates the ERP | Name an owner per SKU family, then hold to it |
| Order status | Amazon cancels while NetSuite is already picking | Amazon, it owns the buyer relationship |
| Shipping address | A buyer edits it before dispatch | Amazon, and NetSuite must see it before the label prints |
Decide these four up front. They cover most of what a sync will ever have to arbitrate.
Resolution has to happen per field, not per record. If a buyer changes their shipping address in the same minute a picker in the warehouse adds a note to the order, a record-level rule discards one of the two edits. A field-level engine applies both, because they never actually collided.
The other half of the problem is echo. The engine writes a quantity to Amazon, then reads Amazon a moment later and sees a change it made itself. Without origin tracking, that write comes back into NetSuite as a fresh update and the two systems trade the same number back and forth. Tagging every write with where it came from is what turns two-way sync from a nice idea into something you can leave running.
What a stale listing costs
On most channels, overselling costs you a refund and an apology. On Amazon it costs you standing. Amazon measures sellers on a pre-fulfilment cancellation rate, a late shipment rate, and whether shipments carry valid tracking, and it publishes targets for each that leave very little room. Cancelling orders because the listing was wrong is counted against you directly.
The consequences compound. Falling short of those targets puts Buy Box eligibility at risk, and losing the Buy Box on a competitive listing removes most of its sales without removing any of its costs. That is why inventory accuracy on Amazon is not an operations detail: the integration that keeps the number current is protecting the channel's economics, not just its logistics.
What to check before you build it
Whether you build the connection or buy it, four questions decide whether it survives a peak week.
- How does it behave against Amazon's rate limits? Each Selling Partner API operation has its own quota. A design that pushes a full inventory file on a timer will hit a limit during exactly the promotion where accuracy matters most. Work should queue, back off, and drain in order.
- How does it behave against NetSuite's concurrency limits? NetSuite governs how many requests an account can run at once. An integration that ignores that will contend with every other job and script you already run there.
- Does it sync changes or reload objects? Field-level change detection uses a fraction of the quota and makes conflict resolution possible. A full reload uses the budget and destroys the information you need to arbitrate.
- Can you prove what happened? When a quantity is wrong, you need to know which system wrote it and when. An exportable audit trail per write turns a two-hour argument into a lookup.
One number, two systems
The goal is unglamorous: the quantity on the listing and the quantity in NetSuite should be the same number, all day, without anyone maintaining that fact. Everything else, the orders, the tracking, the fees, follows from treating the two systems as one rather than as a source and a copy.
Stacksync syncs Amazon Seller Central and NetSuite in real time and both ways on one engine, resolving conflicts per field and tracking the origin of every write, over OAuth and without storing a copy of your data. To see it against your own catalog, book a demo, or read more about the Amazon Seller Central and NetSuite integration, the NetSuite connector, and what to look for in an enterprise iPaaS for Amazon Seller Central. For the finance side of the same data, see how to sync Amazon Seller Central with QuickBooks.
FAQ
Frequently asked questions
Related articles
