agent failed to parse the receipt date: ambiguous d-m-y format error

Not specified by the original author.

TL;DR

Dates like 04/05/2026 are ambiguous between day-month and month-day order. Parse using the receipt's locale (vendor country, currency), flag dates that are valid both ways, and confirm the ambiguous ones rather than guessing.

Error

agent failed to parse the receipt date: ambiguous d-m-y format

Steps

1. Detect the receipt's locale signals: vendor country, currency, and address format. Expected: a likely date-order convention.
2. Parse the date under that convention. Expected: a candidate date.
3. Check whether the date is also valid under the other convention (both day and month are 12 or less). Expected: ambiguous dates are identified.
4. For ambiguous dates, prefer the transaction or card-posting date as a tiebreaker where available. Expected: an independent signal resolves most cases.
5. Where no tiebreaker exists, flag the date for human confirmation instead of guessing. Expected: no silent wrong dates.

When to use

• Receipt dates are ambiguous between day-month and month-day.
• The vendor operates in a day-first locale but the agent assumes month-first.

When not to use

• The date is missing entirely (request the date).
• The date is unambiguous but wrong (an OCR problem).

Tool compatibility

• Custom agent date parsing; locale-aware date libraries.

Variant phrasings

Ambiguous date on receipt

Same failure, shorter wording.

Could not determine date order

The parsing-specific phrasing.

Why it happens

Much of the world writes day-month-year while the US writes month-day-year. A parser with one default convention silently misdates every receipt from the other convention.

Provenance

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

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

Thread query: agent failed to parse the receipt date: ambiguous d-m-y format error

TL;DR: Dates like 04/05/2026 are ambiguous between day-month and month-day order. Parse using the receipt's locale (vendor country, currency), flag dates that are valid both ways, and confirm the ambiguous ones rather than guessing.

Not specified by the original author.

TL;DR

A swapped date never looks broken, the thirteenth of a month is impossible and gets caught, but the fifth of June read as May the sixth sails through every validation and quietly moves a renewal by a month. Contracts mix date conventions by counterparty and country, and an agent parsing all of them with one assumed order will swap every ambiguous date it meets. Detect the pattern from the impossible dates it rejected, parse with the documents own locale evidence, route true ambiguity to humans, and rebuild the forecast from corrected dates.

agent extracted renewal dates from contracts with day and month swapped: forecast off by months

Use this when

• Extracted renewal dates are systematically off by weeks or months, clustering where day and month values are both small
• Some contracts failed extraction with invalid dates, the visible tip of the same problem
• The contract set spans countries or counterparties with different date conventions

Not for this skill when

• The agent reads dates correctly and the forecast error comes from amendments changing the real dates later
• Contracts use one consistent format and the errors are random OCR misreads of digits, a different defect

Steps

1. Measure the swap pattern from evidence. Gather extracted renewal dates and their source contract texts for a sample, compare each against the date as written in the document, and count how many match a day month swap exactly, how many are correct, and how many failed as impossible. The impossible ones, where the day value exceeds twelve in the written order, prove which convention those documents used. Verify: the sample is classified into swapped, correct, and previously impossible with counts
2. Find the parsing assumption in the agent. Locate where extracted date strings become dates, identify the single format or locale the parser assumes, and check whether anything upstream, OCR, a template, or a language model extraction step, normalises the written date before parsing, because a helpful normalisation to one format is often where the original convention information is destroyed. Verify: the parsing assumption and any normalising step are pinpointed
3. Rebuild parsing on document evidence. Determine each contracts convention from unambiguous clues in the document itself, dates written in words, a governing law or address country, the contracts own date format elsewhere, or an impossible value that reveals the order, and only then parse the renewal date with that convention, recording which evidence decided it alongside the extracted value. Verify: the rebuilt parser classifies the sample correctly with the deciding evidence logged per contract
4. Route genuine ambiguity to people. Where a date is ambiguous and no document evidence resolves it, the agent must flag the contract for human reading instead of guessing, and the forecast should show that renewal as date uncertain within a range, because a guessed date presented as fact is worse than an honest range a rep can plan around. Verify: ambiguous test contracts are flagged with a range rather than assigned a guessed date
5. Repair the forecast and its history. Re-extract renewal dates across the contract base with the corrected parser, list every date that changed and by how much, rebuild the renewal forecast, and brief the owners of accounts whose renewal moved materially, since some renewals are now months sooner than the plan they are working to. Verify: changed dates are listed and owners of materially moved renewals are briefed
6. Add date extraction tests and monitoring. Keep contracts covering each convention and the ambiguous case as regression fixtures, and monitor extracted dates for sanity, renewal dates in the past for active contracts, impossible clustering on the first of a month, and report extraction confidence per contract so forecast consumers can see which dates are solid and which are inferred. Verify: the regression fixtures pass and the sanity report runs on the live extraction

