Join for free

Extract fields to verify from invoices

Author: AILesson9 min setupTested with:ChatGPTReviewed: 2026-08-28

Quick answer

Extract invoice headers, lines, tax, payment terms, and anomalies with source locations and arithmetic checks. Provide: Invoice text or OCR, Required fields and definitions, Verification and privacy controls. Expected result: A source-linked invoice record, line table, verification queue, duplicate keys, and reconciliation.

1

Add your context

Your text stays in this browser. AILesson Prompts does not send it to a model or server.

2

Your prompt

Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt

Extract fields from the supplied invoice for human verification.

Invoice text or OCR:
[invoice]

Required schema:
[schema]

Controls:
[controls]

Treat OCR as unverified evidence. Preserve the exact source string and page or line location for every extracted value; use Not found or Unclear rather than guessing. Never normalize an ambiguous digit, date, currency, tax ID, bank detail, quantity, rate, or total without showing the original. Extract header fields and one row per line item, then check quantity × unit price, discounts, subtotal, tax by rate, withholding, prior payment, rounding, and amount due under the supplied definitions. Do not infer tax validity, vendor legitimacy, delivery, approval, bank ownership, or payment eligibility. Flag unexpected bank changes, duplicate keys, PO mismatches, missing mandatory fields, unreadable text, and arithmetic differences for the authorized reviewer. Output extraction tables, reconciliation, field-level confidence and reason, and a verification queue ordered by payment risk.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.

From input to outcome

A worked example

See how concrete context turns this recipe into a usable result

Actual input

Invoice text or OCR
Page 1 lines 1–5: NORTHLIGHT PRINT CO. | Invoice NL-2048 | Invoice date 2026-08-18 | Due 2026-09-17 | Currency CNY Lines 6–8: Bill to River Studio | PO RS-771 | Tax ID 91310O?45 (OCR; sixth character may be zero or letter O) Table lines 10–13: Design proof | qty 2 | unit 450.00 | amount 900.00; A4 booklets | qty 300 | unit 8.00 | amount 2,400.00; Delivery | qty 1 | unit 180.00 | amount 180.00 Lines 15–19: Subtotal 3,480.00 | Discount 100.00 | Tax 6% 202.80 | Total 3,582.80 | Deposit received 500.00 | Amount due 3,082.8O (last character OCR letter O) Line 22: Pay to Harbor Bank acct ending 8841. Handwritten: ‘new bank from Aug’. No delivery date shown.
Required fields and definitions
Header: vendor legal name, invoice number, invoice date, due date, currency, buyer, PO, supplier tax ID, bank ending. Lines: description, quantity, unit price, line amount. Totals: subtotal before discount, discount, taxable base, tax rate, tax, total, deposit, amount due. ISO dates; amounts decimal. Duplicate key vendor + invoice number + gross total. Match PO amount and approved bank against reference. Arithmetic: taxable base = subtotal - discount; tax = base × rate; total = base + tax; due = total - deposit.
Verification and privacy controls
Reference: PO RS-771 approved maximum CNY 3,600 including tax; expected items and quantities match all three lines. Vendor master bank ends 1139, not 8841. No prior invoice NL-2048 in register. Tolerance CNY 0.01. Medium or low confidence needs Accounts Payable review. Never expose full bank or tax identifiers. Extraction cannot approve payment or validate tax. Bank change always blocks payment until vendor verification through an approved independent contact.

Example output

Invoice extraction — verification required

Header: vendor NORTHLIGHT PRINT CO. (p1 l1, high); invoice NL-2048 (l2, high); invoice date 2026-08-18 and due 2026-09-17 (l3–4, high); currency CNY (l5, high); buyer River Studio and PO RS-771 (l6–7, high); tax ID source “91310O?45” (l8, low, redacted display 913…?45; do not normalize); bank ending 8841 (l22, high transcription, failed master-data match).

LineQtyUnitAmountCheck
Design proof2450.00900.00matches
A4 booklets3008.002,400.00matches
Delivery1180.00180.00matches

Line sum 3,480.00 matches subtotal. Taxable base 3,480.00 − 100.00 = 3,380.00. Tax 3,380.00 × 6% = 202.80. Total 3,380.00 + 202.80 = 3,582.80. Due 3,582.80 − 500.00 = 3,082.80; source “3,082.8O” is low-confidence OCR but arithmetic supports 3,082.80 for review, not silent correction. Gross total is within PO maximum by 17.20 and listed items match the supplied PO reference; this does not prove receipt or approval. Duplicate key is new in the supplied register.

Payment-risk queue: 1) Block payment: bank ending differs from master 1139 and handwritten change is not verification; confirm through approved independent contact. 2) Verify ambiguous tax ID against authoritative vendor record. 3) Visually confirm amount-due final character. 4) Confirm deposit evidence and goods/service receipt; delivery date is not found. 5) Authorized reviewer decides tax validity and payment eligibility. Extraction status: complete with blockers; no payment approval.

Why this works

  1. 1

    Source strings and locations make every normalized field auditable against imperfect OCR

  2. 2

    Arithmetic and reference checks catch payment risks that accurate transcription alone cannot

Check the result

  • Can every extracted or normalized value be traced to an exact source location and original string?

  • Do lines, subtotal, tax, prior payment, and amount due reconcile within the stated tolerance?

  • Are bank changes, duplicates, PO differences, missing fields, and ambiguity kept out of automatic approval?

Use it with confidence

Frequently asked questions

Practical answers about when to use this recipe, what to provide, and where human review still matters

What should I prepare before using “Extract fields to verify from invoices”?

For “Extract fields to verify from invoices,” prepare Invoice text or OCR, Required fields and definitions, and Verification and privacy controls. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.

When is the “Extract fields to verify from invoices” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—A source-linked invoice record, line table, verification queue, duplicate keys, and reconciliation—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.

Which AI tools have recorded tests for “Extract fields to verify from invoices”?

The published test record for “Extract fields to verify from invoices” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.

More ways to explore

Where this recipe fits

Text promptsDocument analysisData analysisFinance, procurement & administrationProcurement & vendor management

Keep the work moving