Loss control and cash risks

One manual discount means nothing. Twenty discounts under one PIN in a shift, when everyone else averages three, mean something.

Loss control has two layers. The first is the log of risky operations, which answers "what happened". The second is eight rules, which answer the owner's question: "what should I look at".

The log of risky operations#

The till writes an event stream of risky actions attributed to the current cashier (quick PIN switching counts, not just whoever is logged into the device):

The stream itself, with filters by cashier and operation type, lives on the "Risky operations" tab of the Statistics section — see Site traffic and sales summary. It is not duplicated here.

To go through a month with your accountant or manager, click "⬇ Download CSV" above the "Event feed": the file gets the whole filtered feed (cashier, operation type, location and period), not just the rows on screen — time, who and in which role, what changed, the amount, the order number and who approved it. If a single order's history is open, that history is exported.

By register and by reason#

Below the By cashier and By type tables on the Risky operations tab there are two more summaries for the same period and filters:

• By reason — cancellations, voids and refunds by the reason the cashier chose: “Guest declined”, “Dish defect”, “Long wait”, “Cashier error”, “Test / training”, reasons from your returns list and Other (own words), where you also see what was written. Count and amount per reason; the rows add up to the number of operations with a reason. To make the register always ask for a reason, turn on the location setting Ask for a reason when voiding a sent item (dining-room orders). Cancellations recorded before this summary appeared keep the reason only in the operation text — they are not counted, their number is shown below the table. The reason reaches the summary from both the browser register and the register app for Android, Windows and Ubuntu — when voiding a sent item and when refunding a receipt.
• By register — on which register (device) the operation was made: count, amount and how many times the drawer was opened without a sale. Name a register on the device itself: in the web register — the “POS appearance” window → “Register name”; in the register app for Android, Windows and Ubuntu — the “Register name” field in the device settings. Without a name the app shows under the device name (tablet model or computer name), the web register under a short number. The same breakdown by revenue is in Finance.

The log has a second, server-side leg. Risky operations are not only recorded by the till — the server also derives them on its own, from the way the order itself changed: voiding an item already sent to the kitchen, a manual discount, a price override, reopening a closed order, cancelling after payment, a refund, an edit after the pre-bill. The till cannot bypass this record: it is made on the side that accepts the order, not in the browser.

The two legs feed a rule of their own — “log mismatch”: when an operation appears in the till log but not in the server one (or the other way round), it is worth a closer look — the app was offline, the log never arrived, or the cashier tried to dodge the record. Such a mismatch shows up in “Till risks” on the “Under control” tab alongside the other alerts.

The eight rules#

Rules are evaluated on the server against the log and your accounting data. The observation window is one week; a "shift" is approximated by the location's calendar day.

Own norm vs the shared median. "Discount spree" compares a cashier with everyone else and misses an employee whose discounts are always three times higher than colleagues'. "Above own norm" compares a person with themselves: a spike shows up even if the amount is ordinary for the venue. Shifts without discounts count into the norm as zeros. So that one small thing is not a "spike", the day needs at least two money operations (or three voids) and a value at least one and a half times the norm.

Why money thresholds self-calibrate. A constant doesn't work here: accounts have different currencies and different check sizes. So the money rules compare a cashier with the median across all cashiers of the same account and only fire when it is exceeded threefold.

The median purchase price is computed over 30- and 90-day windows, with one invoice counting as one sample point (a supplier who splits a delivery into five lines does not shift the median five times harder). Fewer than three deliveries is not a sample and the rule stays silent. The same median powers the "+N % vs median" badge right on the receiving line — see Inventory.

Every alert carries a severity (high/medium), the amount at risk, the event count and the period. Re-running the calculation does not create duplicates: the same anomaly on the same day is the same alert.

Where to look and how to configure#

The "Cash risks" block sits in Work chat → Needs a decision → the “Under control” tab, together with the rest of the to-dos. There is no separate "Needs attention" section in the panel any more; the old address leads here. The "Review" button opens the event stream.

Thresholds open from the ⚙️ gear in the header of the "Statistics" section, the "Alert thresholds" item: it switches to the "Risky operations" tab and expands the collapsed thresholds block for you (the item is visible to the owner and the manager). You can also get there by hand — the "Risky operations" tab → the thresholds block. What you set:

• total manual discounts per shift — raises the bar: both conditions are required, the threshold and exceeding the median (what counts as a normal discount is relative and depends on promos);
• void series per shift — a count threshold;
• cash discrepancy — replaces the median: here the owner knows their tolerance in absolute money;
• losses above theoretical consumption, %;
• purchase price above median, %;
• "Compare each employee with their own norm" — the switch of the "Above own norm" rule (on by default), sensitivity k and how many shifts the norm needs.

An empty threshold means "no threshold": the rule works from the median (money rules) or from a conservative default.

The owner's e-mail is opt-in. By default alerts are calculated and visible in the admin panel, but nobody gets letters. The e-mail switch lives in the same settings, and the design is one letter per run summarising new alerts, rather than one letter each: a void series usually arrives in a batch.

Push to the manager's phone is opt-in too. The "Push to the manager's phone" switch is in the same settings: the manager learns about a new shortage, too much cash in the drawer, or discounts and voids above the norm in the Cenaly Business app (the order monitor on the owner's phone), even when not on the floor. To keep it from becoming noise:

• one summary, not more often than every 4 hours (the default; the “Not more often than once in, hours” field): new signals pile up and leave as one notification, e.g. "Anna: discounts 18,000 vs usual 7,000";
• quiet hours (23:00–08:00 location time by default): at night the push waits and the summary arrives in the morning;
• only cash rules are pushed (cash discrepancy, too much cash, above own norm, discount and void series) and only for today and yesterday — turning push on does not send you a summary of last week.

The push goes to the account owner on phones where the app is signed in. Tapping it opens "Risky operations".

Video clips of risky operations#

If a camera is connected to the till device through Cenaly Hardware Bridge, a short video clip can be attached to an event: a few seconds before and after the operation.

It is configured per location (every till has its own room and its own camera angle) in the hardware section:

