Ledgers, Journals and Accounts

4.0 What this chapter gives you#

1. You will be able to explain why a bank’s general ledger contains no account with your name on it, and where your own balance actually lives.
2. You will be able to describe the difference between the journal and the ledger — what happened against where we stand — and say why a business of any size needs both shapes of the same information.
3. You will be able to say what a chart of accounts is for, why it is designed backwards from the returns it must produce, and what its segments typically carry.
4. You will be able to separate recording, posting, settlement and valuation as four events with four timings, and use booking date and value date correctly.
5. You will be able to explain a card memo post: why the available balance drops, why the ledger balance does not, and why the amount can change before the real entry lands.
6. You will be able to answer “we missed the cut-off” with the only useful follow-up question, given that CHAPS, Bacs, the card schemes and the bank’s own close are four different moments.
7. You will be able to give four independent reasons a bank must have an end of day, and describe the close-of-business sequence from stopping postings to rolling the business date.
8. You will be able to explain why immutability is a set of controls rather than a property of the technology, and what to ask a vendor who sells you an “immutable ledger”.
9. You will be able to distinguish a reversal from an adjustment, say when each is appropriate, and explain why amendment in place is never legitimate.
10. You will be able to explain why a payment often cannot be cancelled, using camt.056, camt.029 and pacs.004, or the ISO 8583 reversal messages, to show that not one of them is an edit.

The previous chapter established that every payment is two facts rather than one, and that the two facts must agree. This chapter is about where those facts are written down, in what order, under what names, and according to what rules — because a principle that is never implemented is just a slogan, and double entry is implemented with almost fanatical specificity.

The distinction matters more than it sounds. It is possible to understand double entry perfectly and still have no idea what a bank’s books actually look like, in the same way that it is possible to understand arithmetic and have no idea how a payroll system is organised. The discipline is the easy part. The filing is the hard part, and the filing is where the interesting failures live.

There is also a piece of misinformation to clear away first. Most people, if they think about it at all, imagine that somewhere inside their bank there is a very large table with one row per customer, and that their balance is the number in that row. There is no such table. There is a system that holds customer balances, certainly, but it is not the bank’s ledger — it is one of a dozen feeder systems whose totals are summarised into the ledger. The ledger itself has no idea who you are. It knows only that the bank owes something in the order of fourteen billion pounds to a category of people called personal current account holders, and it knows that figure to the penny.

The rest of this chapter explains how that arrangement works, why it is arranged that way, what “end of day” means to an institution that never actually closes, and why the single most important rule in the whole apparatus is that you never rub anything out.

The plain version#

Go back to Ada’s village shop from the first chapter, and imagine that it has done rather well.

Ada now has four shops, a delivery van, eleven staff, an accountant who visits on Thursdays, and about six hundred customers who run accounts with her. The notebook under the counter stopped working around the time she opened the second shop, for a reason that is entirely practical: a single notebook, written in the order things happen, is wonderful for answering the question what happened today and hopeless for answering the question how much does Tom owe me. To answer the second question from a notebook you would have to read every page since the beginning of time and add up all the Toms.

So Ada does what every business in history has eventually done. She splits her record-keeping into two shapes of the same information.

The diary and the folders#

The first shape is a diary. Every time anything happens, someone writes it down in the order it happened, with the date, the amount, and what it was for. Nothing is ever skipped and nothing is ever written out of order. This is the record of events, and it is complete. In bookkeeping this is called the journal, and older British businesses called it the day book.

The second shape is a set of folders. There is a folder for Tom, a folder for Sam, a folder for the till, a folder for the van, a folder for wages, a folder for rent, a folder for everything Ada cares about separately. Whenever something goes into the diary, it also gets copied into the folders it affects — and because of double entry, it always affects exactly two of them at minimum, one on each side. This set of folders is called the ledger, each folder is called an account, and the act of copying an event from the diary into the folders is called posting.

The diary answers what happened. The folders answer where do we stand. They contain identical information arranged for two different questions, and a business needs both.

There is a third document, less glamorous and quietly essential: the list of which folders exist. Ada cannot have her Tuesday assistant inventing a folder called “bits and bobs” whenever something puzzling arrives, because in a year nobody will know what is in it. So there is a fixed, numbered, agreed list of every folder that may be used, and if something does not fit any of them, it goes into a holding folder and somebody senior sorts it out. That list is the chart of accounts, and the holding folder is the suspense account.

A day at Ada’s Bank#

Now make Ada a banker, because the arithmetic is the same and the example is more useful.

