Invoice Field Extraction from Unstructured Text Prompt Template

This prompt is designed for accounts payable automation teams and data pipeline engineers who receive unstructured invoice text from OCR engines, email bodies, or model narratives and need to convert it into a validated, structured JSON record. Use this prompt when the source text contains invoice-level information including vendor details, line items, totals, tax amounts, and dates but arrives as free text rather than a typed schema. The ideal user is an integration engineer or AP operations lead who already has a working extraction pipeline but encounters a recurring failure mode: the upstream model or OCR system produces a narrative description of the invoice instead of a machine-readable payload, and that narrative must be repaired into a clean, application-ready record without manual re-keying.

This prompt is part of the Output Repair and Validation Prompts pillar because it handles the post-generation repair loop. It is not a general-purpose extraction prompt for raw document images or PDFs. It assumes the text has already been extracted and that the failure is structural—the information exists in prose form but lacks the schema required by your general ledger, ERP, or approval system. The prompt includes built-in arithmetic validation checks that reconcile line-item sums against stated subtotals, tax amounts, and invoice totals. These checks serve as a first-pass quality gate, flagging records where the extracted figures do not add up so your pipeline can route them for human review rather than silently posting incorrect data.

Do not use this prompt when the source is a clean, typed invoice object already conforming to your schema—that is a straight mapping problem, not a repair problem. Do not use it for multi-page legal contracts, purchase orders, or receipts, which have different field semantics and validation rules. Do not use it as a substitute for a proper OCR confidence threshold or as the sole validation layer in a high-volume, fully automated posting pipeline. In regulated environments where incorrect invoice posting has material financial or compliance impact, always pair this prompt with a human-in-the-loop review step for any record that fails arithmetic validation or has missing required fields. The next section provides the copy-ready prompt template you can adapt for your specific invoice schema and validation rules.

This template is designed to be the core instruction you send to a model when a previous extraction attempt has failed, or when you are working with raw, unstructured text that needs to be converted into a clean, typed invoice record. It is not a general-purpose extraction prompt; it is specifically hardened for the repair and normalization of invoice data, including line items, totals, and tax breakdowns. The template uses square-bracket placeholders like [INPUT_TEXT] and [OUTPUT_SCHEMA] that you must replace with your actual data and constraints before execution. This prompt assumes you have already attempted a structured output generation and are now in a repair loop, or that you are dealing with narrative text from an OCR engine.

Below is the copy-ready template. Replace every placeholder with your concrete values. The [OUTPUT_SCHEMA] should be a strict JSON schema. The [CONSTRAINTS] section is where you enforce business rules like currency normalization to USD or arithmetic consistency checks. The [EXAMPLES] section is critical for few-shot repair; provide at least one example of a malformed input and its perfectly corrected output. The [RISK_LEVEL] placeholder should be set to high for any financial data, which will trigger the instruction to flag low-confidence fields for human review.

textCopy
You are an expert data repair agent specializing in financial documents. Your task is to extract structured invoice data from the unstructured text provided below. The previous extraction attempt failed validation or produced a narrative instead of a typed record. You must repair this by outputting a single, valid JSON object that strictly conforms to the provided schema.

### UNSTRUCTURED INPUT TEXT
[INPUT_TEXT]

### REQUIRED OUTPUT JSON SCHEMA
You must output a JSON object that validates against this schema. Do not include any fields not defined here.
[OUTPUT_SCHEMA]

### CONSTRAINTS AND NORMALIZATION RULES
- Currency: Normalize all monetary values to [TARGET_CURRENCY] using a precision of two decimal places. Do not include currency symbols in numeric fields.
- Dates: Convert all dates to ISO 8601 format (YYYY-MM-DD).
- Line Items: Extract every line item into the `line_items` array. Recalculate the `line_total` for each item as `quantity` * `unit_price`.
- Arithmetic Verification: Calculate the sum of all `line_items.line_total` and the `tax_amount` to verify it matches the provided `total_amount`. If it does not, set the `totals_match` field to `false`.
- Missing Information: For any required field where the value is not present in the text, use `null` and add the field path to the `missing_fields` array.
- Confidence: For each top-level field and each line item, provide a `confidence` score between 0.0 and 1.0.
[CONSTRAINTS]

