05 · Selected Work
Invoice Reconciliation
Every morning at eight it reads the purchase-order sheet and the invoices that arrived overnight, extracts each one into structured fields, and cross-checks it against the order it claims to be for. Clean invoices get a due date in the calendar. Only the ones that don’t reconcile reach a person.
Role
Engineer
Year
2026
Type
Internal automation
Stack
n8n · Claude · Gmail · Google Sheets · Calendar
The workflow
Nine nodes. The model does one job — turning an email into typed fields — and ordinary code makes every decision after that.
The problem
Invoice checking is the kind of task that is easy to do and easy to stop doing. Someone opens the inbox, finds the purchase order, compares the amount, notes the due date. It takes a few minutes and it gets skipped on a busy week — and the invoices that most need checking are exactly the ones that look ordinary.
This does the comparison every morning whether anyone is looking, and only interrupts a person when the numbers disagree.
Decisions worth noting
The model fills a schema; it doesn’t decide anything. Claude extracts five typed fields — invoice number and vendor required, PO number, amount and due date optional — and the amount comes back as a number, not a string to be parsed later. Every judgement after that is ordinary deterministic code, so the outcome is reproducible and reviewable.
Matching is deliberately forgiving of real spreadsheets. Column headings are normalised before comparison, so PO Number, po_number and PONumber all resolve to the same field. Amounts are parsed with currency symbols and separators stripped. Vendor names compare without regard to case or stray whitespace. The data is messy because people typed it.
Amounts compare with a tolerance. A difference smaller than a hundredth of a cent is not a discrepancy. Without that, floating point noise would flag correct invoices every morning, and a check that cries wolf gets switched off.
“No PO referenced” and “no matching PO” are different findings. One is an invoice that never cited an order; the other cited one that doesn’t exist. They need different follow-up, so the flag says which rather than reporting a generic failure.
Every invoice reaches the calendar; only mismatches reach a person. A correct invoice still has to be paid on time, so the due date is recorded either way. The email is reserved for the cases that actually need a human, and it carries both figures side by side so the decision can be made without opening anything else.
Interested in something similar?