Ada’s Bank opens on Monday morning with the following position. It has £40,000 of banknotes in its vault, £45,000 sitting in its account at the central bank, and £430,000 of loans it has made to people. Against that, it owes £500,000 to its depositors, and the £15,000 left over belongs to Ada. Notice that the two sides already agree: £40,000 plus £45,000 plus £430,000 is £515,000, and £500,000 plus £15,000 is £515,000.

Four things happen during the day, and one thing happens because the day happened at all.

Tom brings in £300 in cash. The vault goes up by £300 and what the bank owes Tom goes up by £300. Two facts.

Priya pays Sam £120, both of them being Ada’s customers. What the bank owes Priya falls by £120; what it owes Sam rises by £120. Two facts, and notice that from the bank’s point of view nothing at all has changed in total. It owed £500,000 before and it owes £500,000 after. The money did not go anywhere. The label on it changed.

Sam takes £200 out of the cash machine. The vault falls by £200 and what the bank owes Sam falls by £200.

Ada charges Priya a £5 monthly account fee. What the bank owes Priya falls by £5, and the bank’s income rises by £5. This is the first entry in the day that makes Ada better off rather than simply rearranging her obligations.

And then the day itself does something. Ada’s £430,000 of loans earn interest at 5% a year, and one day has passed. Five per cent of £430,000 is £21,500 a year, which is £58.90 for the day. Nobody has paid it yet, and nobody will until the borrowers’ payment dates, but Ada has earned it, so it goes in the books: the bank is owed another £58.90, and the bank’s income rises by £58.90.

That last one is worth pausing on, because it is the entry that people find strangest and it explains a great deal about why banks have an “end of day” at all. Nothing happened. Nobody did anything. No customer touched anything. But time passed, and time passing is itself an economic event when you are in the business of lending money. Somebody or something has to notice that the day has ended and write down what the ending of the day earned. That is a job, it happens once per day, and it is one of the reasons the concept of a banking day exists.

Proving it adds up#

At the end of Monday, Ada’s accounts stand like this. On the left-hand side are the things the bank has and is owed. On the right-hand side are the things the bank owes and has earned.

The two columns agree, to the penny. This list is called the trial balance, and producing it is the oldest sanity check in commerce. If the columns do not agree, something has gone wrong and you know it immediately, before it turns into a mystery.

Work through the arithmetic once and it stops feeling like magic. The vault is £40,000 plus Tom’s £300 minus Sam’s £200. Deposits are £500,000 plus Tom’s £300 minus Sam’s £200 minus Priya’s £5 fee — Priya’s payment to Sam nets to nothing because both are Ada’s customers. Every single line came from an event that was written down twice, once on each side, and so the totals cannot help but match.

The rule about the eraser#

Now the most important part of this chapter, and the part that governs everything that comes later in this book.

On Tuesday, Ada’s assistant discovers that £250 which arrived on Monday for a customer called Priya Shah was credited to a different customer, also called P. Shah. It is an honest mistake and it needs fixing.

The wrong way to fix it — the way that feels natural, and the way every spreadsheet in the world invites you to — is to find Monday’s entry, cross out the wrong name, and write the right one. Two seconds, problem solved, books still balance.

Ada’s books do not permit this, and no proper set of books anywhere has permitted it for five hundred years. What actually happens is that three separate things are written down, all dated Tuesday, none of them touching Monday’s page.

First, an entry that is the exact mirror image of Monday’s mistake: take £250 back off the wrong P. Shah and put it back where it came from. This is called a reversing entry, and it does not make Monday disappear. Monday’s entry is still there, still visible, still wrong. It has simply been cancelled out by an equal and opposite entry the following day.

Second, the correct entry: take the £250 out of the holding account and credit it to Priya Shah, where it should have gone in the first place.

Third — and this is the part that separates a real ledger from a tidy one — a note, attached to both of the above, saying who found the error, who authorised the correction, when, and why.

Six lines of writing where an eraser would have taken none. This looks like bureaucratic self-punishment until you consider what the eraser costs you. Once erasing is permitted, no statement of the books is ever evidence of anything. If Monday’s page can be quietly changed on Tuesday, then Monday’s page proves nothing about Monday, and neither does any other page. The auditor cannot check the books, because the books are whatever the last person to touch them says they are. The customer cannot dispute a figure, because there is no fixed figure to dispute. And someone stealing money can hide it perfectly by simply amending history.

