Process the bill — OCR, email-in, manual

From two days a week to two hours a week

A part-time bookkeeper at a thirty-person agency used to spend every Tuesday and Thursday morning typing bills into a spreadsheet. Supplier name, invoice number, date, due date, net, VAT, gross, GL code, department, project — for every bill that came in. Some weeks were sixty bills; some weeks were thirty; either way, the rhythm was the same: print the PDF, prop it on a stand, type, double-check, save. Then onto the next.

After moving to a system with OCR and email-in, the same workload now takes about two hours a week. The bills land in a draft queue with the fields already populated. She opens each one, glances at the original PDF on the right-hand side of the screen, fixes the one or two fields OCR fluffed (always the GL code; sometimes the VAT split), picks the supplier from the dropdown, hits Send. Thirty seconds a bill instead of three minutes.

The interesting bit isn't the time saved. It's what she does with it. The hours she got back went into supplier reconciliation, which she'd never had time for before — and that surfaced two duplicate-billed contracts and an over-charged hosting renewal in the first quarter. The OCR didn't catch those; she did, with the time it freed up.

That's the right way to think about bill processing. The system handles the typing. You handle the judgement.

The three entry paths

Every bill that lands in Blankitt Finance Business arrived via one of three routes.

Upload. Drag a PDF or photograph into the Bills → Upload screen. OCR runs in around ten seconds. The draft appears in the bills queue with parsed fields pre-filled. Used by AP staff for bills they've collected from a shared mailbox, downloaded from a supplier portal, or received on paper and scanned.

Email-in. Each tenant gets a unique alias on bills.blankitt.com — something like acme-co@bills.blankitt.com. Anything that lands there with a PDF attached becomes a draft bill automatically. Suppliers can email the alias directly; you can forward from your AP inbox; you can give it to procurement to use as a billing address. OCR runs the same way; the draft lands with an email_in source tag.

Manual entry. For the rare bills OCR can't help with — paper-only suppliers, hand-written invoices, foreign-language documents, supplier statements you need to log as a memo. Open Bills → New and type the fields by hand. You can still attach the source PDF; OCR just doesn't run on it.

Most teams settle on a hybrid: email-in for everything that lands by email (which is most of it), upload for the occasional ad-hoc, manual for the long tail. The system doesn't care which path a bill arrived through; once it's in the queue, the downstream flow is identical.

What OCR gets and what it misses

OCR is good at structured fields with consistent vocabulary. It's worse at things that vary by supplier and need judgement.

Reliably extracted:

• Supplier name (from the letterhead, the From address, or the bank-details block)
• Invoice number (the field labelled "Invoice", "Inv No", "Document", "Reference", or similar)
• Issue date
• Due date (or payment terms it can interpret — "Net 30" + issue date)
• Gross total (almost always the largest currency value on the document)
• VAT total (the field labelled VAT, Tax, GST)
• Currency

Often imperfect:

• Line items, especially on multi-page bills. The matcher can usually identify the line table, but column boundaries on PDFs with non-standard layouts get mangled. Single-line bills (one row, one total) extract fine; complex line tables sometimes don't.
• Payment terms expressed in non-standard phrasing ("within thirty days of receipt of goods", "EOM + 14 days").
• VAT splits when a bill has mixed VAT rates (5% on energy, 20% on something else).

Always your job:

• The GL code. OCR will never pick the right account code. It doesn't know your chart of accounts and can't infer "Office expenses" vs "Software" from the supplier name alone. Every draft bill arrives with the GL code blank.
• The department / project / cost-centre coding. Same reason — these are your dimensions, not anything OCR can read.
• The PO link. Sometimes OCR catches a PO number on the bill and auto-links. Often it doesn't. Verify.
• Reasonableness checks. Is this the right supplier? Is the amount what you expected? Has it been billed already? OCR can't ask those questions.

Always review before clicking Send. The system pre-fills; it doesn't approve.

The OCR allowance

Each Blankitt Finance Business plan includes a monthly OCR page allowance — Starter gets 50 pages, Growth gets 200, Scale gets 1,000. Anything above the included allowance bills as PAYG metered usage at a per-page rate (currently 8p/page).

The meter ticks one page per OCR'd document page, not per bill — a 4-page invoice consumes 4 pages even if it's one bill. Documents pushed in via email-in count the same as ones uploaded manually.

The included allowance resets on the 1st of the month. PAYG usage accrues daily and pushes to Stripe each night, where it appears as a metered-billing line item on the next invoice. You can see the running tally in Billing → Usage, broken down by day.

If you don't want to risk an OCR bill, you can disable PAYG in Settings → Bills → OCR. With PAYG off, drafts beyond the allowance get parked in a "no OCR" queue and you process them manually — the PDF is still attached, the supplier and total fields are blank, and you type. Not ideal for high-volume teams, but useful for keeping costs deterministic.

Email-in (bills.blankitt.com)

The email-in alias is one of the most-used features in the product. Three things to know about it.

Setup is one click. Open Settings → Bills → Email Routing, click Enable, copy your alias. The alias follows the pattern {tenant-slug}@bills.blankitt.com — for example acme-co@bills.blankitt.com if your tenant slug is acme-co.

Routing is by alias, not by sender. Anything sent to your alias lands in your queue, regardless of who sent it. You can give the alias to suppliers as your billing address, forward from your AP mailbox, set up auto-forwarding rules in Outlook or Gmail, or push from procurement tools — all routes land in the same place.

Attachments become bills. The OCR runs on the PDF attachment, not the email body. If a supplier puts the invoice in the email body and the PDF is just a logo, OCR will return nothing useful. If a supplier sends multiple PDFs in one email, each PDF becomes its own bill (which is sometimes what you want, sometimes not — see Tips).

There's a quiet failure mode worth knowing: forwarded emails from some clients (notably Outlook desktop) strip the original sender. The matcher uses the PDF text to identify the supplier, not the From address, so this rarely matters — but if a forwarded bill lands with no parsed supplier, that's usually why.

Bill status flow

Bills move through five statuses.

  draft  →  sent  →  paid
              ↓
           partial  →  paid
              ↓
           overdue

draft — newly uploaded or email-captured, not yet approved. Lives in the drafts queue. Editable. No journal posted.

sent — approved and ready to pay. Lives in the payables queue. Journal posted (DR Expense, CR Accounts Payable). Eligible for payment runs. Not editable.

partial — some payment recorded, balance outstanding. The bill stays in the payables queue with a reduced "outstanding" amount. Eligible for further partial payments.

paid — fully paid. Lives in the archive (still searchable). Final journal entries posted. No further action possible.

overdue — past due-date, still unpaid. A derived status, not a stored one — the system computes it on the fly when due-date < today and status is sent or partial. Drives the aged-creditor report.

A bill can never go backwards. If you need to undo a sent bill, you raise a credit note against it (effectively a negative bill) rather than reverting the status.

Linking to the PO

When a bill mentions a PO number — usually in a "Your reference" or "PO" field — OCR catches it and auto-links. The bill detail page then shows the linked PO at the top, the matcher runs immediately, and any discrepancies surface as match_warning flags.

When OCR doesn't catch the PO (or the supplier didn't include one), you link manually: open the bill, click Link to PO, search for the PO by number or supplier. The matcher runs as soon as the link is saved.

A bill can link to at most one PO. If a single invoice covers two POs (rare but it happens — usually a consolidated bill from a supplier you do a lot of work with), you have to split the bill into two before processing. Easier to push back to the supplier and ask for separate invoices.

Bills without a PO link aren't blocked from payment — they just bypass the three-way match. The match_status reads no_po and the bill processes through the un-matched flow.

Account coding and why it matters

Each bill line gets posted to a GL account. The account drives where the cost shows up on the P&L, which VAT box the input tax falls in, and which department or project the spend hits.

A few things to keep straight:

• The GL code is per line, not per bill. A supplier invoice for "consulting (£800) + travel (£200)" should code to two different accounts — Consulting Fees and Travel Expenses — even though it's one bill.
• VAT cash basis vs accrual changes when the VAT is recognised, not the account. Under accrual, VAT lands in Box 4 when the bill is sent. Under cash basis, it lands in Box 4 when the bill is paid (proportionally for partial payments — see chapter 6).
• Department / project / cost-centre are your dimensions, layered on top of the GL account. Bills also carry these for RBAC scope: an approver whose policy is scoped to "Marketing" can only see bills coded to Marketing.

The system suggests an account code based on recent bills from the same supplier — but suggestions aren't defaults, they're nudges. Always verify on first review.

What if OCR got it wrong

OCR's failure mode is usually subtle: a digit transposed, the wrong VAT split picked, the due-date set to today because the field was blank. Edit the fields before sending. The original PDF is preserved; your overrides become the canonical bill.

If a bill is so badly OCR'd it's faster to start over, click Discard and re-enter manually. The PDF stays attached; the OCR'd fields blank out and you type. This is rarer than it sounds — usually editing two or three fields is enough.

For bills that come in regularly from the same supplier with the same OCR errors (legacy supplier with a weird PDF format), set up supplier-level OCR overrides in the supplier contact record. You define which fields OCR should ignore for that supplier, and they always come in blank for you to type. Useful for the long-tail supplier whose PDF OCR consistently mis-parses.

Tips

• Forward bills as PDF attachments, not as forwarded-with-quoted-text. OCR works on the attachment, not the email body. If a supplier emails an invoice in the body of the email with a logo as the attachment, OCR returns nothing.
• One bill per email. Two bills attached to one email creates two draft rows (good), but two bills combined into one PDF creates one draft row covering both — and the line-item matcher will mangle it. Push back to the supplier and ask for separate PDFs.
• When the supplier's invoice number isn't on the PDF, make one up with their initials and the date — for example ACME-20260526. Invoice numbers must be unique per supplier in the system, and "blank" isn't a valid value.
• Code on first review, not later. Every bill you defer to "code it tomorrow" is a bill that won't get paid on time. Build the discipline of coding at draft-review.
• Set up email-routing rules for high-volume suppliers in your AP mailbox: auto-forward anything from accounts@bigsupplier.com direct to your bills.blankitt.com alias. Removes the human step entirely.
• The OCR allowance is per-month, not per-bill. A team that uploads one 80-page contract draft will burn through the Starter allowance in one click. Watch the usage dashboard if you're processing long documents.

Next chapter: paying the bills you've just processed — BACS for bulk, Faster Payments for urgent, and how the bank statement closes the loop.