What we check
Four rules, run over every sale. Each one is deterministic: it names the records that prove it, and you can check those records yourself. Nothing here is a model guessing at intent.
R-PAY-01
Unpaid sale
Sale without matching payment
A recorded sale has no payment covering its expected amount once the settlement grace period has passed.
R-PAY-02
Payment diverted
Payment into an unapproved account
A payment was received through an account not on the business's approved list.
R-INV-01
Stock unaccounted
Stock left without a sale
Outbound inventory movement with no sale linked to it — stock that has gone with nothing to account for it.
R-FUL-01
Not dispatched
Paid sale never dispatched
A sale has been paid for but has not reached dispatch within the fulfilment window.
Thresholds in force
These are assumptions, not findings. The team has not set KPI targets yet (risk R12), so every number below is a starting position to be argued with.
DetectionSettings(payment_grace_hours=6, amount_tolerance=Decimal('50.00'), dispatch_grace_hours=48, unlinked_stock_grace_hours=1)Where this data comes from
Every figure on this site is simulated. There is no POS integration and no bank or fintech connection — that is risk R11 held to its own stated mitigation: define the prototype's limits rather than pretend past them.
The generator records the leakage it plants, so the rules can be checked against a known answer rather than merely demonstrated:
Leakage planted
- unpaid sales
- 3
- diverted payments
- 7
- unexplained stock movements
- 12
- undispatched paid sales
- 13
Leakage found
- R-PAY-01 Unpaid sale
- 3
- R-PAY-02 Payment diverted
- 7
- R-INV-01 Stock unaccounted
- 12
- R-FUL-01 Not dispatched
- 9
R-FUL-01 finds fewer than were planted on purpose: it yields to R-PAY-01 on unpaid sales so one break produces one alert, and it respects the dispatch grace window, so the most recent sales are not yet late.