The reversing entry is therefore not an accounting formality. It is the mechanism by which a set of books becomes evidence rather than opinion. And once you have seen it, you will see it everywhere in payments, because the same logic applies at every level of the system. A refund is not the deletion of a purchase; it is a second, opposite transaction. A cancelled bank transfer is not an unsent message; it is a new message asking the other bank to send the money back. Nothing is ever undone. Things are only ever answered.

Where the plain version stops being true#

The shop is a good model and it will get you through a dinner party. Four things about it are wrong in ways that matter.

First: there is no folder with your name on it in the general ledger. There never was.

The plain version implied a single ledger containing an account for each customer. Real institutions do not work this way and could not. A bank with eight million current accounts does not maintain eight million accounts in its general ledger; the general ledger might contain a few thousand accounts in total, and one of them will be something like “personal current accounts, sterling, retail division” holding a single aggregate balance of several billion pounds.

Your individual balance lives in a sub-ledger — in this case the deposit system, which is part of what the industry calls the core banking platform. The sub-ledger holds the detail: your account, your balance, your transactions, your overdraft limit. The general ledger holds the summary, in a control account, and the two are reconciled, usually daily. If the deposit sub-ledger says the bank owes £14,208,331,402.71 across all personal current accounts and the general ledger control account says £14,208,331,398.44, there is a problem, it is a serious one, and somebody’s afternoon is now about finding £4.27.

This is not merely a technical arrangement; it changes what questions each system can answer. The general ledger cannot tell you anything about you. It can tell you what the bank owes in total, by product, by currency, by legal entity, by branch. That is what it is for, because that is what regulatory returns, statutory accounts and capital calculations are built from. Confusing the two leads people to make wrong assumptions about what a bank can look up and how fast.

Second: recording, posting, settling and valuing are four different events, and they routinely happen on different days.

The plain version used “write it down” and “post it” almost interchangeably. In a real system they are distinct stages with distinct timestamps and distinct meanings, and the gaps between them explain a large fraction of the questions customers ask.

An entry is recorded when it is captured into the system. At that stage it may exist in an unposted state — validated or not, awaiting authorisation, awaiting a matching leg. It is posted when it is committed to the account and actually changes the balance. It carries a booking date, being the day the bank’s books recognise it, and a value date, being the day from which it counts for interest and availability. Those two dates are frequently different. A cheque paid in on Friday may be booked on Friday and valued on the following Wednesday. A payment made on a Saturday may be booked with Monday’s date because Saturday is not a business day in the bank’s accounting calendar.

And settlement — the moment the two banks are actually square with each other, usually across accounts at the central bank — is a fourth event with its own timing, which frequently happens after the customer has seen the money. Chapter seven is entirely about the difference between clearing and settlement, and the reason it needs a chapter is that the two are conflated constantly, including inside banks.

The most visible consequence of this is the card authorisation. When you tap for £43.20 in a supermarket, no accounting entry is posted anywhere. What happens is a memo post: your available balance drops by £43.20 while your ledger balance is untouched, because no double entry has occurred. The real posting happens when the transaction clears, typically one to three business days later, at which point the memo hold is released and a genuine entry lands. This is why the amount can change between the two — a restaurant tip, a fuel pump, a hotel — and why the date on your statement is sometimes not the date you were in the shop.

Third: “end of day” is not a moment when the bank stops, and there is more than one of them.

The shop closes at six. A bank does not close at all — Faster Payments has run around the clock since 2008, cash machines never sleep, and card authorisations arrive at four in the morning from customers in other time zones.

What a bank has instead is a business date, which is a label rather than a wall clock. Postings are stamped with a business date, and at some point the system performs a set of end-of-day procedures and rolls the business date forward. Transactions arriving after the roll get tomorrow’s date even though it is still today outside. The batch is a logical boundary, not a physical shutdown, and for a bank operating in several countries there may be several business dates alive at once across different books.

Worse, there is no single cut-off, because the bank sits inside other people’s calendars as well as its own. In the United Kingdom, CHAPS opens at 6am and closes at 6pm on working days, with customer payments required by 5.40pm. Bacs input files must reach the scheme between 07.00 and 22.30 on input day. Card schemes have their own daily cut-offs which do not align with either. Each of those is somebody’s end of day, none of them is the same moment, and the bank’s own accounting close is yet another. When somebody in payments says “we missed the cut-off”, the useful follow-up question is always whose.

Fourth: immutability is a set of controls, not a property of the technology.

The plain version said you never rub anything out. That is the rule. It is not, however, a law of physics.

