Sage Intacct and Amazon Seller Central integration

What moves between them

The main flow is Amazon into Sage Intacct. Financial events, settlement records, and refund events from Amazon Seller Central are polled and transformed into AP invoices, GL journal entries, and vendor records in Sage Intacct. Vendor purchase orders may flow from Amazon back to Sage Intacct for inventory tracking. The cadence is polling-based on a schedule you control, typically daily or weekly, since both systems are pull-primary (Amazon also supports push via EventBridge, but settlement data requires polling).

How ml-connector handles it

ml-connector stores the Amazon OAuth refresh_token encrypted and exchanges it for a fresh access_token before each request, since tokens expire after one hour. For Sage Intacct, it manages the XML session credential set and reuses the sessionid within its 50-minute lifetime, refreshing only when needed. Amazon's regional endpoints are selected based on your configuration, and the API surface is chosen per request (Orders, Finances, Reports, Catalogs). XML control characters that Intacct forbids (C0 control codes except tab, newline, carriage return) are stripped before serialization to prevent parsing errors. Amazon's Reports API is asynchronous, so ml-connector polls getReport until the status is DONE, then downloads the result from the presigned S3 URL. Financial events are mapped to Intacct GL accounts and vendors by configurable rules, and retried operations use Intacct's uniqueid flag for server-side deduplication. Every record carries a full audit trail.

A real-world example

An online retail company with multiple product lines on Amazon Seller Central also runs Sage Intacct for accounting and vendor management. Before integration, the finance team downloaded settlement reports from Amazon weekly, manually created AP invoices in Sage Intacct for each settlement, and reconciled vendor balances by hand. This process took two days per week and created opportunities for data entry errors. With Sage Intacct and Amazon Seller Central connected via ml-connector, settlement records flow into Sage Intacct automatically, mapped to the correct GL accounts and vendors, and the reconciliation step is eliminated. The finance team now closes the books in hours instead of days, and vendor accounts stay accurate without re-keying.

What you can do

• •Post Amazon financial events and settlement records into Sage Intacct as AP invoices and GL journal entries, mapped to the correct GL accounts and vendors.
• •Manage Amazon OAuth token refresh automatically and maintain Sage Intacct session credentials across 50-minute session boundaries.
• •Transform Amazon financial events (refunds, service fees, adjustments, shipment fees) into accounting transactions using configurable mapping rules.
• •Handle asynchronous Reports API workflows by polling until completion and downloading results from presigned S3 URLs.
• •Strip forbidden XML control characters and validate entity paths before posting to Intacct, with full audit logging of every record and retry state.

Questions

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

The main flow is Amazon Seller Central into Sage Intacct. Financial events, settlement records, refunds, and vendor purchase orders move from Amazon into Sage Intacct for GL posting and vendor reconciliation. Sage Intacct master data like GL accounts and vendors are read for mapping, so ml-connector can route Amazon transactions to the correct Intacct dimensions. Writes go one direction: Amazon to Intacct.

How does ml-connector handle the different authentication methods?

ml-connector stores the Amazon OAuth refresh_token encrypted and requests a new access_token before each call, since tokens expire after one hour. For Sage Intacct, it maintains the XML session credential set and reuses the sessionid for up to 50 minutes, refreshing only when the session expires. Both token types are kept in sync so neither side causes authentication failures.

How does ml-connector handle Amazon's asynchronous Reports API?

Amazon's Reports API requires ml-connector to create a report request, poll getReport until the status is DONE (which may take minutes), then download the result from a presigned S3 URL. ml-connector manages this workflow automatically, storing report IDs and download URLs so partial downloads can be retried. If polling times out, the job is logged and can be resumed manually or on the next scheduled run.