What connects to Amazon

For many European sellers Amazon earns a large share of revenue, in a system with its own language of seller SKUs, ASINs, marketplaces, and FBA versus FBM, paid out in net settlements that span thousands of orders.

What gets connected depends on where the business is run. Merchandise management pushes listings, prices, and stock out to each marketplace and pulls orders and refunds back, as in JTL to Amazon. An ERP takes orders, fulfilments, credit memos, and settlement postings into the right subsidiary and currency, as in Amazon to NetSuite. And the Steuerberater needs the same activity as correctly coded bookings, as in Amazon to DATEV.

Where Amazon integrations break

The settlement report is not an accounting record. It nets sales, refunds, and a dozen fee types into one payout and spans two calendar months at the fortnightly boundary. Booked as a lump sum, it loses the tax detail the VAT return depends on.
Amazon collects some of the VAT itself. For many B2C orders Amazon calculates, collects, and remits VAT as deemed reseller. Those sales need different coding from sales where you owe the tax, or you pay twice or under-declare.
Pan-EU FBA moves your tax obligations. When FBA ships your stock to a fulfilment centre in another country, that is an intra-community movement. It appears in the VAT Transactions Report, never in the settlement file.
FBA stock belongs to Amazon. FBM stock is yours and is pushed with a safety buffer; FBA quantities are pulled back and never overwritten. Mixing the two oversells your warehouse or fights Amazon over its own inventory.
The SP-API is throttled and asynchronous. Limits apply per operation with a token-bucket model, reports and feeds are processed later, and buyer PII sits behind a Restricted Data Token. A sync has to pace itself and check per-SKU results rather than trust an accepted feed.