Underneath almost every general ledger in the world sits a perfectly ordinary relational database in which any sufficiently privileged person can execute an update statement against a posted journal line. What prevents it is not that the operation is impossible but that it is prohibited, monitored, and detectable — application designs that only ever append, database permissions that deny direct write access to production financial tables, audit logging that records every access, hash-chaining or sequence numbering that makes gaps visible, and separation of duties so that the person who creates a journal entry is never the person who approves it.

This matters practically, because software is sold on the claim of being an “immutable ledger” when what is meant is that the vendor’s own screens have no delete button. That is a real and useful control, but it is a control, not a guarantee, and anyone assessing a system should ask what stops a database administrator, what stops a support engineer with an emergency fix script, and what would make either visible afterwards. The answer is usually a combination of restricted access, mandatory approval workflow, and independent reconciliation — and if the answer is “nobody would do that”, the system does not have immutability, it has trust.

There is also a narrower correction. Reversal is not the only permitted repair. A reversing entry restores the position exactly and then the correct entry is made afresh, which is preferred because it preserves the gross record of what was originally done. An adjusting entry posts only the net difference, which is shorter but leaves the original figure standing uncorrected in the account. Both are legitimate, both are used, and the choice depends on materiality, on whether the accounting period has closed, and on the institution’s own policy. What is never legitimate is amendment in place.

The technical version#

Accounts and their classes#

An account is a classification bucket with a running balance. Every account belongs to one of five classes, and the class determines which side of the entry increases it.

The perpetual confusion for non-accountants is that a customer deposit is a liability, so the bank credits your account when it owes you more. Your statement is written from the bank’s point of view, which is why a credit is money in and a debit is money out, and why the words appear reversed relative to the bank’s own internal usage in ordinary conversation. Chapter ten returns to this, at length, because it is the single most common source of misreading a statement.

The fundamental identity that all of this enforces is that assets equal liabilities plus equity, extended within a period to include income and expense, which are closed to retained earnings at period end.

The chart of accounts#

The chart of accounts is the controlled list of every account that may be posted to, together with its class, its posting rules and its reporting mappings. In an institution of any size it is not a flat list of numbers but a structured code, typically composed of independent segments.

A realistic account code in a bank might carry a legal entity identifier, a natural account, a currency, a product or portfolio code, a cost or profit centre, and an intercompany counterparty segment. The natural account alone might be six or seven digits; the full posting string might be thirty characters or more. This structure exists because the same economic fact needs to be sliced several ways: interest income needs to be reportable by product for management, by entity for statutory accounts, by currency for treasury, and by counterparty type for regulatory returns, and it is far cheaper to encode all of that on the entry than to reconstruct it later.

The chart is not designed in isolation. It is designed backwards from the reports it must produce. In the United Kingdom those include the company’s statutory accounts under the Companies Act 2006 and the applicable accounting framework, the prudential and financial reporting returns required by the Prudential Regulation Authority, and the statistical returns required by the Bank of England. In the European Union the equivalent frameworks are the European Banking Authority’s COREP, covering own funds and prudential metrics, and FINREP, covering financial information anchored to the accounting figures. A chart of accounts that cannot be mapped cleanly to the required returns is not a stylistic problem; it is an annual manual reconciliation exercise for the rest of the institution’s life.

Multi-currency handling adds a further layer. Accounts are held in a transaction currency and translated into the entity’s functional currency for reporting, with periodic revaluation of monetary balances and the resulting gains or losses posted to defined revaluation accounts. The revaluation run is another of the jobs that must happen at a defined point in the day, using a defined rate, from a defined source.

Journals, journal entries and journal lines#

A journal is the chronological record. A journal entry is the atomic unit of posting: a header describing the event and two or more lines describing its effects, whose debits and credits must sum to zero before the entry is accepted. The system rejects an unbalanced entry outright, which is the single most valuable structural property of double entry as implemented in software.

A minimally serious journal entry carries, at header level, a unique identifier, the source system, the journal category or type, the business date, the currency, the description or narrative, the creating user or process, the approving user, the approval timestamp, and a reference to the originating business object such as a payment identifier or a card transaction identifier. At line level it carries the full account code string, the debit or credit indicator, the transaction amount, the functional-currency amount and the rate used, the value date if it differs from the business date, and a line-level narrative.

