The Number the Cashier Can See
The stock module hides the expected quantity from the counter by default. The till displays Expected Cash to the cashier as a tile on the sale screen. Same product, opposite answers to the same control question — and only one of them is defensible.
A count that knows its own answer is not a count. It is a confirmation, and the difference is the entire reason anybody counts anything.
What the stock module does
A stock count here is blind by default. The flag lives on the count plan and on the session created from it, and the default is true in both places — a decision somebody made deliberately, twice.
The service that runs counting says so in its own comments: under a blind count the person counting cannot see the expected figure. They write down what is on the shelf. The system does the comparison afterwards.
What the till does
The sale screen carries a band of four tiles for the open drawer: opening float, cash sales, drops, and expected cash.
That last tile is the number the cashier is about to be asked to match. It is on screen throughout the shift, and it is on screen at the moment the drawer is closed. The close itself accepts a counted amount and a note, and computes the variance from the two.
There is no blind option to switch on. The session record has no such field — fourteen columns, and none of them is a mode. So this is not a control that is off by default; it is a control that has no switch.
The same question, asked of both modules
| Control | Stock count | Cash drawer |
|---|---|---|
| The expected figure is hidden from the counter | Yes | No |
| Blind mode exists as a setting | Yes | No |
| Blind is the default | Yes | No |
| A variance is computed and stored | Yes | Yes |
| A variance needs a reason | Partly — configurable by you | Partly — configurable by you |
| A variance becomes an approved correction | Yes | No |
| The session cannot close with unresolved lines | Yes | No |
Built and maintained Configurable by you, not maintained by us Not built
Two "part" rows: a stock variance flows into an adjustment that carries a reason; a cash variance gets the free-text note on the close, which is not the same thing.
A variance of zero on a drawer whose expected figure was on screen all afternoon tells you almost nothing. That is the honest reading of a perfect till.
Why it matters more for cash than for stock
Stock is bulky, slow to move and hard to convert. Cash is none of those things. If there is one place in an operation where a count should not know its own answer, it is the drawer.
And the psychology runs the wrong way too. A person who is short and can see they are short has a decision to make before they type a number. A person who cannot see is simply reporting what they counted. Blind counting does not catch dishonesty so much as remove the moment where it becomes tempting.
One switch, and one thing that has to come with it
This is a small build and the second half is the part that gets forgotten. Shipping the first without the second produces a control that people route around within a week.
A blind close, per counter
A flag on the counter or the tenant that suppresses the expected-cash tile and the running totals for the cashier while leaving them visible to a supervisor. The stock module already models exactly this, so the shape is not in question — it is the same decision applied to a screen it was never applied to.
A variance reason, from a list, above a threshold
A blind count produces variances. Without somewhere structured for the explanation to go, those variances become a free-text note nobody reads, and the control decays into paperwork. The reason list is what makes the blind count analysable rather than merely stricter.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If cash handling is the reason you are looking at a till system, raise this first — it is the control most often assumed to be present.
Talk to us about cash controlsFour questions about a cash drawer
Can the cashier see the expected cash before counting?
A good answer sounds like
No, not unless a supervisor enables it.
What it actually means
The whole question. Ours shows it as a tile, and there is no mode that does not.
Where does the explanation for a variance go?
A good answer sounds like
A reason list, plus a note.
What it actually means
A free-text note is evidence, not data. Ours is a note.
Can a drawer be closed with an unexplained variance?
A good answer sounds like
Above a threshold, no.
What it actually means
A close that always succeeds is a record of an event, not a control over it.
Does the same vendor hide the expected figure in stock counts?
A good answer sounds like
They answer both consistently.
What it actually means
Ask both. An inconsistency inside one product usually means nobody has looked at the two together — which is how ours happened.
Our position
Treat the cash count here as a reconciliation rather than as a control, because that is what it is. Have a supervisor present at close, count before opening the screen if you can, and read the variance trend rather than the individual figure. If blind cash counting is a requirement — and for a cash-dominant retail operation it reasonably is — it is a build, and it is one of the smaller ones on this blog.
What AWRA OpsHub does today
- Cash sessions per counter, with an opening float, an opening and closing actor, and timestamps for both.
- Cash drops recorded during a shift, so a drawer that is emptied mid-shift still reconciles.
- An expected cash figure computed from the float, the cash sales and the drops.
- A counted figure entered at close, a stored variance, and a free-text note.
- Session reporting and export, so variance can be tracked per counter and per cashier over time.
- A genuinely blind count in the stock module, on by default, which is where the comparison in this post comes from.
What it does not do
- Any blind mode on a cash session. There is no such column and no such setting.
- Any suppression of the expected-cash tile on the sale screen.
- A reason list for a cash variance. The close takes a note.
- Any threshold above which a variance needs approval or blocks the close.
- A denomination breakdown at count time.
- Any alert on a variance pattern by cashier.
Not ours, by choice
- The stock module having this and the till not having it is an inconsistency in our own product. We would rather point at it than explain it away, and it is recorded as a priority gap.
- Nothing here suggests cashiers are dishonest. Blind counting exists because a visible target changes what an honest tired person types at the end of a long shift.
- Nothing here is Gabonese. Libreville is here because in a cash-dominant retail market the drawer is the primary control surface, not a secondary one.
Ask what the counter can see
In any till demonstration, ask to close a drawer and watch the screen. If the expected figure is visible while somebody types the counted one, you are looking at a reconciliation and not a count.
Talk about cash handlingFrequently asked questions
Can I just tell cashiers not to look?
That is genuinely the current control and it is weaker than it sounds, because the figure is a tile on the screen they are already using rather than something they would have to go and find.
Is the variance recorded even so?
Yes, computed and stored on the session, with the counted and expected figures alongside it. The record is sound; what is missing is the condition under which the counted figure was produced.
Does a supervisor have to approve the close?
No. The close validates a counted amount and an optional note, and succeeds. Any supervisory step is a practice you run beside the software rather than one it enforces.
