CSV bank import failed: "invalid date format" error on rows from the Deutsche Bank format
Fixes a CSV bank import failing with invalid date format on Deutsche Bank rows: map the source date format explicitly, convert a sample file, and stop relying on locale auto-detection. Use when dates from one bank format break the import. Not for files with genuinely corrupt date values.
TL;DR
Deutsche Bank exports typically use day month year ordering with dots or a German locale format, while the importer guesses month first or expects ISO dates, so valid dates read as invalid or, worse, swap silently. Set the import mapping for this source to the exact format the file uses, convert and verify a small sample by checking known statement dates, then import the full file. Dates that parse but swap day and month are the dangerous version of this bug, so verification matters more than the import succeeding.
CSV bank import failed: "invalid date format" error on rows from the Deutsche Bank formatUse this when
- Import errors cite invalid date format on rows from a Deutsche Bank export.
- The file's dates use a format such as 31.12.2026 or 31/12/2026 while the importer expects another order.
- Other banks' files import into the same template without date errors.
Not for this skill when
- The file contains genuinely malformed values like month 13 from source corruption. Those rows need source correction.
- Dates import but amounts are wrong too. The whole template mapping is off for this source; rebuild it, not just the date field.
Steps
- Open the raw file and record the exact date strings on the first, middle, and last rows, plus the statement period they must fall inside. Verify: the source format is stated from the file itself
- Check the import template's date setting and the locale it assumes for this source. Verify: you can name the mismatch between file format and template expectation
- Create a source-specific template with the date format set explicitly to the file's format. Verify: the template is saved for the Deutsche Bank source only, leaving other banks untouched
- Convert and import a ten-row sample and check each imported date against the statement's known dates, including one date with a day above 12 that cannot swap silently. Verify: sample dates land exactly, with no day month swaps
- Import the full file and reconcile its total and date range to the statement. Verify: imported range covers the statement period and totals agree
Variant phrasings
Deutsche Bank CSV date format import invalid date
The bank-specific date phrasing.
bank CSV day month year format importer swapping dates
When silent swaps are the fear.
Compatibility: CSV bank import templates in QuickBooks, Xero, NetSuite, Sage, and custom import pipelines.
Why it happens
Date formats are conventions, not data URIs 03/04 can be March 4 or April 3, and dot-separated German dates are unambiguous only to readers who know the convention. Importers guess from system locale, and a guess that is wrong for one bank's export either rejects valid rows loudly, the lucky case, or swaps them quietly into wrong periods. Per-source explicit formats remove the guess for exactly the source that needs it.
Edge cases / pitfalls
- A day value above 12 in the sample is the only proof against swapping; always include one in verification.
- Some German exports carry a booking date and a value date column. Mapping the wrong one imports cleanly and reconciles badly; confirm which date the rec should use.
- Keep the raw file unchanged as evidence. Convert through the template, not by editing the bank's file.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_pRRhqfnoxiTvsN3xC4-ylg