Daily cash + float control for mobile money, POS, remittance and agent-banking businesses
Operational case file

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.

Field-derived caseFalse balance riskProvider settlement
Evidence basisThis case pattern was encountered during internal operating/testing work that led to accounting corrections in the TrustPoint control system. Names and transaction amounts are removed; the worked figures below are simplified for teaching.
Visible symptomCash down, platform apparently up
Hidden issueUnsettled provider receivable
Control objectiveDo not spend value that has not settled

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

Simplified worked example

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.

Questions this case answers

Frequently asked questions

What is a provider settlement receivable?

It is value a provider or partner owes the business after the business has already funded a customer payout or related transaction.

Should provider float increase when the customer is paid?

Not unless the provider value has actually settled under that provider model. The payout and settlement receipt should be treated as distinct events.

Why can this look like a staff shortage?

Because the wrong classification changes expected cash or platform balances, creating a variance that may be blamed on staff even though the accounting trail is wrong.