Count first, compare secondCount first, compare second

A cashier opens a shop's cash drawer in the morning, takes orders all day, pays a supplier for milk out of the till, accepts cash from a regular who is settling last week's credit, and hands the counter over in the evening. At the end of the day the owner has one question: is the right amount of money in the drawer? If not, how much is missing, since when, and why?

Tigg POS could not answer any of it. It already had sessions. Earlier engineers built them in 2023: a person started a session at a location, sold things, and stopped it. But a session recorded a time and a person. It did not record money. There was no opening count and no record of cash taken out or put in. There was no closing count, and nothing to compare one against. When the drawer came up short, the difference had no owner, no timestamp and no explanation. In my own words from the time, shops had no record.

The job was to turn a stopwatch with a name on it into an accountable cash drawer: every session carries an opening count, cash in and out with reasons, a closing count checked against what should be there, and an explanation whenever the two don't match. And shops that don't want any of this shouldn't be slowed down by it.

As I remember it, the request came from sales and went to the CEO. The CEO planned the feature and asked me to ideate and design it. I am the only UI/UX designer at Tigg, and I usually work with the CEO and a senior frontend engineer, who both sometimes review my Figma files.

The work followed Tigg's usual path from ticket and design through a "Ready for dev" handoff, development, QA and UAT to a production release. My first working version ran on 2 June 2026. The feature reached the production branch in the second half of June, and I kept refining it into mid-July.

I want to be precise here, because this part is thin.

• The brief. The CEO's plan, and conversations with him while I ideated. There was no written requirements document.
• Other products. I looked at the cash-session features of many other POS apps. I didn't write down which ones, so I won't name them as things I studied. Zoho is the product I usually look to for patterns.
• An internal demonstration with real equipment. We walked through the flow in the office with actual cash drawers and the counter hardware. It was a hardware walkthrough, not user research: nobody outside the team took part.
• Indirect signal. I hear about user problems from QA, support and the CEO. During the build, QA's follow-up list was the most concrete feedback I had.

There were no shop visits, interviews, usability tests or analytics. The design rests on the CEO's knowledge of the shops, the patterns other POS products share, and careful reasoning about money: what a number means, what "nothing" means, and who may change what.

Before drawing screens I wrote down how money moves through one drawer in one shift. Expected cash isn't a number the system should simply assert; it's a sum a manager should be able to re-add from top to bottom:

Expected cash = opening count + cash sales − cash refunds + credit collected in cash + cash in − cash out

Difference = counted cash − expected cash

Writing it as a ledger exposed three gaps a sales report hides:

• Cash that moves without a sale. Change top-ups, a supplier paid from the till, an owner taking money out. Without a record of these, no expected figure can be honest. So cash in and cash out became their own entries, each with a reason.
• Credit settled in cash. In Nepali shops customers often run a tab and pay it later. That cash is real, but it isn't a new sale. It needed its own row, and the backend engineer made sure credit collections reached the session report.
• Cash versus everything else. Shops take QR and wallet payments alongside cash. The drawer should only count what is physically in it, so the Cash Drawer card uses the cash share of sales, refunds and collections, and the other payment methods stay in the Transaction Summary.

Counting also had to fit Nepali money. The default denomination list is Rs 1,000, 500, 100, 50, 20, 10, 5, 2 and 1, in descending order, which is how a cashier counts. The less common Rs 25 and Rs 250 notes are not in the default, but a shop can add them in settings. That is why the list is editable rather than fixed.

The first thing I had to get right was not a screen but a model. A session in this feature varies along three separate dimensions:

1. Lifecycle: in progress, or closed.
2. Cash result: balanced, short or excess. It exists only for closed sessions at locations that verify cash.
3. Who is looking: the session's owner, an admin, or another member of staff.

It's tempting to merge the first two, so that "Closed" implies everything is fine. But a closed session is not necessarily a balanced one, and an owner reviewing last week wants exactly the closed sessions that came up short. So the list filter nests Balanced, Short and Excess under Closed, and only shows them when the location verifies cash. The third dimension decides what each person can do: the owner of a session and admins can record and correct cash; everyone else sees the record but can't change someone else's drawer.

With the dimensions separated, the states followed. Cash verification is a per-location setting called Require Cash Verification, a label the CEO chose. When it's on (internally we called this strict mode), the session has to be opened with a count and closed with one. When it's off (easy mode), start and close are one click each, and counts can still be added later if a shop wants them.

The closing flow is the heart of the feature, and the most important decision in it was deliberate from the start: the cashier counts before seeing the expected amount.

If the expected figure sits next to the input, the count is no longer independent. A tired cashier who counts Rs 17,280 and sees Rs 17,600 on screen has every reason to recount until the number agrees, or just type the target. I wanted to reduce that bias toward matching the expected amount. So closing has two phases. In the first, the cashier enters a total or counts by denomination, and nothing on screen says what the answer "should" be. Only after Submit Count does the system fetch the expected cash and show the review: expected, counted, the difference, and a plain-language status.

Here is one fictional session from its opening count to a close that comes up short. Step through it; every step is also listed below the panel.

The blind count has one honest limit. During an open session, the Cash Drawer card on the session detail does show the running expected cash, because people need to see the drawer build up. A cashier who wants the target can find it. The two-phase close removes the target from the moment of counting; it doesn't make the whole product blind.

