Direct Debit Payments Explained: ACH, SEPA SDD, Bacs, and eGIRO

Direct debit is the mechanism behind most bank-account-based recurring payment collection — utility bills, subscription services, insurance premiums, loan repayments, and B2B invoice settlement. Operators use it because it eliminates the card network layer and its interchange, removes per-collection customer authentication, and does not expire when a card is reissued. The trade-off is a different set of failure modes: mandates must be obtained before any debit is initiated, settlements take longer than cards, and consumer protection frameworks in Europe and the UK create reverse-flow risk that card recurring does not have.

This article covers the mechanics of direct debit across ACH (US), SEPA SDD (Europe), Bacs (UK), and eGIRO (Singapore) — how mandates work, how each payment moves, what return codes mean, and what operators must build to handle each rail correctly. For a cross-rail comparison including card recurring, A2A mandates, and wallet billing, see Recurring Payments: Cards, Direct Debit, A2A, and Wallet Billing Compared.

The short answer

Direct debit pulls funds from a bank account using a mandate — a prior authorization the payer grants once, allowing the operator to initiate collections without per-transaction customer action. The payer’s bank honors the debit unless the account has insufficient funds, the mandate is cancelled, or the payer exercises a scheme-specific refund right.

ACH, SEPA SDD, Bacs, and eGIRO are all direct debit mechanisms. Each operates under different scheme rules, with different settlement timelines, return windows, and consumer protections. The mandate is the common element across all four: no valid mandate, no valid debit. Understanding what constitutes a valid mandate under each scheme — and what obligations flow from it — is the first operational requirement for any operator building on these rails.

What direct debit means

A payment is a direct debit when the payee — the party receiving funds — initiates the transaction by instructing their bank to pull from the payer’s account. This distinguishes it from:

Credit transfers (SEPA SCT, ACH credit, Faster Payments, PayNow): the payer pushes the funds; the payee receives passively.

Card payments: the payer’s card credentials are used, but the transaction routes through a card network (Visa, Mastercard) with authorization, interchange, and card scheme rules — not directly between bank accounts.

Real-time A2A mandates (UK VRP, UPI AutoPay, Pix Automático): bank-account pull payments that use newer instant-payment infrastructure. These are not direct debit in the traditional scheme sense; they use different clearing architecture, different authorization frameworks, and different settlement mechanics.

Legacy direct debit — ACH, Bacs, SEPA SDD, eGIRO — uses batch clearing infrastructure in most cases. This is why settlement takes days rather than seconds. It is a structural property of the rails, not something PSP routing can override.

The operator receives a net credit to their account when the debit settles. Between initiation and settlement, the debit is in the clearing system. After settlement, the payer’s bank can still return funds under defined return conditions — which is why direct debit revenue is not irrevocable until the applicable return window closes.

How a direct debit payment moves

The generic flow across all four rails follows the same five steps, with rail-specific timing:

Step 1 — Mandate in place. A valid mandate must exist before any debit is initiated. The mandate ties the payer’s account, the operator’s identity, and the scope of authorized collections. Without a valid mandate, the debit has no authorization basis and will be returned or result in an indemnity claim.

Step 2 — Debit file submitted. On the scheduled collection date — accounting for the rail’s required lead time — the operator or their PSP submits a debit instruction to the clearing network. For ACH, this is a Nacha-formatted file submitted by the ODFI (Originating Depository Financial Institution). For SEPA SDD, it is a pain.008 XML message submitted to the creditor’s bank. For Bacs, it is a file submitted through the Bacs system. For eGIRO, it is an API call to the ABS clearing infrastructure.

Step 3 — Clearing. The debit instruction routes through the clearing network to the payer’s bank. The payer’s bank checks whether the account is active, whether a valid mandate exists, and whether the account can honor the debit.

Step 4 — Settlement. Funds transfer from the payer’s account to the operator’s account. ACH standard: 1–3 business days; Same Day ACH: same business day; SEPA SDD Core: T+1 to T+5; Bacs: T+3 (three-day cycle); eGIRO: typically next business day.

Step 5 — Settlement confirmed or return received. If the debit cannot be honored, the payer’s bank returns the transaction with a standardized reason code. After the return window closes without a reversal, the settled funds are treated as final. For SEPA SDD Core, the consumer refund right extends the practical risk window to 8 weeks post-settlement.

