Detect unusual prepaid activity across branches
When a branch exceeds its prepaid limit, start with the orders that made up the total. Compare them with approvals and the branch's recent trading. Keep completed, pending and unknown results separate so the manager can see which items need checking.
Show the rule that was triggered, the records behind it and who should look at them. Set thresholds that reflect the outlet's hours, customer mix and products. The same volume can be routine at one branch and worth checking at another.
A small exception report
| Indicator | Example review trigger | Owner action |
|---|---|---|
| Orders above branch limit | Any amount beyond an approved cap | Confirm approval and records |
| Repeated value or recipient | Locally defined unusual pattern | Match references and context |
| Unmatched transactions | Any unresolved item at close | Reconcile original references |
| Sudden volume shift | Material change from branch baseline | Ask for business context |
| Access outside expected role | Activity inconsistent with permissions | Review access and approval record |
By Freepaid · Published
Set rules that can be explained
For every alert, document the data source, report period, calculation and threshold owner. State whether the rule is based on the branch's own history, an approved spending limit or another internal control. If records use different time zones or close at different times, normalise those conventions before comparing counts and values.
Keep the report focused on action. A flag should not label a person as dishonest or a transaction as fraudulent. Use neutral terms such as “requires approval check” or “unmatched record”. Access should be limited to the people responsible for the review, and reports should include only the personal details needed to investigate.
Worked example: a limit exception
Suppose a branch has an illustrative daily limit of R1,000 and reports R1,180 in orders. The report flags the R180 excess. The manager checks the approvals, individual order references and the period cut-off. If the activity was valid but the authorisation was missing, the manager records the approval gap and follows the business's remediation process. If the references do not match the supplier report, finance receives a reconciliation task.
The excess could come from a legitimate campaign, a timing difference, a duplicate entry or an order nobody approved. Check which explanation fits the records before changing access or raising a formal allegation.
Build a reviewable exception process
- Define a small set of indicators tied to a business rule or observed operating pattern.
- Confirm that the source reports contain the fields needed to evaluate each flag.
- Assign a reviewer and backup for every exception type.
- Record the finding, evidence, decision and any approval separately.
- Escalate suspected policy breaches using the organisation's established process.
- Review false positives and missed cases, then adjust thresholds with approval.
Give each flag a reviewer, a due date and a place to record the outcome. Keep the branch, date and order references with it. When an order cannot be verified, leave it open and ask the supplier to check the existing reference.
Review patterns, not just individual rows
A repeated issue may reveal a process gap. If multiple branches report missing references, the cause may be receipt design or staff training. If a single product has more unresolved cases, check its specific workflow and support route. Use the smallest evidence set that explains the pattern, and avoid concluding there is a supplier-wide issue based on one branch's report.
Review which flags turned up actual issues and which were cleared. Save the reason for each decision so you can see which thresholds need adjusting.