Journals divide broadly into automatic and manual. Automatic journals are generated by feeder systems — deposits, lending, cards, treasury, payments — from business events, according to fixed accounting rules held in an accounting rules engine that maps event types to debit and credit account pairs. Manual journals are typed in by the finance function to record accruals, provisions, reclassifications and corrections. Manual journals are the ones auditors care about, because they are the ones a human chose. International Standard on Auditing 240, which governs the auditor’s responsibilities relating to fraud, requires auditors to test the appropriateness of journal entries recorded in the general ledger — with particular attention to entries made outside the normal course of business, entries posted at period end, and entries made by people who do not usually post journals.

Recurring journals — accruals, prepayments, depreciation — are templated and generated on a schedule. Reversing journals are a special case worth naming: an accrual posted at month end is very often flagged to reverse automatically on the first day of the following month, so that when the actual invoice arrives it can be posted gross without double counting. This is an entirely routine use of reversal that has nothing to do with error correction.

Sub-ledgers and control accounts#

The general ledger is fed by sub-ledgers, each of which holds transaction-level detail for one domain and reports a summary into a control account.

British practice historically named these the sales ledger and the purchase ledger, with the general ledger itself called the nominal ledger — terminology still common in UK accounting software and worth recognising when it appears.

The sub-ledger to general ledger reconciliation is the control that binds the two together, and in a bank it is performed daily rather than monthly. Its logic is simple: the sum of all detail balances in the sub-ledger must equal the balance of the corresponding control account. Any difference is a break, and breaks are aged, categorised and escalated. Where an item cannot be resolved immediately it is parked in a suspense account — a temporary general ledger account for items that are known to have occurred but are not yet correctly classified. A suspense account that is cleared daily is housekeeping. A suspense account with a growing balance and items aged over ninety days is one of the clearest early indicators that an institution’s operations are failing, and it is precisely what supervisors and auditors look for.

Posting versus recording, precisely#

The lifecycle of an entry runs: capture, validate, authorise, post, report. Only the fourth step changes a balance.

The distinction is visible on the wire in ISO 20022 cash management reporting. The message camt.053, formally BankToCustomerStatement, is the end-of-day statement covering a completed business day. Each entry within it carries a status; the value BOOK indicates that the entry has been booked to the account, as opposed to being merely pending. Each entry also carries BookgDt, the booking date, and ValDt, the value date, as separate elements — the standard treats them as two different facts about the same entry precisely because they routinely differ. Statement-level balances are typed by code, with OPBD for the opening booked balance and CLBD for the closing booked balance, and separate codes exist for available balances, which is the standard’s way of making explicit the ledger-versus-available distinction introduced in chapter two.

The companion messages complete the picture. Camt.052, BankToCustomerAccountReport, carries intraday reporting, including items that are not yet booked. Camt.054, BankToCustomerDebitCreditNotification, notifies the account owner of individual debit or credit entries as they occur. In the older SWIFT FIN world the equivalents are MT940 for the end-of-day customer statement and MT942 for the interim transaction report, in which the same information is encoded positionally inside fixed-format tags — a Tag 61 statement line packs the value date and entry date into the first ten characters, which is compact, unforgiving, and the reason the industry is migrating.

The trial balance, and what it does not prove#

The trial balance is the list of every account’s closing balance with debits in one column and credits in the other. It is produced as a matter of routine, at least monthly and in banks daily, and its agreement is a necessary condition for the books being correct.

It is emphatically not a sufficient one. A trial balance will balance perfectly in the presence of at least four distinct classes of error. An entry omitted entirely, both legs missing, leaves the totals untouched. An entry posted to the wrong account of the same class — Priya’s £250 credited to the wrong customer — leaves the totals untouched, which is exactly the error the plain version used. An entry posted twice in full leaves the totals untouched. And compensating errors, where two mistakes happen to offset, leave the totals untouched. A balanced trial balance means the arithmetic is consistent. It says nothing whatever about whether the entries describe reality.

This is why reconciliation exists as a separate discipline from bookkeeping, and why chapter six of volume five is devoted to it. Balancing proves internal consistency. Reconciliation proves agreement with an external record — the counterparty bank’s statement, the scheme’s settlement file, the central bank’s account. The two controls catch different things and neither substitutes for the other.

End of day, and why batch processing exists at all#

Modern engineers, raised on event streams and continuous deployment, tend to treat batch processing as a relic. It is not. There are at least four independent reasons a bank must have a defined daily boundary, and none of them is about the age of the software.

The first is that some financial facts are defined per day and cannot exist without a day. Interest accrual is the obvious case: interest accrues on a balance for a period, and the period has to end for the accrual to be computed. So do daily fee applications, daily limit resets, daily average balance calculations, and the ageing of arrears. A system with no end of day cannot compute these because the input to the calculation does not exist until the day is closed.

