Handwritten invoices
Seven scrawled amounts in. Three coded lines out.
A field vendor writes the invoice on a carbonless pad in the truck, photographs it crooked, and emails it from a phone. That is a real payable for real work. It is also the document most AP automation hands straight back to you.
Invoice 104240, posted with no human touch and reconciled to $1,060.00.
0.10 min
Reported processing time
3
GL-coded line items
7
Amounts grouped
$1,060.00
Reconciled to the cent
The source document
Every field on this page is in the wrong box.
One handwritten page, scanned, with the vendor and the property redacted. This is invoice 104240 as it arrived, and to the right is what came back off it.
What came back
- Invoice
- 104240
- Date
- 04/10/2026
- Subtotal
- 1,060.00
- Tax / ship / misc
- 0.00
- Total
- 1,060.00
Matched to masters
- Supplier
- Supp code
- Property
- Prop code
- Unit
- 27-202
The stamp shows a trade name. The rest came from the masters, including a street address that is not on the page.
Processing
- Status
- Processed, uploaded
- Rules
- Matched
- PO / credit
- none / no
The form has no unit prices. Every line came back as a quantity of one at the extended amount, because nothing on the page supports a rate.
Where naive OCR breaks
Six reasons a printed-invoice pipeline hands this page back.
These are the flags on the scan above. Each one reads correctly to a person and wrong to a parser that trusts the printed labels.
The date is in no field
The printed Date box is empty. The date sits above the rules as 4-10.26, and the approval stamp below writes it again as 4/10/26.
The vendor is in the Ship To box
The form carries no letterhead, so the vendor stamped itself into Ship To. A parser reading the labels literally swaps payee and payer.
The ZIP fell into the F.O.B. field
The rubber stamp overran its box. 48152 landed a row down, in the space reserved for freight terms.
The quantity columns hold a unit number
27- in Ordered and 202 in Shipped is apartment 27-202. It came back as an account segment on all three lines, which is where it belongs.
No two counts on the page agree
The description runs across three rows, the amounts occupy seven, and the account codes number three. Nothing on the page maps the scope onto the money.
A second document prints over the first
The approval stamp lands across the line items, rotated and faded. Its account codes sit above their own labels, under yellow highlighter.
The grouping nobody wrote down
5106 - 360.00 / 5114 - 450.00 / 5109 - 250.00
The page never says which amounts fed which account.
The vendor wrote seven amounts down the column. The approver stamped three account codes across the middle of it. Neither of them wrote down how the two sets line up.
BillRoute returned three line items. Each one sums a group of the handwritten amounts and lands on the account the approver stamped, which is the mapping neither of them recorded. The property and the unit ride along as segments.
It settles the first amount too. The glyphs allow $360.00 or $3,600.00. Only $360.00 lets the split close against the written total.
The incumbent
Ask any vendor what it does with this exact page.
AvidXchange is the incumbent in multifamily AP. It was taken private by TPG and Corpay in a $2.2B deal that closed in October 2025, and it sits embedded inside AppFolio. Nobody should tell you the incumbent is about to fall over.
We have not run invoice 104240 through their product, so read the heading as a claim about printed-invoice pipelines rather than a benchmark. Four questions settle it on your own documents in an afternoon.
Does a pad invoice come back as line items, or as one lump total with a page image attached?
Does anything group seven written amounts onto three stamped account codes, or does a person do that part?
Is there a separate queue for scanned documents, which is where a tool puts the pages it could not read?
What counts as billable, given a handwritten invoice is one page and takes the most work of anything you send?
We charge $1 per invoice uploaded, so the fourth question is not a neutral one coming from us. A vendor billing per page earns the same on this document whether it reads it or returns it.
Limits
Handwriting is the least reliable path in the pipeline.
It should be. A printed invoice from a vendor with a billing department extracts at very high confidence. A photographed carbonless pad does not, and a tool claiming otherwise is either hiding its confidence threshold or guessing on amounts.
Our 98% automation rate is a portfolio figure across every document type at a 24,000 unit portfolio. The handwritten subset sits below it. In a representative month, 197 invoices out of 2,665 reached a person, and these are disproportionately the ones.
What we hold ourselves to is narrower. A page we cannot read fails loudly, with the specific reason attached, inside the same queue and the same audit trail as everything else. Nobody should find a guessed number at close.
The five failure types and how the error queue works are on invoice capture. The recognition problem itself is covered in why OCR fails on handwritten vendor invoices.
FAQ
Handwritten capture questions
Do you read the handwriting, or route it to a person?
What happens when a figure is genuinely ambiguous?
Do vendors have to change how they send invoices?
How accurate is this compared to a printed invoice?
What about a pad invoice with no invoice number?
Does the coding come from a rule or from history?
Send us the ones you key by hand.
Not the clean PDFs. The pad invoices, the phone photos, and the ones with an approval stamp printed over the line items. We will show you what comes back coded.