How to do a cash count that tells you where the money went
A cash count compares what the system expected in the drawer against what you counted, for each payment method. The difference only gets a name if every non-sale withdrawal was logged the moment it happened.
Saturday, 8:40 p.m. Cecilia closes up her tortillería in Cuautla, takes the money out of the drawer, and counts it. She counts it again and gets the same number: $340 short.
Nobody stole anything. At eleven she sent out for change with $200 from the register. At one she paid $140 to the plastic-bag supplier, who showed up unannounced. Both things happened, both were fine, and neither got written down.
At 8:40 the drawer can only say one thing: there’s less here than there should be. Cecilia has to reconstruct the rest from memory, twelve hours later and tired.
That’s the problem with a cash count, and it doesn’t get fixed by counting better.
What is a cash count?
A cash count is the comparison between the money the system expected to be there and what you actually counted, for each payment method. There are four numbers for each one, in this order: the opening float you started with, the expected amount, the counted amount, and the difference.
The expected amount isn’t an estimate. It’s the float the register opened with, plus whatever was charged through that payment method during the shift, minus refunds, minus cash that left the drawer, plus cash that came in. The difference is a subtraction — counted minus expected — and it’s the only one of the four numbers anyone’s going to argue about.
Why does your register never balance?
Because money leaves the drawer that isn’t a sale, and no system can guess that on its own. Change for a customer, the supplier who showed up unannounced, the $500 you pulled out for an emergency, the stack of bills you moved to the safe mid-afternoon: none of those leave a trace by themselves.
Sales get logged the moment they’re charged, because logging them is part of charging them. Money that leaves isn’t charged: it’s handed over. And what’s handed over only gets written down if someone writes it down.
That’s why a count done with nothing but a calculator always ends up in the same place: an unnamed difference. And an unnamed difference doesn’t get investigated, it gets assumed — some days someone gave the wrong change, other days something worse.
What does whoever’s on the register need to log?
One line for every time money goes in or out of the drawer without being a sale, right when it happens. In Proyecta’s point of sale, that line is an entry, a withdrawal, or a “to safe,” with a reason picked from a list of five: Delivery, Supplies, Change, Owner withdrawal, and Other. And “Other” requires a note.
Five reasons go further than they seem to. At closing, the count stops saying “$340 short” and says “$200 went out for Change and $140 for Supplies, and nothing’s missing.” The list is closed on purpose: with free text, in three weeks you’d have two hundred ways to write “expenses” and the report would stop adding up.
And yes, it’s one more thing to do at the counter. The difference is who and when: it’s logged by whoever has the money in hand, in the ten seconds they’re holding it — not you at nine at night, piecing together an afternoon that’s already gone.
Why is the count done blind?
Because a count where you already know the number you’re supposed to hit doesn’t measure anything. The point of sale ships with blind counting turned on: whoever closes counts each payment method and writes it down; the expected amount and the difference only appear afterward, once they can’t be fudged. The console puts it this way: “Your staff counts the money without seeing how much there should be. That’s what makes the difference meaningful.”
This isn’t about distrusting your people. The app’s owner can see the expected amount before the count; whoever’s working the register can’t. A test you answer while looking at the answer key isn’t a test.
How big can a normal difference be?
There’s no universal number, and anyone who gives you one is making it up: it depends on how much cash you handle and how many hands pass through the drawer. What you can do is set your own threshold, and the register already ships with one: above a $50 difference, the count asks for a written reason before it lets you close the shift. You control that amount.
What makes the threshold valuable isn’t the number, it’s the timing: it forces the explanation to get written the same day, while the shift is still fresh. A month of those reasons adds up to something no report can tell you on its own — that the differences fall on Saturdays, or always on the same shift, or right after you sent someone out for change.
What about card terminal sales?
Those don’t live in the drawer and get counted separately: each payment method carries its own expected and counted amounts, and the terminal gets reconciled against what it reports. A charge left hanging — the customer already left, the machine never responded — blocks the shift from closing until it’s resolved, because closing with a charge up in the air means signing off on a number that can still change. And if you connect the terminal you already have (Clip or Mercado Pago Point), the sale keeps the card brand and its last four digits: that line reconciles without transcribing the little receipt.
What won’t the count tell you?
Three things, and better to know them from the start. It doesn’t invent the reason nobody wrote down: if the withdrawal wasn’t logged, the difference shows up anyway and stays unnamed. The count names what was recorded, not what happened. The receipt isn’t an invoice: it’s the counter’s proof of purchase, and you still issue the CFDI separately. And if the internet goes down, the register keeps charging and the sales get saved, but the shift won’t close until they sync — a count that’s missing sales isn’t a count.
Describe it, and open it at the counter
You don’t have to ask for the register separately. Every store built with Proyecta already has a Point of Sale section in its dashboard: you create your Register 1, choose the payment methods you accept, and it opens at the counter as soon as you publish.
“A page for my tortillería in Cuautla with prices for tortillas, totopos, and masa, pickup orders, and a point of sale at the counter with cash and card, a closing count, and a log of cash withdrawals.”
Before you count, write down how much you think is there
Tonight when you close, before you touch the money, write on a piece of paper how much you think is in the drawer. Then count.
That piece of paper is worth more than the count. If you landed within $20, your day’s already under control and all that’s left is writing it down somewhere other than your head. If you were off by $600, you don’t have an arithmetic problem: you have hours of the day that never got logged anywhere, and now you know what to fix tomorrow.
Describe it at proyecta.dev and publish it.