How SEPA works across countries: a worked example

Consider a company headquartered in Amsterdam that employs people in Germany, France and Spain, buys goods from a supplier in Italy, and sells a subscription service to customers in eight countries. Before SEPA, this company would have needed separate payment processes for each country, with different formats, different cut offs and different charges. With SEPA, the company uses one process for all of it. The payroll is a single SCT file that pays employees in four countries, using their IBANs and the same pacs.008 format. The supplier payment to Italy is a single SCT, sent on the same day as a domestic payment would be. The subscription collections are SDD Core collections presented through the same file format in every country, using mandates that follow the same rulebook everywhere. Put numbers on the payroll. The company employs 120 people across Germany, France, Spain and the Netherlands, and the monthly payroll is 480,000 euro. Before SEPA, the payroll team ran four separate files in four formats, with four cut offs and four sets of charges. With SEPA, the team runs one pain.001 file with 120 payments, each addressed by IBAN, each carrying the employee name and the salary reference, and the file is submitted once, before the single cut off. The payer bank validates the file, debits the company 480,000 euro, and sends 120 pacs.008 messages through STEP2. The employees are credited within one business day, in full, in four countries, from one file. The saving is not just the fees; it is the four processes collapsed into one. Put numbers on the supplier payment. The company buys goods from a supplier in Italy for 25,000 euro, and the invoice must be paid by Friday. The accounts payable team instructs a single SCT on Wednesday morning, giving the supplier IBAN and the invoice number as remittance information. The payer bank debits the company 25,000 euro, sends a pacs.008 through STEP2, and the net position settles in T2. The Italian bank credits the supplier 25,000 euro in full on Thursday, and the supplier reconciles the payment against the invoice using the remittance information. Before SEPA the same payment would have cost a cross border fee, taken three to five days, and arrived with a deduction. The difference is the scheme, not the technology. Put numbers on the subscriptions. The company sells a subscription service to 8,000 customers in eight countries, at 12 euro a month, and collects 96,000 euro a month by SDD Core. Each customer signed a mandate with a unique reference, and the company stores all 8,000 mandates. Fourteen days before the due date, the company sends a single pain.008 file with 8,000 collections, each carrying the mandate reference, the sequence type recurrent, and the due date. The creditor bank sends 8,000 pacs.003 messages through the clearing system, the debtor banks debit the customers on the due date, and the company is credited 96,000 euro less the returns. In a typical month 40 collections return with AM04 for insufficient funds and are retried once; 15 return with AC04 for closed accounts and trigger a letter asking for new bank details. The return rate is under 1 percent, and the reason codes tell the collections team exactly what to do with each one. The cross border nature of SEPA is invisible to the customer, and that invisibility is the point. A customer in Lyon who pays a business in Berlin does not need to know that the payment crossed a border, does not need to provide a BIC, does not need to pay a cross border fee, and does not need to wait longer than a domestic payment. The clearing system routes the payment to the right bank, the settlement happens through T2, and the beneficiary is credited in the same timeframe as a local payment. The analyst's job is to preserve that invisibility in the product design. The payment screen should not ask the customer whether the payment is domestic or cross border inside SEPA, because the scheme treats them the same. The screen should ask for the IBAN and the amount, validate the IBAN, and let the system handle the rest. Reconciliation is where the single process pays off again. At the end of each day, the company's bank sends a camt.053 statement listing every debit and credit, and the company's finance team reconciles the payroll debits, the supplier payment and the subscription credits against the same statement, in the same format, for all four countries. The end to end reference on each payment links the pain.001 instruction to the pacs.008 interbank message to the camt.053 statement line, so a payment can be traced from instruction to statement without manual work. Before SEPA, the finance team reconciled four different statements in four formats; now it reconciles one. The remaining differences inside SEPA are operational rather than structural, and the analyst should know where to look for them. Cut off times vary by bank and by clearing system, so a payment sent at 4 in the afternoon may settle the same day from one bank and the next day from another. Some countries have local clearing arrangements that sit alongside SEPA, and some use cases, such as cheques in France, still follow national practice. The refund timelines for SDD are the same everywhere, but the way a customer disputes a collection can differ by bank. These are details, not barriers, and they do not change the fundamental achievement. A euro is a euro everywhere in SEPA, and a payment is a payment everywhere in SEPA. That is the lesson this chapter leaves with the analyst. The analyst's checklist for a multi country SEPA operation has four items. First, one integration for all countries, with the IBAN as the only account identifier the customer must provide. Second, one cut off per payment type, stated clearly, with the value date shown before the customer confirms. Third, one mandate process for all SDD collections, with the mandate stored and retrievable in every country. Fourth, one reconciliation, using the camt.053 statement and the end to end reference to trace every payment from instruction to settlement. A company that gets all four right has a payment operation that scales to any number of SEPA countries without adding a process per country.