Ledger versus available balance

The ledger balance and the available balance are two different numbers for the same account, and the difference between them is the money that is already committed but not yet settled. The ledger balance is the balance after all posted entries, including every debit and credit that has been booked to the account. A customer who sees a ledger balance of GBP 10,000 and an available balance of GBP 8,500 has GBP 1,500 that is committed and cannot be spent, and a payment of GBP 9,000 will be rejected even though the ledger balance appears to cover it. Source: Bank for International Settlements, Committee on Payments and Market Infrastructures; card scheme authorisation rules and core banking practice. The items that sit between the two balances each have a name and a lifecycle. A card authorisation hold reserves funds when a card payment is authorised, and it is released when the clearing file arrives, when the merchant reverses it, or when it expires, typically after 7 to 30 days depending on the merchant type and the scheme rules. A cheque deposit hold reserves funds until the cheque clears, because the paying bank may still return it. A sanction or fraud hold freezes the whole balance or a part of it, and it is released only by the compliance or fraud team, not by the customer. Each hold must be visible to the customer, with a reason and an expiry. A worked example makes the two balances concrete. A customer holds a current account with a ledger balance of EUR 20,000 on Monday morning. The customer pays EUR 3,000 for a hotel by card, and the authorisation hold reduces the available balance to EUR 17,000, while the ledger balance stays at EUR 20,000. The customer then instructs a EUR 18,000 supplier payment, which is accepted, and the available balance falls to EUR 2,000. When the hotel clearing file arrives for EUR 2,800, the hold is replaced by a debit of EUR 2,800, the ledger balance falls to EUR 22,200, and EUR 200 of the hold is released back to the available balance. Every step is a different posting, and the customer statement must explain each one. The parties and the systems that maintain the two balances are the core banking system, the card authorisation system and the payment hub. The core banking system holds the ledger balance and posts debits and credits. The card system holds the authorisation holds and sends the clearing file. The payment hub holds future dated instructions and pending payments, and it tells the core system how much to reserve. A channel that shows only the ledger balance will generate complaints, and a channel that shows only the available balance will hide the posted position, so both must be shown, with the difference explained. Failure happens when the two balances disagree, and the disagreement has real consequences. A hold that is released too early, before the clearing file arrives, lets the customer spend the same money twice, and the bank bears the loss when the clearing file arrives and the account goes overdrawn. A payment that is authorised against the ledger balance instead of the available balance will be accepted and then fail at settlement, and the customer will have been told the payment succeeded when it did not. A fraud hold that is released by the wrong team, or a sanction hold that is released at all, is a compliance breach, not a customer service error. The effect on the bank, the customer and operations is direct. For the customer, the available balance is the money that can be spent, and the ledger balance is the record of what has been posted, and the customer needs both, with the holds explained. For the bank, the available balance is the control that prevents overdrafts, duplicate spending and fraud, and it is the balance that the payment authorisation decision must use. A business analyst must specify which balance each decision uses, because authorising against the wrong balance is a design error that will appear in production as failed payments and customer complaints. For a business analyst, product owner or subject matter expert, the test is to walk a single payment through both balances and name every hold, its owner, its expiry and its release trigger. Ask what happens when a card authorisation is never cleared, when a cheque is returned after the hold is released, when a future dated payment is cancelled, and when a fraud hold is placed on an account that also has a direct debit due. The ISO 20022 camt.052 intraday report can carry the ledger balance and the available balance as separate balance types, and the mapping from the core system to the message must be specified, because a customer who receives a camt.053 statement with only one balance cannot reconcile it. Two mistakes are common and must be avoided. The first is to treat the available balance as the ledger balance in a requirement, which causes the payment engine to authorise payments that will fail at posting, and the failure will be discovered by the customer, not by the test team. The second is to hide holds from the customer, which causes complaints, disputes and regulatory attention, because the customer has a right to know why money that appears to be theirs cannot be spent. The correct design shows both balances, lists the holds with merchant, amount and expiry, and provides a release process that is owned, timed and audited. A payment product that cannot explain the difference between its two balances is not ready for launch. Takeaway: the ledger balance is what has been posted, the available balance is what can be spent, and the difference is holds, pending authorisations, uncleared funds and future dated instructions. Authorise against the available balance, show both balances with the holds explained, and give every hold an owner, an expiry and a release trigger. Further reading: Bank for International Settlements, Committee on Payments and Market Infrastructures, A glossary of terms used in payments and settlement systems; ISO 20022, camt.052 and camt.053 balance types; Visa and Mastercard authorisation and clearing rules. Last reviewed 7 November 2026.