Automating receipt collection: the image, the data and the record

Most conversations about receipt automation stop at the photograph. Somebody spends money, somebody takes a picture, the picture lands in a system, everybody feels organised. The interesting questions all sit after that point, and they are the ones that decide whether the resulting record is worth anything when it is examined.

A receipt exists to support two claims: that an expense was incurred wholly and exclusively for the business, and where relevant that VAT was charged and is recoverable. Those claims have to hold up a year or five years later, to somebody who was not there. That requirement, rather than the convenience of capture, is what should shape the process.

What we'll cover

• The image and the data are different things
• What actually has to be kept
• Capture at the moment of spend
• Building it with CodeWords
• Extraction and the confidence problem
• The decisions a machine should not make
• Why the VAT position needs more than a total
• Where receipts go missing
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

The image and the data are different things

A photograph of a till receipt is evidence. The row in the ledger saying £42.60, Sundries, 14 March is a record. They serve different purposes and they fail in different ways, and a process that conflates them produces a ledger nobody can defend.

The row is what the accounts are built from; the image is what proves it. Discard the image once the data is extracted and the row becomes an assertion. Keep the image without linking it and finding the evidence for one line means searching a folder of nine hundred photographs.

So the pairing is the thing to build, and it has to survive software changes, staff changes and the client moving to a different bookkeeper, which is more than a chat thread can promise.

What actually has to be kept

Digital copies are acceptable. HMRC does not require the paper, provided what you hold is legible and complete.

The durations are longer than most clients expect. Self-employed records must be kept for at least five years after the 31 January submission deadline for the relevant tax year, and company records for six years from the end of the financial year they relate to (self-employed, company).

There is also now a positive requirement for many clients to keep records digitally in the first place. Making Tax Digital for Income Tax obliges sole traders and landlords over the qualifying income threshold to maintain digital records and report quarterly through compatible software, phasing in from April 2026 above £50,000, April 2027 above £30,000 and April 2028 above £20,000 (HMRC guidance). For those clients a carrier bag in December stopped being a viable method.

Practically, that means the storage question comes before the capture question. Where do the images live, who can retrieve them in four years, and what happens to them if the client leaves.

Capture at the moment of spend

The timing is the whole trick. A receipt captured at the till is complete and legible. The same receipt captured at month end has been through a wash cycle, and the one captured at year end mostly does not exist.

Three things make capture happen at the till rather than later.

It takes one action. Photograph, send, done. Any step requiring a login or a category choice moves the task to later, and later is where receipts die.

It uses something already in their hand. Messaging channels work here because the client already has the app open and has nothing to learn.

It gets acknowledged. Without a confirmation, careful clients send the same receipt twice and careless ones assume it went through when it did not.

A weekly prompt helps clients who spend regularly and irritates clients who do not. Set the cadence from how often each one actually transacts, and let them turn it off.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: who is prompted and how often, what happens when an image arrives, which fields you want read, and what confidence level sends something for review.
3. Authorize the connections to your ledger system, your document storage, and the channel clients send from.
4. Describe the exceptions: an unreadable image, a total above a threshold you want to see, a supplier you have never seen before, something that is not a receipt at all.
5. Run it for one client for a month before extending it, and reconcile the extracted rows against the images by hand once to see where it disagrees with you.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Extraction and the confidence problem

Reading a merchant, date and total off a photograph is well-solved for a clean receipt and unreliable for a creased thermal one photographed in a car. The failure that matters is not the obvious one.

An extraction that fails visibly is harmless, because somebody fixes it. An extraction that returns a plausible wrong number is the expensive one: a £4.60 read as £46.00, a date read from the card authorisation rather than the transaction, a total that captured the subtotal because the VAT line wrapped.

So the design question is what the system does when it is unsure, and the answer has to be something other than guessing confidently.

Surface the confidence. A row the system is unsure about arrives marked for review rather than dropping silently into the ledger.

Set a value threshold. Anything above a figure you choose gets looked at regardless of confidence, because the cost of a wrong large number is not symmetric with a wrong small one.

Check the arithmetic. Where a receipt shows net, VAT and gross, they should add up.

Watch new suppliers. A merchant that has never appeared before is worth a glance; one appearing weekly is comparatively safe.

The decisions a machine should not make

Extraction reads what is printed. Several of the decisions that follow are not printed anywhere.

Business or personal. A supermarket receipt cannot tell you whether the spend was stock, staff refreshments or the client's weekly shop.

