Skip to content
allanninal.dev/build
Collaborate

Part 4 of 7 · Cash drawer reconciler series ~5 min read

How a cash pattern gets surfaced

Everything so far has been about getting an honest residual number. This post is about the discipline of not doing anything with it. A single shift’s residual variance carries almost no information: the distribution of honest miscounts at eleven at night is wide, and any threshold tight enough to catch a real problem in one shift will fire constantly on nothing.

Key takeaways

  • Nothing is reported on a single shift, with exactly one exception.
  • The window is per till and per shift slot, because Thursday evening is a different animal from Monday morning.
  • Three patterns are worth a message: consistently short, consistently over, and rising spread.
  • Consistently over matters as much as short; it is usually a pricing or keying problem.
  • The exception is a residual so large that waiting would be absurd, and that threshold is yours.

The window

The unit of attention is a till and a shift slot — till 2, Thursday evening — over a rolling number of occurrences rather than a number of days. That distinction matters for anywhere that does not trade the same hours every day. Four Thursday evenings is four data points whether they took a fortnight or a month.

How a residual variance becomes a pattern worth reportingA vertical chain of six steps entered by a box labelled Residual variance for one shift. Step one asks whether it is big enough on its own to skip the window, reading the line from the thresholds tab; if it is over, it exits to Tell somebody now, one shift and one message. Step two adds the residual to the window for that till and shift slot, held in a DynamoDB windows table covering the last N occurrences. Step three asks whether the till is consistently short, N of the last M, exiting to Surface the pattern, described by till and slot rather than by person. Step four asks the same question the other way for consistently over, which is usually a pricing problem. Step five asks whether the spread is widening, exiting to Surface quietly in the monthly summary. Step six is Nothing to say, the usual outcome. A note says four of the five exits are rare and the last step is what happens on almost every shift.AWS ACCOUNTResidual varianceone shiftBig enough alone?the skip-the-window lineThresholds tabyours, in a sheetTell somebody nowone shift, one messageoverAdd to the windowtill + shift slotDynamoDB windowslast N occurrencesConsistently short?N of the last MSurface the patterntill and slot, not a personyesConsistently over?same test, other waySurface the patternusually pricingyesSpread widening?variance of the varianceSurface quietlyin the monthly summaryyesNothing to saythe usual outcomeFour of the five exits are rare. The last step is what happens on almost every shift.
Fig 1. What happens to a residual. One escape hatch for genuinely large amounts, then a window, then three pattern tests, and then the outcome that occurs almost every time: nothing.
  • Database
  • App integration
  • Machine learning
  • Management
  • Analytics

Consistently short

N of the last M occurrences short by more than the noise threshold, in the same direction. Four of the last five is a reasonable default. The message names the till and the slot, gives the amounts, and says nothing else — because at this point the system genuinely does not know whether the cause is theft, a recurring cash payment nobody wrote down, a float that was permanently changed, or a scale that weighs light.

Consistently over

The same test in the other direction, and the one that most systems ignore entirely. A till that is regularly over is not a happy accident: it usually means customers are being overcharged, or a keying habit is producing sales at the wrong price, or somebody is short-changing people. It costs you customers rather than cash, which is worse, and it is invisible to anybody who only looks for shortages.

Widening spread

The subtlest of the three: the average residual is fine but the swing is growing. That usually means the counting itself has got sloppy — a new person, a rushed close, a broken note counter. It never generates a message on its own, because it is weak evidence, but it appears in the monthly summary where a manager can put it next to everything else they know.

What the message actually says

The whole message, in order

  • Line one. The till and the slot. “Till 2, Thursday evenings.”
  • Line two. The pattern, with the numbers. “Short by £5–8 on four of the last five, after refunds and no-sales were accounted for.”
  • Line three. What was already ruled out. “No matching refunds, no-sales or float changes on any of the four.”
  • One button. “I know why — here’s what it is”, which records a cause against that till and slot and stops the pattern being reported again.
  • No names. The system does not hold who was on shift, so it cannot name anybody even if asked. That is a design choice, not an oversight.

The absence of names is worth defending. It would be easy to join the shift record against a rota and produce a per-person variance report, and every business that has ever built one has regretted it. The number is dominated by which till somebody works, how busy their shifts are and how often they handle refunds, none of which is about them. A per-till pattern points a manager at a real question. A per-person league table points them at the person who works the busiest till.

Next: what happens to a surfaced pattern — how it gets closed, and what the monthly summary is actually for.

All posts