Amazon Marketplace Connector

The problem

Selling on Amazon breaks NetSuite in a way that selling on your own store does not, because Amazon does not send you money per order. It sends you a settlement — a fortnightly net deposit with hundreds of line types inside it: referral fees, FBA fulfilment fees, storage fees, long-term storage surcharges, removal fees, advertising, reimbursements, refunds, chargebacks and promotional rebates. Finance receives one bank line and no defensible way to allocate it.

Meanwhile the operations side has its own arithmetic problem. FBA inventory sits in Amazon's fulfilment centres but belongs to you, so it must appear on your balance sheet at cost in a NetSuite location you do not physically control. Units get lost, damaged, reimbursed and returned to a different centre than they left. FBM orders need to reach your warehouse fast enough to hit Amazon's ship-by date or the account health metrics slide. And every marketplace you add — a second region, a second brand, a second seller account — multiplies all of it.

Spreadsheet reconciliation covers this for a while and then stops scaling, usually at exactly the point the business is growing fastest.

What ECOSIRE builds

ECOSIRE builds a NetSuite-native integration to the Amazon Selling Partner API using SuiteScript 2.1, custom records, saved searches and SuiteFlow, delivered as an unmanaged bundle and an SDF project you own. The scripts run in your account and call SP-API directly under your own seller credentials. Nothing routes through a third-party middleware tenant.

Order ingestion

A Scheduled script polls the SP-API Orders endpoints on a cadence you set, or consumes SQS-delivered notifications where you have them configured. Each order is written first to a staging custom record with the Amazon Order ID, marketplace ID, fulfilment channel and raw payload, then transformed by a Map/Reduce script into a NetSuite Sales Order. Staging is deliberate — SP-API is rate-limited and NetSuite is governance-limited, and those two constraints must be decoupled or you lose orders during a spike.

Each order maps its ASIN or seller SKU to a NetSuite item, applies the subsidiary, location, department, class and custom segments for that marketplace, books in the marketplace's currency, and records the Amazon Order ID on a custom field so nothing is ever ingested twice. Business orders, replacement orders and multi-channel fulfilment orders are handled per rules agreed at scoping.

FBA versus FBM

FBA orders arrive already shipped from Amazon's perspective, so the script creates the Sales Order and the matching Item Fulfilment from the shipment data, relieving inventory from the FBA location. FBM orders are created open, routed to your warehouse location, and a User Event script on Item Fulfilment submits the shipment confirmation feed back to Amazon with carrier and tracking so the buyer is notified and the ship-by metric is met.

Inventory

A Map/Reduce script pulls FBA inventory summaries — fulfillable, reserved, inbound working, inbound shipped, inbound receiving, unfulfillable — and reconciles them against the NetSuite quantity in your FBA locations, writing variances to a review record rather than silently adjusting. For FBM listings, available quantity flows the other way: NetSuite availability from your nominated locations pushes to Amazon via listings feeds so you stop overselling stock that a wholesale order has already committed. Inbound shipment plans can be represented as Transfer Orders so in-transit units are visible.

Settlement reconciliation

This is the module that pays for the project. A Scheduled script retrieves settlement reports, parses every transaction type, and posts them to the GL accounts you nominate in a mapping custom record: order revenue to the originating Sales Orders, referral and FBA fees to their own expense accounts, refunds against Credit Memos, reimbursements to other income, advertising to marketing spend. The result is a settlement summary record whose net figure equals the deposit Amazon actually sent, with a drill-down to every component. Unmapped transaction types are flagged for a human decision rather than dumped into a suspense account.

Returns and reimbursements

Amazon-initiated refunds create Credit Memos or Return Authorisations against the original Sales Order. FBA customer returns update the disposition — sellable, damaged, carrier-damaged — so unsellable units do not remain valued as good stock. Reimbursement transactions are matched to their originating claim where Amazon provides the linkage.

Multi-marketplace and multi-account

Each marketplace or seller account gets its own configuration record: credentials, marketplace ID, subsidiary, currency, location set, item mapping strategy and GL accounts. Adding a region later is a configuration exercise, not a rebuild.

Error handling

Every SP-API request and response is logged with endpoint, status and throttling metadata. Rate-limit responses back off and retry rather than failing. Persistent failures raise saved-search email alerts, and a dashboard portlet shows unprocessed orders, unreconciled settlements and the last successful poll per marketplace.

Who this is for

Mid-market sellers running Seller Central — FBA, FBM or both — on NetSuite, including OneWorld accounts spanning several regions or legal entities. It fits businesses where Amazon is a material revenue channel and finance needs the fee load per marketplace to be visible rather than buried in a net deposit. If you also run Vendor Central, multi-channel fulfilment, or bundles and virtual kits on Amazon, raise it at scoping — each changes the item mapping design.

How delivery works

1. Scoping call. We review your Seller Central setup and your NetSuite account: marketplaces, seller accounts, fulfilment mix, SKU and ASIN structure, subsidiary and location design, current inventory valuation approach, and exactly how your controller wants settlements posted. You receive a written scope naming every record, field, report and direction in play.

2. Fixed quote. A fixed price and delivery window against that scope — normally one working week, driven mostly by marketplace count and whether settlement reconciliation is included. Work begins only on your approval.

3. Build. Developed in your sandbox against SP-API sandbox or a controlled subset of live data, source-controlled as an SDF project.

4. Install in test, then production. Deployed to sandbox first and validated against your own history: an FBA order, an FBM order, a partial refund, an inventory reconciliation cycle and a complete settlement period reconciled to a real deposit you can check. After your sign-off, the bundle installs to production with deployments held at a controlled status until you release them.

5. Support. A defect-fix window after go-live, full documentation, and a handover session with whoever will own the integration. You hold the source and the credentials throughout.