Mandates: paper, electronic, API-based, and lifecycle

A mandate is the payer’s authorization for the operator to initiate direct debits. The form of mandate differs by rail, but the operational principles are consistent across all four.

Paper mandates. The payer signs a physical form; the operator retains the original. Paper mandates are historically associated with Bacs and SEPA SDD. They remain valid under most schemes but are increasingly replaced by electronic setup for new mandates.

Electronic mandates. Authorization is captured digitally — via a web form, app, or email confirmation. Nacha’s WEB SEC code governs electronically initiated ACH consumer debits. SEPA SDD supports electronic mandate setup as long as the content meets EPC requirements. Bacs supports AUDDIS (Automated Direct Debit Instruction Service) for electronic DDI setup, which is the standard for any operator using a bureau or modern payment provider.

API-based mandates. eGIRO in Singapore uses a real-time API flow: the operator initiates a mandate request via the ABS API, the payer authenticates in their bank’s interface, and the mandate is confirmed near-instantly. This eliminates the multi-day setup lag of legacy batch processes and is the most modern mandate setup pattern in commercial use.

Mandate lifecycle. A mandate progresses through: (1) creation and validation, (2) first collection (some schemes require a delay — AUDDIS for Bacs requires a minimum of 3 working days between DDI submission and first collection), (3) active recurring use, (4) amendment if amount or date changes, and (5) cancellation. Cancellation can be initiated by the payer — directly via their bank, without needing to notify the operator first — which means mandate status can change without the operator’s knowledge.

Mandate portability risk. Mandates are typically tied to the bureau or PSP that created them. A PSP migration may require full re-authorization by existing customers: Bacs mandates are registered under the Service User Number (SUN) of the originating bureau; SEPA SDD mandates are tied to the operator’s Creditor ID and held by the operator (more portable in principle); ACH authorizations are held by the originator but require ODFI re-setup. For subscription businesses at scale, mandate portability is a material churn risk that should be assessed before committing to a bureau.

ACH debit in the United States

ACH (Automated Clearing House) is the US bank-debit mechanism, governed by Nacha’s Operating Rules. Every ACH debit is originated by an ODFI (Originating Depository Financial Institution) — the operator’s bank or payment processor — and received by the RDFI (Receiving Depository Financial Institution), the payer’s bank. The ODFI is responsible to Nacha for the transactions it originates; this is why ODFI compliance requirements flow through to operators.

Authorization requirements

Every ACH debit requires a valid authorization from the receiver (payer) before any transaction is originated. Nacha’s rules specify that the authorization must: identify the receiver, name the merchant/company, state the amount or describe how the amount will be determined, specify the timing or frequency, and capture the receiver’s routing and account numbers. Electronic authorizations must meet Nacha’s format requirements. All authorizations must be retained for a minimum of two years after the last use or revocation.

SEC codes

Standard Entry Class (SEC) codes classify the type of ACH transaction. The codes most relevant to operator billing:

PPD (Prearranged Payment and Deposit). Consumer bank accounts, recurring or one-time, with a written or electronically agreed authorization. The standard SEC code for consumer subscription billing, utility payments, and loan repayments.

CCD (Corporate Credit or Debit). Business bank accounts. Requires a separate written authorization. Used for B2B invoice collection and business-to-business recurring payments.

WEB (Internet-Initiated/Mobile Entry). Consumer accounts; authorization captured via the internet or a mobile device. WEB requires additional verification procedures for accounts used for the first time and an annual audit of the security system used to protect account information. The appropriate SEC code when mandate setup happens through a web form or app.

TEL (Telephone-Initiated). Consumer accounts; authorization obtained by telephone. Less common for subscription billing; requires specific notification language at the time of authorization.

Using an incorrect SEC code for a transaction type is a Nacha rule violation and can generate return complications.

Same Day ACH

Nacha’s Same Day ACH rule allows eligible debit entries to settle on the same business day they are submitted, processed through three daily settlement windows. The per-item cap is $1 million. Same Day ACH is available for PPD, CCD, and WEB debit transactions. For operators needing same-day certainty on collections, Same Day ACH eliminates the 1–3 day standard settlement lag — at a slightly higher per-transaction cost.

