Double-entry bookkeeping

Double-entry bookkeeping is the rule that every financial event is recorded as at least one debit and at least one credit of equal value, so the books always balance. The rule was described by Luca Pacioli in 1494, and it remains the foundation of every bank ledger, every payment engine and every reconciliation. A debit increases an asset or an expense, or decreases a liability, while a credit increases a liability or income, or decreases an asset. If it does not, a posting is missing, duplicated or wrong, and the error must be found before the books can close. Source: Bank for International Settlements, Committee on Payments and Market Infrastructures; International Financial Reporting Standards, conceptual framework. The reason double entry matters for payments is that a payment is never a single entry. When a customer pays EUR 10,000 to a supplier at another bank, the debtor bank debits the customer deposit account and credits its reserve account at the central bank, and the creditor bank debits its reserve account and credits the supplier deposit account. Each bank posts two entries, and the four entries together describe the whole payment. A system that posts the debit twice has destroyed money on its books, and the customer will complain that the balance is wrong. Double entry is therefore a control, not just an accounting convention, and it is the first control that a payment engine must pass. A worked example with real numbers shows the rule in action. Bank A customer holds EUR 50,000 and pays EUR 12,000 to a customer of Bank B. Bank A posts debit customer deposit EUR 12,000 and credit reserve account EUR 12,000, so the customer balance falls to EUR 38,000 and the reserve balance falls by EUR 12,000, and the Bank A books still balance. Bank B posts debit reserve account EUR 12,000 and credit supplier deposit EUR 12,000, so the supplier balance rises by EUR 12,000 and the Bank B books still balance. The central bank posts debit Bank A reserve EUR 12,000 and credit Bank B reserve EUR 12,000. A payment that cannot be traced this way has a missing posting. The parties that rely on double entry are the bank finance team, the auditors, the regulators and the operations team, and each uses it differently. Finance uses it to produce the balance sheet and the profit and loss account, and to prove that the bank assets equal its liabilities plus capital. Auditors use it to trace a payment from the instruction to the ledger, and to test that the controls work. Regulators use it to check capital adequacy, because the balance sheet is the source for the capital calculation. A business analyst who cannot state the debit and the credit for a payment cannot write a requirement that finance can approve. Failure in double entry is a break, and the break has a standard handling. If a payment is credited twice, the customer receives the money twice, and the duplicate must be reversed with a correcting entry, not by deleting the original, because the audit trail must show both the error and the correction. If a payment is posted to the wrong account, the correction is a reversal of the wrong posting and a new posting to the right account, with both entries visible. Deleting a posting is never permitted, because it destroys the audit trail, and the regulator and the auditor will treat a deleted posting as a control failure. The effect on the bank, the customer and operations is that double entry is the last line of defence. For the customer, it means the balance is the result of postings that can be explained, entry by entry, and a disputed balance can be traced to the payment that caused it. For the bank, it means the balance sheet is provable, and the capital and liquidity calculations rest on postings that balance. For operations, it means every payment, return, recall, fee and interest adjustment has a defined debit and credit, and the end of day close is the proof that all of them were posted. A payment product that cannot state its postings is not ready for a finance review, however good its message handling is, because finance owns the ledger and will block the launch. For a business analyst, product owner or subject matter expert, the test is to write the debit and the credit for every event in the product, before writing the message flow. Ask what is debited, what is credited, for how much, in which currency, and on which value date, for a payment, a return, a recall, a fee, a charge and an interest adjustment. Ask what happens when one side posts and the other fails, and how the system recovers without deleting a posting. Ask how the trial balance is proved at the end of the day, and who signs it off. The ISO 20022 messages carry the instruction, but the ledger carries the money, and the two must be linked by a posting reference, so that any message can be traced to its postings and any posting can be traced to its message. Double entry also explains why a payment engine and a ledger are separate systems with a defined interface. The payment engine validates, screens, routes and sends the message, and it raises a posting event for each step. The ledger consumes the posting event, validates that the debit equals the credit, and posts to the accounts, or rejects the event if it does not balance. A hub that posts directly to the ledger without a posting event, or that posts without checking that the debit equals the credit, has no control, and the first duplicate or missing posting will be discovered by the customer, not by the system. Takeaway: every payment is at least one debit and one credit of equal value, and the books must balance at every step, in every bank and at the central bank. A break is a debit without a credit, and it is corrected by a reversing entry, never by deleting the original. State the debit and the credit for every payment, return, recall, fee and interest adjustment before writing the message flow. Further reading: Luca Pacioli, Summa de arithmetica, 1494, on double-entry bookkeeping; Bank for International Settlements, Committee on Payments and Market Infrastructures, A glossary of terms used in payments and settlement systems. Last reviewed 7 November 2026.