Ledger, Reconciliation and Reporting

The ledger is the accounting heart of the hub, recording every movement of money as a double entry. When a payment is released, the ledger debits the customer's account and credits a settlement or clearing account. When the payment settles, the clearing account is debited and the correspondent or central bank account is credited. These entries must balance exactly, and they must be posted in the right order, because the general ledger is the bank's official record of its financial position. The ledger service is usually separate from the payment engine, so that accounting rules can change without affecting payment processing, and so that accounting entries can be replayed or corrected if an error is found. A BA should understand the basic entries for each payment type, because reconciliation breaks and finance queries almost always start with the ledger. Reconciliation is the daily process of proving that the hub's records match the records of everyone else involved in the payment. The hub's outgoing payments are matched against the clearing system's confirmations, the incoming payments are matched against the nostro account statements, and the ledger entries are matched against the general ledger. Any break, such as a payment the hub thinks was sent but the clearing system never received, becomes an exception that operations must investigate. Reconciliation is usually automated, with matching rules that handle timing differences, such as a payment sent late in the day that settles the next morning, and only the true breaks reach a human. Good reconciliation design reduces operational risk dramatically, because it catches errors on the same day they happen instead of weeks later. Reporting is the third part of this picture, and it serves three audiences. Operations need intraday dashboards showing payment volumes, failure rates and queue depths, so they can react before a small problem becomes a big one. Finance needs daily reports on volumes, values, charges and settlement positions. Compliance and risk need reports on screening hits, fraud alerts, rejected payments and exceptions, to prove that controls are working. A BA writing reporting requirements should start from the decision each report supports, not from the data available, because a report nobody acts on is just noise. The hub's data must also be stored in a way that supports investigation months later, because a customer dispute or a regulatory query can arrive long after the payment was made. A worked example shows the ledger entries for a payment. A customer pays EUR 25,000 to a supplier through SEPA. When the payment is released, the engine debits the customer account EUR 25,000 and credits the bank's SEPA clearing account EUR 25,000. At settlement in T2, the engine debits the SEPA clearing account EUR 25,000 and credits the bank's T2 central bank account EUR 25,000. The supplier's bank does the mirror entries and credits the supplier in full. At the end of the day, the bank reconciles its SEPA clearing account against the STEP2 settlement report: every debit must have a matching credit, and any difference is a break that must be investigated the same day. A break of EUR 25,000 that is not investigated is a payment that may have been sent twice, or not at all. A failure scenario tests the reconciliation. The STEP2 settlement report shows a payment of EUR 10,000 that the bank's ledger does not have, because the engine crashed between sending the clearing message and posting the ledger entry. The reconciliation team finds the break by matching the settlement report against the ledger, identifies the payment from its end to end identification, and posts the missing entry manually with a record of why it was posted late. The engine is then fixed so that the clearing message and the ledger entry are recorded in the same transaction, and cannot be separated by a crash. For a business analyst, the requirement is to define the reconciliation process, the matching rules, the break thresholds, and the escalation for breaks that are not resolved within the working day. Last reviewed 7 November 2026. Further reading: public post on nostro reconciliation and double entry booking; ISO 20022 camt.053 account statement message definition. Take a customer payment of GBP 10,000 sent through Faster Payments. The ledger posts four entries. First, debit the customer account GBP 10,000 and credit the Faster Payments settlement account GBP 10,000. Second, when the payment settles, debit the settlement account GBP 10,000 and credit the Bank of England reserve account GBP 10,000. If the payment is returned, the entries reverse: debit the reserve account, credit the settlement account, debit the settlement account, credit the customer. Each entry carries the payment reference, the value date and the user who authorised it, so that finance can trace any balance back to the payment that caused it. A ledger that cannot do that is not a ledger, it is a list of numbers. A reconciliation break is a difference between two records that should agree, and operations must resolve it the same day. Suppose the hub shows a payment of EUR 50,000 as settled, but the clearing system has no record of it. The break could be a timing difference, a duplicate, a message that was lost, or a payment that was sent twice. The analyst checks the hub log, the clearing confirmation, and the ledger entries, and finds that the clearing acknowledgement was received but not processed because the hub was restarting. The fix is to replay the acknowledgement, not to re-send the payment, because re-sending would create a duplicate. A BA should write the break handling as a workflow: who sees the break, what evidence is attached, how it is resolved, and how the resolution is recorded. Reporting requirements start from the decision, not the data. Operations needs a dashboard that shows the number of unmatched items, the oldest break, and the value at risk, because those three numbers decide whether the day can close. Finance needs a report that proves the ledger balances, with the total debits equal to the total credits, every day without exception. Compliance needs a report that lists every payment that was held, rejected or returned, with the reason code, because those are the payments a regulator will ask about. The BA should define each report by its audience, its frequency, and the action it triggers, and should test the reports with real data before go live, because a report that is wrong on day one is never trusted again.