In short: there are three ways to connect Amazon and NetSuite: Oracle's NetSuite Connector, Celigo's Amazon–NetSuite integration app, or a custom build against the Selling Partner API (SP-API). The right one depends on your marketplaces, your FBA programme, your volume, how finance wants sales and fees posted and who will maintain it. We map the flows first, then choose.
When Amazon and NetSuite don't talk
It usually starts with a small manual step that never goes away. You will recognise some of these:
- Amazon orders are re-keyed, or imported from a file in batches.
- Stock on Amazon and stock in NetSuite disagree, so you oversell one SKU and sit on another.
- Planners can't see how much FBA stock sits in which Amazon fulfilment country.
- Settlements are posted as one number, so gross sales and fees are invisible.
- Returns and reimbursements are nobody's job, so they are never booked.
- Several marketplaces report in different currencies, and the differences are absorbed somewhere.
Stock drift is rarely a speed problem; we explain why stock drifts between channels. The design questions below are what fix it.
Seller or Vendor, FBA or FBM: what changes in the integration
The model you sell under decides what enters NetSuite, so settle it before choosing a route.
| Model | Who holds the stock | What enters NetSuite | Who ships | What comes back |
|---|---|---|---|---|
| Seller Central, FBA | Amazon, in its fulfilment centres | Sales orders or invoices from Amazon orders; FBA stock levels for visibility | Amazon | Returns, refunds, reimbursements |
| Seller Central, FBM (MFN) | You | Sales orders; your stock is the source of truth | You or your 3PL | Fulfilment and tracking go back to Amazon; returns come in |
| Vendor Central (1P) | Amazon, after it buys from you | Purchase orders from Amazon, which you invoice | You | Shipment confirmations, invoices, chargebacks |
| Multi-Channel Fulfilment (MCF) | Amazon, fulfilling orders from other channels | Orders from your other stores, such as Shopify | Amazon | Tracking back to the originating store |
Vendor Central is a different flow: Amazon sends you purchase orders, through EDI or an API, and you invoice Amazon, rather than Amazon passing you customer orders. Most of this page is about Seller Central, which is where most European brands start.
What we sync between Amazon and NetSuite
| Flow | Direction | What it covers |
|---|---|---|
| Orders | Amazon → NetSuite | MFN and FBA orders with marketplace, currency and taxes as Amazon reports them |
| Inventory | NetSuite → Amazon for FBM; Amazon → NetSuite for FBA | Available quantity pushed for FBM; FBA stock by location pulled for visibility |
| Listings and pricing | NetSuite → Amazon | Prices and availability, when NetSuite is the item master |
| Fulfilment and tracking | NetSuite → Amazon | Shipment confirmation and tracking for MFN orders |
| Returns, refunds and reimbursements | Amazon → NetSuite | Credit memos and refunds, matched to the original order; see returns, refunds and credit notes |
| Settlements | Amazon → NetSuite | Summary below; the full treatment is on our marketplace settlements page |
Getting orders in is the easy half. Our piece on four ways to get ecommerce orders into your ERP covers the architecture choices behind it.
Three ways to connect Amazon and NetSuite, and how we choose
| Route | Best when | Watch out for | Who runs it |
|---|---|---|---|
| NetSuite Connector (Oracle) | Standard Seller Central or Vendor Central flows, NetSuite-centric team | Processes that don't fit its standard mappings; check coverage for each marketplace you use | Your team, inside NetSuite |
| Celigo Amazon–NetSuite integration app | You want a vendor-backed app on a managed platform, extended with custom flows | Marketplace coverage and edition limits: Celigo's settlement flows require its Premium edition | A managed platform, operated by us or by your team |
| Custom build against SP-API | Unusual flows, high-volume summarisation, bundles and kits, multi-entity (OneWorld) routing | You own the code, so it must be documented and monitored | Us, or your team once trained |
NetSuite Connector
Oracle's prebuilt connector. Its documentation lists Amazon Seller Central and Amazon Vendor Central among the supported storefronts (NetSuite Connector, Supported Storefronts and 3PLs). It is a sound choice for standard flows when the team lives in NetSuite. Whether it covers every European marketplace and your bundle, return and multi-currency rules is something to check against your own list before you commit.
Celigo Amazon–NetSuite integration app
As a Celigo implementation partner, we deploy Celigo's prebuilt integration apps, this one included, configured to your processes. The app has flows for order import, for inventory, pricing and fulfilment export, and for settlements. Celigo documents its settlement flows, which turn settlement data into custom settlement records and customer payments, as available in the Premium edition only. Its release notes mention several European marketplaces, but coverage differs by marketplace and by edition, so we confirm each marketplace you sell on in Celigo's documentation, and with Celigo where it is unclear, before we recommend it. We implement Celigo and recommend it only when it fits.
Custom build against SP-API
Amazon's Selling Partner API on one side, NetSuite's SuiteTalk and RESTlets on the other, in our own stack: no third-party licence in the middle and no connector limits to design around. We choose it when your flows are unusual, when volume calls for summarising instead of per-order posting, when bundles and kits need their own logic, or when orders must be routed across several NetSuite entities. Where a process needs approvals or several steps, we add n8n for the orchestration.
How we choose. The recommendation follows your volume, the marketplaces you sell on, your FBA programme, your item model, the posting rules finance wants and any iPaaS you already pay for. We are not resellers, and the answer follows your case, not a quota. For the wider architecture trade-off, read iPaaS, point-to-point and middleware.
Not sure which route fits? Book a 30-min call and bring your current setup.
Amazon-specific design decisions
This is where Amazon integrations succeed or fail. None of it comes out of a connector's default settings.
FBA inventory in NetSuite. Stock that Amazon holds should appear in NetSuite as its own location or locations, one per country or programme, or a single "Amazon EU" location, fed from Amazon's inventory data and reconciled with Amazon's inventory reports. Inbound shipments to Amazon are transfers from your warehouse location to the Amazon location. Planners then see what is in your warehouse and what is in Amazon's separately, and neither number is a guess.
Pan-European FBA and several marketplaces. With Pan-European FBA, Amazon can move your stock between countries, and orders arrive from amazon.es, .de, .fr, .it and others, in euros and in other currencies such as Swedish krona, Polish zloty or sterling where you sell there. The design must decide whether the NetSuite customer is one per marketplace or one per buyer, how stock movements between countries are recorded, and where currency differences land.
Restricted buyer data. Amazon limits what a seller's integration may read about buyers: personal data is restricted data in SP-API. Customer records in NetSuite should be designed around that, not the other way round. Check Amazon's current developer data-protection requirements for what applies to you; this is not legal advice.
Per-order or summarised posting. High-volume B2C sellers often post a daily summary rather than every order, which keeps NetSuite fast and the ledger readable. Low-volume or B2B sellers usually want every order. This is a decision for finance, and it should be made before the mapping.
SKU, ASIN and FNSKU mapping. An Amazon listing, an Amazon fulfilment label and your own item are three identifiers for one product. Bundles and kits make it harder, because a sale on Amazon may consume several NetSuite items. We agree the item model first.
VAT and OSS. Holding stock in another EU country and selling through several marketplaces can create VAT obligations. The integration has to carry the tax data Amazon reports correctly, and the rules come from your tax advisor, not from us. In Spain, invoices raised from this data also fall under the e-invoicing and tax-reporting rules (SII, Verifactu), which we cover separately.
Settlements: where most Amazon integrations fail
Amazon pays a net amount for each settlement period, after fees, FBA charges, advertising, refunds and reserves. If the integration posts that as one deposit, gross sales and fees disappear into a single line and nobody can say what a channel really earns. A proper integration splits each settlement into sales, fees, refunds and the net payout, so the deposit matches the bank line and every fee has an account. Amazon's older XML and flat-file settlement reports are being retired in favour of the Flat File V2 report on 11 November 2026, so a reader built for the old format has a deadline (Amazon SP-API changelog).
We deliberately do not repeat the whole treatment here. The marketplace settlements page covers multi-marketplace reconciliation, with Amazon, Zalando and Mirakl side by side, and our post on the marketplace settlements reconciliation gap explains why it matters. Selling through Amazon and your own store? See also how we connect WooCommerce and Magento.
How a NetSuite–Amazon project runs
- Discovery. Marketplaces, FBA programme, volumes and posting rules.
- Sandbox build and mapping. With your real data, covering the edge cases: returns, bundles, several currencies, stock moving between countries.
- Parallel run. On a subset of SKUs or orders, comparing against what you do today.
- Go-live and monitoring. We deploy, watch the first syncs closely and stay on.
The timeline depends on the marketplaces and the route, and we fix scope and effort in an integration blueprint after discovery rather than guessing before it.
After go-live: monitoring, errors and ownership
Most integrations don't fail on day one. They fail on a busy week, silently, and someone notices at month-end. That is why error handling, retries and alerts ship with the integration, not as an upsell after the first silent failure. For Amazon, the alerts we typically set up cover order import failures, unmapped SKUs, rejected inventory feeds and settlement mismatches.
You own what we build. We document the flows, and if you would rather run them yourselves, we train your team. Our piece on life after go-live explains why this phase decides whether an integration lasts.
Why Atypical Tech
- NetSuite depth, not just plumbing. We understand the records, the processes and the finance behind every flow.
- Senior engineers only. The people who scope your project are the ones who build it.
- Partner where it helps, independent where it counts. We are a Celigo implementation partner and a Stacksync partner, and we build directly against APIs when no platform fits.
- Based in Spain, working across Europe. In English, Spanish, Portuguese and Catalan. We already run Shopify, WooCommerce and Magento integrations and marketplace settlement reconciliation. See all the systems we connect.
Sources
- Oracle NetSuite Help Center, NetSuite Connector: Supported Storefronts and 3PLs, accessed 7 October 2026.
- Celigo Help Center, Amazon Seller Central–NetSuite integration app and release notes, accessed 7 October 2026.
- Amazon SP-API, changelog: removal of the XML and flat-file settlement reports, accessed 7 October 2026.