Return codes

When an ACH debit cannot be honored, the RDFI returns it with a Nacha reason code. The codes most relevant to operator billing operations:

Return rate thresholds

Nacha monitors return rates at the ODFI level. Two thresholds are operationally significant for billing programs:

• Overall debit return rate above 15% triggers Nacha compliance review
• Unauthorized debit return rate above 0.5% triggers Nacha compliance review

These thresholds apply to the ODFI’s portfolio, not individual operators — but operators with elevated rates expose their ODFI and therefore their processing relationship. Return rate monitoring should be a standard operational KPI for any ACH-based billing program. For broader guidance on payment KPI frameworks, see Payment Routing KPIs.

SEPA Direct Debit in Europe

SEPA Direct Debit operates under EPC (European Payments Council) rulebooks across 36 countries — the EU27, Iceland, Liechtenstein, Norway, Switzerland, Monaco, San Marino, and, under bilateral arrangements, the United Kingdom. Two schemes apply to operator billing: SDD Core and SDD B2B. For full SEPA scheme operator implementation detail, see SEPA Credit Transfer, Instant, and Direct Debit: Operator Guide.

Creditor ID

Before initiating any SDD collection, the operator must obtain a Creditor ID — a unique identifier issued by the national payment authority in the operator’s home country. It is structured as: a two-letter country code, a two-digit check digit, and a creditor business code of up to three characters, followed by a national sequence. The Creditor ID appears on every mandate and every debit transaction. Obtaining a Creditor ID is the foundational administrative step; without it, no SDD initiation is possible.

The process and issuing authority vary by country. In Germany, the Creditor ID is issued by the Deutsche Bundesbank. In France, it is issued via the bank. In the Netherlands, by the Dutch central bank. Operators with multi-country SDD programs can typically use a single Creditor ID from their home country across the full SEPA zone.

SDD Core

SDD Core is used for collections from consumer and business accounts. The operator holds the mandate — it is not registered at the debtor’s bank.

Pre-notification. The creditor must notify the payer of the amount and date of each collection at least 14 calendar days before the due date, unless a shorter period has been agreed between the parties. Many operators agree to a shorter period in their terms — as short as 3 days — reducing the operational overhead of advance notice. Pre-notification is typically delivered by email or platform notification; it does not require bank-system involvement.

SCA exemption. SDD Core collections are explicitly exempt from per-collection Strong Customer Authentication under the PSD2 technical standards. The mandate setup itself may require SCA if done electronically. This is a significant advantage over card recurring, where the MIT/CIT framework requires an SCA-authenticated Cardholder-Initiated Transaction to open the Merchant-Initiated Transaction chain.

8-week consumer refund right. A payer can claim a full refund of any SDD Core collection within 8 weeks of the debit settlement date, with no justification required. The payer’s bank provides the refund immediately on request. The operator has no right to block or contest the refund during this window. Revenue from each SDD Core collection is therefore at risk of reversal for two months.

13-month window for unauthorized claims. Where the payer asserts the debit was never authorized — mandate dispute, not just a change of mind — the refund right extends to 13 months from settlement. Long-tail mandate management risk.

EPC SDD Core Rulebook 2025 v1.0 entered force on 5 October 2025.

SDD B2B

SDD B2B is restricted to transactions where both the creditor and debtor are non-consumers (business accounts). Key operational differences from SDD Core:

• No consumer refund right. Once 3 business days after settlement pass without a contest, the debit is irrevocable.
• Debtor bank pre-validates the mandate. Before the first SDD B2B debit, the debtor must register the mandate with their bank; the bank verifies all subsequent debits against the registered mandate. This adds setup friction but reduces return risk.
• T+1 settlement.
• SCA considerations. Mandate pre-registration at the debtor’s bank is the authentication step.

R-transaction types

SEPA SDD uses five distinct R-transaction categories when a debit cannot proceed or must be reversed:

Return. The payer’s bank sends funds back after settlement — for insufficient funds, account closure, or other post-settlement reasons. A return occurs after funds have moved; the operator loses previously settled revenue.

Refusal. The payer’s bank rejects the debit before settlement — account blocked, mandate not registered for B2B, or bank-side refusal. No funds move. A refusal requires investigation before re-submission.

