DATEV import errors from bank and accounting files

DATEV import problems are usually not caused by one dramatic error. They come from small mismatches between the file, the export settings, and the import profile. A file can be perfectly reasonable for one accounting workflow and still fail in DATEV because the delimiter, encoding, date format, decimal separator, account mapping, or column order does not match what the import expects.

Many teams also move data through several formats before it reaches DATEV. Bank statements may start as CAMT.053, MT940, OFX, CSV, or a portal export. A bookkeeper may then convert or enrich the data before import. Every conversion step is an opportunity to lose meaning.

If you are troubleshooting a source bank file before conversion, start with a diagnostic pass:

Check your bank file

Know which import profile you are targeting

DATEV is used in several workflows. The expected file shape depends on the import profile, product area, region, and accounting process. A CSV intended for booking records is not the same as a bank statement exchange file. A file prepared for one consultant or chart of accounts may not fit another.

Before editing data, identify the target import profile and obtain a known-good sample if possible. Compare your file to the sample. Do not only compare column names. Compare delimiter, quote handling, decimal marks, date shape, encoding, required fields, and whether empty fields are represented consistently.

Delimiter and quote problems

CSV-like files are fragile. A semicolon-delimited export may be opened by spreadsheet software and saved as comma-delimited. A memo field may contain the delimiter character. A quoted field may contain a line break. The file still opens visually, but the importer reads the columns differently.

Typical symptoms include:

• fields shifting into the wrong columns
• account numbers appearing in description fields
• amounts split at a comma decimal separator
• header count not matching row count
• rows rejected after a description contains a delimiter

If you inspect the file in a spreadsheet, remember that the spreadsheet may silently transform it. For troubleshooting, use a plain text view as well.

Encoding and special characters

German accounting data often includes umlauts, names, addresses, and merchant descriptions with non-ASCII characters. If the file declares or assumes one encoding but is saved in another, DATEV may reject it or import garbled text.

Encoding issues can also appear after copying data between systems. Smart quotes, non-breaking spaces, byte order marks, and hidden control characters can create failures that are hard to see. If only a few rows fail, inspect text fields in those rows carefully.

Decimal separators and amount signs

Amount formatting is a frequent import blocker. A German-style decimal comma may be correct for one workflow, while another expects a dot. Thousands separators can be misread as decimal separators. Parentheses around negative values may be display-friendly but machine-unfriendly.

Debit and credit direction can be represented by sign, by separate debit and credit columns, or by a transaction type field. Conversions between bank statement formats and accounting import formats often get this wrong. A file that imports with signs reversed is more dangerous than a file that fails loudly.

Review a few known transactions before import:

• bank fees
• customer payments
• refunds
• internal transfers
• card payouts
• tax payments

Confirm that the sign and account side are correct after mapping.

Date formats and booking periods

DATEV import workflows may distinguish document date, posting date, value date, and statement date. Bank exports may include booking date and value date. OFX may include posted date and user date. CAMT.053 may include booking and value date elements.

When these fields are converted, labels can be swapped. A value date may become a posting date. A date may be exported as 2026-01-31, 31.01.2026, 20260131, or another local format. If the importer expects one shape and receives another, the row can fail.

Also check whether the imported dates belong to the selected accounting period. A structurally valid file can be rejected because it is outside the allowed period or conflicts with a locked period.

Account, contra account, and tax fields

Accounting import files usually need more than bank transaction data. They may need account numbers, contra accounts, tax keys, cost centers, document numbers, or booking text. Bank statement formats rarely contain all of that information. If a converter fills defaults, those defaults need review.

Common problems include:

• missing ledger account
• account numbers with leading zeros removed
• tax code missing or invalid for the selected account
• cost center not recognized
• booking text too long
• document number generated in a duplicate pattern

Spreadsheet software is especially risky for account numbers with leading zeros. Once the zeros are stripped, the file may look cleaner but fail mapping.

Source bank file problems

Sometimes the DATEV-facing file is wrong because the source bank file was wrong. A CAMT.053 statement may include unexpected namespaces. An OFX file may have duplicate transaction IDs. A CSV export may include pending transactions mixed with posted entries. Those problems propagate into the final import.

If you receive a converted file from a bank portal or middleware product, ask for the source export as well. Debugging only the final import file can hide the root cause.

Problems introduced by spreadsheet cleanup

Many DATEV import files pass through Excel, Google Sheets, or another spreadsheet during cleanup. That can be useful for human review, but it can also change the data. Dates may be reformatted. Long identifiers may become scientific notation. Leading zeros may be removed from account numbers. Decimal commas may become decimal dots, or the reverse. Text encoding may change when the file is saved.

These changes are easy to miss because the spreadsheet display looks clean. The importer reads the saved text file, not the display. Before using a spreadsheet in the process, confirm exactly how it exports delimiters, quote characters, line endings, and encoding.

If you must use a spreadsheet, protect sensitive columns as text before opening the file. Account numbers, document numbers, tax identifiers, and bank references should not be treated as numbers. After saving, compare row count, column count, and several representative rows against the original.

Mapping bank data into accounting meaning

Bank files describe movement of money. DATEV import workflows often need accounting meaning. A bank transaction description may say “CARD SETTLEMENT” or “TRANSFER”, but that does not identify the ledger account, tax treatment, cost center, or document relationship. Import failures sometimes reveal that the file is structurally fine but semantically incomplete.

This is why automatic conversion should be reviewed. A converter can infer useful defaults, but it cannot always know whether a payment is revenue, owner transfer, reimbursement, loan repayment, or tax-related movement. If the import succeeds with poor defaults, cleanup moves from technical troubleshooting into accounting correction.

Practical troubleshooting workflow

Use a layered approach:

1. Keep the original source export and the converted import file.
2. Identify the exact DATEV import profile.
3. Compare against a known-good sample.
4. Check delimiter, quotes, encoding, headers, and row length.
5. Review date formats and accounting period.
6. Validate amount signs and decimal separators.
7. Confirm account, tax, and cost center mappings.
8. Import a small sample before importing the full file.

The best fix depends on where the error was introduced. If the source bank file is malformed, re-export it. If the conversion is wrong, change converter settings. If the DATEV import profile does not match the file, adjust the import workflow rather than editing transaction data blindly.

correctbankfile.com can help with the bank-file side of that investigation before data is converted downstream.

Upload the source bank file and run a diagnosis

Check your bank file before you import again

Upload the export and get practical diagnostics for finance-file import failures.

Try the file checker Back to Help