Transactions automation

How it started

The client was a startup, and its back office was still being done by hand. Receipts were going missing, and the ones that survived were matched to the bank statement by eye, line by line. The objective was simple: stop losing them, and stop spending people on finding them.

The premise we walked in with: a receipt is only hard to process once it has gone cold. Photographed and emailed at the till, it is structured data with a picture attached.

What we found

The usual pattern at that stage – the paperwork worked exactly as well as everyone’s memory did.

• Reconciliation was a person and a spreadsheet, each debit paired to a receipt by eye.
• Nothing distinguished "no receipt yet" from "no receipt ever".
• The inputs were builders' phone photos – rotated, half-legible, mixed in with logos and signature images that were not receipts at all.
• The weekly invoice had a fixed shape the client already sent their own customers, so it had to be reproduced, not approximated.

The receipts were never the problem. The gap between buying something and anyone looking at the proof was.

What we did

Builders emailed a photo to one address with the client’s name in the subject. An always-on Mac did the rest, once a day.

• Intake – the inbox read over an API, not a browser. No login to keep alive, nothing to get blocked.
• Extraction – Claude kept only genuine invoices and returned line items ex-VAT. The logos and the dog photos were discarded on sight.
• Arithmetic – deterministic, not the model’s opinion. Printed totals were ground truth; anything that didn’t add up was flagged, not averaged.
• Filing – per client, per week, plus a monthly archive. Nothing filed twice.
• Invoicing – every Friday the closed week compiled into the client’s own template, cell for cell.
• Reconciliation – bank statement imported, debits matched on amount to the cent and confirmed by vendor or date. Manual decisions were never overwritten.

How it went

Capture at the source. Deterministic where money is involved. No match beats a wrong match. Nothing hosted.

It ran beside the existing operation and disrupted none of it – the bank spreadsheet stayed the record and the robot never wrote back, so nobody had to stop working to adopt it. Matching on amount alone turned out to be wrong: round sums collide, and one 70,00 payment cheerfully attached itself to a receipt five months away. Precision beat coverage from then on.

What we delivered

A receipt pipeline on hardware the client already owned, with nothing new to pay for monthly.

• The robot – reads, files and invoices on a schedule, and catches up by itself if the machine was off.
• Filed receipts – original, spreadsheet and data for every invoice, plus one archive by month.
• The weekly invoice – in the format they already send, agreeing with the dashboard to the cent.
• Invoice management – bank import, strict matching, manual override, export of any batch with its receipts. It holds because it refuses to guess.
• One click to install or update – keeps everything already on the machine, and won’t claim success unless the running version matches.

The result

A receipt is a bearer instrument – worth something only while you still have it, which is why glove compartments quietly cost money. Capture moved to the moment of purchase, where the receipt still exists. The payments with nothing behind them are now a list instead of a discovery, and nobody has to remember the automation exists – which is the only reliable test of whether one keeps running.