Every month, the same ritual. Download the card statement. Hunt down the receipts, half of which are buried in email. Rename everything so the file name says what it is. Send the pile to my accountant and hope nothing bounces back.

It stopped being viable when the number of sources grew: card statements, bank exports, my own outgoing invoices, PDFs attached to email. Four places to look, every month, for something that has to be exactly right.

So I built Claude a skill for it.

Bookkeeping is a reconciliation problem

That framing is the whole trick. Every euro that left an account needs a receipt. Every receipt needs somewhere to live. Everything in between belongs in a ledger you can check.

Written that way, it stops being clerical work and becomes matching, which is something a model is genuinely good at. I say "close out June" and it runs four stages:

Read in. Every payment source lands in one transaction ledger. Refunds, card fees and private spending get separated immediately so they do not clog the exceptions list.

Resolve. For each transaction, find the receipt: inbox folder, month folder, previous month, email. This is matching by reasoning rather than string comparison. AMZN Mktp DE is Amazon. A $100 charge that shows up as €94.80 is currency conversion plus a card fee.

Assemble. Each card statement becomes a bundle: statement first, then every receipt in statement order. That is the format accountants actually want.

Report. Anything unresolved goes in a file with a reason and rolls into next month automatically.

The sentence that makes it usable

The most important line in the whole skill:

If you are not certain a receipt matches a transaction, leave the item open
and tell me why. Never attach a receipt you cannot defend.

A documented gap is fine. A silent one is not. Without that instruction the model does what models do when they want to be helpful: it finds something plausible and moves on. That is the failure mode that makes automated bookkeeping worse than doing it by hand, because now the error is buried somewhere in a folder you have already signed off.

Does it actually work

I built a month designed to break it. Foreign currency charges. A refund that must be skipped rather than matched. A private card on the same account. An invoice with an identical amount to another one, sitting there as bait. Two receipts that genuinely do not exist.

The skill passed 100% of the checks. The same model, same month, without the skill: 90%. It flagged the refund as a missing receipt.

That 10% is the entire argument for writing the skill down. A model with general competence gets most of it right and then quietly invents an answer at the edge. The edges are where bookkeeping lives.

What it cost

The trap month took an afternoon to build, which is longer than the skill took to write. That ratio sounds wrong and is not. The skill is a description of how I already work. The test is the part that tells you whether the description is true.

Running a real month costs a few cents and about ninety seconds. I still read the exceptions file, because that is the part that needs me.