Reversal. The creditor (operator) sends back a collection it originated — for a duplicate, incorrect amount, or post-settlement error. The operator initiates the reversal.

Refund. The payer exercises the 8-week no-questions-asked right (SDD Core only). The payer instructs their bank; funds are returned to the payer; the operator has no contest right during the 8-week window.

Reject. The collection is rejected by the clearing infrastructure before reaching the payer’s bank — typically for format errors, missing mandatory fields, or an expired mandate. Rejects occur early in processing; no funds move.

Each R-transaction type requires a distinct operational workflow. Conflating them — treating all R-transactions as retry-eligible, for example — generates repeated scheme violations and customer complaints.

Bacs Direct Debit in the United Kingdom

Bacs Direct Debit is the dominant bank-account debit mechanism in the UK, governed by Pay.UK’s Bacs scheme and processed by Vocalink.

Service User Number

To originate Bacs Direct Debits, an operator must hold a Service User Number (SUN) — a six-digit identifier linking all Direct Debit Instructions (DDIs) to the operator. A SUN is obtained directly from the operator’s sponsoring bank (for high-volume originators) or through a Bacs-approved bureau (such as GoCardless or Bottomline Technologies). Bureau-obtained SUNs are registered under the bureau’s identity; the bureau sponsors the operator as a client. This bureau relationship is the source of the mandate portability constraint: mandates created under a bureau SUN cannot be transferred to another bureau without customer re-authorization.

The three-day submission cycle

Bacs processes in batch, with a fixed three-business-day cycle from file submission to settlement:

Files must be submitted at least 3 business days before the intended payment date. There is no same-day Bacs debit equivalent. Operators scheduling collections must account for this lead time; last-minute submission is not possible.

Advance notice requirement

Operators must give advance notice to payers of the amount and date of each Direct Debit collection. The scheme minimum is 2 working days notice for established mandates. Standard industry practice — and the convention stated in most mandate agreements — is 10 working days, particularly for consumer billing. For new mandates set up via AUDDIS, the first collection must be at least 3 working days after the DDI is submitted. Operators must also give advance notice of any change to collection amount or date before the change takes effect.

Direct Debit Guarantee

The Direct Debit Guarantee provides three protections to any UK bank customer with a direct debit in place:

1. Advance notice of amount and date before any debit is applied
2. Immediate full refund from the bank for any Direct Debit applied incorrectly — wrong amount, wrong date, or unauthorized
3. Cancellation right at any time by notifying the bank

The Guarantee has no fixed time limit on unauthorized-debit claims. A payer can claim a refund for an unauthorized Direct Debit at any point, creating ongoing liability for operators with mandate management gaps.

Indemnity claims

When a payer invokes the Direct Debit Guarantee, their bank refunds them immediately and then recovers the funds from the operator’s sponsoring bank or bureau via an indemnity claim. The operator’s account is debited. The operator can dispute the indemnity claim with evidence of a valid mandate, but the default outcome favors the payer. High indemnity claim rates are a significant compliance signal — they can result in SUN review or suspension.

AUDDIS

AUDDIS (Automated Direct Debit Instruction Service) is the electronic system for creating, amending, and cancelling Direct Debit Instructions without paper forms. Operators submit DDI data electronically; the payer’s bank validates the account before the first collection is attempted, reducing the rate of initial collection failures. AUDDIS is now the standard for any operator using a bureau or modern payment provider.

eGIRO in Singapore

eGIRO is Singapore’s API-based bank mandate system for recurring SGD debit billing, introduced by the Association of Banks in Singapore (ABS). It replaces the paper GIRO form for digital mandate setup.

How legacy paper GIRO worked

Before eGIRO, setting up a GIRO mandate required a paper form: the payer signed a GIRO application, submitted it to the payee or their bank, and the payee’s bank processed the setup — typically taking 14–21 days. Paper GIRO remains in use for certain legacy contexts (utility billing, government payments) but is being progressively replaced by eGIRO for new operator integrations.

eGIRO mandate flow

eGIRO uses a real-time API mandate setup:

1. The operator initiates a mandate request through the ABS eGIRO API
2. The customer is redirected to their bank’s authentication interface — online banking or a banking app
3. The customer authenticates and approves the mandate within their bank’s interface
4. The mandate is confirmed near-instantly; the operator receives confirmation via API callback

