How a petty cash receipt gets captured
A till receipt photographed on a phone in a shop doorway is the worst input in this entire series. Thermal paper fades, curls and reflects; the total is often not the largest number on the page; and half of them have been in a pocket. This post is about getting a reliable number out of that, and about the fields where the honest answer is a question.
Key takeaways
- One screen: take a photo. No amount field, no category, no float picker.
- The float is inferred from who took the photo, and confirmed only when ambiguous.
- The total is the one field that is never guessed. Everything else can be filled in later.
- A blurred or partial photo is rejected immediately, while the receipt is still in hand.
- The photo is the accounting record and is kept for as long as your obligation runs.
One screen
The capture screen has a camera button and nothing else. No amount field, because typing an amount is the thing the photo exists to avoid. No category, because categorising is a bookkeeping decision that a bookkeeper makes faster and better at month end. No float picker, because the answer is nearly always inferable.
- App integration
- Machine learning
- Management
- Analytics
- Front-end & mobile
- People
The on-device check
A blur and edge check in the browser before upload is a few lines of canvas work and it removes most of the failure cases downstream. More importantly it removes them at the only moment they are cheap to fix. A rejected photo two seconds after it is taken is a retake; the same rejection three minutes later, after the receipt has gone in the tin and the person has walked away, is a question that will not get answered.
Inferring the float
Most people have access to exactly one tin, so the float is simply looked up from who took the photo. The custodian list maps people to floats, and the common case needs no input at all. Somebody with access to two — a manager who covers the office and the workshop — gets two buttons, which is one tap and only appears for the handful of people it applies to.
What the reader will and will not guess
| Field | If unclear | Why |
|---|---|---|
| Total | Ask, with the crop | A wrong total is a wrong balance nobody will trace |
| Vendor | Leave null | The bookkeeper can read the photo at month end |
| Date | Use the photo date | A receipt is photographed the same day in practice |
| Tax | Leave null | Tax treatment is a bookkeeping judgement, not an extraction |
| Category | Never attempted | Categorising is done once, at month end, by one person |
The asymmetry there is deliberate. The total is the only field that affects the balance, so it is the only one worth interrupting somebody for. Everything else can be null, because the photograph itself carries the information and a bookkeeper reading forty receipts at month end will fill them in far faster than forty people interrupted individually.
Why the total is hard
On a supermarket receipt the total is not the largest number, is frequently below a subtotal and a discount line, and sits above a cash-tendered figure and a change figure that look exactly like it. “£20.00” and “£11.80” and “£8.20” all appear in the same block and only one is the spend.
The model is given the Textract layout and asked specifically for the amount paid, with the instruction that a cash-tendered line and a change line are not it. Where the block is ambiguous it returns null and the question shows the crop of that block, which a human resolves instantly because they were there.
What is kept, and for how long
- The original photograph, unmodified, because it is the accounting record and a re-encoded copy is a worse one.
- The Textract output, so a re-read later never needs a second paid extraction.
- The extracted fields and who confirmed any of them.
- All of it for as long as your record-keeping obligation runs, then deleted by a lifecycle rule rather than by anybody remembering.
Next: how the balance stays right when two people spend at once.
All posts