JTL DATEV integration

What a JTL to DATEV integration actually does

JTL-Wawi is where your multichannel commerce comes together - orders from Amazon, eBay, your JTL-Shop and other marketplaces, turned into outgoing invoices, credit notes, and recorded payments. DATEV, and the tax advisor working inside it, needs all of that expressed as bookings: the right revenue account, the right tax key, the right posting date, the correct debtor, and a clean split between the invoice and the money that actually landed in the bank.

The gap between those two worlds is where the work lives. JTL ships a DATEV export via the Ameise tool, but it hands over a flat file and leaves the accounting judgement to you. A proper JTL to DATEV integration closes the gap automatically: it reads each relevant invoice and payment from JTL-Wawi, applies your accounting logic, and hands DATEV a clean booking batch your Kanzlei can import without touching a spreadsheet.

What data moves

JTL-Wawi object / event	Becomes in DATEV	Notes
Outgoing invoice (Ausgangsrechnung)	Revenue booking, split by tax rate	Coded to the correct SKR03 / SKR04 revenue account per tax treatment
Tax class (Steuerklasse) per line	Correct tax key (BU-Schluessel)	Domestic 19% / 7%, EU OSS, reverse-charge, third-country export
Customer (Kunde)	Debtor account (Debitor / Personenkonto)	Stable mapping into your Debitoren range; collective account where preferred
Credit note (Gutschrift)	Reversing booking	Same accounts and tax keys as the original, dated to the credit note
Shipping & discounts	Separate booking lines	Shipping is itself taxable and needs its own account
Marketplace / PSP payout	Clearing-account settlement	Amazon, eBay, PayPal, Mollie each reconciled separately
Platform fees	Expense booking	Netted payout matched to gross invoices plus fees

The exact account numbers, tax keys, debtor ranges, 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 exports

The Ameise export or a generic connector gets you 80% of the way and leaves the expensive 20% on your desk:

• Debtor accounts. DATEV expects each customer on a Personenkonto in a defined range (in SKR03 typically 10000-69999). JTL customer numbers are not DATEV debtor numbers. Without a stable, deduplicated mapping you get orphaned debtors, split histories, and a Kanzlei that cannot reconcile a single customer.
• Tax keys per tax class. A JTL Steuerklasse is not a DATEV tax key. A 19% domestic sale, a 7% reduced-rate item, an EU distance sale under OSS, and an export to Switzerland are four different BU-Schluessel. Get one wrong and the advance VAT return (Umsatzsteuervoranmeldung) is wrong.
• The payout is not the revenue. Amazon and eBay settle net of fees, days later, in a batch that spans many orders. Booking the settlement as revenue reconciles to nothing. The invoice and the settlement must be separate bookings joined by a clearing account, with fees booked out.
• Invoice numbers and credit notes. The Belegnummer has to survive into DATEV so postings are traceable, and the number range must stay gap-free. A credit note has to reverse the exact accounts and tax keys of the original invoice, on its own date.
• Idempotency and Wawi updates. Re-run the Ameise export over a date window and you book those invoices twice. A JTL-Wawi version update can quietly change the database schema the export reads. A pipeline has to know which invoices it has already sent and survive schema drift without silently dropping rows.

How we build and run it

We treat this as a pipeline, not a manual batch job. JTL-Wawi invoices, credit notes, and payments are read on a schedule (against the Wawi database or via the JTL data layer), 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 JTL invoice carries a stable identifier and Belegnummer, so a retry or a re-run never produces a duplicate booking. It runs on cloud-native, fully EU-hosted AWS infrastructure, so invoice 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 - watching for JTL-Wawi schema changes and DATEV format changes are our responsibility under contract. The month-end close stops depending on someone remembering to run the Ameise.

When this integration is worth building

If you sell through a single channel at one VAT rate and post a handful of invoices a month, JTL’s built-in DATEV export is genuinely fine and we will tell you so. The integration earns its place when you sell across Amazon, eBay, and your own shop, when EU cross-border sales pull you into OSS, when marketplace payouts and fees make reconciliation a monthly chore, or when your tax advisor is charging you to clean up exports that a pipeline should have delivered correctly in the first place.