This eliminates the paper-processing lag and manual error surface of the legacy process. For operators using a PSP that supports eGIRO, the integration is typically via the PSP’s API rather than direct ABS API access.

Scope and limitations

eGIRO is SGD-denominated only — cross-currency recurring debits are outside its scope. Participating banks are Singapore-licensed institutions operating under the ABS framework; the current list is published by ABS and may expand over time. For operators billing in currencies other than SGD, or with customers at non-participating banks, eGIRO does not apply. A card or alternative payment method is required for those customers.

Settlement for eGIRO-initiated debits follows standard Singapore interbank settlement cycles, typically the next business day.

eGIRO vs card billing for Singapore

Cards remain the default for cross-currency recurring billing and for customers at non-participating banks. eGIRO is most relevant for SGD subscription billing where the operator wants to avoid card interchange, has customers concentrated at participating banks, and benefits from bank-account mechanics (no card expiry, lower MDR). For a broader view of recurring payment rails in APAC including UPI AutoPay and Pix Automático, see Subscription Rails: eGIRO, UPI AutoPay, SEPA SDD, Pix Automático.

Direct debit vs card recurring and A2A

Cards provide global coverage and require no bank mandate setup, but carry interchange (typically 0.1–0.3% for domestic debit, higher for credit), card expiry risk, and in Europe the SCA/MIT/CIT framework for recurring collections. For card recurring mechanics and authorization rate optimization, see Authorization Optimization and Card Acceptance.

A2A mandates — UK VRP, UPI AutoPay, Pix Automático — pull from bank accounts using instant-payment infrastructure with near-zero MDR and near-instant settlement. They are not legacy direct debit; they use different clearing architecture and different authorization frameworks. Geographic availability is limited: UK, India, Brazil respectively. For detail on the UK VRP framework, see Variable Recurring Payments and Open Banking.

Legacy direct debit (ACH, SEPA SDD, Bacs, eGIRO) is appropriate when operators need bank-account billing in a market where it is established infrastructure, where the target customer base uses bank accounts as the primary payment instrument, or where the operator needs lower MDR than card processing. The return-window risk and settlement lag are the structural trade-offs.

Common mistakes operators make

Initiating a debit without a valid mandate in place. ACH, SEPA SDD, and Bacs all require valid pre-authorization before the first debit is originated. Initiating without one is a scheme rule violation that results in returns, indemnity claims, and — in SEPA — potential Creditor ID suspension.

Missing pre-notification deadlines. SEPA SDD Core requires pre-notification at least 14 calendar days before each collection (or the agreed shorter period). Bacs requires advance notice of any change to amount or date. Missing these deadlines does not always prevent the debit from settling, but it gives the payer grounds for a scheme-protected refund or indemnity claim.

Not mapping R-transaction types to distinct action workflows. A SEPA return (post-settlement funds reversed) requires different handling than a refusal (pre-settlement rejection). An ACH R07 (authorization revoked by customer) must result in mandate cancellation, not a retry. Operators without explicit R-transaction routing tend to treat all non-settled debits as retry-eligible, which generates scheme violations and customer complaints.

Treating eGIRO as a card-declined fallback. eGIRO is SGD-only, requires ABS API integration, and only works for customers at participating banks. It is a separate payment method requiring explicit customer enrollment — not a generic fallback for card failure.

Assuming Bacs 3-day settlement is equivalent to T+1. The three-day submission-to-settlement cycle is fixed. Operators who schedule debit file submissions too close to the intended payment date will receive funds late, creating invoicing and subscription-anniversary mismatches.

Not modeling the SEPA SDD Core 8-week refund window in cash flow. For subscription businesses with significant eurozone volume, the 8-week consumer refund right creates a revenue reversal risk on every collection for two months. Revenue from SDD Core collections should be treated provisionally until the window closes.

Underestimating mandate portability risk. Before committing to a bureau at scale, confirm the mandate data portability terms: whether mandates can migrate to a new provider without customer re-authorization, and what re-authorization conversion rates look like in practice. For the card-recurring equivalent of this risk on PSP migration, see Merchant-Initiated Transactions: SCA, Reason Codes, Auth Rate Impact.