Extract structured data from messy documents without silently inventing fields

You are extracting structured data from a vendor invoices (PDF, OCR'd text) into JSON that must validate against the schema below and feed directly into a downstream database — a wrong or invented value here is worse than a missing one, because it looks identical to a correct value once it's in the database.

TARGET SCHEMA
{ invoice_number: string, vendor_name: string, invoice_date: string, due_date: string | null, line_items: [{description, qty, unit_price, total}], subtotal: number, tax: number, total: number }

SOURCE DOCUMENT
the OCR'd text of a single invoice PDF, pasted in full including any garbled OCR artifacts

EXTRACTION RULES
- Extract only values actually present in the document, in the form they appear. Don't normalize a date format, currency, or unit unless the normalization rules below say to — normalization is itself a transformation that can introduce errors, so it needs to be an explicit, auditable rule, not something you decide to do on the fly.
Convert all dates to ISO 8601 (YYYY-MM-DD); leave currency amounts in the original currency, do not convert
- If a field required by the schema isn't present anywhere in the document, set it to null and add it to a separate "missing_required_fields" list — never fill it with a plausible-looking default just to satisfy the schema's type requirement.
- If a field's value is present but ambiguous — a name that could be split into first/last two different ways, a date format that could be read as either DD/MM or MM/DD — flag it in "ambiguous_fields" with the possible readings, rather than picking one silently.

CONFIDENCE HANDLING
For every extracted field, include a confidence of "high", "medium", or "low": high means the value appears verbatim and unambiguously; medium means the value required light inference, such as reading a total from a subtotal-plus-tax line rather than a single stated total; low means the value was inferred from context rather than stated directly. A downstream reviewer uses this to decide what to spot-check — don't mark everything "high" by default.

VALIDATION
After extraction, check your own output against the schema: correct types, required fields present even if null, no extra fields not in the schema. If your output fails this check, fix it before returning it — don't return invalid JSON and note the problem in prose instead.

OUTPUT FORMAT
Valid JSON matching the schema, plus three arrays: missing_required_fields, ambiguous_fields with alternate readings, and low_confidence_fields with the field name and why. If the document is unreadable, corrupted, or clearly not a vendor invoices (PDF, OCR'd text), say so instead of returning a JSON object full of nulls.