What connects to JTL-Wawi

JTL-Wawi is the merchandise management system behind a large number of German online retailers. Catalogue, stock, prices, orders, invoices, and credit notes live there. JTL ships its own tools for the common cases: JTL-eazyAuction for marketplaces and the Ameise for exports.

Integrations start where those tools stop. On the sales side, JTL pushes listings, prices, and stock to marketplaces and pulls orders back, and several seller accounts, Pan-EU FBA, or channel-specific pricing are the usual reasons to go beyond eazyAuction, as in JTL to Amazon. On the accounting side, the invoices and credit notes JTL generates have to reach the Steuerberater as a DATEV Buchungsstapel with stable debtor accounts and correct tax keys, as in JTL to DATEV.

Where JTL-Wawi integrations break

Artikelnummern are not seller SKUs. Amazon works in seller SKUs and ASINs per marketplace. Variants and bundles have to be mapped explicitly, or a product lists against the wrong ASIN or splits across marketplaces.
Customer numbers are not debtor accounts. DATEV expects each customer on a Personenkonto in a defined range. Without a stable, deduplicated mapping from JTL customer numbers, histories split and the Kanzlei cannot reconcile a single customer.
A tax class is not a tax key. A JTL Steuerklasse does not tell DATEV whether a sale was domestic, an OSS distance sale, or an export. The tax key has to be derived for each invoice.
Invoice numbers have to survive. The Belegnummer must reach DATEV so postings stay traceable and the number range stays gap-free, and a credit note has to reverse the original’s accounts and tax keys on its own date.
Exports are not idempotent, and updates move the schema. Re-run the Ameise export over a date window and those invoices are booked twice. A JTL-Wawi version update can quietly change the database schema an export reads.