Our client is a commercial and industrial lighting brand, specializing in energy-efficient LED fixtures for warehouses, parking lots and corporate facilities. They sell on Amazon through both fulfillment models at once, FBA for the fast-moving catalog and FBM from their own locations for everything else. [Referred to as the client or the company]
The Challenge
Amazon was already connected to NetSuite through one of the leading off-the-shelf connectors, and it was not working. The client’s own description was that it did not run correctly, that errors were a routine part of the week rather than an exception, and that they wanted the process to be smooth instead of supervised.
Order import was rarely the thing that broke. What broke was everything downstream of it.
Amazon does not report a single stock figure. It reports quantities across a dozen states, and the distinctions matter: units in an inbound shipment are not the same asset as units reserved against a customer order, which are not the same as units a fulfillment center has marked damaged. Flattening that into one on-hand number destroys information the finance and planning teams need. The company also sells refurbished fixtures alongside new ones, which Amazon models as separate listings, creating a real risk of new and used stock double-counting against the same item.
Pushing availability the other way carried a worse failure mode. FBM stock sits across several NetSuite locations, and Amazon models fulfillment channels separately from warehouses. Getting that mapping wrong means overselling. A lighting catalog also supersedes constantly, so discontinued SKUs kept their reviews and search ranking while going out of stock against their own inventory rather than their replacement’s.
Settlements were the third problem. Amazon sends a report, not an explanation, and reconciling it into the general ledger was manual work that had to be repeated every settlement period.
The Solution
We replaced the connector with a native SuiteScript integration running entirely inside NetSuite. Seven entry points sit on a single shared module that owns configuration, authentication and all Amazon API access, with no external platform in the path and no credentials in the codebase.
FBA inventory is reconciled as a difference rather than an overwrite. Amazon’s quantity buckets are mapped one to one onto NetSuite inventory statuses, so inbound, reserved, defective and damaged stock each keep their identity. Damaged quantities are aggregated by matching the field name rather than by listing Amazon’s categories, so new damage types are picked up without a code change. Refurbished listings are detected from the SKU and bucketed into separate used statuses, which lets one physical item carry two Amazon identities with no double-counting. The job computes the difference per item and status, discards every zero, and writes one adjustment record covering every remaining line.
FBM availability is pushed with a configurable buffer subtracted, so drift between syncs cannot turn into an oversell. Stock is gathered across every configured location and rolled up through a location-to-channel map, and any location without a mapping is surfaced rather than silently zeroed. Discontinued items can point at their replacement, and the successor’s stock is folded into the predecessor’s listing quantity so a superseded SKU keeps selling.
Settlement reports are parsed from Amazon’s flat file, where five separate type and amount column pairs each run through their own mapping into account totals. Those totals become a journal entry, with a clearing line drawn from the report summary that makes the entry tie to the actual deposit. Unmapped values are logged rather than dropped, so a new Amazon fee type appears as a line in a log instead of an unexplained variance.
Every flow is idempotent, each by the mechanism that suits it: an existence check before creating orders, a composite key for returns, a settlement identifier on the journal entry memo, and for inventory, the diff itself, which makes a second run a no-op by construction.
The Outcome
The brief was that the existing setup did not work correctly and the client wanted it to be smooth. In practice that meant the integration had to stop generating work, and it does.
FBA inventory reconciles on a thirty minute cycle without supervision, and a cycle in which nothing changed writes nothing at all. Amazon’s quantity distinctions survive into NetSuite, so stock in transit, stock reserved and stock damaged are three different things in reporting, as they are in reality. New and refurbished inventory are tracked against the same item without ever double-counting.
FBM availability goes out across every mapped channel with a buffer in front of it, and superseded products keep selling against their replacement’s stock instead of losing their ranking. Settlements arrive as a balanced journal entry that reconciles to the bank deposit, replacing work that was previously done by hand every settlement period.
The errors that remain are the ones that should exist. An unknown SKU holding real stock raises an alert to the operations team; an unknown SKU holding no stock is logged and nothing more, because a dead listing should not page anyone. Distinguishing between those two cases is most of what a business means when it asks for something to run smoothly.
Read the technical walkthrough of the FBA, FBM and settlement flows →