Using SEPA Direct Debit

With self-managed SEPA Direct Debit processing, you can set up and accept one-time and recurring SEPA direct debit payments through:

• Giving Pages: accept payments through Givings Pages configured to use Authorize.net for card payments
• PayLinks: create and share PayLinks for one-time or recurring payments
• Payment API: custom front-end integration to the Payment API to accept new payments and update existing commitments

You can also use Salesforce tools like Gift Entry (nonprofit solutions) to create new SEPA Direct Debit payments. Manual record creation is supported as well, but you need to make sure all the required records are created and correctly linked.

For manual SEPA Direct Debit payment creation, enter records in this order:

1. Contact/Account record (if the payer is new)
2. Payment Profile record (if one doesn't exist for the payer's bank account)
3. Mandate record (skip of auto-create mandates is enabled in FinDock Core)
4. Installment or source-specific recurring payment record (with links to contact/account, mandate and payment profile).

When it comes to SEPA mandates, as noted in our configuration guidance, you need to create your own processes around how to handle Mandate records. The records are auto-created by FinDock according to your setup, but other actions, such as deactivating unused mandates, requires custom business logic.

Collecting SEPA Direct Debit payments

To collect both one-time and recurring SEPA Direct Debit payments, you run payment schedules. The schedules generate payment instructions in a standard pain.008 file that FinDock uploads to your Chatter Group for file-exchanges.

The pain.008 files generated by FinDock needs to be transferred to your bank for processing. This can be done either through manual actions or custom automation using Salesforce tooling and your bank's services.

Payment reference and sequence type

Every installment contains a payment reference. The payment reference is primarily used in matching incoming transactions to a particular installment. When running a SEPA direct debit payment schedule run, the payment reference is used as the End-to-End Id in the generated pain.008 file.

FinDock also inserts the sequence type for each entry in the pain.008 file based on the related mandate.

On the related mandate for an installment, if Use First on Next run is checked, the next installment gets sequence type FRST. This is automatically checked for new Mandate records and then unchecked with the first installment is set to Collected. FinDock also sequence type FRST if the Lase Used date on the mandate is empty.

To make FinDock insert sequence type FNL (final collection), you can mark the Use Last on Next run checkbox on the mandate.

In all other cases, New or Pending installments for recurring payments get sequence type RCUR.

Changing the debtor account

If a payer wants to change the bank account (debtor account) for an existing recurring payment, you need to create a new payment profile and mandate, then update the recurring payment to use the new payment profile.

With auto-create mandates enabled, you just need to create the new payment profile and update the recurring payment to use the that profile (Payment Profile field on Mandate). If you are using FinDock Standalone, you also need to empty the Mandate field on the recurring payment to trigger the mandate auto-creation.

Reconciling SEPA Direct Debit payments

SEPA Direct Debit payments are confirmed through reconciliation matches transactions from bank statements to Salesforce records and updates data according to the bank's latest information. Typically this is handled through file-based reconciliation using camt.053 or camt.054 files. However, other types of bank statements, such as CODA, are also used for SEPA Direct Debit reconciliation.

Alternatively, you can use FinDock Bank Feed to automatically fetch transaction entries from bank accounts. This is particularly helpful if you are working with many accounts. Transactions pulled in through Bank Feed are matched to Salesforce records using Guided Matching. With Guided Matching, you can extend your reconciliation business logic, improve matching rates and further enrich Salesforce data.

Customizing payment schedule closing logic

With the default payment schedule logic, FinDock marks installments Collected when you click File Accepted (or update the schedule status to Verified).

However, you can change the payment schedule logic to mark installments as collected only after reconciliation is complete. This, for example, would allow you to confirm that the money is actually on the creditor bank account before changing the installment status to Collected in Salesforce.

To modify the schedule closing logic, you need to do:

1. Add a status to the Finished Status picklist field on Payment Schedule that the installments will get after the schedule is complete. You could use, for example, Pending Processing.
2. For new payment schedules, select the Finished Status option from step 1.
3. Run the schedule as normal until the Pending Verification step.
4. Do NOT use the File Accepted button or a custom approval workflow that changes the schedule status to Verified.
5. Change the status of the schedule from Pending Verification to Done (manually or through custom automation).

When the schedule is set to Done, a batch job runs that updates the status of all the linked installments to the Finished Status value. Then, through reconciliation, FinDock changes installments to Collected based on the camt.053 (MT 940 or other format) bank file entries.

This customization works with SEPA Direct Debit because the scheme includes collection confirmation. We can also be relatively certain that the confirmation arrives before R-code notifications. However, it is possible that the ordering of these entries in a given bank file may not be correct. If this happens, the reversal fails and you can handle this through Guided Matching with, for example, a Guided Review rule.

R-transactions

When reconciling SEPA Direct Debit payments, it is important to properly handle SEPA R-transactions. The European Payments Council provides detailed guidance that you can use for customizing business processes.

R-transactions are captured in four simple terms: Reject, Return, Reversal, and Refusal. On their own, these terms are hard to interpret. For clarity, the SEPA Direct Debit scheme defines a long list of reason codes that capture the many different aspects of unsuccessful collections.

The reason codes for R-transactions are included in bank transaction details and stored in Salesforce on the Reason Code field (cpm__Reason_Code__C) of Transaction records. Each reason code can be associated with one or more R-transactions. For example, reason code AC01 (Incorrect Account Number) can apply to both Reject (invalid debtor account number) or Return (debtor account number not found). The code explanations are covered in the detailed guidance linked above.