Invoice Extractor

Every supplier invoices differently. Somebody pays for that.

A business with fifteen suppliers receives fifteen different invoice layouts. Dates in three formats. VAT shown as a line, a percentage, or not at all. Reference numbers in the header, the footer, or the filename. Some are text; some are scans.

The resolution is almost always the same: a person opens each one and types the numbers into a spreadsheet. Half a day a month at the small end, several days a week at the large end — and it is genuinely miserable work, which is exactly why it gets deferred until the accountant asks.

Traditional software struggles here, and the reason is instructive. A parser can be written for one supplier's layout, and it works until that supplier redesigns their template. Fifteen suppliers means fifteen brittle parsers and a maintenance job nobody wants. This is one of the few problems where a language model is straightforwardly the right tool.

Point it at a folder. Get a spreadsheet.

No interface, no accounts, no platform. A script that reads every PDF in a directory and writes one CSV — deliberately the smallest possible thing that solves the whole problem.

• Layout-independent extraction. The model is asked for meaning, not position — supplier, invoice number, date, net, VAT, total, line items — so it handles a template it has never seen without new code.
• One schema out. Every invoice, regardless of origin, lands in identical columns. That's the entire value: the output is consistent even though the input never is.
• Validation after extraction. Totals are checked arithmetically, dates normalised to one format, and anything that doesn't reconcile is flagged rather than quietly accepted.
• Traceability. Each row records the file it came from, so a questionable figure can be checked against the original in seconds.
• Spreadsheet output on purpose. CSV opens in whatever the business already uses. No migration, no training, no new subscription.

The model reads. The code checks.

This is the studio's standard division of labour applied at small scale: the model does the one thing it's genuinely better at than any parser — understanding an unfamiliar document — and ordinary Python does everything that must be exact.

• Structured output. The model returns a defined schema rather than prose, so the result can be validated programmatically instead of interpreted.
• Arithmetic is never trusted to the model. Net plus VAT is verified in code. If it doesn't reconcile, the row is flagged for a human — a fifteen-second check instead of a fifteen-minute retype.
• Batch processing. A folder at a time rather than a file at a time, because that matches how invoices actually accumulate.
• Right-sized model. Extraction doesn't need frontier-scale reasoning. A smaller model does it accurately for a fraction of the cost, which is what makes the economics obvious.

• Python
• PDF parsing
• Claude API
• Structured output
• CSV export
• Validation rules

The clearest business case in the portfolio.

Half a day a month, recovered permanently, for a build that costs less than the annual value of the time it replaces.

• Hours back, every month, forever. The saving doesn't decay — it compounds as supplier volume grows.
• Fewer typing errors. Validated extraction beats manual entry at the end of a long day, and the flags catch what neither would.
• Bookkeeping stops being deferred. When the job takes minutes, it gets done monthly rather than in a panic before a deadline.
• Real spend visibility. Structured supplier data makes it possible to see what's actually being spent, with whom, and whether prices have crept.
• It generalises. The same approach handles delivery notes, timesheets, purchase orders, application forms — any document that arrives in many shapes and needs to leave in one.

If you're wondering where to start with automation, this is usually the honest answer: find the document your team retypes, and stop retyping it.