Why batch entry fails
Everyone starts with the same plan: collect receipts as they happen, sit down once a month, deal with them all at once. It fails reliably, and it fails for structural reasons rather than character ones.
The short version is that capture is a per-transaction task and batching it converts something trivial into something aversive, while destroying the only information the paper never carried.
Two costs, and only one of them is obvious
The mechanical cost per receipt is roughly flat. Flattening a slip, photographing it, naming the file, putting it somewhere — that takes about the same effort whether you do it now or in five weeks. Batching genuinely does save a little here, because you set up once and repeat.
The recall cost per receipt is not flat. It rises, steeply. The field that decides whether a record is worth anything is what the spend was for, and that field is never printed — what makes a receipt useful later is largely about this. At the till you know. A week later you can reconstruct it. Five weeks later, faced with £31.40 at a hardware shop, you are guessing, and the guess is a fabrication with a plausible face on it.
So batching optimises the cost that was already small and inflates the cost that was the whole point.
Why the session keeps not happening
There is a second mechanism, and it is the one that produces shoeboxes.
The task grows while it waits. A batch of six receipts is fifteen minutes. A batch of ninety is an afternoon, and an afternoon is not a thing you slot into a Tuesday. So it gets deferred, and while it is deferred the pile grows, which makes the session longer, which makes it easier to defer. The feedback loop runs the wrong way and it has no natural stopping point.
The task also gets vaguer. Six receipts is a defined job. Ninety receipts includes ones you can’t identify, ones that have faded, ones that might be duplicates, and at least one that raises a question you don’t know how to answer. An undefined task with unknown depth is exactly the shape of thing people avoid, and no amount of intending harder changes the shape.
And it needs a slot that doesn’t exist. Per-receipt capture needs ten seconds and no particular place. Batch processing needs a desk, a stretch of time, and a mood. You have the first every day and the third occasionally.
The split that actually works
The useful move isn’t “capture more often”. It’s to notice that capture and processing are two different jobs with different requirements, and to stop doing them together.
Capture is per-transaction, and it must be batchless. Its only job is to get an image and a reason into a holding place before either degrades. Ten seconds, standing up, one-handed, no decisions. Where it goes doesn’t matter yet — see an inbox and an archive for why having a deliberately unsorted destination is what makes this fast.
Processing is fine to batch, because nothing in it decays. Renaming, sorting, reconciling against a statement, chasing the ones that don’t match: none of that depends on your memory of the transaction, because capture already preserved the memory. Do it monthly, do it quarterly, do it in one grim session before a deadline. It will still work.
Almost everything people hate about receipt admin lives in the second job. Almost everything that gets lost forever lives in the first.
Making the ten seconds actually happen
Decide the destination once. Every hesitation at capture time is a decision you shouldn’t be making, and “which folder” is the commonest. One destination, always, no exceptions.
Attach the reason in the same motion. Two or three words, in whatever field is nearest — the filename, a note, written on the paper with a pen. Not later. Later is where the reason goes to die.
Tie it to the transaction, not to the day. Habits anchored to an event fire; habits anchored to “this evening” compete with everything else that evening. The event here is putting your card away.
Have a paper fallback for when capture fails. It will. A labelled envelope you drop the slip into is a legitimate second-best, and it keeps the paper somewhere that won’t cook it — where paper survives covers what that place looks like.
Use a weekly sweep as a net, not as the system. Five minutes to catch what escaped. If the sweep is doing all the work, you’re back to batching, just at a shorter interval.
Keep or bin
KEEP OR BIN — habits, not paper
· Capturing at the moment of payment
→ KEEP. Only point at which the
reason is free.
· Batching the renaming and sorting
→ KEEP. Nothing in it decays.
· "I'll do them all on Sunday"
→ BIN. Grows faster than it gets
done, and the reason is gone.
· Reconstructing the reason from a
statement line weeks later
→ NOT A RECORD. It's an inference
you made up, wearing the clothes
of a fact. Mark it as such.
· A pile of already-lapsed receipts
→ KEEP, and triage rather than
process. See below.
· Whether an annotation you wrote
yourself counts for anything
→ ASK LOCALLY. Substantiation
rules vary by jurisdiction and
circumstance.
The backlog is a separate problem
None of the above helps with the pile that already exists, and it is worth being explicit that these are two different jobs. A functioning capture habit stops the pile growing. It does nothing to the part of it that has already lost its context, and trying to fix both at once is how people give up on the first.
Start the habit today, on today’s transactions. Treat the existing pile as an archaeology project with its own separate hour, and accept in advance that some of it will only ever be a statement line with a shrug attached.
What this doesn’t settle
Whether a record captured weeks late is acceptable, whether a note you added yourself carries any weight, and whether contemporaneous capture is required rather than merely sensible. Those are substantiation questions, they vary by jurisdiction, and your tax authority or adviser answers them.
What is true regardless of any rule: the reason for a spend exists only in your head at the moment of the spend, and it leaves on a schedule no filing system can negotiate with.