Extract mixed South African and US dates by preserving the printed value, applying explicit field-level format rules and sending unresolved interpretations for human confirmation. Do not silently turn 04/05/2026 into either 4 May or 5 April. Both readings are possible without more evidence.
The workflow below is a proposed operating design, not a report of a completed implementation. Its examples are hypothetical. The aim is to give your team a clear decision: which dates can become structured values, and which must remain unresolved until someone checks the evidence.
1. Define the date field before choosing the format
Identify what each date means before interpreting its numbers. An invoice date, delivery date and payment due date are separate fields, even when they appear on the same page.
Start with a small inventory of the fields your downstream process actually needs. For each field, record its label, likely location, required precision and responsible reviewer. Decide whether a missing value blocks the record or merely creates a follow-up task.
Treat a PDF bundle as several possible documents, not one reliable locale. A South African covering letter might accompany a US supplier invoice and a locally completed delivery form. A format rule for the covering letter should not flow into the attachment.
Google’s Source: Document AI overview describes extracting text and layout, identifying fields, and splitting or classifying documents. Those capabilities can support evidence capture. They do not establish how your team should resolve an ambiguous date.
For a scoped document processing project, define the date fields and exception decisions before selecting extraction tools.
2. Preserve the printed date and its evidence
Store the original date text separately from its interpreted value. A reviewer should be able to see what was printed, where it appeared and why a particular reading was proposed.
Use the following proposed record fields:
| Field | What to retain |
|---|---|
raw_date |
Exact extracted text, including separators and missing parts |
date_role |
Invoice date, due date or another identified business field |
source_location |
Document reference, page and text position or image crop |
context_excerpt |
Nearby label and any relevant format note |
candidate_dates |
Valid interpretations in YYYY-MM-DD form |
resolved_date |
Chosen date, or null while unresolved |
status |
Ready, needs confirmation, missing, invalid or conflicting |
decision_evidence |
Applied rule or recorded human confirmation |
Keep OCR text and any corrected transcription distinguishable. If a reviewer reads a blurred character differently, record the correction without overwriting the original extraction.
Access to document images and excerpts should follow a policy reviewed by the appropriate security or privacy owner. Evidence retention is not a reason to distribute sensitive documents more widely.
3. Apply explicit rules within a narrow scope
Use a documented format declaration where it clearly applies to the field. Treat contextual clues as supporting evidence, not permission to guess.
A proposed evidence order is:
- A month written in words, with a complete year and readable day.
- An explicit field instruction such as
DD/MM/YYYYorMM/DD/YYYY. - A documented, approved rule for that exact template version and field.
- A numeric interpretation where only one supported ordering produces a valid calendar date.
- Other surrounding clues, which may inform a reviewer but should not independently resolve ambiguity.
For example, in a hypothetical field limited to day-first or month-first formats, 18/04/2026 has only one valid reading: 18 April. But 04/05/2026 still has two.
Do not let a South African address, rand amount or US email domain decide the order. A supplier can use imported software or several templates.
Record each proposed rule’s scope, owner and version. If a new template contradicts it, suspend that rule for the affected records and request confirmation rather than forcing the old interpretation.
4. Separate extraction from calendar validation
Let extraction identify evidence, then use deterministic checks to validate candidate dates. A neatly structured answer can still contain the wrong interpretation.
OpenAI’s Source: Structured Outputs guide describes responses constrained to a supplied JSON schema. That can support consistent fields and status values. Schema adherence does not establish that a date is factually correct.
In this proposed design, the extraction step returns the printed text, date role and evidence. Application code then checks the supported formats, valid month ranges, month lengths and leap-year conditions. The resolved field must accept null.
Keep two-digit years unresolved unless an approved rule explicitly defines the century. Do not fill in a missing year from the upload date. Similarly, a date-only value should remain a date, not become a timestamp with an invented time zone.
A hypothetical 31/04/2026 is invalid under both relevant orderings. It needs correction or confirmation, not a swap. Business chronology can flag an unusual sequence, but should not manufacture a replacement date.
5. Give reviewers a specific confirmation task
Ask reviewers to choose between visible interpretations using evidence, rather than presenting a single answer for approval. This makes the unresolved decision explicit.
For a hypothetical 04/05/2026, show:
- Original text and page crop.
- Field label and nearby format information.
- Candidate A: 4 May 2026, stored as
2026-05-04. - Candidate B: 5 April 2026, stored as
2026-04-05. - Any conflicting evidence.
- Actions to select a candidate, enter a supported correction, request confirmation or leave unresolved.
The proposed confirmation request to the issuer is: “Please confirm whether the invoice date printed as 04/05/2026 means 4 May 2026 or 5 April 2026.”
Record who confirmed it, what evidence they used and when the record changed. A reviewer’s unsupported preference should not become a permanent supplier rule.
Where the date affects payment, tax, employment obligations or legal deadlines, confirmation prepares the record for the appropriate human decision. It does not authorise that decision. Escalate uncertain consequences to the responsible finance, HR or legal person.
6. Control hand-offs and duplicate records
Release only resolved date values into date-dependent downstream steps, while keeping unresolved records visible in a review queue. Do not replace missing dates with today’s date or an empty string that another system might interpret incorrectly.
If you use tools to retrieve template rules or create review tasks, keep their permissions narrow. OpenAI’s Source: function calling guide explains that a model can request a function call and application code executes it. Your application should therefore validate the request and enforce the release rule itself.
A retry should update the existing extraction record rather than create another business document. Link exact duplicate files to their original record. Treat revised documents separately, preserving the earlier version and its decisions.
The choice between a fixed parser and a more flexible orchestration layer should follow the exception work required. The AI agents vs automation comparison provides a useful starting point. The custom AI agent glossary explains the term; an agent is not required simply because dates are ambiguous.
7. Evaluate ambiguous cases before expanding the workflow
Evaluate the proposed process against human-labelled examples, including cases that should remain unresolved. Measuring only whether the output contains a date rewards guessing.
Build a representative evaluation set with readable day-first and month-first fields, explicit format labels, mixed attachments, poor scans, missing years, impossible dates and revised documents. Keep rule-development examples separate from the examples used for final evaluation.
Compare each extracted date with a human-confirmed answer and its supporting evidence. Track:
- Correct resolved dates among fields released as ready.
- Ambiguous dates incorrectly released without confirmation.
- Missing or invalid dates replaced with invented values.
- Fields routed unnecessarily to review.
- Records whose evidence could not be retrieved.
- Duplicate records created during retries.
A proposed release criterion is that known unresolved ambiguities must not pass as ready. The team should set other acceptance criteria according to the consequences of error, not a generic confidence percentage.
Repeat the evaluation when templates, parsing rules or extraction components change. The custom AI agents workflow resource can help frame broader orchestration, but this date policy needs its own acceptance checks. Any potential improvement in accuracy or review effort must be demonstrated locally.
Reusable date-ambiguity review policy
Use this proposed policy as a starting point for team approval. It covers both the interpretation decision and the evidence required to close an exception.
Proposed policy: mixed-format document dates
Scope: Apply per date field and document version. Never infer a bundle-wide format from country or currency.
| Evidence or condition | Proposed handling |
|---|---|
| Readable month in words, complete year | Validate calendar date; retain printed evidence |
| Explicit field format or approved matching template rule | Apply rule; record its scope and version |
| Only one valid day-first/month-first interpretation | Resolve only within supported formats; record reason |
| Both interpretations valid, no decisive rule | Retain both candidates; leave resolved date null |
| Missing year, two-digit year without rule, or unreadable text | Request clarification; do not supply missing parts |
| Impossible date or conflicting format evidence | Hold field for correction or confirmation |
| Exact duplicate file | Link to existing record; do not create another business record |
| Revised document | Preserve versions; review changed dates separately |
Review procedure: Show the original crop, label, candidates and conflict. Assign a named reviewer. Record their selection, confirmation evidence and decision time. If evidence remains insufficient, keep the field unresolved and request issuer confirmation.
Release gate: Export resolved dates as YYYY-MM-DD; keep raw text and evidence retrievable. Unresolved fields must not drive date-dependent actions. Payment, tax, employment and legal consequences remain with the appropriate human decision-maker.
Hypothetical walkthrough: one bundle, different decisions
Handle each field independently, even when the documents arrived together. Consider this entirely hypothetical bundle received by a South African purchasing team.
Normal case: A delivery form says Delivered: 18/04/2026. The image is readable, the year is complete and the field supports day-first or month-first formats. Calendar validation finds only 18 April valid. The record becomes ready with 2026-04-18, retaining its page location and interpretation reason.
Ambiguous case: The attached supplier invoice says Invoice date: 04/05/2026, with no format declaration. Its US address is not decisive evidence. The system retains 4 May and 5 April as candidates, leaves resolved_date null and assigns a reviewer. The reviewer requests issuer confirmation. If the issuer confirms 5 April in writing, the reviewer records that evidence and resolves the field as 2026-04-05.
Missing case: A handwritten receiving note shows 04/05 without a year. The reviewer requests the missing year and date order. Neither the delivery date nor the arrival date fills the gap automatically.
Duplicate case: The same invoice file arrives again. The proposed duplicate check links it to the existing unresolved record rather than producing a second invoice entry. If a corrected invoice arrives instead, the reviewer compares versions and records which one should supply the date.
FAQs about mixed-format date extraction
These answers keep common shortcuts from overriding the evidence policy.
Can one clear date establish the format for every date on a page?
Not by itself. A hypothetical 18/04/2026 supports a day-first reading for that field, but another field may come from a different system. Use it as context unless an explicit declaration or approved template rule covers both fields. If the page mixes a supplier header, imported table and handwritten note, assess those areas separately. A contradictory date should trigger review of the rule’s scope, not automatic conversion.
Should a high model confidence score resolve 04/05/2026?
No. Under this proposed policy, confidence cannot replace decisive evidence. A model may prefer one interpretation while both remain valid. Show the original text and both calendar candidates, then request confirmation. If confidence scores are available, evaluate whether they help prioritise review, but do not make them the release gate. The key question is whether the document or a recorded confirmation supports the chosen date.
Can a due date be calculated when only the invoice date is present?
Keep calculation separate from extraction. If an approved business rule permits a derived date, label it as derived and retain its inputs and rule version. Do not claim it was printed on the invoice. If the invoice date is unresolved, the calculation must wait. Payment terms, business-day rules and contractual consequences require the appropriate finance or legal judgement before the derived value is used.
If your business needs help defining this evidence trail and review queue, Symaxx’s AI automation service is a starting point. Get in touch to discuss the document types, unresolved cases and human decisions the proposed workflow must support.