The second is that the bank sits inside external cycles that are batch by design. The Bacs three-day cycle, run by Pay.UK, is the clearest example in Britain: files are submitted on input day, with transmission to Bacs permitted between 07.00 and 22.30; they are processed and distributed to the receiving payment service providers on processing day; and on entry day, day three, the payments are simultaneously credited to the recipients’ accounts and debited from the originator’s. That structure is not negotiable by an individual bank, and a bank’s own processing has to align to it.

The third is settlement. Obligations between banks are settled at the Bank of England across settlement accounts in the RTGS service, and the settlement arrangements are themselves periodic. CHAPS settles individually and in real time on a gross basis throughout the day, between 6am and 6pm. Bacs settles on a net basis once each business day. The Faster Payments Service, despite running around the clock for customers, settles net three times each business day. The Image Clearing System for cheques runs a two-day cycle and settles net once each business day. LINK, Visa Europe and Mastercard Europe settle 24-hour cycles, with cycles falling on weekends and public holidays settling on the following business day. Every one of those is a boundary the bank’s books must respect.

The fourth is that reporting requires a frozen point. A regulatory return, a statutory account, a customer statement and a management report are all statements about a defined moment. If the underlying figures never stop moving, no two reports of the same period will ever agree, and the institution loses the ability to say anything definite about itself.

In practice this is implemented as a sequence of scheduled jobs, known in core banking platforms as close of business or COB. Temenos, whose Transact platform is one of the most widely deployed core banking systems in the world, structures this as pre-COB, COB and post-COB stages. The typical sequence within it is: stop accepting new postings for the current business date; complete or fail any in-flight transactions; execute standing orders and scheduled payments due today; calculate and post interest accruals; apply fees and charges; revalue foreign currency positions; run limit and arrears checks; generate customer statements; extract summarised postings into the general ledger; produce the trial balance; run the sub-ledger reconciliations; produce regulatory and statistical extracts; take the backup; and finally roll the business date.

The reason this sequence is treated with something close to reverence in banking operations is that it is both mandatory and time-boxed. It must complete before the next business day’s processing begins, which in a 24/7 institution means it must complete inside a window measured in hours while customers are still transacting. If COB does not finish, statements do not generate, interest does not post, files do not go to the schemes, and the bank enters the next day without knowing its own position. Delayed or failed end-of-day runs are among the most serious incidents a bank can have, and they are the reason batch scheduling and workload automation remain specialist and well-paid disciplines.

The consequences of getting this wrong are not theoretical. On 20 December 2022 the Financial Conduct Authority and the Prudential Regulation Authority jointly fined TSB Bank plc a total of £48,650,000 — £29,750,000 by the FCA and £18,900,000 by the PRA — for operational risk management and governance failures relating to the bank’s 2018 IT migration programme, in which customers lost access to accounts and the bank lost the ability to present them with reliable information about their own money. The fine was for the management of the risk, not for the technology. That is the correct place to put it.

Immutability, reversal, and why payment systems inherit the rule#

The governing principle is that a posted entry is never amended and never deleted. Corrections are made by further entries.

The legal underpinning in the United Kingdom starts with the Companies Act 2006. Section 386 requires every company to keep adequate accounting records, defined as records sufficient to show and explain the company’s transactions, to disclose with reasonable accuracy at any time the financial position of the company at that time, and to enable the directors to ensure the accounts comply with the Act. Section 386(3)(a) specifies that those records must contain “entries from day to day of all sums of money received and expended by the company and the matters in respect of which the receipt and expenditure takes place”. Section 388 requires records to be preserved for three years from the date they are made for a private company, and six years for a public company.

For regulated firms the requirement is stricter. The FCA’s Senior Management Arrangements, Systems and Controls sourcebook, at SYSC 9.1.1R, requires a firm to “arrange for orderly records to be kept of its business and internal organisation, including all services and transactions undertaken by it, which must be sufficient to enable the FCA to monitor the firm’s compliance with the requirements under the regulatory system, and in particular to ascertain that the firm has complied with all obligations with respect to clients”. SYSC 9.1.2R requires a common platform firm to retain records relating to its MiFID business for at least five years. A record that can be silently altered is not a record for these purposes.

The mechanics of correction have names. A reversal, known on the continent and in a good deal of banking software by the German term storno, posts the exact contra of the original entry: same accounts, same amount, opposite sides, with an explicit reference linking it to the entry being reversed. The original and the reversal both remain visible. An adjustment posts only the net correction. Reversal is generally preferred for erroneous postings because it preserves the gross history and makes the sequence of events legible; adjustment is used where the original entry was correct in kind but wrong in amount, and where the period is still open.

