Amazon FBA & Multi-Channel Fulfillment Sync

The problem

Most Amazon integrations stop at the sales order. They pull the order down, create a cash sale or invoice, and consider the job done. That works for merchant-fulfilled orders and falls apart the moment inventory lives inside Amazon's network.

FBA is a different data model. You send goods to Amazon on an inbound shipment plan that Amazon splits across several fulfillment centers, often in different states with different tax nexus consequences. Between the day the truck leaves your dock and the day the units become sellable, that stock is in transit and belongs on your books but not in your available-to-promise. Amazon then moves units between fulfillment centers on its own schedule, disposes of unsellable units, reimburses you for some of them, and fulfills orders from whichever center is closest to the buyer. Layer Multi-Channel Fulfillment on top — where an order placed on your own webstore or another marketplace is fulfilled out of your FBA stock — and the NetSuite side needs to know which orders it must not try to ship itself.

The common workaround is a spreadsheet: someone downloads the FBA inventory report weekly, compares it to NetSuite, and posts an inventory adjustment for the difference. That hides shrinkage, delays reimbursement claims past Amazon's filing windows, and makes the inventory asset account impossible to defend at audit.

What ECOSIRE builds

We build a NetSuite customization that models the Amazon fulfillment network as first-class NetSuite data, using SuiteScript 2.1 and Amazon's Selling Partner API. Nothing here is a pre-built download — it is a bundle we write against your chart of accounts, your item master and your subsidiary structure.

Fulfillment centers as real locations

We create a location hierarchy for the Amazon network: a parent location per marketplace and child locations per fulfillment center, or a single logical FBA location with fulfillment-center detail on a custom record, depending on how granular your inventory reporting needs to be. Scoping decides which. If you run OneWorld, locations are assigned to the correct subsidiary and we set nexus expectations for the states where your inventory physically sits, so your tax team has the data it needs.

A custom record, customrecord_eco_fba_center, holds each center's Amazon code, address, region and active flag, and is referenced from inventory and shipment records.

Inbound shipments end to end

We build a custom record for the inbound shipment plan and its child shipments, linked to a NetSuite transfer order. When you create an inbound plan, a Scheduled script pushes the shipment to Amazon, records the shipment IDs and carton labels, and creates one transfer order per destination center. As Amazon receives and checks in units, a Map/Reduce script polls receiving status and receives the transfer order in stages, so partial receipts are visible instead of an all-or-nothing flip at the end. Discrepancies between shipped and received quantities are written to a reconciliation record with the variance, the reason code where Amazon supplies one, and the date the claim window closes.

Inventory that reflects reality

A Map/Reduce script pulls the FBA inventory summary on a schedule you choose and reconciles it against the NetSuite location. Sellable, unsellable, reserved and inbound-working quantities are held separately so available-to-promise is honest. Where the ledger and Amazon disagree, the script creates an inventory adjustment against the account you nominate during scoping — typically a dedicated shrinkage or in-transit variance account — with a memo tracing back to the report, rather than silently overwriting quantities.

MCF order routing

Orders that must be fulfilled from FBA stock are flagged on the sales order with a custom field and a SuiteFlow state. A User Event script prevents your warehouse team from picking them, and a Scheduled script submits the fulfillment request to Amazon, stores the returned fulfillment order ID, and polls for shipment confirmation. When Amazon ships, the script creates the item fulfillment against the correct FBA location with the carrier, tracking number and ship date returned by Amazon, so the customer-facing record and the ledger agree.

Errors you can see

Every API call is logged to a custom record with the request, the response, the record it relates to and a retry counter. Failed calls are retried with backoff and, past a threshold you set, raise a NetSuite system note and an email to a named group. Saved searches ship for the queues your team will actually watch: shipments overdue for check-in, orders stuck awaiting Amazon acknowledgement, and inventory variances above a threshold.

Who this is for

Merchants running meaningful FBA volume on NetSuite who already have order data flowing but no trustworthy inventory or inbound picture. It suits brands with their own webstore fulfilled out of FBA stock, sellers with several marketplaces sharing one pool of inventory, and OneWorld accounts where stock sitting in a fulfillment center in another state or country has real tax consequences. It is not the right fit if you are purely merchant-fulfilled — you would be buying a model you do not use.

How delivery works

Scoping call. We walk your item master, location setup, subsidiaries, existing Amazon order flow and the accounts you want variances posting to. We agree what the fulfillment-center granularity should be and which reports drive the reconciliation.

Fixed quote. You get a written scope, the object list, the price and a delivery window before any code is written. Lead time is typically one working week from acceptance.

Build. We develop as an SDF project against your requirements, using SuiteScript 2.1 and the Selling Partner API, with your Amazon credentials held in NetSuite's secrets management rather than in script parameters.

Install in sandbox. We deploy to your sandbox or a Release Preview account, load real data, and run inbound, reconciliation and MCF cycles with you. You test with your own SKUs before anything touches production.

Install in production. We deploy the bundle, configure roles and permissions, set script deployment schedules and run the first reconciliation with your team watching.

Support. A support window is included from go-live, covering defects, Amazon API changes affecting the delivered scope, and questions from your team. You own the code and the SDF project.