Case File: Cash Went Out, but Provider Settlement Had Not Arrived
Physical cash fell, yet the system made provider/platform value look available too early.
The operational problem
A cash-heavy agent can pay a customer before a remittance or partner provider has settled the business. The business has genuinely given up physical cash, but it has not yet received the offsetting provider value. If the bookkeeping immediately increases the provider balance, the business appears stronger than it really is.
That creates a false balance: the total may look reasonable, but one asset has been recognized before it exists. When the provider finally settles, a second mistake can occur if the system also records another cash movement or recognizes the settlement twice.
The correct control trail
A LRD 10,000 payout before provider settlement
At payout: physical cash decreases by LRD 10,000. Provider receivable increases by LRD 10,000. The provider/platform balance does not increase yet.
When settlement arrives later: the selected provider/platform balance increases by the settlement amount. Provider receivable decreases. Physical cash does not move a second time.
Why this matters at daily close
Without the receivable bridge, an owner can believe there is usable float when there is only a promise to settle. That can lead to over-trading, an unexplained platform variance, or a shortage that appears to come from staff even though the real problem is transaction classification.
The shortage-forensics question
When cash is lower than expected and a provider balance seems unusually high, ask: Did we pay out before the provider settled, and did we accidentally count the provider value as already received?
Control lesson
- Separate payout from settlement receipt.
- Track provider receivable as its own bucket.
- Do not increase provider/platform balance until evidence shows settlement arrived.
- Do not create a second physical-cash movement when the provider settles.
- Keep fees separate from principal and from the receivable.
Public case files describe the diagnostic principle and control lesson. Detailed TrustPoint formulas, automation rules, thresholds and app implementation remain private.