Around both sits the audit trail: who created the entry, who approved it, when, from what terminal, under what authority, and with what stated reason. Segregation of duties — maker and checker as different people, with the system enforcing it — is the control that makes the audit trail meaningful, since an audit trail showing that one person did everything is a record of a risk rather than a mitigation of it.

Now the important part for this book. The same principle governs payment networks, and for the same reason: a message that has been sent to another institution cannot be unsent, because the other institution has already acted on it.

In the card world, ISO 8583 provides message type indicators 0400 for an acquirer reversal request and 0420 for an acquirer reversal advice. A reversal does not delete the original authorisation; it is a separate message referring to it, and it must be matched to it by the identifiers described in volume three. A refund is not a reversal at all — it is a fresh transaction in the opposite direction, submitted through the normal clearing process, which is precisely why a refund takes days when the original purchase appeared to take seconds. Nothing is being undone. A second thing is being done.

In the ISO 20022 world the vocabulary is explicit about this. Camt.056, the FIToFIPaymentCancellationRequest, is a request to cancel a payment — it can be refused, because the receiving institution may already have paid the money away. Camt.029, ResolutionOfInvestigation, carries the answer. And pacs.004, PaymentReturn, is the message that actually sends the funds back: a new payment, in the opposite direction, referencing the original. Three messages, and not one of them is an edit.

In Bacs the same logic appears as an operational rule rather than a message. Once a submission has passed its cut-off, the individual payments within it cannot be removed; a payment can be recalled only before a specified deadline through the originator’s payment service provider, and after entry day the remedy lies outside the clearing — through the Direct Debit Guarantee for a collection, or through an indemnity claim for a credit sent in error.

This is why “can you cancel that payment?” is so often answered with an apologetic no. It is not obstruction and it is not usually a technical limitation. It is the same rule as the one that stops Ada rubbing out Monday, applied across institutional boundaries, where the stakes are higher and the parties do not report to the same management.

What this means if you are building something#

Five consequences follow directly, and each of them is a mistake that is expensive to discover late.

Model postings as an append-only sequence and derive balances from them. If your data model has an UPDATE balances SET amount = ? in it anywhere, you have built a system that cannot explain itself, and an unexplainable balance is a regulatory problem before it is an engineering one.

Give every entry at least three dates and never conflate them: the timestamp at which the event occurred, the business date under which it is booked, and the value date from which it counts. Store the timezone explicitly. A great many reconciliation breaks are timezone bugs wearing a costume.

Make reversal a first-class operation with a mandatory link to the entry being reversed, and make it the only way an entry can be neutralised. If a support tool needs to fix something, it should issue a reversal through the same path as everything else, under the same approval controls, and appear in the same audit trail.

Reconcile sub-ledger to general ledger on a fixed cycle, automatically, with breaks aged and escalated. Do not wait for month end. In payments, a break that is one day old is a bug report and a break that is thirty days old is an investigation.

And define your business date explicitly, in one place, as a value the system knows about, rather than letting it be implied by whatever the server clock says. Every scheduled job, every report, every statement and every extract should agree on which day it is, and they will not do so by accident.

The next chapter takes the aggregate view that the general ledger produces and asks what it adds up to. A bank’s balance sheet is not a summary of a bank; it is a description of what a bank fundamentally is, and once the ledger machinery is understood, the balance sheet stops being an accounting artefact and becomes the clearest available answer to the question of why your asset is somebody else’s debt.

4.98 Common wrong ideas#

