Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Cash drawer reconciler series ~6 min read

A cash drawer reconciler on AWS for a few dollars a month

Cash variance is the most emotionally loaded number in a small business. It is usually four pounds, it is almost always somebody misreading a twenty at eleven at night, and it is nonetheless the number that quietly changes how a manager feels about a member of staff. The reason it does that is not the money. It is that nobody has time to work out where four pounds went, so the variance is recorded, unexplained, over and over, until it becomes a pattern in somebody’s head. This post walks through a small system that does the working-out.

Cafe counter with order here signs
Photo by Vaibhav Surana on Unsplash

Key takeaways

  • Two inputs at close: a photo of the count sheet and the till report for the same shift.
  • The variance is explained from the day’s own records before anybody is told about it.
  • Only unexplained variance above a threshold you set ever reaches a person.
  • Nothing is reported on a single shift. The unit of attention is a till over a fortnight.
  • Designed on AWS for about $3 a month for a handful of tills.

The whole system on one page

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

System: a count sheet and a till report, three pieces inside AWSThree boxes across the top sit outside the AWS account. On the left, Close-of-shift count: a photograph of the handwritten count sheet. In the middle, Till report: the point-of-sale export or emailed summary for the same shift. On the right, Manager: the person who sees patterns rather than individual shifts. Each connects by an arrow to the AWS account container below. The count supplies the cash actually there; the till report supplies what should have been there. Inside the AWS account are three components in a row. On the left, the Reader, which turns the count and the takings into one shift record. In the middle, the Explainer, which tries to account for the difference using the day's refunds, no-sales, float changes and safe drops. On the right, the Surfacer, which holds what is left and only reports when it persists. A note at the bottom says a four-pound variance on a Tuesday is noise and four pounds every Tuesday is a finding.AWS ACCOUNTClose-of-shift countphoto of the sheetTill reportPOS export or emailManagersees patterns, not shiftsReadercount and takingsinto one shift recordExplainerrefunds, no-sales,float, dropsSurfacerwhat is left,over timecounted cashexpected cashonly what persistsA four-pound variance on a Tuesday is noise. Four pounds every Tuesday is a finding.
Fig 1. Two inputs, three pieces, and one deliberate delay. Nothing about a single shift is reported; the surfacer only speaks when a pattern survives across a fortnight.
  • Machine learning
  • Analytics
  • Front-end & mobile
  • People

What you set up once (the outside)

  • A count sheet. Whatever you already use — a denomination grid on paper is the common case and works fine. It is photographed at close and that is the whole submission. Covered in Part 2.
  • A till report. Most points of sale can email or export an end-of-shift summary. That summary is the source for expected cash, card totals, refunds and no-sales. If yours only prints, a photo of the printout works exactly like the count sheet does.
  • A thresholds tab. One sheet: the variance below which nothing is ever said, the number of shifts a pattern has to survive before it is surfaced, and the float each till is supposed to start with. Setting the first two too tight is the main way this kind of system goes wrong.

What runs at every close (the inside)

  • The reader. Turns a photographed denomination grid into a total, and the till report into expected cash, refunds and no-sales. A digit it cannot read confidently is marked unreadable and asked about rather than guessed, because a misread five is a forty-five pound variance out of nothing.
  • The explainer. Takes the raw difference and works through the day’s own records looking for it: a refund given in cash but rung as card, a no-sale near the variance amount, a float that was topped up and not recorded, a safe drop logged after the count. Most variance is explained here and never becomes a variance at all.
  • The surfacer. Holds what is left. It does not report a shift. It watches the residual variance per till over a rolling window, and speaks only when the pattern clears a threshold — consistently short, consistently over, or a single amount large enough that waiting would be silly.

One close, end to end

One end-of-shift close, in five stagesA horizontal row of five boxes joined by arrows. Counted: a photo taken at close. Compared: the counted cash set against the expected cash. Explained: the difference is attributed to refunds, no-sales and float changes where possible. Residual: what is genuinely left over. Watched: the residual is tracked over a fortnight. A note says only the fifth stage ever produces a message, and usually it does not.ONE CLOSE, END TO ENDCountedphoto at closeComparedcounted vs expectedExplainedrefunds, no-sales, floatResidualwhat is genuinely leftWatchedover a fortnightOnly the fifth stage ever produces a message, and usually it does not.
Fig 2. The same system as one line. The unusual part is the last stage: the output of a close is not a report, it is a data point in a window.

In plain words

Your evening supervisor closes till two at eleven. She photographs the count sheet and the till printout. The reader makes the count £412.50 and the expected cash £429.00, a variance of £16.50 short. Before anybody sees that number, the explainer opens the day’s records: there is a refund at 18:42 for £16.50, rung as card, and the note on it says “gave cash”. That accounts for the whole variance. The shift is recorded as explained, the residual is zero, and nobody is told anything at all.

The following Thursday the same till is £6.20 short with nothing to explain it. That is a data point, not an event, and nobody hears about it. Three Thursdays later the surfacer notices that till two is short on Thursday evenings and not on any other shift, by between five and eight pounds, four times running. That is when it says something — and what it says is “till 2, Thursday evenings, consistently £5-8 short over four shifts”, which is a question about a shift pattern rather than an allegation about a person. Nine times out of ten the answer turns out to be the Thursday delivery driver being paid in cash out of the till.

Design rules that shaped every decision

  • Explain before you report. Most variance has a cause sitting in the day’s own records, and finding it is the entire job.
  • Never report a single shift. The unit of attention is a till over a window, because one shift is almost pure noise.
  • Talk about tills and shift patterns, not people. The system does not know who was on, and deliberately does not ask.
  • An unreadable digit is a question, not a number. A misread five becomes a forty-five pound phantom variance and destroys trust in the whole thing.
  • The thresholds are yours, in a sheet. Set them loose; a system that flags every four pounds gets switched off within a month.
  • Over is as interesting as short. A till that is consistently over is usually a pricing or keying problem and costs you customers rather than cash.

Why this shape

The two common approaches both do harm. One is to record variance in a book and never look at it, which means real problems run for months and everybody knows the book is theatre. The other is to review it nightly, which means somebody in authority looks at a four-pound difference every day with no time to investigate it, and forms an impression instead. The second is worse, because impressions formed from unexplained numbers are almost impossible to dislodge and are frequently about the wrong person.

The shape above puts the effort where it is cheap — the explaining, which is tedious lookup work a computer is good at — and puts a deliberate delay where the harm is. Nothing is said until a pattern survives a window. In exchange for learning about a genuine problem a fortnight later than you might have, you stop having a hundred and four unexplained conversations a year.

The next four posts walk through each piece: how a close gets recorded, how a variance gets explained, how a pattern gets surfaced, and how a finding gets closed. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts