Auto-extracting invoices into spreadsheets, with a model that never leaves the building

Every small business has the same drawer.

It's full of invoices. PDFs from AWS, paper receipts from coffee meetings, contractor statements that arrive once a month, a utility bill someone scanned with their phone. At the end of the quarter, somebody — usually the founder, sometimes the founder's spouse — sits down with that drawer and types it all into a spreadsheet.

This is a stupid problem. We've had OCR for thirty years. We've had structured-data extraction for ten. The reason it hasn't been solved isn't technical — it's that nobody wanted to upload their entire financial paper trail to a third-party API to make it work.

ByrdDrive Sovereign solves this with a model that lives on the box you bought. Here is exactly how that pipeline works, in the order it happens.

The four moving parts

1. A file lands in a folder. It doesn't matter where it came from — email forward, drag-and-drop, network share, an iPhone scan over AirDrop. The folder is tagged as a "Finance" project kind inside ByrdDrive, which means every file that lands inside it gets the auto-extraction treatment automatically.

2. OCR happens immediately. A local vision-language model — we ship with Qwen2.5-VL by default; it has open weights and runs comfortably on every appliance we sell — reads the page and writes the full text into a hidden field on the file record. The OCR is the unsexy part of this pipeline. It's also the part that took the longest to get right.

3. A structured-extraction prompt runs against the OCR text. This is the interesting part: we never ask the model to "extract the invoice." We ask it to fill a schema — a typed list of fields like vendor, invoiceNumber, total, currency, dueDate, category — and the model returns a JSON object that conforms to it.

4. The object becomes a row. The row links back to the original PDF, which stays untouched in case anyone needs to verify. The row joins the project's spreadsheet — except the spreadsheet is queryable, sortable, and exportable, and it's never out of date because the rows came from the PDFs themselves.

What "fill a schema" actually looks like

The model gets a system prompt that looks roughly like this:

You're filling an invoice record. Here are the fields. Return JSON.

vendor (string, required) — the company that's billing. invoiceNumber (string). issueDate (date, YYYY-MM-DD). dueDate (date, YYYY-MM-DD). total (number, required) — final amount in source currency. currency (enum: USD, EUR, GBP, CAD, AUD, JPY, …). category (enum: software, contractor, office, marketing, …). status (enum: paid, unpaid, overdue, disputed).

If a field is unclear in the document, leave it blank. The human will fill it in.

That last line is the most important sentence in the entire pipeline. We do not ask the model to guess. We tell it: if you're not sure, leave it.

The model is well-behaved about this. Out of about two hundred test invoices, Qwen2.5-VL only hallucinated a number on three of them — and all three were corner cases (handwritten amount on a stamped receipt, no machine-readable text). For everything else, the model either filled the field correctly or left it blank for a person to verify.

Why local, and not cloud

The cloud version of this pipeline is faster. We've measured it. A frontier model running in someone else's data center walks through two hundred invoices in about four minutes. Our local Qwen takes closer to ten.

That speed comes with a cost most people don't price in.

Your accounting paper trail has now been sent to a third party.

For most small businesses that's a non-event. For a law firm holding privileged client billings, a healthcare practice with HIPAA-bound vendor invoices, or any defense contractor — that's an immediate disqualification. Their CFO can't sign off on a workflow that requires invoices to leave the premises, even encrypted, even with a signed DPA.

So a local model isn't a worse version of the cloud one. It's the version that lets these teams use this workflow at all.

What we changed our minds about

When we first built this, we used a 70B model. It was slow on smaller appliances, but we figured the quality justified the cost.

It didn't.

Once we got the schema and the "leave it blank if unsure" instruction tight, a 14B model performed within two percentage points of the 70B on invoice extraction. We switched everything to 14B and it freed up enough compute that the same appliance could also handle searching the team's library AND drafting client replies, without anyone noticing a slowdown.

The lesson — and we're saying this out loud because it's not the conventional take — is that a small model on a clear task beats a big model on a fuzzy task, every time. Most of what businesses actually want AI to do is clear tasks. Stop reaching for the biggest model. Reach for the right-sized one and a tighter prompt.

What it feels like, after a week

The pitch is "drop a PDF, get a row." That's exactly what it is. But it's worth describing what it feels like once you've lived with it for a week.

You stop dreading the drawer.

You scan something on your phone, AirDrop it into the Finance folder, and walk away. A few seconds later there's a row in the system. The row has the vendor, the amount, the date, the category. By the end of the quarter you have a complete, queryable history of your business's spending — and you have not transcribed a single character of it yourself.

The best AI is the AI that disappears. It does the thing, then leaves you alone.

That's what we mean.

Try it

If you're on the Sovereign track, this pipeline ships on by default in any project tagged as "Finance." If you're a cloud ByrdDrive customer on Standard or Business, the same pipeline runs against our managed model — same schema, same "leave it blank if unsure" discipline, same end result. The only difference is which box the model happens to live on.