Case File: Credit Hit the Business Platform, but There Was No Correct Transaction Type
A real provider/Xpress/Ecobank credit arrived, but the control system rejected the entry unless it was forced into “Other” with a note.
Why “credit received” is dangerously ambiguous
In a cash-heavy agent business, “credit” can mean at least three different events: a customer paying an old debt, a provider settling an amount it owed, or a provider/bank simply posting a credit to the business platform account. Those events do not have the same accounting trail.
| Event | What increases? | What decreases? | Is it income? |
|---|---|---|---|
| Customer receivable collected | Actual receiving asset | Customer receivable | No new income; it clears earlier credit |
| Provider settlement received | Actual settlement/platform asset | Provider receivable | Not automatically |
| Platform / Xpress credit received | Actual platform asset | Nothing automatically | Not automatically |
Why “Other” is not good enough
A note can preserve context for a human, but a generic transaction type prevents the system from classifying the value correctly. At close, the owner cannot reliably answer whether the platform increase came from a customer, provider settlement, owner injection, correction or ordinary transaction.
Control lesson
- Give platform credit its own transaction type.
- Increase only the real credited platform account unless another real-world movement occurred.
- Require a statement/reference or explanatory note.
- Do not classify the credit as sales merely because the business asset increased.
- Do not reduce customer/provider receivables unless that specific debt was actually settled.
Public guidance explains the classification boundary. TrustPoint's transaction engine and validation implementation remain private.