Booking entries per message: how a payment posts to the ledger

Every payment message creates accounting entries, and a business analyst who cannot read those entries cannot explain why a payment is where it is. The ledger is the bank's book of record: every debit has a matching credit, and the sum of all debits equals the sum of all credits at all times. When a payment moves money, the engine posts a set of double entries that record the movement. The entries differ by message type, because each message represents a different event in the payment lifecycle. This lesson teaches the booking entries for the four messages a payments SME meets most often: pacs.008, pacs.004, camt.056 and pacs.009. Source: public post on double entry booking per message; ISO 20022 message definitions. A pacs.008 customer credit transfer creates the core payment entries. Take a corporate payment of EUR 25,000 from a customer at Bank A to a supplier at Bank B, sent through STEP2 and settled in T2. At Bank A, 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. The customer account goes down, the clearing account goes up, and the books balance. At settlement, Bank A debits the SEPA clearing account EUR 25,000 and credits its T2 central bank account EUR 25,000, because the funds have now left the bank through the central bank. At Bank B, the mirror entries happen: debit the T2 central bank account EUR 25,000, credit the SEPA clearing account EUR 25,000, then debit the clearing account and credit the supplier account EUR 25,000. The supplier is credited in full, which is the SEPA rule: the full amount must reach the beneficiary. A pacs.004 payment return reverses a pacs.008, and its entries are the mirror image of the original. Suppose the supplier account at Bank B is closed, so Bank B returns the EUR 25,000 with reason code AC04. Bank B debits the supplier clearing account EUR 25,000 and credits its T2 account EUR 25,000, sending the funds back. Bank A receives the return, debits its T2 account EUR 25,000 and credits its SEPA clearing account EUR 25,000, then debits the clearing account and credits the original customer account EUR 25,000. The customer is made whole. The return also carries the original end to end identification, so the bank can match the return to the original payment and close the case. A return that cannot be matched to an original payment sits in a suspense account until an operator investigates it, because an unmatched credit is a reconciliation break. For a business analyst, the requirement is to define this behaviour explicitly, because the engine does what the requirement says and nothing more. A camt.056 payment cancellation request does not itself move money; it asks the next bank in the chain to stop or reverse a payment that has already been sent. The accounting depends on what the receiving bank does. If the payment has not yet been credited to the beneficiary, the receiving bank stops it and returns the funds with a pacs.004, and the entries are the same as a return. The operations team must be able to see this state on a dashboard, because a payment that cannot be seen cannot be managed. If the payment has already been credited, the receiving bank cannot simply take the money back: it must ask the beneficiary for consent, and if consent is given, it debits the beneficiary account and returns the funds. If consent is refused, the funds stay with the beneficiary and the requesting bank must pursue the matter through other channels. The camt.029 resolution of investigation reports the outcome, and the engine posts entries only when the funds actually move, never on the basis of the request alone. A pacs.009 financial institution credit transfer moves funds between banks, and its entries are simpler because no customer account is involved. When Bank A sends USD 10 million to Bank B through its correspondent account, Bank A debits its nostro account with Bank B USD 10 million and credits its own settlement account USD 10 million. Bank B, receiving the funds, debits its settlement account USD 10 million and credits Bank A's vostro account USD 10 million. The nostro and vostro accounts are two views of the same account: Bank A's nostro is Bank B's vostro, and the two must agree. If they do not agree, the difference is a nostro break that the reconciliation team must investigate. A pacs.009 with a cover (MT202 COV in the legacy world) carries the underlying customer payment reference, so the receiving bank can match the cover to the customer instruction it already received directly. The suspense account is where payments go when the engine cannot post them cleanly. A payment with an invalid account number, a payment whose beneficiary cannot be identified, or a return that cannot be matched to an original payment is posted to a suspense account instead of being lost. The suspense account is a real ledger account, and its balance is monitored daily: a growing suspense balance means something is wrong in intake, enrichment or matching. Every suspense entry must have an owner and an age, and entries older than a defined threshold are escalated. For a business analyst, the suspense account is a diagnostic: if you want to know where a bank's payment process is weakest, look at what is sitting in suspense and why. Further reading: public post on double entry booking per message; ISO 20022 pacs.008, pacs.004, camt.056 and pacs.009 message definitions. Last reviewed 7 November 2026.