Entertaining or subsistence. A restaurant bill is a different animal depending on who was at the table, and the treatment differs sharply. That fact lives in the client's memory and nowhere on the paper.

Capital or revenue. A £900 laptop and £900 of consumables photograph identically.

Which entity. Clients with more than one company routinely pay for one out of the other.

So capture the missing fact while the client still remembers it. One question at the moment of sending costs nothing and removes a query from your month end.

Why the VAT position needs more than a total

For VAT-registered clients the receipt has to support the input tax claim, which means it needs more than a figure.

A simplified VAT invoice, available where the supply does not exceed £250, has to show the supplier's name, address and VAT registration number, the time of supply, a description of what was supplied, and for each rate the gross amount payable and the rate applied (VAT Notice 700). Above that threshold, a full VAT invoice is required, with more detail again.

Two consequences for the capture process. A photograph that cuts off the foot of the receipt has usually cut off the VAT registration number, which is the part that makes the claim supportable. And card machine slips are not VAT invoices: they prove a payment and not the supply, which is why the till receipt matters and the card slip stapled to it does not.

Worth telling clients once, plainly, that the whole receipt has to be in the frame. It saves a great deal of re-asking.

Where receipts go missing

Between apps. Screenshot from an email, saved to a camera roll, never sent.

In the wrong thread. Sent to a staff member's personal number, then lost when that phone is replaced.

Under a subscription. Recurring card payments generate email invoices nobody photographs, and they are frequently the largest deductible spend a small client has.

At the point of extraction. Captured, unreadable, flagged, then never chased because the flag sat in a queue nobody owns. That last one needs a named owner, since a review queue without a person attached becomes a graveyard.

Making it survive

Keep the image and the row linked, permanently, in a place that outlives your current software.

Give the review queue an owner and a maximum age.

Ask the unknowable questions at capture, not at month end.

Do not let the chat thread be the archive. Messaging platforms are a transport, and retention obligations run for years.

Reconcile against the bank periodically. Transactions with no receipt are the gap that matters, and only the bank feed can show you it.

Limits worth knowing about

Extraction accuracy depends on the photograph, and no model reads a receipt that has been through a wash.

A missing receipt cannot be recovered by software. Some can be reconstructed from card statements and supplier portals, which is a manual job.

Clients who will not photograph anything exist, and the honest answer there is a different service at a different fee.

Confidence scores route work rather than guarantee accuracy, and the arithmetic checks matter more.

Faster capture does not improve coding judgement. It gets more receipts to you sooner, labelled correctly only if you asked the right question at the right moment.

What to build first

One client, one month, capture and review only. No ledger integration, no categorisation rules, no prompts to the rest of your book. Photograph in, stored, extracted, reviewed by you against the image.

Two habits make the difference. Keep the image tied to the row it produced, because the day that link matters is the day somebody is asking questions and you cannot rebuild it. And put a person's name on the review queue, since the receipts that hurt you are not the ones that never arrived, they are the ones that arrived, failed quietly, and sat in a list nobody opened.

Frequently asked questions

Does HMRC accept photographs of receipts?

Yes. Digital copies are acceptable provided they are legible and complete, and for many clients digital record-keeping is now a positive requirement under Making Tax Digital for Income Tax rather than an option.

How long do receipts need to be kept?

At least five years after the 31 January submission deadline for the self-employed, and six years from the end of the financial year for companies. Storage has to be chosen with that in mind.

What goes wrong with automatic extraction?

The dangerous failures are plausible wrong values rather than obvious ones: a decimal misread, a date taken from the card authorisation, a subtotal captured as the total. Arithmetic checks and a value threshold catch more of these than confidence scores alone.

Is a card machine slip enough for VAT?

No. It evidences a payment rather than the supply. The claim needs a VAT invoice, and for supplies up to £250 a simplified one showing the supplier's VAT number, the time of supply, a description and the gross at each rate.

Why does the whole receipt need to be in the photograph?

Because the part most often cropped is the foot, which carries the VAT registration number. Without it the input tax claim is harder to support.

What should happen to an unreadable image?

It should be flagged and chased while the client still has the paper, which means within days. A flag that sits in an unowned queue for three weeks is the same as no capture at all.

How do I find receipts that were never sent?

Reconcile against the bank. Transactions with no matching receipt are the only reliable way to see the gap, and subscriptions billed by email are usually the biggest part of it.

Related reading

• Making a document request land
• Which channel is the client file
• Working out where your own hours go