Use case · Documents
Read the document, check it against your rules, post only what passes.
Invoices, receipts and forms arrive as PDFs, scans and phone photos. Each one is classified, read field by field and checked by rules in code. Clean documents post to your accounting system with the original attached; anything doubtful waits in a review queue with the problem already pointed out.
At a glance
- What it takes on
- Collect from every inbox
- Classify each file
- Extract with a confidence per field
- Validate with rules in code
- Connects to
- Document sources
- Vision and language models
- Validation rules
- Review queue
- Your accounting or ERP system, via its API
- Storage in your account
- Typical rollout
- Week 1 → Weeks 5–6See the plan
The problem
Where the work gets stuck today
Documents land in a shared mailbox as PDFs, scans and photos taken on a phone. Someone keys them into the accounting system field by field, checks the purchase order, and catches the odd duplicate when there is time. Month end turns that into a backlog.
Text-recognition tools read the characters but not the meaning. They do not know that a tax amount which does not add up, a new bank account on a long-standing supplier or a repeated invoice number needs a person. Fully automatic posting is how small errors, and sometimes fraud, slip into the ledger.
- Keying the same fields from similar invoices takes hours every week.
- Purchase-order matching happens after payment, if at all.
- Duplicates are found by suppliers chasing a second payment, or not at all.
- Bank-detail changes arrive by email and are trusted because the invoice looks right.
Task catalog
What the system takes on
Task 01
Collect from every inbox
The accounts mailbox, an upload folder and scanner output feed one queue, so nothing depends on who opened which email.
Task 02
Classify each file
Invoice, credit note, receipt, statement or something else. Each type follows its own field list and rules, and non-payable documents are set aside.
Task 03
Extract with a confidence per field
Header fields and line items are read with a confidence for each value and a pointer to where on the page it came from.
Task 04
Validate with rules in code
Sums, tax rate, duplicate numbers, purchase-order match and vendor-master match are deterministic checks, not a model’s opinion.
Task 05
Hold what needs a person
Low-confidence or failed fields go to a review queue with the source region of the page shown next to the value.
Task 06
Post with the original attached
Approved documents post to your accounting or ERP system through its API, idempotently, with the file attached for audit.
Step trace
One run, step by step
- ap-inboxshared mailbox, checked on a schedule
- invoice-supplier-a-20417.pdfdigital PDF · invoice
- scan-0193.jpgphone photo · invoice · 3 fields held
- credit-note-0077.pdfcredit note · its own rules
- statement-september.pdfstatement · not an invoice
- invoice-supplier-c-1102.pdfsame number as a posted invoice
- postedpassed every check
- reviewheld for a person
- scan-0193.jpgtax, PO number, bank details
- rejectedkept out of the ledger
Read the trace as text (Sample data)
- 07:00MailboxStepFive new files picked up from the accounts-payable inbox.
- 07:00ClassifierStepTwo invoices, one credit note, one statement, and one invoice whose number was already posted.
- 07:01ExtractorDoneHeader fields and line items read, each with its own confidence.
- 07:01ValidatorDoneSupplier A invoice: arithmetic, duplicate, PO and vendor checks all pass.
- 07:02PostingDonePosted to the accounting system with the original PDF attached; credit note matched to its invoice.
- 07:02ValidatorCheckscan-0193: tax does not add up, PO number not found, bank account differs from the vendor master.
- 07:02Review queueApprovalscan-0193 held with three flagged fields for a finance reviewer.
- 07:03RejectedErrorDuplicate invoice and statement kept out of the ledger, each with its reason.
Review queue
One held document, the way your reviewer sees it
| Field | Read as | Confidence | Check | Status |
|---|---|---|---|---|
| Supplier | Supplier B | 0.97 | Matched to the vendor master | Passed |
| Invoice number | B-20418 | 0.95 | Not seen before for this supplier | Passed |
| Invoice date | 03 Oct 2026 | 0.92 | Inside the accepted date range | Passed |
| Subtotal | 1,000.00 | 0.93 | Line items add up to the subtotal | Passed |
| Tax | 108.00 | 0.64 | Subtotal plus tax does not equal the total | Needs review |
| Total | 1,180.00 | 0.94 | Read clearly; used to cross-check the tax | Passed |
| PO number | PO-7781 | 0.58 | No open purchase order with this number | Needs review |
| Bank account | ending 4471 | 0.96 | Differs from the vendor master (ending 0932) Call the number already on file, not the one printed on the invoice. | Finance only |
Posting is blocked while any field is held.
Systems involved
What it connects to
- Document sources
- The accounts mailbox, a cloud upload folder and scanner output, collected into one queue with the original files kept unchanged.
- Vision and language models
- OpenAI, Anthropic Claude or Google Gemini to read scans and fields, or an open-weight model in your own cloud account for sensitive documents.
- Validation rules
- Code that checks sums, tax, duplicates and purchase-order matches against the vendor master and open orders read from your accounting system.
- Review queue
- A small web app for your finance team: flagged fields beside the highlighted region of the original, with confirm and correct actions.
- Your accounting or ERP system, via its API
- System of record. Approved documents post once, with the original attached; nothing is written before every check passes.
- Storage in your account
- Originals and the extraction log, in your cloud storage, so the audit trail stays with you.
Guardrails
- Validation is code, not a model judgement: arithmetic, tax, duplicates and purchase-order matches are deterministic checks with clear reasons.
- Every field has its own confidence threshold; anything below it goes to review with the region of the page shown next to the value.
- A changed bank account, a new supplier or a repeated invoice number always needs a person, whatever the confidence.
- Nothing posts until every check passes or a reviewer signs it off, and posting is idempotent, so a document can never post twice.
- Originals are stored unchanged alongside the extracted record, so any posted figure can be traced to the page it came from.
- Sensitive documents can be processed by a model deployed in your own cloud account, so the files never leave it.
Human checkpoint
Your finance team works a review queue instead of a mailbox. Each held document shows the flagged fields beside the highlighted part of the original, the rule that failed and a suggested value where one can be worked out. A reviewer confirms or corrects, then posts. Bank-detail changes are cleared only after a call to the number already on file. Corrections are logged and reviewed before they change any rule or prompt, so nothing drifts silently.
What we plan for
Typical targets
Typical target
60–80%
Standard supplier invoices posted with no field corrected
Basis: For typed, digital PDFs from repeat suppliers with a clean purchase-order match; scans, handwriting and new suppliers land lower. Measured on a sample of your own recent invoices in the pilot.
Typical target
None, by design
Documents posted with a failed check
Basis: Posting is blocked in code until arithmetic, duplicate, purchase-order and vendor checks pass or a reviewer signs off; tested with deliberately faulty documents before launch.
Typical target
We plan for 95%+ on typed invoices
Header-field accuracy on your labelled sample
Basis: A planning threshold, agreed with you before launch and measured field by field on documents you label with us in week two; line items and scans are measured separately.
Rollout
Week by week
Week 1
A sample of recent documents, the field list per document type, validation rules and approval limits, and access to your accounting system.
Week 2
Classification and extraction on the sample; a labelled test set built with your team; accuracy measured per field.
Week 3
Validation rules, vendor-master and purchase-order lookups, and the review queue.
Week 4
Posting into a sandbox or test company in your accounting system, plus deliberately faulty documents to prove the checks.
Weeks 5–6
Parallel run while your team keys as usual, then the switch once the review numbers hold.
FAQ
Frequently asked questions
Which documents can be extracted besides invoices?
Receipts, credit notes, delivery notes, purchase orders, application forms, claim forms and similar structured or semi-structured documents. Each type gets its own field list, rules and labelled test set, so we usually start with the one that costs your team the most keying time.
How well does it cope with scans and phone photos?
Vision models read most legible scans and photos, but skew, glare and handwriting lower the confidence. Low-confidence fields go to review rather than being guessed, and the review screen shows the region of the image so the reviewer can read it themselves.
What stops a duplicate or fraudulent invoice getting paid?
Rules, not luck. Every invoice number is checked against what is already posted for that supplier, totals are recalculated, and any bank account that differs from your vendor master is held for finance, who confirm it by calling the number already on file.
Can it read line items as well as totals?
Yes. Line items are extracted with quantities, unit prices and amounts, checked against the subtotal, and can be matched to purchase-order lines. Ledger or cost codes are suggested from past postings and confirmed by a reviewer until you trust them.
Do our documents leave our own cloud account?
They do not have to. For sensitive documents we can run an open-weight model inside your cloud account. Where a hosted model is acceptable, it runs on your account with the provider’s data-retention options set as you decide, and originals stay in your storage.
What does the review screen look like for our finance team?
A queue of held documents. Opening one shows each flagged field next to the highlighted part of the original, the rule that failed and a suggested value where one exists. Reviewers confirm, correct or reject, and the Post action stays disabled until nothing is left unresolved.
How do we know it is accurate enough before we switch over?
We measure it on your documents. In week two we label a sample together and score extraction field by field; then the parallel run compares the system’s output with what your team keyed. You decide the go-live threshold before seeing the results.
Next step
Have a workflow in mind? Let’s scope it together.
Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.
Free 30-minute call · no commitment