Your invoice-extraction tool returns dates in whatever format appeared in the source — sometimes "May 4, 2024", sometimes "5/4/2024", sometimes "2024-05-04", sometimes "04 May 24". Downstream systems expect ISO 8601 (YYYY-MM-DD). Currently the team runs a post-processing date-parser, which catches most cases but silently mis-parses 5/4/2024 as April 5 sometimes (DD/MM) and May 4 other times (MM/DD).
What's the cleaner fix?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
Normalize at the layer that has full context. During extraction, the model sees the whole document — it knows which field is the invoice date, what the country is, whether dates elsewhere are formatted MM/DD or DD/MM. A post-processing parser sees only the date string with none of that context, so it has to guess. In-prompt normalization rules let the model use document-level context to produce a correct ISO date the first time, and explicitly flag ambiguous cases instead of silently guessing wrong.
Post-processing parsers are blind to document-level context, which is exactly what disambiguates 5/4/2024. More cases in the parser don't help when the parser fundamentally can't see the surrounding fields.
Asking every downstream system to accept every format multiplies the problem — every consumer now has to parse dates, and every consumer has the same disambiguation issue. Normalize once, at the source.
Most invoices in the wild aren't issued in ISO 8601. Rejecting non-ISO sources discards the majority of real documents — solving the format problem by abandoning the data.