When month-end billing hides in a thousand hand-filled forms

A lot of real work still starts on paper. Someone in the field fills in a work-order sheet by hand — what was done, where, how much, on which item — signs it, and it gets scanned. Multiply that by hundreds of locations across several branches and month-end billing turns into an archaeology project: someone retypes a thousand noisy scans into a spreadsheet line by line, then reconciles each row against the order list to find the right code, the right item and the right price. It's slow, it's error-prone, and the mistakes don't surface until they're already invoices. We built a controlled system that does this end to end — and it runs in production for a large organization with field teams, processing thousands of hand-filled work-order sheets a month.

The problem: paper in, invoice out — with a reconciliation step nobody enjoys

This isn't a "scan to text" problem. The document is a hand-filled form, so the scan is noisy — and the number on the form is rarely the number you bill on. That cost concentrates in three concrete problems.

1. Thousands of noisy sheets, retyped by hand

Who has it: an organization whose field teams hand-fill work-order sheets across dozens of branches, so a single month's billing means keying thousands of scanned sheets — with no text layer — into an exact spreadsheet structure before anything can be invoiced.

Handwriting makes the scan ambiguous in the worst possible places: a 9 reads as 1 (a quantity of 9.00 vs 1.00), 2026 reads as 2018, an operation code 112 reads as 122. Every one of those becomes a wrong invoice line if a tired person keys it at 11 p.m. on deadline.

How we solve it: the sheets are read by an ensemble of independent vision models, not one — and the system never keys blind. Where the models disagree on an item, a quantity or an operation, that field is marked uncertain rather than guessed.

2. The code on the sheet isn't the code you bill on

Who has it: any operation where the field form uses one vocabulary and the billing system uses another — the item is written 649 2 on the sheet but stored as 0649_2 in the order list; a job is marked operation 122 on the form but billed under 111 in the order.

Match the two literally and you get near-zero matches — and a person spends the day hand-correcting. This is the single most common silent reason a batch "won't reconcile."

How we solve it: every line is reconciled against the order list — the authoritative source of codes (internal codes, framework order, item, operation, quantity) — using a canonical key that normalizes the mismatch (pads the item code to a fixed width, unifies separators, maps 122 → 111). In one real batch, fixing just the item key lifted matches from 8 of 28 to 22 of 28.

3. The errors hide until they're invoices

Who has it: an operation billing against capped orders, where booking more quantity than the order allows, or against the wrong item, isn't caught until reconciliation at year-end — when it's expensive to unwind.

How we solve it: the system cross-checks each line against the system of record and the order caps, and flags over-booked orders, quantity mismatches and missing sign-off before they reach the invoice — as exceptions queued for a human, not errors buried in a spreadsheet.

The idea: a controlled reconciliation system

All three problems share one cause: the data lives on paper and gets reconciled by hand under deadline. The fix is to wrap a controlled system around it — and, as always, the system prepares the work; a person makes the call.

How it works