### FEW-SHOT EXAMPLES OF REPAIR
[EXAMPLES]

### RISK LEVEL
[RISK_LEVEL]

### FINAL INSTRUCTION
Output only the JSON object. Do not include any explanatory text, markdown fences, or code blocks before or after the JSON. If the risk level is `high`, you must include a top-level field `requires_human_review` set to `true` if any required field has a confidence score below [CONFIDENCE_THRESHOLD].

To adapt this template, start by pasting your raw, unstructured invoice text into [INPUT_TEXT]. Then, define your [OUTPUT_SCHEMA] as a strict JSON schema, including required fields like invoice_number, vendor_name, invoice_date, total_amount, and line_items. In the [CONSTRAINTS] section, specify your target currency and any other business logic. Crucially, populate [EXAMPLES] with one or two pairs of a malformed input and its correct, schema-compliant JSON output. This teaches the model the exact repair pattern you expect. Finally, set [RISK_LEVEL] to high and [CONFIDENCE_THRESHOLD] to 0.9 for financial workflows. After receiving the output, you must programmatically validate it against your JSON schema and the arithmetic consistency rule before considering the repair successful. If validation fails, the output should be fed back into this same template as a new [INPUT_TEXT] for a retry loop, up to a defined limit.

This prompt is designed to be a post-generation repair step, not the primary structured output generator. The typical integration pattern is: (1) attempt structured generation via function calling or JSON mode, (2) if that fails or returns narrative text, route the output to this prompt for repair, (3) validate the repaired output against the invoice schema, and (4) escalate to human review if validation still fails. Do not use this prompt as your first-choice extraction method—it is a safety net for when the model ignores your output format instructions.

Validation checks must run after every extraction. At minimum, verify: (a) invoice_total equals the sum of line_items[].line_total plus tax_breakdown[].tax_amount, within a small floating-point tolerance; (b) all required fields (invoice_number, invoice_date, vendor_name, invoice_total, currency) are present and non-null; (c) invoice_date and due_date parse to valid ISO 8601 dates; (d) currency matches an expected ISO 4217 code; and (e) line_items is a non-empty array with each item containing description, quantity, unit_price, and line_total. If any check fails, log the specific failure and the raw model output for debugging. For high-value invoices (above a configurable threshold), route failures to a human review queue with the original OCR text, the extracted fields, and the specific validation errors highlighted.

Retry logic should be bounded. If the first repair attempt produces invalid output, retry once with the same prompt but prepend the validation errors as additional context: [PREVIOUS_OUTPUT] and [VALIDATION_ERRORS]. If the second attempt also fails, stop retrying and escalate. Avoid infinite repair loops—each retry costs tokens and latency. For production systems processing hundreds of invoices per hour, consider a model routing strategy: use a faster, cheaper model for the initial structured extraction attempt, and reserve a more capable model (e.g., GPT-4 or Claude 3.5 Sonnet) for the repair step only when the primary extraction fails.

Logging and observability are critical. Capture the raw OCR input, the primary extraction output, whether the repair prompt was invoked, the repaired output, validation results, and the final disposition (accepted, repaired, escalated). This trace data lets you measure repair prompt effectiveness over time and identify patterns—for example, if certain vendors or invoice formats consistently trigger the repair path, you may need to improve your primary extraction prompt or add few-shot examples for those cases. Store these traces in your existing observability platform (Datadog, Grafana, etc.) alongside other model inference metrics.

Human review integration should present reviewers with a side-by-side view: original document text on the left, extracted fields on the right, with validation failures highlighted in red. Allow reviewers to correct fields directly and submit the corrected record. Use these corrections as feedback data to improve both the primary extraction prompt and the repair prompt over time—each human correction is a labeled example you can add to your few-shot examples or use for fine-tuning evaluation.