Wave Accounting and Amazon Seller Central integration

What moves between them

The flow runs from Amazon Seller Central into Wave Accounting. ml-connector reads Amazon orders and posts them into Wave as sales invoices, mapping the buyer to a Wave customer and each line item to a product and income account. After Amazon releases a settlement, it reads the financial events and the settlement report and posts them into Wave as money transactions, so seller fees, FBA charges, refunds, and the net disbursement land on the correct expense and clearing accounts. Reference data such as products and customers is created in Wave as new orders reference it. Wave is the system of record for the books, so nothing financial is written back into Amazon.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two token paths in parallel: it exchanges the Amazon refresh token for a one-hour access token on the x-amz-access-token header, and it refreshes the Wave bearer token before its two-hour expiry rather than waiting for a 401. Because Amazon settlement data is async and has no push notification type, the connector polls the Finances API and the settlement report on a schedule rather than relying on events, and it follows Amazon NextToken pagination on reads and Wave page and pageSize pagination on writes. Each Amazon order maps to a Wave invoice, and each financial event maps to a money transaction whose externalId is set from the Amazon order id, which Wave uses as an idempotency key so a retried poll never creates a duplicate journal entry. GraphQL errors come back with HTTP 200, so the connector checks the errors array on every Wave write, not just the status code. Amazon throttles per operation with HTTP 429, so reads back off and retry, and orders older than two years are skipped because Amazon does not return them. Every record carries a full audit trail and can be replayed if a downstream write fails.

A real-world example

A direct-to-consumer brand with roughly thirty employees sells on Amazon through FBA and keeps its books in Wave Accounting on a Wave Pro plan. Before the integration, the bookkeeper downloaded the Amazon settlement report every two weeks and hand-entered one lump sum into Wave, which buried referral fees, FBA charges, and refunds inside a single line and made it impossible to see true margin per channel. With Wave Accounting and Amazon Seller Central connected, each order posts as a Wave invoice and every settlement is broken out into its own journal lines for fees, refunds, and the net payout against the right accounts. The owner sees real Amazon profitability in Wave, and the manual settlement re-keying is gone.

What you can do

• •Post Amazon Seller Central orders into Wave Accounting as sales invoices with line items mapped to products and income accounts.
• •Break each Amazon settlement into Wave money transactions so referral fees, FBA charges, refunds, and net payouts hit the correct accounts.
• •Bridge the Amazon Login with Amazon refresh-token grant and the Wave OAuth2 session, refreshing both tokens before they expire.
• •Poll the Amazon Finances and Reports APIs on a schedule, since settlement data is released only after a statement closes.
• •Dedupe every posting on the Amazon order id so retries never create duplicate invoices or journal entries.

Questions

Which direction does data move between Wave Accounting and Amazon Seller Central?

Data moves from Amazon Seller Central into Wave Accounting. Orders post as Wave invoices and settled financial events post as money transactions against the matching accounts. Wave is the system of record for the books, so ml-connector does not write financial entries back into Amazon.

Why does the integration poll Amazon instead of using webhooks?

Amazon Seller Central does not deliver plain HTTP webhooks; its push notifications go only through AWS EventBridge or SQS, and there is no notification type for settlement or invoice results. Financial settlement is also async and appears only after Amazon releases a statement. For those reasons ml-connector polls the Finances API and the settlement report on a schedule rather than waiting for an event.

How are duplicate postings prevented when a sync retries?

Wave's moneyTransactionCreate mutation accepts an externalId field that acts as a caller-supplied dedup key. ml-connector sets it from the Amazon order id, so re-reading the same order or financial event on a later poll updates rather than duplicates the entry. Amazon reads also follow NextToken pagination to avoid reprocessing pages.