Amazon NetSuite integration

What an Amazon to NetSuite integration actually does

Amazon Seller Central knows everything about a sale the moment it happens - the buyer, the line items, the marketplace it came from, whether it ships FBA or FBM, the refund a week later, the settlement that pays you net of fees a fortnight after that. NetSuite needs all of it expressed as records: a Sales Order or Cash Sale against the right customer and subsidiary, an Item Fulfillment when FBA ships, a Credit Memo when money goes back, and a clean settlement posting so finance can close the month.

The gap between those two systems is where the manual work lives today - people exporting order reports, re-keying them into NetSuite, and trying to make a lump-sum Amazon deposit tie out against thousands of individual orders. An Amazon to NetSuite integration closes that gap automatically: it reads each relevant event from the Selling Partner API, applies your accounting and fulfillment logic, and writes the correct records into NetSuite without anyone touching a spreadsheet.

What data moves

Amazon object / event	Becomes in NetSuite	Notes
Order (SP-API getOrders)	Sales Order or Cash Sale	One record per AmazonOrderId, mapped to the marketplace’s subsidiary and currency
Order line items	Sales Order lines	Amazon SKU matched to the NetSuite item; unmatched SKUs held, not guessed
Buyer / recipient	Customer record	Often a generic or anonymised marketplace customer; PII pulled only via a Restricted Data Token
FBA shipment confirmation	Item Fulfillment	Drives inventory relief and shipment status back to the order
Refund / return	Credit Memo	Reverses the exact items and tax of the original order, dated to the refund
FBA reimbursement	Journal Entry / other charge	Amazon compensating for lost or damaged stock
Settlement report (financial events)	Journal Entry through a clearing account	Splits gross sales, referral and FBA fees, refunds; nets to the bank deposit
FBA inventory movement	Inventory Adjustment	Keeps NetSuite stock aligned with Amazon fulfilment centres

The exact item mappings, subsidiaries, tax codes, and clearing accounts are agreed once during scoping and encoded in the pipeline. After that, nobody maps them again by hand.

The details that break naive syncs

A prebuilt connector or a report export gets you most of the way and leaves the expensive part on your desk:

• SP-API rate limits. The Selling Partner API is throttled per endpoint with a token-bucket model, and reports are asynchronous - you request a report, poll for it, then download it. A naive loop hits the limit and silently drops data. The pipeline has to back off, respect the buckets, and resume cleanly.
• Restricted buyer data. Amazon no longer hands out buyer PII freely. Names and addresses require a Restricted Data Token and are only needed for FBM shipping labels, not for the accounting. The integration should pull PII only where it is genuinely required and keep it out of NetSuite where it is not.
• The settlement is not the order. Amazon deposits a single net figure every settlement period that spans thousands of orders, minus referral fees, FBA fees, refunds, and adjustments. Booking the deposit as revenue reconciles to nothing. Sales and settlement have to be separate postings joined by a clearing account.
• Marketplace facilitator VAT. Where Amazon collects and remits tax itself, that tax is not your output VAT and must be coded separately - otherwise your VAT return overstates what you owe.
• Multi-marketplace, multi-currency. A pan-EU seller runs amazon.de, .fr, .it, .es and more, each in its own currency and tax context, all needing to land in the right OneWorld subsidiary rather than one undifferentiated entity.
• Idempotency. Re-run a naive import and the same order posts twice. Every Amazon event carries a stable identifier - AmazonOrderId, settlement group id - and the pipeline must know what it has already written and never duplicate it.

How we build and run it

We treat this as a pipeline, not a batch job someone kicks off. Orders, refunds, FBA events, and settlement reports are pulled from the Selling Partner API on a schedule, validated, transformed into your agreed NetSuite mapping, and written through SuiteTalk (or the REST record API) as Sales Orders, Item Fulfillments, Credit Memos, and settlement Journal Entries.

The pipeline is idempotent: every Amazon event carries a stable id, so a retry or a re-run never creates a duplicate record in NetSuite. It runs on cloud-native, fully EU-hosted AWS infrastructure, so order and customer data never leaves the EU - which keeps your DPA / AVV and your GDPR obligations clean. Partial failures do not corrupt the run: a single unmatched SKU or a locked NetSuite period parks that record for review rather than aborting the batch or half-writing it.

And then we keep it running. Monitoring, alerting, incident response, and - critically - watching for Amazon SP-API and NetSuite SuiteTalk changes are our responsibility under contract. You get a named owner and an SLA, and the month-end close stops depending on anyone remembering to run an export.

When this integration is worth building

If you ship a handful of Amazon orders a month from a single marketplace, the Seller Central reports and manual entry are genuinely fine, and we will tell you so. The integration earns its place when order volume climbs, when you sell across several EU marketplaces and subsidiaries, when FBA fees and settlement reconciliation turn every month-end into a chore, or when a prebuilt connector keeps breaking on the exact edge cases - facilitator VAT, refunds, currency - that your business actually runs on.