Troubleshooting

Datevz refused to export

Every one of these is deliberate. A DATEV import is not a good place to find out about a mapping mistake, so the export stops and names the order.

"No account is mapped for … at 19%"

A bucket of revenue has no account. Either the chart of accounts is incomplete — press Fill from SKR03/04 — or a product needs a mapping rule of its own.

"The postings come to 118,99 but the order total is 119,00"

The batch would not reconcile. This is almost always inclusive tax rounding across several lines. Set a Rundungsdifferenzen account and the difference is booked there; leave it blank and the export keeps refusing, which is the safer default.

If the gap is larger than a cent or two, something else is wrong — usually a custom adjuster Datevz booked at 0% and warned about.

"The orders fall in 2 different fiscal years"

Belegdatum carries only a day and a month; the year comes from the fiscal year in the header. A batch spanning a year-end would book half its postings into the wrong year — silently, with every row individually valid. Export one year at a time.

"The order is in USD, but the batch is in EUR"

A Buchungsstapel declares one currency in its header. Booking another one needs a Basis-Umsatz and an exchange rate, which are yours to supply rather than Datevz's to invent. Filter the export to one currency.

"A reverse-charge supply needs the customer's VAT ID"

An EU business order with no valid VAT ID is not a reverse-charge supply — it is a domestic sale, and Datevz books it as one. If you expected reverse charge, the number on the address is missing or malformed.

"No debtor account"

No collective account is set, or per-customer mode has exhausted its number range. The Debtors screen shows the next number and says when the range is full.

Warnings that do not stop an export

"Booked as Export (non-EU), but the order carries 19,00 of tax"

The treatment and the tax charged disagree. Datevz will not override the treatment on the basis of the money — that would hide a real problem in the shop's tax configuration. Check the tax zones in Commerce.

"Booked as a domestic sale, but no tax was charged"

The mirror image. Legitimate for a Kleinunternehmer under §19 UStG; otherwise a tax rate is not matching the orders you think it is.

"Order-level tax 'VAT' was spread across the revenue lines by net value"

A tax rate applied to the order total rather than to line items. Datevz apportions it by net, which is the only reasonable reading, but which revenue account carries it is then an inference rather than a statement. Rates applied per line item avoid the guess.

"Document number 'RE-1042' is used by 2 different orders"

Two orders resolve to the same Belegfeld 1. Usually a documentNumberSource set to something that is not unique.

DATEV refused the file

The import stops immediately, before any posting

Something in the header line. Check the Beraternummer and Mandantennummer are the right way round, and that the format version matches what the practice's DATEV expects — try 12 if 13 is refused.

"Konto nicht im Kontenrahmen" / account master errors

Almost always the Sachkontenlänge. Debtor accounts are that plus one; a 4-digit collective debtor in a 4-digit chart is refused because DATEV expects 5.

Umlauts arrive mangled

Switch the encoding to UTF-8 with BOM. Datevz writes Windows-1252 by default because DATEV's own exports do, but current releases read UTF-8 and it survives names CP1252 cannot represent.

The postings import but land in the wrong year

The fiscal year in the header. If the client's Wirtschaftsjahr is not the calendar year, set its start month and day in the settings — Belegdatum has no year of its own to correct it with.

Nothing to export

The date range filters on whichever date Belegdatum is set to. If that is the payment date, an order placed in March and paid in April belongs to April's batch.

Orders already exported are excluded — tick Include orders that were exported before to see them, or delete the batch that holds them.

Checking a stored batch

The batch detail screen recomputes the checksum every time it renders. If it says the stored file no longer matches, the row has been altered in the database since it was written — the download is no longer the file whose hash was recorded.