Amazon DATEV integration

What an Amazon to DATEV integration actually does

Seller Central knows everything about your marketplace business - every order across every EU marketplace, the referral fee Amazon took, the FBA fulfilment and storage charges, the refund a customer triggered a week later, the reserve held back, and the disbursement that lands in your bank every fortnight net of all of it. DATEV, and the tax advisor working inside it, needs all of that expressed as bookings: the right account, the right tax key, the right posting date, and a clean line between the revenue you earned and the money that actually arrived.

The gap between those two worlds is where the work lives, and on Amazon it is wider than on most channels. An Amazon to DATEV integration closes it automatically: it reads each relevant event from the SP-API, applies your accounting logic, and hands DATEV a booking batch your Kanzlei can import without rebuilding it in Excel first.

What data moves

Amazon object / event	Becomes in DATEV	Notes
Settlement line (shipped order)	Revenue booking, split by VAT rate	Coded to the correct SKR03 / SKR04 revenue account per marketplace and tax treatment
VAT Transactions Report line	Correct tax key (Steuerschlüssel / BU-Schlüssel)	Distinguishes domestic, OSS distance sale, local registration, and marketplace-collected VAT
Referral & FBA fees	Expense bookings	Selling fees, fulfilment, storage, and long-term storage each to their own account
Advertising / Sponsored charges	Expense booking	Often invoiced separately from settlements; reconciled to the same period
Refund / return	Reversing booking	Same accounts and tax keys as the original order, dated to the refund
Cross-border FBA stock movement	Intra-community movement record	Pan-EU transfers between fulfilment centres flagged for the VAT return, not booked as sales
14-day disbursement	Clearing-account settlement	Netted payout reconciled against gross sales minus fees, refunds, and reserve

The exact account numbers, tax keys, marketplace mappings, and clearing accounts are agreed once with your tax advisor and encoded in the pipeline. After that, nobody maps them again by hand.

The details that break naive settlement imports

A settlement-report download or a generic connector app gets you 80% of the way and leaves the expensive 20% on your desk:

• The settlement report is not your accounting record. It is a payout document. It nets sales, refunds, and a dozen fee types into one figure and spans two calendar months at the fortnightly boundary. Booking it as a lump sum destroys the tax-key detail your VAT return depends on.
• Marketplace-facilitator VAT. For many B2C orders Amazon now calculates, collects, and remits the VAT itself as deemed reseller. That sale must be coded differently from one where you owe the VAT - get it wrong and you either double-pay or under-declare.
• Pan-EU moves your tax obligations physically. When FBA ships your stock to a fulfilment centre in France or Poland, it creates an intra-community movement and often a local VAT-registration duty. Those movements appear in the VAT Transactions Report, never in the settlement file, and are invisible to a naive export.
• Multiple marketplaces, multiple currencies. amazon.de, .fr, .it, .es and .co.uk settle separately, and non-euro marketplaces need a consistent, documented conversion date so revenue and payout reconcile.
• Idempotency. Re-import a settlement period and you book it twice. The pipeline tracks a stable identifier per transaction and never posts the same event again.

How we build and run it

We treat this as a pipeline, not a monthly download. Amazon SP-API settlement, fee, refund, and VAT-transaction data is pulled on a schedule, validated, transformed into your agreed DATEV coding, and written out as a DATEV-Format booking batch - or delivered through the DATEV Rechnungsdatenservice into DATEV Unternehmen online where that suits your Kanzlei’s workflow.

The pipeline is idempotent: every Amazon transaction carries a stable identifier, so a retry or a re-run never produces a duplicate booking. It runs on cloud-native, fully EU-hosted AWS infrastructure, so order and customer data never leaves the EU - which keeps the DPA / AVV with your tax advisor and your GDPR obligations clean.

And then we keep it running. Monitoring, alerting, incident response, and - critically - tracking Amazon’s frequent SP-API report deprecations and DATEV format changes are our responsibility under contract. The month-end close stops depending on someone remembering to log into Seller Central.

When this integration is worth building

If you sell a modest volume on a single marketplace, ship yourself rather than through FBA, and never cross a border, a manual settlement import is genuinely fine and we will tell you so. The integration earns its place when you run Pan-EU or FBA across several countries, when marketplace-collected VAT and local registrations make the tax treatment order-by-order, when disbursements and reserves make reconciliation a fortnightly chore, or when your tax advisor is billing you to untangle settlement reports that a pipeline should have delivered correctly in the first place.