Exception-based reporting for small businesses
Exception-based reporting (EBR) is the practice of reviewing only the transactions that fall outside a defined normal range, instead of reading every transaction. Large retailers have run it for decades with dedicated loss-prevention software; the same method works for a single store once the point of sale exposes its transaction data.
The idea
A store rings thousands of transactions a month. Almost all of them are unremarkable. EBR defines what "remarkable" means in advance (a refund over a certain amount, a discount over a certain percentage, a refund issued minutes after the sale, a rate of voids far above the store's average) and surfaces only those, with the details needed to review them.
Three properties make it work: the definitions are set by the business, not by the software; each exception carries the numbers that triggered it; and the output is a review queue, not a conclusion. The person reviewing decides what an exception means.
The exceptions that matter at the register
| Exception | What it is | Typical threshold | Why it is reviewed |
|---|---|---|---|
| Large refund | A single refund at or above an amount | $100 | Refunds move cash out; large ones should match a real return |
| Large discount | A discount at or above a percentage | 30% | Should match a running promotion or an approved comp |
| Refund shortly after sale | A refund within minutes of the original sale | 15 minutes | Compare against the receipt and customer contact |
| Open check outstanding | An order open with no payment after a number of hours | 6 hours | Reconcile at close |
| No-sale drawer open | Drawer opened without a sale | Count per employee per day | Compare with what the shift needed |
| Refund, discount or void rate | An employee's rate versus the store's average | 3× the average of other non-manager staff, after 50 transactions | Managers excluded; small samples excluded |
Thresholds versus baselines
Threshold rules ("any refund over $100") need no history and work from the first day. Baseline rules ("refund rate three times the store average") need enough transactions for the average to mean something, which is why they are usually gated on a minimum sample, commonly 50 transactions per employee in the last 30 days. Using both avoids the two failure modes: thresholds alone miss many small exceptions; baselines alone say nothing on day one.
Why managers are excluded from rate comparisons
Managers approve comps, override prices and void mistakes for everyone. Their refund, discount and void rates are legitimately higher, and including them both inflates the store average and flags them constantly. Sensible EBR compares non-manager staff with each other, and reviews manager activity with its own thresholds.
What good output looks like
An exception should read like a fact, with the comparison attached: "A $42.00 refund on a cash sale was issued 4 minutes after the sale was rung up, by [employee], at [time]. Your alert window is 15 minutes." Not a score, not a percentage, not a recommendation about the person. That is partly good practice and partly law: several US states and Canadian provinces now regulate automated systems that influence employment decisions, and a growing number require written notice to staff that transactions are monitored. Output that states records and comparisons, and leaves the decision to the employer, stays on the right side of both.
Running it in a small business
- Decide your thresholds. Defaults like those above are a starting point; adjust to your price points and refund policy.
- Mark your managers so they are excluded from rate comparisons.
- Give staff written notice that transaction activity is monitored, where your jurisdiction requires it (many do).
- Review exceptions on a fixed rhythm, weekly at least, and dismiss each with a reason so the log shows what was checked.
- Adjust thresholds when a rule produces mostly noise. An exception rule that fires on every shift is set too tight.