Sage 100 and Amazon Seller Central integration

What moves between them

The primary flow runs from Amazon Seller Central into Sage 100. ml-connector reads Amazon orders and writes them as Sage 100 sales orders, then AR invoices, against the right customer, and reads settlement financial events so Amazon fees, refunds, and net payouts post as GL journal entries on the correct segmented accounts. Listing and pricing data flows the other direction: Sage 100 item prices and quantity-on-hand are pushed to the matching Amazon listings so the storefront reflects ERP stock. Reference data such as SKU to ItemCode and marketplace to GL account is aligned so every line lands on a valid account. Cadence follows your settlement and reporting calendar, polling at the interval Sage 100's lack of push events requires.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two auth paths at once: it exchanges the Amazon refresh token for a fresh access token before each batch and caches it for its one-hour life, and it sends the Sage 100 username, password, and company code inline on every call, either to eBusiness Web Services for sales orders and customers or to the local agent for AP, GL, and item writes through BOI. On the Amazon side it follows NextToken until the cursor is absent and passes the marketplace ID on every call. Because Amazon settlement is asynchronous, it treats the Reports API settlement report as the authoritative payout source and reconciles event-level Finances data against it. Sage 100 has no webhooks, so it polls on a schedule; it has no idempotency key, so the connector checks GetSalesOrder and the VendorNo plus InvoiceNo natural key before each insert and uses the GetNext number helpers to pre-generate keys. Segmented GL account strings are parsed defensively per company. SP-API returns HTTP 429 under load and Sage 100 BOI raises record-locking errors under concurrent writes, so it backs off with jitter and retries, with a full audit trail and replay on every record.

A real-world example

A consumer-goods wholesaler with roughly forty staff runs Sage 100 on a server in its warehouse and sells across Amazon US and Canada through Seller Central. Before the integration, an accountant downloaded Amazon settlement reports every two weeks and hand-keyed gross sales, FBA fees, refunds, and the net payout into Sage 100, while a warehouse clerk re-entered each Amazon order as a sales order. Reconciling the Amazon deposit to the ledger took days at month-end close. With Sage 100 and Amazon Seller Central connected through the local agent, each marketplace order becomes a sales order and invoice, and each settlement posts its fees and payout as a journal entry automatically, split by marketplace. The bank deposit ties out to the ledger on its own, and the manual re-keying is gone.

What you can do

• •Turn Amazon Seller Central orders into Sage 100 sales orders and AR invoices against the correct customer and ItemCode.
• •Post Amazon settlement fees, refunds, and net payouts into Sage 100 as GL journal entries on segmented accounts.
• •Push Sage 100 item prices and quantity-on-hand out to the matching Amazon listings so the storefront reflects ERP stock.
• •Bridge the Login with Amazon refresh token and the inline Sage 100 logon credentials through a local agent for full GL access.
• •Poll on your settlement schedule with NextToken paging, pre-insert duplicate checks, 429 and record-lock backoff, and a full audit trail.

Questions

Which direction does data move between Sage 100 and Amazon Seller Central?

The main flow is Amazon into Sage 100. Orders become Sage 100 sales orders and invoices, and Amazon settlement events post as fee and payout journal entries. Listing prices and stock flow the other way, from Sage 100 items out to Amazon listings, so the storefront reflects ERP inventory.

Why does Sage 100 need a local agent for this integration?

Sage 100 is on-premises and has no cloud API. Its SOAP service only exposes Customers and Sales Orders, while AP, GL, and PO access lives in the Business Object Interface, a COM layer that runs on the Sage 100 server and cannot be called over HTTP directly. A lightweight Windows agent wraps that interface behind an HTTPS endpoint so ml-connector can reach the full ledger to post settlement journals.

Does the integration use Amazon push notifications, and how does it avoid duplicates?

It polls on a schedule. SP-API sends no plain HTTP webhooks, its push events arrive only through AWS EventBridge or SQS, and Sage 100 has no push events at all, so ml-connector reads the Orders, Finances, and Reports APIs on a cadence tied to your settlement calendar. Neither side offers an idempotency key, so it checks GetSalesOrder and the VendorNo plus InvoiceNo natural key before each insert to prevent duplicate records.