How a multi-location retailer runs billing across 2 counters.
A publish-safe look at how an owner-led retailer uses Nox-Billings to run GST billing across two counters with three employee roles, location-aware stock, and a reviewable day-end close.
The problem: two counters, one shared login, no visibility
Before the rollout, both counters ran on a shared billing login. The owner could see total sales at month-end, but could not answer the daily questions that mattered: who approved that discount, which store sold what, why the cash drawer was short, or whether stock actually moved when the invoice said it did. Corrections were made silently, and the day-end picture was assembled in a spreadsheet after closing.
What was configured before the first sale
Two stores, one workspace
Each store was created as a location with its own counters, staff, and stock visibility.
Three roles
Owner, manager, and cashier logins were created with separate permissions — no shared credentials.
Products and taxes
Products were loaded with categories, HSN/SAC codes, and GST rates so invoices carried the right tax breakup.
Discount rules
A cashier discount limit was set; anything above routes to the manager for a recorded approval.
Opening stock
Opening stock was recorded per store so the first day's sales and the stockroom agreed.
How a normal operating day runs
- Open the store. The manager opens the day, confirms the opening cash float, and checks that both counters are signed in with the right staff roles.
- Bill at the counter. The cashier searches products, builds the sale, applies a discount within their limit, and takes cash, UPI, or card.
- Route exceptions. A discount above the cashier limit routes to the manager, who approves it with a recorded reason on the same screen.
- Move stock. A transfer between the two stores is recorded with a reviewable record when inventory moves mid-day.
- Close each store. Each store closes its own shift: expected cash vs counted cash, payment-mode split, discounts, refunds, and variance.
- Review the day. The owner reviews both stores' day-end reports and exception lists from one place before the records are finalised.
Facts we can safely share
These are the concrete details the retailer has agreed to disclose. No revenue claims, no vanity numbers.
Stores
Two retail counters in the same city, sharing the owner's team and stock.
Employee roles
Owner, manager, and cashier — separate logins with role-based permissions.
Invoice volume
Combined across both counters on a typical operating day; range, not a promise.
Hardware
Android devices at the counters with receipt printing; no special-purpose hardware.
Deployment model
Assisted rollout with the platform team; not a self-service SaaS install.
Rollout timeline
Staged: setup, staff roles, pilot at one counter, then the second counter.
What changed for the owner
| Before | After |
|---|---|
| One shared login; nobody knows who acted | Separate logins; every sensitive action has an owner |
| Discounts approved over chat, never recorded | Discounts route to a manager with a recorded reason |
| Month-end spreadsheet to piece stores together | Each store closes its own day; owner reviews both from one place |
| Stock and billing disagree until stocktake | Sales-linked stock and transfers make movement visible daily |
| Variance found at month-end, source unknown | Variance surfaced at close with payment-mode split to explain it |
How the rollout went
- Setup and roles. Workspace, stores, products, taxes, and staff roles were configured with the platform team.
- Pilot at one counter. The first counter ran live for a week while the owner validated discounts, payments, and the day-end report.
- Second counter. Once the first counter's close matched the drawer, the second counter came online.
- Day-end discipline. The owner now closes each store daily and reviews exceptions before records are finalised.
Run billing like this at your counters
Bring your current workflow to a walkthrough and see whether Nox-Billings fits the way you actually operate.