Two small rules carry most of the feature's integrity.

Empty means forgotten; zero means no cash

A blank opening count and an opening count of zero look alike on a screen, but they mean different things. Blank means someone forgot to enter it: the value is unknown. Zero means someone checked and the drawer really was empty: the value is known. If the interface quietly turned a blank into 0, a forgotten count would look like an honest empty drawer, and every difference after it would be wrong.

So a balance field keeps a typed 0 visible and accepts it, and a blank field is rejected with "Enter an opening amount." A cash movement is different: it is an event, and a movement of zero didn't happen, so cash in and cash out need an amount above zero.

A note is required only when something is wrong

When the drawer is balanced, the closing note is optional. When it's short or over, the note is required, because a mismatch means something went wrong and the record should say what. The same logic applies wherever money changes without a sale: every cash in and cash out needs a note, and so does every edit to an opening or closing balance.

I didn't make the note required on every close. A note that is always mandatory soon becomes "ok" typed forty times a week, and then it carries no information. Asking only when the numbers disagree keeps the request rare, and so it is more likely to get a real answer.

At a location that verifies cash, what happens if a cashier tries to sell before entering an opening count? Something has to stop them. The question was where.

My first version of the check, on 9 June, sat at every entry point: the restaurant order page, the retail order page, quick orders and the payment calculator. It worked, but it could stop a cashier while they were still building an order, with a customer waiting, and it had to be kept consistent across four places. On 18 June I moved it to one place: the payment page. The page asks for the opening count when it loads, and again if the cashier presses Complete Order without one. I made the change for ease of use and a better experience at the counter. Order-building is never interrupted, and cash is asked about at the moment cash is about to be taken.

Moving the gate also meant the interrupted action had to survive the interruption. If a cashier presses Complete Order and is asked for the opening count first, saving that count should finish the order, not dump them back to press the button again. And cancelling the prompt should take them back to the order without a confusing "unsaved changes" warning. Both are small, but they decide whether the gate feels like a checkpoint or a trap. Chapter 14 describes a timing bug this exposed.

Most of the decisive changes in this project removed something. I built each of these, used it, and replaced it.

1. 2 Jun 2026A working prototype before the APIThe whole open, count and close flow ran in the browser, with settings kept locally, so the team could walk through it before the backend was ready.
2. 8 Jun 2026Connected to the real APITwo separate Opening and Closing cards became one Cash Drawer card in ledger order. Drag-to-reorder and per-denomination checkboxes became a plain list sorted by value.
3. 9 – 16 Jun 2026HardeningNotes required on cash movements, zero allowed on balances, history per movement, loading and error states, and fixes for bugs found in testing.
4. 18 Jun 2026One gate, on the payment pageThe check moved from four order entry points to the payment page, for ease of use.
5. 23 – 24 Jun 2026A second switch, removedAn 'Enable Cash Denominations' toggle was added and removed the next day as not necessary: denomination counting is available whenever the location has denominations configured.
6. Jul 2026RefinementSettings are loaded only when someone is about to start a session, rather than for every location on screen.

The single ledger card was the change I'm happiest with in retrospect. Two cards, one per count, gave you two numbers and no explanation. One card that lists opening, cash sales, refunds, credit collection, cash in, cash out, expected, closing and difference, in that order, lets a manager re-add the column and see where a gap came from.

The settings label changed too. It began as "Strict Session Cash", became "Session Cash Management", and ended as Require Cash Verification, the CEO's choice, with the helper text "Require users to record opening and closing counted cash for each session." The final version names what staff will have to do, not the mode's internal name.

Shipped: opening counts by total or by denomination; cash in and out with notes; the blind two-phase close; edits with a visible history; the Cash Drawer card; filtering sessions by cash result; the per-location setting with an editable denomination list; the payment-page gate; and an "Open 12+ hours" label for sessions left open. I designed web and mobile and built the web frontend; the mobile developer built the app.

Live and properly used by real shops.Reported to me by the CEO

That report is my only evidence of use. I don't know how many locations switched verification on, how often drawers close short, or whether closing got faster or slower.

If I could instrument one thing, it would be the share of verified sessions that close with a count, broken down into balanced, short and excess, alongside how many imbalanced closes carry a note that says something. Together those tell you whether the loop works: people count, differences are visible, and differences are explained. I'd also watch the time between the payment page opening and the opening count being saved. A gate that slows the counter too much is the most likely reason an owner would switch verification off, and that would undo the whole feature.

1. 01

   Model the money before the screens

   The feature became manageable once opening, movement, closing and difference were separate records. After that, every screen was a view of the same ledger, and the ledger order became the card layout.

2. 02

   Nothing has two meanings

   In anything financial, blank means unknown and zero means known and empty. Keeping them apart is a data-integrity decision, not a detail of the input field.

3. 03

   Interrupt where the consequence is

   The gate got simpler and less disruptive when it moved to the one place where cash is actually taken. Where you ask matters as much as what you ask.

The hardest part wasn't any single screen. It was timing: what the interface shows while the server is still catching up, and whether an interrupted action survives the interruption. Most of what I fixed after the first build was about that, not about how things looked. Designing this flow meant designing its timing too. Next time I'd draw those in-between states in the first sketch rather than discovering them in testing.