Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Petty cash tracker series ~6 min read

A petty cash tracker on AWS for a few dollars a month

Petty cash is the smallest accounting problem in a business and generates a wildly disproportionate amount of irritation. The tin is short by fourteen pounds. There are two receipts in it with no date. Somebody definitely bought milk. The reconciliation happens at month end, when none of that is recoverable, and the difference gets written off with a small note that quietly implies something about somebody. This post walks through a small system that makes the tin balance itself, on the condition that using it is faster than not.

grayscale photography of metal tools
Photo by Carlos Irineu da Costa on Unsplash

Key takeaways

  • One action per spend: photograph the receipt. That is the entire user interface.
  • The balance is live, so a mismatch is found on the day rather than at month end.
  • Each float is separate, with its own custodian, balance and count cadence.
  • A receipt the reader cannot read is a question, not a guessed number.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: receipts and top-ups in, a live balance, a reconciliation outThree boxes across the top sit outside the AWS account. On the left, Receipt photo: taken at the tin as the receipt goes in. In the middle, Top-ups: cash put into the float. On the right, Custodian: the person who counts the tin and is told when it does not match. Each connects by an arrow to the AWS account container below. Spends and additions flow down into the account. A message goes back out only when a count differs from the expected balance. Inside the AWS account are three components in a row. On the left, the Reader, which pulls the amount, vendor and date from the photograph. In the middle, the Ledger, which keeps one running balance per float. On the right, the Reconciler, which compares a count against the expected balance on the day it is made. A note at the bottom says one action per spend, and that if it takes longer than not doing it nobody will do it.AWS ACCOUNTReceipt phototaken at the tinTop-upscash put inCustodiancounts, and is toldReaderamount, vendor, dateLedgerone running balanceper floatReconcilercount vs expected,on the dayspendsadditionsonly when itdiffersOne action per spend. If it takes longer than not doing it, nobody will do it.
Fig 1. Three things outside the account, three pieces inside it. The design constraint that shapes everything is at the bottom: the system has to be faster than the alternative, which is putting a receipt in a tin and forgetting.
  • Database
  • Machine learning
  • Analytics
  • Front-end & mobile
  • People

The one constraint

Every petty cash system that has ever failed has failed for the same reason: it asked for more effort than the alternative. The alternative is putting a receipt in a tin, which takes one second and requires no thought. Anything that asks somebody standing in a shop doorway to categorise a spend, pick a cost code or type an amount will be skipped, and a petty cash system that is skipped half the time is worse than no system because the balance is now confidently wrong.

So the interface is: photograph the receipt. Put the receipt in the tin as usual. That is all. Everything else — the amount, the vendor, the date, the category, which float it came from — is the system’s problem.

What runs on every receipt (the inside)

  • The reader. Pulls the total, the vendor and the date off a photograph of a till receipt, which is a genuinely hard document — thermal paper, faded, creased, photographed at an angle in bad light. Where it cannot read the total confidently it asks, which is a two-second reply while the person is still holding the receipt.
  • The ledger. One running balance per float, moved by a conditional write so two people spending at the same time cannot both compute from the same starting figure. Every movement records who, what, when and which receipt.
  • The reconciler. Compares a physical count against the expected balance. Runs when somebody counts, which the system prompts for on a cadence. A match is silent. A mismatch lists every movement since the last count, which is almost always where the answer is.

One spend, end to end

One petty cash spend from purchase to recorded balance, in five stagesA horizontal row of five boxes joined by arrows. Bought: milk, three pounds forty. Photographed: one tap. Read: the amount, vendor and date are extracted. Deducted: the balance moves to forty-six pounds sixty. Silent: nobody is told. A note says the whole interaction is the second box and everything else happens without anybody.ONE PETTY CASH SPEND, END TO ENDBoughtmilk, £3.40Photographedone tapReadamount, vendor, dateDeductedbalance now £46.60Silentnobody is toldThe whole interaction is the second box. Everything else happens without anybody.
Fig 2. The same system as one line. Only one of the five stages involves a person, and it takes a second.
  • Machine learning
  • Analytics
  • Front-end & mobile

In plain words

Your office manager buys milk and biscuits on the way in, £8.20. She photographs the receipt at the tin and drops it in. The reader gets £8.20 from a supermarket on today’s date. The ledger moves the office float from £54.80 to £46.60. Nobody hears anything. Three more spends happen that week the same way.

On Friday the system prompts her to count, which it does weekly for that float. She counts £42.60. Expected is £46.60. Four pounds short, and instead of that being a month-end mystery it is a message the same afternoon listing the four movements since the last count. She looks at the tin, finds a parking receipt for £4.00 sitting under the tray that never got photographed, takes the photo, and the float balances. Total time spent: ninety seconds, on the day, by the person who was there.

Design rules that shaped every decision

  • One action per spend, and it has to be faster than not doing it. Everything else is the system’s problem.
  • Never guess an amount. A receipt the reader cannot read confidently becomes a question, because a guessed total is a balance that is wrong in a way nobody will find.
  • Count often and cheaply. A weekly count that takes a minute beats a monthly one that takes an hour and cannot be resolved.
  • A mismatch lists the movements, not a person. The answer is almost always a missing receipt, and the list is where it is found.
  • Each float is separate. A site tin and an office tin have different custodians, cadences and normal behaviour.
  • The system never moves money and never authorises a spend. It records and it reconciles.

Why this shape

Petty cash reconciliation fails at month end for a structural reason: by then the information that would resolve a difference has evaporated. Nobody remembers what they bought on the 9th, the receipt that fell behind the drawer is gone, and the person who could have said “oh, that was the taxi” has had three hundred other thoughts since.

Moving the reconciliation to weekly, and making it cost a minute, changes the economics completely. A four-pound difference found on Friday is nearly always resolvable, because the receipt is still physically nearby and the memory is still there. The same four pounds found on the 31st is a write-off with a note attached.

The next four posts walk through each piece: how a receipt gets captured, how the balance stays right under concurrency, how a count works, and how the month gets closed for the bookkeeper. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts