What does SGApps record as a "loss" in a kitchen?

Any ingredient or prepared-dish outflow that does not reach the customer as a sale: mozzarella dropped on the floor, a burnt pizza, an order cancelled after preparation, a glass broken at the table, an expired product, staff meal, given on-the-house to a customer, or a confirmed theft. Each one enters as a line on a consumption receipt (if tied to an order) or as a standalone writeoff receipt, always with a mandatory reason chosen from the nomenclature configured at the POS.

Why is the reason mandatory on every loss line?

The reason is your accounting and analytical anchor. It is persisted on the receipt line and remains visible in the audit — the head chef, manager and accountant can later filter by reason code (cazut_spart, expirat, ars_preparat, autoconsum_personal, degustare_client, furt_frauda, etc.). Without a mandatory reason, at month-end you only see "4,200 MDL lost" — with a mandatory reason you see 1,800 MDL dropped/broken, 900 MDL expired, 600 MDL staff, 900 MDL offered to VIPs.

How do the approval thresholds on losses work?

Thresholds are configurable per reason type. Default example from docs: losses above 100 MDL value → require approval; losses with the theft/fraud reason → always require approval; losses offered to customers above 50 MDL → approval. Below the threshold, the operator records directly. Above the threshold, the receipt enters the "awaiting approval" state, the shift manager gets a notification and approves with one click or rejects with a reason. We configure thresholds and reasons during onboarding, then you can adjust them from the admin area.

What does the loss anomaly detector look like?

The HoReCa panel has a "Loss anomaly detection" section that compares today's losses with the mean + standard deviation of the last N days (configurable window 3-30 days, default 7). It flags products above 1× stddev yellow (warn) and above 2× stddev red (alert); both thresholds are configurable and can be lowered to 0.5× for small-volume locations. Products with too short a history (under 3 days) are skipped because the standard deviation is not reliable on so little data.

🍽️ For restaurant · café · bar

How do you control kitchen losses?

Q: Who sees the top-10 losses at shift close?

The shift manager. When they press "Close shift" in the Reports tab, the retrospective snapshot is generated for the calendar-date × POS pair. It includes subtotals for the seven movement types (production, sales, writeoffs, transfers, supply, transformations, e-commerce), top-10 losses per product (product, event count, quantity) and a summary of the bills. The snapshot is immutable once written.

The system requires a mandatory reason on every loss line, chosen from a nomenclature configured at the POS. Above the per-reason thresholds (configurable), the loss requires shift-manager approval. At shift close you see the top-10 losses per product, and an anomaly detector with a rolling window (3-30 days, default 7) flags yellow anything exceeding mean + 1σ and red anything exceeding 2σ.

Free discovery call · 20 min See the anomaly detector

📋 Mandatory reason · chosen from the POS nomenclature 🛑 Per-reason thresholds · manager approval above threshold 🏆 Top-10 losses · in the shift-close snapshot 🚨 Anomaly detector · configurable warn / alert thresholds

How it works, step by step

Three layers: the line (mandatory reason), the receipt (threshold + approval), the report (top-10 + anomalies). We handle the configuration at onboarding based on the discovery conversation.

1. Mandatory reason on the line

When the cook taps + Add loss on the tablet, they pick the product, enter the quantity (negative = stock outflow — positive is reserved for inventory corrections) and select the reason from a list configured at the POS: cazut_spart, expirat, ars_preparat, anulare_client, autoconsum_personal, degustare_client, furt_frauda, etc.

The system validates that the reason belongs to the configured list. If the list is empty, free text is accepted — but we recommend a strict nomenclature so you can filter later.

2. Live stock-impact preview

Before saving, the system displays next to the input: "Will remove 0.060 kg from the Mozzarella stock at POS X". If the removal would leave stock negative, a visible warning appears — the cook checks that they didn't mistype.

The "Apply stock removal immediately" checkbox is unchecked by default — it protects stock against mistakes during busy moments. The shift manager confirms (legacy two-step flow).

3. Threshold → manager approval

Above the threshold configured per reason type, the receipt enters the "awaiting approval" state. The shift manager receives a notification, approves with one click (optionally with a comment) or rejects with a reason → the operator adjusts and resubmits.

Default example: above 100 MDL value — approval; reason furt_frauda — always approval; given to customers above 50 MDL — approval.

4. Top-10 losses at close

When the manager taps "Close shift", the retrospective snapshot is generated for the calendar-date × POS pair. It includes subtotals for the seven movement types (production, sales, writeoffs, transfers, supply, transformations, e-commerce) and top-10 losses per product (product, event count, quantity).

The snapshot is immutable once written — re-closing the same date+POS pair creates a duplicate folder, it does not overwrite.

Three real loss-flow examples

The concrete situations you see daily in the kitchen and how the system handles them.

Mozzarella dropped during packing

The cook drops 60g of mozzarella on the floor while preparing a pizza. On their tablet: + Add loss → Mozzarella → −0.060 kg → reason cazut_spart → note "Dropped during packing" → saved.

Below threshold (60g mozzarella ≈ 15 MDL < 100 MDL) → no approval needed. The line appears on the pizza's existing consumption receipt, stock is decremented, the reason stays for audit.

Pizza burnt in the oven

The cook forgets a pizza in the oven. Reason ars_preparat → requires manager approval above threshold. The pizza must be remade by re-ordering (manual flow at the till), while the loss stays in the audit with the reason and the approver.

Offered to VIP customers

The owner decides to offer a bottle of wine and a tapas platter to the VIPs. The waiter marks the lines "gift" with reason degustare_client → amount > 50 MDL freebie threshold → shift-manager approval → lines with 0 MDL price on the fiscal receipt, the reason stays persisted for the monthly report.

Staff meal at shift end

At 23:30 the manager opens "Record staff consumption": list of cooks + dishes consumed, reason autoconsum_personal, note "Shift meal". The system generates a standalone writeoff receipt, decrements ingredient stock (BOM exploded), the reason stays on every line.

Reason nomenclature — common examples

Each code has its own approval threshold, configurable per POS:

Reason code             Description                        Approval
─────────────────────   ─────────────────────────────────  ────────────
productive              Normal consumption (BOM ingredient) no
anulare_client          Cancelled after prep start          no
ars_preparat            Burnt / ruined dish                 yes
cazut_spart             Dropped / broken                    yes (>100 MDL)
expirat                 Expired                             no
autoconsum_personal     Staff meal                          no
degustare_client        Offered to customer                 yes (>50 MDL)
furt_frauda             Theft / fraud                       yes (always)

We configure thresholds and the reason list at onboarding — then you can adjust them from the admin area at any time.

The anomaly detector — how it decides "yellow" vs "red"

Runs on-demand from the 📊 Reports → Loss anomaly detection tab. The manager picks the historical window, the system does the rest.

Rolling window 3-30 days

The historical window is configurable between 3 and 30 days (default 7). The system computes the mean + standard deviation of losses for each product over that interval, on the current POS.

Warn threshold (yellow) — 1σ default

Products with losses above mean + 1× stddev appear flagged yellow. The threshold is configurable — it can be lowered to 0.5σ for small locations with low volume, so detection doesn't miss anomalies on little data.

Alert threshold (red) — 2σ default

Products above mean + 2× stddev appear red. A clear signal: "Mozzarella has 4× more losses than the weekly average — check the fridge, check the batch".

Products with short history — skipped

The system skips products with less than 3 days of history. The standard deviation on such little data is not reliable and would produce false positives.

What the detector does not do (transparency)

The detector works per product, aggregated per POS. The following remain ⚙️ available on request (support effort at cost, priced in support hours after evaluation):

Extra segmentation per day / hour / reason (cross-reason or temporal pattern)
Comparison between physical stations (hot kitchen vs cold kitchen) — currently aggregated at POS level

The results are clickable — from the anomaly list you jump straight to the product card in the warehouse to investigate.

Frequently asked questions

What happens if a loss was applied wrongly?

Every loss receipt appears as an internal invoice in the invoice panel, with the exact report of stock changes (which product, what quantity, in which warehouse). At invoice level there is a stock adjustment tool which the administrator (or a user with specific permissions) uses to reverse the effect. The invoice remains in the archives, visible for audit, with author + reason + timestamp.

Positive quantity = adding to stock?

Yes, but strictly for rare inventory corrections (a recount finds 3 extra units). It requires a separate admin permission, a yellow warning on the form and an additional confirmation checkbox before saving. Regular operators cannot accidentally make this kind of adjustment.

Can I add context to a loss (e.g. the table where a glass was broken)?

Yes. When recording the loss the operator can add a free-text comment — useful for losses scoped to a specific table ("glass broken at table 5") or any other context relevant for audit. The comment stays on the receipt line and remains visible later.

Who sees the close-shift report with the top-10 losses?

The shift manager taps the "Close shift" button in the Reports tab and receives the full snapshot — subtypes subtotals, top-10 products with losses, bills summary. Cooks and waiters do not have access to financial reports by default.

Is SNC account bookkeeping automatic?

No. The reason is persisted on the receipt line, and the mapping reason → SNC account (611 / 711 / 712 / 713 / 714) remains the accountant's responsibility. Automatic split on SNC accounts in the shift report is ⚙️ available on request — support effort at cost, priced in support hours after evaluation.

Is there a full history per loss for audit?

Yes. Every loss receipt appears in the internal invoice list, with author, second-precision timestamp, reason and comment. From the list you open any receipt and see every detail — useful for retrospective inspection or accountant discussion.

The packages below are indicative — the exact configuration (reason thresholds, anomaly detector window, per-station nomenclature) is done at onboarding based on the discovery.

Want real control over losses in your restaurant?

Loss control (mandatory reasons, per-reason thresholds, manager approval, top-10 and anomaly detector) is part of the Extra HoReCa package. We configure the reason nomenclature + thresholds at onboarding based on your policy (who approves what, at which threshold). Package comparison + current price → see the pricing page.

Free discovery call · 20 min See package comparison Learn more about HoReCa

Book a conversation

For custom configurations (reason thresholds, detector window, automatic SNC split, comparison between physical stations), we quote after discovery — support effort at cost, priced in support hours after evaluation. For the rest — standard reason nomenclature, default thresholds, top-10 and anomaly detector with 1σ/2σ — the Extra HoReCa package is ready at onboarding.

contact@sgapps.md

Phone / WhatsApp

+373 61 233 303

Book a call

sgapps.io/contact

SGAPPS LABS SRL · Chișinău, Moldova · Continuously in production since 2018 · POS · ERP · MEV fiscal register · Android fleet