1. Extract — every scan is rendered at high resolution and read by several independent vision models. The system finds the boundaries of each sheet itself (a sheet can run to several pages, with sketches and blanks in between) and pulls the header and each work line.
2. Reach consensus — repeating fields (branch, unit, the responsible person, the stamp) are settled by majority vote across the batch: a value seen the same way on several sheets beats a one-off misread.
3. Reconcile against the order list — every line is matched to the authoritative order list on a canonical key, which supplies the correct billing codes and prices and corrects the field-form vocabulary.
4. Cross-check the system of record — where an official record export exists, the system pulls the authoritative quantity, verifies the quantity on the sheet against the system, and checks the order caps.
5. Flag, don't guess — anything uncertain or unmatched is highlighted and written to a control report, with the reason. Nothing ambiguous is silently pushed into the billing file.
6. Build the workbook — the output is the exact structure the operator bills on: an overview sheet (what we know / the result / what's missing), the work list (WL), the order reference, and the cover sheet with totals. Each row carries the source file and page, so any number can be traced back to the original scan.
7. Measure & repeat — next month, you just drop in the new scans; already-processed sheets are skipped and only the new ones are read.

It's also a control on the input documents

Alongside billing, the system acts as an automatic control on the input documents: it checks every sheet as it arrives, before anything reaches billing. It watches for:

• completeness — missing fields (quantity, item, sheet number),
• the responsible person's signature and stamp — is the sheet even valid, and is that person authorized for this branch,
• consistency with the system of record — do the quantity and item on the sheet match what's in the system,
• order caps — is more booked than the order allows,
• duplicates — the same document scanned twice (or two originals) isn't billed twice: the system keeps the more legible one and lists the other as a duplicate,
• a valid sheet number — it has to match the batch (year, month, branch).

So the output isn't only a billing file — it's also a picture of input quality: which sheets are clean, which are missing a signature, which exceed the order, and which need to go back for completion. The paperwork gets checked at intake, not at year-end.

Two independent safety nets — this is why it's trustworthy

Hand-filled forms are noisy, so a single read is never trusted. Reliability rests on two independent nets:

• Consensus across documents catches OCR misreads on the fields that repeat.
• Reconciliation against the order list catches the fields that vary (item, operation, quantity) — the order list has the final word.

And a rule that matters more than any model: never fake certainty. A field the system isn't sure about is turned yellow and listed for review — not quietly invented. On a batch of thousands, that turns month-end from retype everything and hope into review only the handful of flagged rows.

The system learns from the human's decisions

The system doesn't close when it hands over the file — it closes through the person. Every time someone resolves a flagged (yellow) row — confirms that 9.00 should be 1.00, matches an item that wasn't found, or corrects a misread code — the system remembers that decision and applies it itself next time:

• repeated fixes become rules — the same code swap (122 → 111) or item-format quirk isn't asked twice,
• confirmed matches enrich the order list — what a person mapped once, the system maps on its own,
• the share of flagged rows falls month over month — the system absorbs the human's judgment, so there's less to review each time.

So it isn't a one-off retype but a system that gets better with every close — precisely because it leaves the decision to a person and learns from it.

What the output looks like

The work list is the operator's exact billing structure — here simplified to the columns that matter:

Sheet no.	Branch	Item	Operation	Quantity	€	Source	Check
…0605-118	Branch A	0649_2	111	4.00	4.00	scan.pdf · p.7	matched
…0605-131	Branch A	0651_1	011A	2.10	2.10	scan.pdf · p.9	matched
…0605-142	Branch A	0663	122→111	9.00 → 1.00?	—	scan.pdf · p.12	⚠ quantity vs system

The yellow row is the point: it isn't dropped and it isn't guessed — it's surfaced for a person to resolve in seconds, with the source scan one click away.

What we measure

A reconciliation system should be measured from day one:

What we measure	Why it matters
Matched vs unmatched lines	Shows how much reached billing untouched vs needs a human
Fields flagged uncertain	Shows scan/handwriting quality, and where to look first
OCR corrections applied	Shows the codes the order list fixed automatically
Over-booked orders caught	Stops billing beyond the order before it's invoiced
Sheets processed per run	The volume a person no longer keys by hand

If the first version doesn't collapse the retyping and catch the errors earlier, you know quickly — that's the point of validating on one month first.

Who it's for

This is not really about any one industry. It makes sense for any operation that runs on hand-filled forms that have to be reconciled against a master list and billed — construction site dockets, field-service tickets, delivery notes, agricultural and subsidy claims, public-sector paperwork. Especially if:

• the forms arrive as noisy scans with no text layer,
• the codes on the form differ from the codes you bill on,
• someone reconciles hundreds or thousands of them by hand at month-end,
• billing is capped by an order or contract, and over-booking is expensive,
• you want AI to do the reading — but a person to keep the final say.

The system doesn't invoice anything on its own. It reads the scans, reconciles every line against the authoritative source, flags what it isn't sure about, and hands a person a billing file plus a short list of exceptions — instead of a thousand forms to retype.

The same read-then-reconcile problem shows up on supplier invoices — our neutral guide to invoice data extraction: how it works and what it costs walks through the invoice version, from capture to validation.

Want to see it on your own paperwork? Get a free diagnostic — we take one real batch of your forms, run it through the system and show you exactly what we'd build, the match rate, and what it saves. No obligation.