1. Wrong: somewhere inside your bank there is a very large table with one row per customer, and that table is the ledger. Right: your balance lives in a sub-ledger, and the general ledger holds only an aggregate control account for a whole product, currency and division.
2. Wrong: the general ledger can look you up. Right: it can tell you what the bank owes in total by product, currency, legal entity and branch, because that is what regulatory returns, statutory accounts and capital calculations are built from.
3. Wrong: recording an entry and posting it are the same thing. Right: the lifecycle runs capture, validate, authorise, post, report, and only the fourth step changes a balance.
4. Wrong: the booking date and the value date are the same date. Right: they are two different facts about the same entry, which is why ISO 20022 carries BookgDt and ValDt as separate elements.
5. Wrong: tapping your card posts an accounting entry. Right: it creates a memo post that reduces the available balance while the ledger balance is untouched, with the genuine posting arriving one to three business days later and sometimes at a different amount.
6. Wrong: a bank has an end of day, singular. Right: CHAPS, Bacs, the card schemes and the bank’s own accounting close are separate cut-offs, so the useful follow-up to “we missed the cut-off” is always whose.
7. Wrong: batch processing is a relic that event streams have made unnecessary. Right: interest accrual, external scheme cycles, periodic settlement and the need for a frozen reporting point each independently require a defined daily boundary.
8. Wrong: an immutable ledger is a property of the software you bought. Right: underneath sits an ordinary database in which a sufficiently privileged person can run an update, so immutability is restricted access, approval workflow, audit logging, sequence numbering and independent reconciliation.
9. Wrong: a mistake is fixed by finding the original entry and correcting it. Right: a reversal posts the exact contra with an explicit link, the correct entry is then made afresh, and both remain visible along with a note of who authorised the repair.
10. Wrong: a refund reverses the original payment. Right: a refund is a fresh transaction in the opposite direction through the normal clearing process, which is exactly why it takes days when the purchase appeared to take seconds.

4.99 Chapter summary in 20 lines#

1. A principle that is never implemented is a slogan, and double entry is implemented with almost fanatical specificity.
2. Records take two shapes: a journal in the order things happened, and a ledger of accounts arranged by where things stand.
3. The chart of accounts is the controlled list of which accounts may be used, and the suspense account is where anything that fits none of them waits.
4. A day at Ada’s Bank shows the pattern: a cash deposit, an internal transfer, a withdrawal and a fee, each written twice and each balancing.
5. Time passing is itself an economic event for a lender, which is why a day’s interest accrual has to be computed and posted by somebody.
6. The trial balance lists every account in two columns and proves the totals agree, which is the oldest sanity check in commerce.
7. The rule about the eraser is absolute: a mistake is answered by a reversing entry, a fresh correct entry, and a note of who found and authorised it.
8. Once erasing is permitted no page proves anything about its own day, the auditor cannot check, the customer cannot dispute, and theft can be hidden by amending history.
9. There is no folder with your name on it in the general ledger, because your balance lives in a sub-ledger summarised into a control account.
10. That sub-ledger to general ledger reconciliation runs daily in a bank, and a £4.27 difference is somebody’s afternoon.
11. Recording, posting, settlement and valuation are four events on four timings, and the gaps between them explain a large fraction of what customers ask about.
12. A card authorisation is a memo post against the available balance only, with the real entry landing at clearing days later.
13. A bank has a business date rather than a closing time, and a group operating in several countries may have several alive at once.
14. There is no single cut-off, because CHAPS, Bacs and the card schemes each impose their own and none of them is the bank’s accounting close.
15. Batch exists because some facts are defined per day, because external cycles are batch by design, because settlement is periodic, and because reporting needs a frozen point.
16. Close of business is a mandatory, time-boxed sequence that ends by rolling the business date, and a failed run leaves a bank entering the next day without knowing its own position.
17. TSB’s £48.65 million fine in December 2022 was for the management of operational risk rather than for the technology, which is the correct place to put it.
18. Immutability is a set of controls — restricted access, maker and checker, audit logging, reconciliation — rather than a property of the database underneath.
19. Reversal preserves the gross record and adjustment posts only the net difference; both are legitimate, and amendment in place is not.
20. Payment networks inherit the same rule, so camt.056 is only a request, pacs.004 is a new payment in the opposite direction, and nothing anywhere is an edit.

Chapter sources: Companies Act 2006, sections 386 and 388 (legislation.gov.uk). FCA Handbook, SYSC 9.1.1R and SYSC 9.1.2R. Bank of England — Payment and settlement pages covering CHAPS, Bacs, Faster Payments, the Image Clearing System, LINK and card scheme settlement; policy statement “Extending RTGS and CHAPS settlement hours – early morning extension” (2026). Bacs / Pay.UK — Bacs Direct Credit getting-started guidance on the three-day processing cycle and input window. ISO 20022 message definitions for camt.052, camt.053, camt.054, camt.056, camt.029 and pacs.004, together with the SWIFT camt.053.001.02 message definition report; SWIFT MT940 and MT942. ISO 8583 message type indicators 0400 and 0420. International Standard on Auditing 240 on journal entry testing. European Banking Authority reporting frameworks (COREP and FINREP). Temenos documentation on close-of-business processing. Bank of England and Financial Conduct Authority joint news release, “TSB fined £48.65m for operational resilience failings”, 20 December 2022.