Service
Document intake and extraction
Paper in, structured records out, with the doubtful ones flagged.
Document extraction is the most over-promised automation in the market, because the demo always works. Ten clean invoices from one supplier extract perfectly. The problems arrive with the scanned fax, the credit note that looks like an invoice, and the supplier who changed their template in March.
We build for that long tail. Every field carries a confidence score, totals are checked against line items, and anything below threshold goes to a review queue with the document open beside it. The measure of success is not the extraction rate — it is that nothing wrong reaches your ledger silently.
- Inputs
- PDF · Scans · Images · Email attachments
- Document types
- Invoices · Purchase orders · Delivery notes · Forms · Statements
- Extraction
- Header fields plus line items
- Validation
- Arithmetic, supplier, VAT, and duplicate checks
- Confidence
- Per-field score with a routing threshold
- Human review
- Queue with document and field side by side
- Destinations
- Accounting system · ERP · Database · Sheet
- Evaluation
- Golden set re-run on every prompt or model change
- Audit
- Source document retained and linked to every record
How it runs
Every stage, in order.
Each stage produces something the next one needs. Where a stage can fail, it fails visibly rather than passing bad data forward.
- 01
Intake
Documents arrive by mailbox, watched folder, or upload and are stored immutably before anything touches them.
- 02
Classify
Document type is identified first, because an invoice and a credit note need different rules.
- 03
Extract
Header fields and line items are pulled to a schema, each with a confidence score.
- 04
Validate
Line items must sum to the total, tax must reconcile, and the supplier must exist. Failures never pass silently.
- 05
Review
Anything below threshold is queued for a human with the document and the extracted field side by side.
- 06
Post
Approved records are written into the destination system, idempotently, with the source document linked.
Output
What arrives.
The shape is agreed before build and versioned after it. This is an illustration of the structure, not a fixed schema — yours is written against your requirements.
{
"document_id": "doc_01HQ8F3M",
"type": "invoice",
"type_confidence": 0.99,
"supplier": { "name": "…", "matched_id": "SUP-2041", "confidence": 0.96 },
"invoice_number": { "value": "INV-88412", "confidence": 0.98 },
"issue_date": { "value": "2026-02-28", "confidence": 0.97 },
"currency": "EUR",
"line_items": [
{ "description": "…", "qty": 12, "unit": 41.5, "net": 498.0, "confidence": 0.94 },
{ "description": "…", "qty": 3, "unit": 88.0, "net": 264.0, "confidence": 0.72 }
],
"totals": { "net": 762.0, "tax": 160.02, "gross": 922.02 },
"checks": { "line_sum_matches_total": true, "tax_reconciles": true,
"duplicate_of": null },
"routing": { "decision": "review", "reason": "line_item_confidence_below_0.85" }
}Scope
In detail.
Checks that run before anything posts
10- Line items sum to the stated net
- Tax reconciles at the stated rate
- Gross equals net plus tax
- Supplier resolves to a known record
- Invoice number not already processed
- Purchase order exists and is open
- Quantities within tolerance of the delivery note
- Currency matches the supplier's agreement
- Date within an acceptable window
- Bank details unchanged since last invoice
Deliverables
What you get.
Written into the scope document before work starts, and used as the acceptance test when it finishes.
- 01Intake from email, folder, or upload
- 02Extraction to your field schema with per-field confidence
- 03Validation rules including totals, tax, and duplicate detection
- 04Review queue for anything under threshold
- 05Write-through into your accounting system or database
- 06Evaluation suite built from your real documents
Questions
Asked before.
What accuracy can you commit to?
We commit to a measured accuracy on your documents, established with an evaluation set built from your real inputs before launch. Any number quoted before seeing your documents is marketing.
What happens to documents the system is unsure about?
They go to a review queue. The design goal is that a wrong value never posts silently — being unsure is an acceptable outcome, being confidently wrong is not.
Can it write into our accounting system?
Where the system has an API, yes, idempotently so a retry cannot double-post. Where it does not, we deliver a file in the format it imports.
Do you keep the original documents?
Yes, linked to every record, because an auditor will eventually ask.
Also in Automation
Support triage
Incoming tickets classified, prioritised, enriched with account context, and answered with a draft your team approves.
ServiceEstate audit
A structured review of the automations you already run — what exists, what breaks, what costs, and what happens when the person who built it leaves.
Next step
Scope it before you commit to it.
The first step is a short written scope: fields, volume, schedule, delivery, and acceptance criteria. It is quick, it is concrete, and it tells you whether this is worth doing at all.