• on/off (off by default — video of the till area is personal data and cannot be switched on silently on the client's behalf);
• the till-area camera from the bridge device list;
• how many seconds before and after the event go into the clip — 30 and 30 by default, 5 to 120 seconds allowed;
• a daily clip quota per location — 40 by default, 1 to 200 allowed;
• how many days a clip is kept — 30 days by default, 1 to 365 allowed.

The log works fully without a camera — video is an addition, not a condition.

PIN approval#

Risky operations can be gated behind a supervisor's confirmation: the cashier requests the action, a manager enters their PIN, and the log records both the operation and who approved it.

Per-role limits on discounts, refunds and voids are set by the owner in Staff and shifts; the till uses them to decide whether an operation needs PIN approval.

Reprinting an issued receipt also goes through PIN and is written to the log.

Age checks (18+) and voiding items as waste#

These settings apply to the selected location in the web POS and are off by default. Open the POS settings gear → “Cashier controls”. They work separately from the loss analytics rules described above.

Check age before a sale#

1. Under “Age check (18+)”, enable “Ask for an age check”, set “Minimum age” and “Age-restricted categories”, then “Save”. Subcategories inherit the category mark.
2. Item tags such as “18+” or “21+” set their own threshold. With tag recognition enabled, alcohol, tobacco, wine, beer, hookah and energy-drink tags also count. An age-restricted component of a combo counts too; the highest threshold in the ticket applies.
3. Adding such an item opens the check. Inspect the ID and select, for example, “ID checked — 18+”, or enter “Date of birth from the ID” and confirm the calculated age. “Later” postpones the check until payment; the sale cannot proceed without confirmation.
4. “Refuse sale” removes unsent age-restricted items. Void already-sent items normally in the ticket. The refusal is logged.

The order records the employee, time, confirmation method and age threshold. The date of birth and ID details are not saved. Confirmation applies to the current ticket.

Void a prepared item and account for its ingredients#

1. In “Cashier controls”, enable “Ask what happens to the products”.
2. When voiding a sent item or reducing its quantity, choose “Write off as waste” if it was prepared, or “Do not write off” if the ingredients were not used or the dish went to another guest.
3. After choosing “Write off as waste”, check “Inventory” → “Documents”: the ingredients for the voided quantity are written off in a separate waste document. The item needs a configured inventory composition/recipe. “Do not write off” creates no such waste document.

Limitations#

These workflows cover the web POS. Age checks must be enabled and rely on correct tags or categories; they do not estimate age from appearance. Waste write-offs cover the removed quantity of a sent item, not cancellation of an entire order. Without an inventory composition there is nothing to deduct.

Troubleshooting#

Voiding several items and the per-ticket quantity limit#

Both tools are in the web register; the register app for Android, Windows and Ubuntu does not have them yet.

Remove several items at once#

1. Above the ticket lines, tap ☑ Select and tick the items.
2. Tap ✕ Void.
3. If some of them were already sent to the kitchen, the till asks for the reason once (and, if “Ask what happens to the products” is on, “Write off as waste” or “Do not write off”). A senior PIN is also asked once, per the “Manager PIN to void a sent item” setting.
4. All ticked lines are removed together.

After the order is saved, the risky operations log gets one "Item voided (sent to kitchen)" entry listing the items, the total and the reason. The server still sees each removed line, and the "Log mismatch" rule matches the group entry with all of them — no false alarm. For the "Void series" rule a group void counts as one void. Items not yet sent to the kitchen are removed without questions, like a regular ✕.

Per-ticket quantity limit#

The owner sets “Order quantity” → “Maximum” in the product card (the “Price” tab) — the same field that limits the website cart. The field is in the catalog product card (shop, retail); the restaurant dish card does not have it yet. At the till it is a control rather than a hard ban:

• while the ticket holds no more than the item's maximum (all its lines count), the till rings it up without questions;
• the next unit above it — tile, scan, repeat or + on the line — opens “Manager approval required” explaining “Item limit per ticket exceeded (… 3 with a limit of 2)”;
• after the PIN the item is added; the approval covers this ticket up to the approved quantity — the next unit above that asks again; a refusal means the item is not added;
• a refund is limited to what was sold (as before) and to the item's maximum without a senior PIN.

Weighed and timed items are not limited. The minimum and step from the same card are not enforced at the till: they are about the website cart.

Related sections#

• Site traffic and sales summary — the "Risky operations" stream itself and the "Pour" tab
• Attention — the work chat's "Under control" tab, home of the "Cash risks" block
• POS — PIN roles, pre-checks, refunds
• Cash shift — cash reconciliation and the Z-report the discrepancy comes from
• Inventory — stocktakes, variance and the "+N % vs median" badge on receiving
• Staff and shifts — per-role limits on discounts, refunds and voids

FAQ#

Is this surveillance of staff?#

It is a conversation tool, not a punishment tool. The rules do not accuse — they show that one person's numbers stand sharply out of the overall picture. What happens next is the manager's call.

Why didn't a rule fire even though the discount was huge?#

Money rules look at the shift total against the median across all cashiers, not at a single operation. If large discounts are the norm across the venue, the median is high too. Set an explicit threshold if you want to catch absolute amounts.

Do I get the same alert several times?#

No. An alert's identifier is built from the rule, location, cashier and period — recalculation produces the same alert, and the letter about it goes out once.

The shortage push did not arrive immediately — is it broken?#

No. Rules are recalculated every 30 minutes, the push leaves as one summary not more often than every 4 hours (by default), and during quiet hours it waits for the morning. For urgency, look at the "Risky operations" feed itself: the signal appears there with the next recalculation.

Why doesn't a newcomer get "Above own norm"?#

Until the employee has fewer shifts than set (6 by default) there is no personal norm — nothing to compare with. The shared rules (discount and void series, cash discrepancy) work from day one.

Can I enable e-mail without enabling video?#

Yes, they are independent settings: e-mail lives in the rule thresholds, video in the location's hardware settings.

What do I do when "Consumption above norm" fires?#

Compare theoretical consumption from recipes with the stocktake result: the usual causes are an inaccurate recipe, unrecorded waste write-offs, or portions served "by eye". The breakdown lives on the "Variance" tab of Inventory.