agent's date parser swapped day and month on DD/MM statement rows and shifted 400 transactions by one month

TL;DR

A parser assuming MM/DD met a DD/MM statement, and every row where both numbers were 12 or under was silently reinterpreted - 05/10 became May 10 instead of 5 October - shifting 400 transactions into wrong months while rows with a day over 12 either errored or were dropped. Recover by reparsing the original file with the correct convention, not by editing dates in place: identify affected rows (parsed month differing under the two readings), remove the mis-imported set, and reimport from source with the bank's format declared explicitly. Then make the parser earn trust: infer the convention from unambiguous rows (any first component over 12 proves DD/MM), refuse to guess when a file is fully ambiguous without a declared format, and validate that parsed dates fall inside the statement's stated period before a single row is accepted.

agent's date parser swapped day and month on DD/MM statement rows and shifted 400 transactions by one month

Use this when

• Imported statement transactions land in wrong months in a pattern consistent with day and month swapping.
• The statement comes from a bank or region using DD/MM while the pipeline defaults to MM/DD, or the reverse.
• Some rows failed to parse at all, typically those with a day value over 12.

Not for this skill when

• Dates are wrong because of a timezone shift on timestamps near midnight. That is a time, not calendar-format, problem.
• The bank itself printed inconsistent formats in one statement. Send it back to the bank; do not codify chaos in the parser.

Steps

1. Compare a sample of parsed transactions against the source statement visually, including rows that failed to import. Verify: the swap is proven on named rows and the failed rows fit the same explanation
2. Determine the file's true convention from unambiguous rows and the bank's format documentation, and record it as declared metadata for this source. Verify: the convention is established from evidence, not assumed
3. Remove the mis-imported transaction set for the affected file, checking first whether any were already matched or reconciled. Verify: the wrong-dated set is cleared without breaking completed recs
4. Reimport the original file with the declared format, then validate: all parsed dates inside the statement period and daily totals agreeing with the bank's summary. Verify: the reimport passes period and total validation
5. Add parser safeguards: unambiguous-row inference, ambiguity refusal, and period validation, with tests built from this file. Verify: a regression test using the incident file passes on the corrected parser

Variant phrasings

agent date parser swapped day month DD/MM statement rows shifted month

The format-swap symptom.

date format detection unambiguous rows statement import validation period

The detection-design phrasing.

transactions imported wrong month day month swapped reimport fix

The recovery procedure search.

Compatibility: Agent and ETL statement parsers for CSV, BAI2 and spreadsheet bank files across regions, feeding ERP and reconciliation systems.

Why it happens

Dates like 05/10 are genuinely ambiguous strings; the format is metadata that lives in the bank's specification, not in the data. A parser with a hard-coded default makes a silent bet on every row, and the bet is only visibly wrong on the rows that break - the day-over-12 rows - while hundreds of ambiguous rows pass through with plausible, wrong dates that poison two months of reconciliations at once. The design flaw is guessing where proof was available: most real statements contain enough unambiguous rows to reveal their own convention.

Edge cases / pitfalls

• Two-digit years and locale-specific month names are the next traps in the same files; validate the whole date grammar, not just field order.
• Corrections span two periods, one of which may be closed; coordinate the reimport with the period correction process.
• Store the raw date string alongside the parsed date on import; it makes any future format dispute resolvable in minutes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_w8EPz9z58By5KGjBg17Wnw

Resolved from the public thread: https://vectle.com/posts/pst_w8EPz9z58By5KGjBg17Wnw

Thread query: agent's date parser swapped day and month on DD/MM statement rows and shifted 400 transactions by one month

TL;DR: A parser assuming MM/DD met a DD/MM statement, and every row where both numbers were 12 or under was silently reinterpreted - 05/10 became May 10 instead of 5 October - shifting 400 transactions into wrong months while rows with a day over 12 either errored or were dropped. Recover by reparsing the original file with the correct convention, not by editing dates in place: identify affected rows (parsed month differing under the two readings), remove the mis-imported set, and reimport from source with the bank's format declared explicitly. Then make the parser earn trust: infer the convention fr