Skip to content

Error codes

These status strings appear in the UI, in messages, and in toasts. Below are the cause, consequence, and the concrete steps to resolve each.

Cause: The DATEV export is blocked by an integrity gate. It checks for open exceptions (orders or payments with status PENDING/EXCEPTION in the period) and orders without a EUR amount.

Consequence: No DATEV-EXTF is produced. The request is rejected with the code EXPORT_BLOCKED and a list of the issues.

Resolution:

  1. Open Resolve (/exceptions) and clear all open exceptions.
  2. Check orders without a EUR amount — usually a foreign currency without conversion (see FX_UNCONVERTED).
  3. Then close the period and start the export again.

See DATEV-EXTF validation.

Cause: A foreign-currency order has no EUR conversion yet.

Consequence: The order cannot be booked; it appears as an exception and can trigger EXPORT_BLOCKED.

Resolution:

  1. Look up the EUR rate for the transaction date (e.g. the ECB reference rate).
  2. Convert the amount.
  3. Enter the EUR amount via Accept corrected.

Cause: A source file was uploaded, but its matching counterpart source has not been uploaded yet — for example, a payout without the matching bank CSV as the counterpart.

Consequence: The file cannot be fully reconciled. It appears as an amber card in the Resolve or Imports area.

Resolution:

  1. Upload the missing counterpart source for the same period (e.g. the bank CSV).
  2. Reconciliation re-runs automatically; the card disappears once the counterpart is present.

Which source is the counterpart for which payout is shown on Supported sources.

Cause: An uploaded CSV could not be read — wrong column headers, a corrupted file, or a run that stalled during processing.

Consequence: The file is marked with status PARSE_ERROR; its rows do not enter reconciliation.

Resolution:

  1. Open the file in the imports list and review the error details.
  2. Re-export the source without changing the column headers.
  3. Upload the corrected CSV again (UTF-8 recommended).

Cause: The same file (identical content, same hash) has already been uploaded.

Consequence: The re-upload is rejected (HTTP 409). No duplicate record is created — KanzleiSynchron points to the file that already exists.

Resolution:

  • This is usually not an error but a safeguard against double-booking. Check whether the original file was already processed.
  • If this is meant to be new data, re-export the current date range — a file with changed content has a different hash and will be accepted.