Worked Example: EUR 89.99 Monthly Utility Collection, End to End and How to Test It

The worked example begins on 14 September 2026, when Jonas Weber signs the e-mandate on the Stadtwerke Linden website and Meridian Bank Munich authenticates him and accepts mandate SWL-JW-2026-0417. On 19 October, the utility sends the pre-notification for the November collection, telling Jonas Weber that EUR 89.99 will be collected on Monday 2 November 2026 for the October electricity bill. On 30 October, Stadtwerke Linden sends the pain.008.001.02 file to Harbour Bank Frankfurt, which validates it and creates the pacs.003.001.02 for the interbank leg. The collection is now in the clearing system, waiting for the due date. On Monday 2 November 2026, Meridian Bank Munich receives the pacs.003, checks mandate SWL-JW-2026-0417, confirms that it is valid and not cancelled, and checks that the Jonas Weber account holds at least EUR 89.99. The bank debits EUR 89.99 from the account, sends a pacs.002 report with status ACCP back through clearing, and the funds settle to Harbour Bank Frankfurt, which credits the Stadtwerke Linden account. Jonas Weber sees the debit on his camt.053 statement with the mandate reference and the October bill reference, and Stadtwerke Linden closes the receivable for the October bill. The collection is complete, and the next one is due on 1 December 2026. The same timeline shows what happens when something goes wrong, and each failure has a defined next step. If the Jonas Weber account held only EUR 40.00 on 2 November, Meridian Bank Munich would return the collection with a pacs.004 and a reason code for insufficient funds, and Stadtwerke Linden would invoice Jonas Weber directly. If the mandate had been cancelled in October, the bank would reject the collection with reason MS02, and the utility would need a new mandate before collecting again. If the utility collected EUR 89.99 twice, it would reverse the duplicate with a pain.007 and a pacs.007 carrying reason code AM05, and Jonas Weber would see the credit on his next statement. Testing a direct debit flow needs cases that cover the mandate, the collection, and every exception, because each layer can fail independently. A test pack should include a successful e-mandate, a failed authentication, a collection on the due date, a collection after the cut-off, a reject with MS02 for a missing mandate, a return for insufficient funds, a refund inside eight weeks, an unauthorised refund inside thirteen months, and a reversal with AM05 for a duplicate. Each case should check the message content, the amount, the mandate reference, the reason code, the ledger entries, the customer notification, and the pre-notification timing. A product owner should also test the customer experience, because a debtor who does not understand a debit will call the bank, and a creditor who cannot explain a return will lose the customer. Worked example with numbers: the full timeline runs from 14 September 2026, when Jonas Weber signs the e-mandate and Meridian Bank Munich accepts mandate SWL-JW-2026-0417, through 19 October, when the utility sends the pre-notification for the EUR 89.99 collection, to 2 November, when Meridian Bank debits the account and credits the utility. The same timeline shows what happens when something goes wrong: if the account held only EUR 40.00 on 2 November, Meridian Bank would return the collection with a pacs.004 and a reason code for insufficient funds, and if the utility collected twice, it would reverse the duplicate with a pacs.007 and reason code AM05. Every step has a message, a date and an amount, so the whole payment can be traced from mandate to credit. Failure and recovery: testing a direct debit flow needs cases that cover the mandate, the collection and every exception, because each layer can fail independently. A test pack should include a successful e-mandate, a failed authentication, a collection on the due date, a collection with insufficient funds, a reject before the due date, a return after the due date, a refund within eight weeks, and a reversal for a duplicate, because each case exercises a different layer. A test pack that covers only the happy path will pass its tests and fail in production, because the first real exception will arrive in the first month, and the operations team will have no procedure for it. For a business analyst, product owner or subject matter expert, the worked example requirement must state the full timeline, the messages at each step, and the amounts, so that a tester can follow the payment from mandate to credit without guessing. The requirement must also state the failure at each step and the recovery, because a requirement that shows only the happy path leaves the operations team without a procedure. The test pack must cover the mandate, the collection and every exception, and must name the message and the reason code for each one, because a test that does not name the reason code cannot prove the exception was handled correctly. Source: EPC SDD Core Rulebook 2025; last reviewed 7 November 2026.