SEPA Direct Debit Complete Guide: pain.008, Mandates, and B2B vs Core
A complete guide to SEPA Direct Debit: how pain.008 works, the difference between SDD Core and SDD B2B, mandate management, pre-notification rules, return codes, and common implementation errors.
What is SEPA Direct Debit and How Does It Work?
SEPA Direct Debit (SDD) is the SEPA payment instrument for recurring collections — subscriptions, utility bills, insurance premiums, loan repayments, and any other scenario where a creditor regularly pulls funds from a debtor's account. The technical format is pain.008 (CustomerDirectDebitInitiation), the ISO 20022 XML file submitted by the creditor to their bank to initiate collection.
The SDD process starts with a mandate — a signed authorisation from the debtor (the payer) allowing the creditor to collect from their bank account. The mandate contains the debtor's IBAN and BIC, the creditor's identifier (SEPA Creditor Identifier, CI), and details of the collection agreement. The creditor stores the mandate and references it in every pain.008 collection file using the MandateRelatedInformation element.
Two SDD schemes exist: SDD Core (SEPA Direct Debit Core) for consumer and business-to-consumer collections, and SDD B2B (SEPA Direct Debit Business-to-Business) for inter-company collections. The key difference is that SDD Core allows debtors to request a refund within 8 weeks of the collection date (no-questions-asked), while SDD B2B mandates must be pre-validated by the debtor's bank and do not allow the 8-week refund right.
Common pain.008 Errors and Rejections
SEPA Direct Debit failures are costly — returned collections involve fees, payment delays, and customer relationship issues. Here are the most common causes:
Missing or expired mandate reference (MandateId)
Every pain.008 transaction must reference a valid mandate in MndtRltdInf/MndtId. If the mandate has been cancelled, expired, or the MandateId does not match the bank's records, the collection is rejected with return code MD01 (No Mandate) or MD02.
Wrong SequenceType for first vs. recurring collection
Pain.008 uses SequenceType to distinguish FRST (first collection under a mandate), RCUR (recurring), FNAL (final), and OOFF (one-off). Sending RCUR before FRST, or using OOFF for a recurring mandate, causes bank processing errors and potential mandate disputes.
Pre-notification not sent in time (Core scheme)
SDD Core requires the creditor to notify the debtor at least 14 calendar days before the collection date (or fewer if agreed in the contract). Skipping pre-notification is a mandate dispute risk — the debtor can claim the collection was unauthorised.
SDD Core vs SDD B2B: Key Differences
SDD Core is designed for collections from consumers and SMEs. It allows the debtor to obtain a refund of any authorised collection within 8 weeks of the debit date — no reason required. This 8-week refund right makes SDD Core more debtor-friendly but creates cash flow uncertainty for creditors. SDD Core mandates must be stored by the creditor and do not need bank pre-validation.
SDD B2B is designed for inter-company collections where both parties are businesses. The debtor's bank must pre-validate the B2B mandate before the first collection — the creditor sends mandate details to the debtor's bank which confirms acceptance. Once validated, there is no 8-week refund right, making collections far more predictable for creditors. However, if the mandate details change, re-validation is required.
From a technical perspective, SDD B2B pain.008 files include the same MandateRelatedInformation structure but use LocalInstrument = B2B instead of Core. The collection submission timeline is also different: SDD Core requires collection files at least 5 business days (FRST) or 2 business days (RCUR) before the due date; SDD B2B requires at least 1 business day before the due date.
Return Codes and Dispute Management
When a SEPA Direct Debit collection fails, the bank returns the funds with a return reason code. Understanding these codes is essential for efficient exception handling. Common return codes include: AC01 (incorrect account number), AC04 (closed account), MS02 (refusal by debtor), MD01 (no mandate), MD02 (missing mandatory information in mandate), SL01 (specific service offered by the debtor bank), and AM04 (insufficient funds).
Refund requests from consumers under the 8-week right result in return code MD06 (Refund Request by End Customer). These returns do not imply a mandate dispute — the debtor is simply exercising their legal right. MD07 (End Customer Deceased) and AC06 (Blocked Account) are permanent failure conditions requiring mandate cancellation.
SDD B2B dispute resolution is different: since the debtor's bank has pre-validated the mandate, disputes are handled between the two banks according to the SDD B2B rulebook. The debtor cannot initiate a return through the EPC SDD B2B scheme after the settlement date — disputes must be resolved through direct legal channels between the companies.
Validate Your pain.008 Files with ValidateFin
ValidateFin validates pain.008 files against ISO 20022 schema, SEPA business rules, IBAN checksums, and mandate reference completeness. Catch errors before submission to prevent failed collections and bank fees.
Validate pain.008 nowFrequently Asked Questions
What is pain.008 in SEPA?
Pain.008 (CustomerDirectDebitInitiation) is the ISO 20022 XML file submitted by a creditor to their bank to initiate SEPA Direct Debit collections. It contains the collection details (amount, due date, creditor identifier) and mandate references for each debtor. ValidateFin validates pain.008 files against SEPA rules and ISO 20022 schema.
What is a SEPA mandate?
A SEPA mandate is a signed authorisation from a debtor (payer) allowing a creditor to collect funds from their bank account. It must contain: creditor name, SEPA Creditor Identifier (CI), debtor name and IBAN, type of payment (recurring or one-off), and the debtor's signature and date. The mandate reference (MandateId) must appear in every pain.008 collection transaction.
What is the difference between SDD Core and SDD B2B?
SDD Core allows debtors to request a refund within 8 weeks of the debit date (no questions asked) and is used for consumer and mixed B2B/B2C collections. SDD B2B requires the debtor's bank to pre-validate the mandate, has no 8-week refund right, and is used for inter-company collections where payment certainty is required.
How many days before collection must I submit a pain.008 file?
SDD Core FRST (first collection): minimum 5 TARGET business days before the due date. SDD Core RCUR/FNAL: minimum 2 TARGET business days. SDD B2B (all types): minimum 1 TARGET business day. These are minimum periods — banks may require earlier submission.
What is the SEPA Creditor Identifier (CI)?
The SEPA Creditor Identifier (CI) is a unique identifier assigned to each creditor authorised to collect via SEPA Direct Debit. Format: 2-letter country code + 2 check digits + 3-letter creditor business code + up to 28 alphanumeric characters (national identifier). The CI appears in the pain.008 header (CdtrSchmeId/Id/PrvtId/Othr/Id) and in every mandate.
Can a debtor cancel a SEPA Direct Debit?
Yes. Under SDD Core, debtors can cancel a mandate at any time by notifying their bank. They can also request refunds for any authorised collection within 8 weeks and for unauthorised collections within 13 months. Under SDD B2B, mandate cancellation must be communicated before the next collection date; there is no 8-week refund right once collections have been validated.
What happens if a SEPA Direct Debit is returned?
The collection is reversed and the creditor's account is debited for the returned amount. The bank provides a return reason code (e.g., AC04 for closed account, MS02 for debtor refusal). The creditor must handle the return: contact the debtor, update the mandate if needed, and re-submit or pursue alternative payment methods.
How do I validate a pain.008 file?
Use ValidateFin to validate your pain.008 file against ISO 20022 schema and SEPA business rules. The validator checks XML structure, IBAN mod-97 checksums, mandate reference completeness, SequenceType consistency, and creditor identifier format. All validation runs in your browser — no file is uploaded.
What is the maximum number of transactions in a pain.008 file?
The ISO 20022 standard does not specify a maximum, but banks typically impose limits (e.g., 100,000 transactions per file). Large files should be split into multiple submissions. The NumberOfTransactions element in the header must match the actual count of transactions in the file.
Can I include multiple creditor identifiers in one pain.008 file?
Yes. A pain.008 file can contain multiple PaymentInformation blocks, each with a different creditor identifier (CdtrSchmeId). This allows a single file submission to contain collections for multiple brands or legal entities — useful for large organisations managing several creditor identifiers.