DATEV and Amazon Seller Central integration

What moves between them

The flow runs from Amazon Seller Central into DATEV. After each settlement, ml-connector reads the Amazon settlement report and financial events and builds a DATEV booking batch covering captured sales, refunds, Amazon selling and FBA fees, and chargebacks, each posted to the correct SKR account, tax code, and cost center. The batch is submitted as an EXTF CSV job to DATEV Rechnungswesen, or as a DXSO XML booking suggestion to DATEV Unternehmen Online when a review step is wanted, and the related invoice PDFs are uploaded to DATEV Unternehmen Online as documents. Amazon is treated as a read-only accounting source, so ml-connector never writes orders, listings, or inventory back to Seller Central, and DATEV bookings are write-only, so nothing is read back from the ledger.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Amazon side it exchanges the seller refresh token for a one-hour access token, caches it, and sends the marketplace id and region on each call; on the DATEV side it runs the OAuth authorization code flow with PKCE, where the code challenge must be S256 and the state at least 20 characters, refreshes the 15-minute token with the client id only, and attaches the X-DATEV-Client-Id header. Because neither system pushes the events that matter here, it polls Amazon on a cadence tied to your payout cycle, reads each settlement once a report finishes generating, and follows the NextToken cursor so no transactions are missed. Amazon SKUs and fee types are mapped to DATEV GL accounts and tax codes up front, since the DATEV chart of accounts cannot be read back and must be configured in advance. The EXTF CSV is written as UTF-8 with precomposed characters and a deterministic filename, which lets DATEV reject duplicates safely and lets ml-connector retry; after submission it polls the DATEV job status with backoff until the job confirms or fails. Amazon throttling returns HTTP 429 per operation and DATEV is not built for high-frequency polling, so requests back off and retry, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods seller in Germany, around forty staff, sells across the Amazon DE and other European marketplaces and keeps its books in DATEV through its tax advisor. Before the integration, a bookkeeper downloaded each Amazon settlement report by hand, split out the sales, refunds, and the many Amazon fee lines in a spreadsheet, and typed the totals into DATEV against the right SKR accounts and VAT codes, which lagged by days and made the VAT return a scramble at period end. With DATEV and Amazon Seller Central connected, each settlement is read automatically, booked as an EXTF batch with fees and refunds already split to the correct accounts and tax codes, and the supporting documents land in DATEV Unternehmen Online. The advisor opens a period that is already reconciled to the Amazon payout, and the manual export step is gone.

What you can do

• •Book each Amazon Seller Central settlement into DATEV as an EXTF batch covering sales, refunds, and Amazon fees.
• •Map Amazon SKUs and fee types to DATEV SKR accounts and tax codes so every line lands on a valid account.
• •Upload Amazon invoice and receipt PDFs into DATEV Unternehmen Online with the correct client-specific document type.
• •Bridge the Amazon Login with Amazon refresh token and the DATEV OAuth login with PKCE, refreshing both token sets automatically.
• •Poll Amazon on your payout cycle and poll each DATEV job to completion, with retries and a full audit trail on every record.

Questions

Which direction does data move between DATEV and Amazon Seller Central?

Data moves from Amazon Seller Central into DATEV. ml-connector reads Amazon settlement reports and financial events and posts them into DATEV as booking batches. Amazon is treated as a read-only accounting source, and DATEV bookings are write-only, so nothing is written back to Seller Central and the DATEV ledger is not read back.

Why does the integration poll instead of using webhooks?

Neither side pushes the events that matter for accounting. DATEV has no outbound webhooks at all, and Amazon's notifications run only through AWS EventBridge or SQS and cover no financial settlement event. So ml-connector polls the Amazon Finances and Reports APIs on a cadence tied to your payout cycle and polls each DATEV job status until it confirms.

How are Amazon amounts matched to the right DATEV accounts?

The DATEV chart of accounts cannot be read back through the API, so SKUs and Amazon fee types are mapped to DATEV SKR accounts, tax codes, and cost centers during setup. Each EXTF batch line is then written to the mapped account, and the file is sent as UTF-8 with precomposed characters and a deterministic filename so DATEV can reject duplicates and retries stay safe.