Ledger balances summarize entries according to the rules of the ledger system. Modern Treasury documents pending, posted and available balances, each serving a different question about the same account. A fintech product should specify which balance it displays and which balance governs an outgoing transaction, then keep that decision consistent with how entries change status.
Define the three balances
Modern Treasury’s ledger balances reference gives precise meanings to its three balance types. In that product, pending balance includes both pending and posted entries. Posted balance includes posted entries. Available balance combines posted entries with pending outbound entries, taking the account’s normal balance direction into account.
These definitions are vendor-specific. Read the selected platform’s documentation before using the same labels in a product interface or migration map.
| Balance in Modern Treasury | What the documented calculation includes | Product question to resolve |
|---|---|---|
| Pending | Pending and posted entries | Does the interface explain that this is a combined total? |
| Posted | Posted entries | Which external event permits posting? |
| Available | Posted entries and pending outbound entries | Which spending decision uses this value? |
The final column contains suggested review questions, not additional vendor guarantees.
Do not treat a balance label as a settlement event
A ledger records the events an application sends to it. The transaction-status documentation says a corresponding transaction can be changed to posted when a payment settles. That requires the application to establish the payment outcome and represent it correctly.
For an illustrative credit-normal account, start with $100 posted, then record a $30 pending outgoing payment. Applying the documented definitions gives $100 posted, $70 pending and $70 available. If a separate $20 incoming payment is also pending, the pending total becomes $90 while available remains $70.
These are hypothetical ledger calculations, not a bank statement or a claim that $70 is legally withdrawable. External holds, account restrictions and the actual payment system need their own evidence.
Model failure and reversal explicitly
Modern Treasury permits a pending ledger transaction to be modified and retains prior versions. Once posted or archived, its status and entries are immutable; metadata can still be updated. Undoing the effect of a posted transaction requires a separate reversing transaction.
That behavior affects the operational workflow. For a pending outgoing payment that fails, document how the application archives the corresponding ledger transaction. For a later reversal of a posted payment, retain the original transaction and connect it to the compensating record.
A useful review follows one example from the external payment identifier through the ledger records to the resulting balances. Comparing totals without that connection can miss a duplicate or an incorrectly assigned status.
Make the spending check part of the write
Reading an available balance before writing a transaction leaves a concurrency question: another request may change the account between those two actions.
Modern Treasury’s balance and version locking documentation describes conditional writes. Balance filters evaluate the resulting balance, and a request that violates the specified range fails. An alternative uses the account’s lock version and rejects the transaction when that version has changed.
When evaluating a ledger, ask how it handles two simultaneous outgoing requests that individually fit the last balance read but exceed it together. Record the expected accepted and rejected outcomes, including how the application handles a refusal. A page showing a fresh balance does not answer that concurrency test.
Carry the definitions into reporting and migration
A dashboard, customer statement and transaction service can all use the word “balance” while reading different values. Name the exact field and its effective time in each requirement.
During a core banking migration, compare like-for-like balances and explain entries that are still pending. Our ledger as a service guide covers the broader infrastructure role; this guide addresses the narrower status and calculation decision.
Before release, review an incoming payment, an outgoing payment, a failed pending transaction and a posted reversal. The examples should show both the transaction history and the balance each product surface displays.