Why it happens

Most of the world writes day before month and one large market writes month before day, and both produce identical looking short dates for most of the month. A parser must choose, and a single global choice is wrong for a mixed contract base roughly whenever the day is twelve or under, which is most renewals. The errors are worst precisely because they are small and plausible, shifting quarters and cohorts without ever triggering a sanity check that looks for broken values rather than wrong ones.

Compatibility: Contract date extraction by agents, OCR and document parsing, locale date conventions, and renewal forecasting, in current document processing tooling.

Variants and edge cases

renewal dates day month swapped contract parsing

['The direct phrasing. Impossible dates in the rejection pile are diagnostic treasure, they reveal the documents true convention without guessing.']

agent extracted wrong renewal dates locale format

['The locale variant. Evidence based per document parsing beats a global setting, mixed portfolios guarantee any single setting is wrong for someone.']

forecast off months contract date extraction

['The forecast variant. List every changed date when you repair it, a silently rebuilt forecast leaves reps working from memorised wrong dates.']

Edge cases to work through before you close the incident:

• Dates written in words are the gold standard in a contract. Where they exist, extract them preferentially and use them to calibrate the numeric dates in the same document.
• A two digit year adds a second ambiguity layer. Handle it explicitly in the parser rules rather than inheriting a library pivot year silently.
• Amendments can carry dates in a different convention from the master agreement if the parties differ. Parse each document on its own evidence, never inherit the account level assumption blindly.

Provenance

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

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

Thread query: agent extracted renewal dates from contracts with day and month swapped: forecast off by months

TL;DR: A swapped date never looks broken, the thirteenth of a month is impossible and gets caught, but the fifth of June read as May the sixth sails through every validation and quietly moves a renewal by a month. Contracts mix date conventions by counterparty and country, and an agent parsing all of them with one assumed order will swap every ambiguous date it meets. Detect the pattern from the impossible dates it rejected, parse with the documents own locale evidence, route true ambiguity to humans, and rebuild the forecast from corrected dates.

Not specified by the original author.

TL;DR

Dates like 04/05/2026 are ambiguous between US and international formats, and picking wrong shifts payment timing and period posting. Resolve with vendor country (US vendors use MM/DD, most others DD/MM), then sanity-check against the invoice receipt date and due-date terms. Store dates in ISO format internally and never guess silently: flag true ambiguities.

Error

Extracted invoice date: 04/05/2026 (ambiguous: April 5 or May 4)

Steps

1. Check the vendor's country in the vendor master. Expected: US implies MM/DD/YYYY; most other countries imply DD/MM/YYYY.

2. Cross-check with related dates: due date should equal invoice date plus terms. Expected: The terms arithmetic disambiguates most cases.

3. Verify the date is not in the future and falls within a plausible window. Expected: Obvious misreads get caught.

4. Store the resolved date as ISO YYYY-MM-DD with the interpretation recorded. Expected: An auditable, unambiguous record.

5. If still ambiguous, flag for review rather than guessing. Expected: A wrong date misstates the period.

When to use

• Extracted date has day <= 12 and could be either format
• International vendor base with mixed formats
• Payment terms depend on the invoice date

When not to use

• Date is completely missing from the invoice
• Mapping dates to fiscal periods
• Timezone handling

Compatibility

Extractor-agnostic. Vendor master country data required.

Variant phrasings

invoice date format ambiguous

04/05/2026 month day confusion

US vs EU date on invoice

Root cause

The US uses month-first while most of the world uses day-first, and invoices rarely label the format. OCR reads the digits correctly; the meaning is what is ambiguous.

Edge cases

• Vendors operating in both formats need per-vendor configuration, not country default
• Some invoices print both order date and invoice date; label them before resolving
• Year boundaries (12/01 vs 01/12) affect period close; escalate these

Provenance

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

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

Thread query: invoice date ambiguity: MM/DD/YYYY vs DD/MM/YYYY

TL;DR: Dates like 04/05/2026 are ambiguous between US and international formats, and picking wrong shifts payment timing and period posting. Resolve with vendor country (US vendors use MM/DD, most others DD/MM), then sanity-check against the invoice receipt date and due-date terms. Store dates in ISO format internally and never guess silently: flag true ambiguities.