Standard Direct Debit Process

The Salesforce Direct Debit Service works on the BACS 3 Day Processing Cycle. This means that a file will be generated based on relevant direct debit information in Salesforce 2 banking days before the collection day. Detailed information on this process can be found here.

BACS Rejections (ARUDDS) are processed by the system automatically and Salesforce is informed of any payment failures. This again follows the standard BACS workflow which can be found here. As BACS do not inform service users of successful payments, only failures, and because failure notifications may be received up to five days after the collection date, SmarterPay waits five days to set direct debits to “Successful” by default. This setting can be customised if five days is too long to wait due to business processes of the client.

A typical direct debit collection in Salesforce will follow this pattern:

Prior to Day 1 - Direct Debit entered and scheduled in Salesforce.
Day 1 - Direct Debit picked up and sent to BACS.
Day 2 - Processing at BACS.
Day 3 (Collection Day) - Money changes bank accounts.
Day 4 - Rejection files received from BACS.
Day 5 - Rejection files uploaded to Salesforce.
Day 8 - Direct Debits that have not failed are updated to “Successful” in Salesforce.


Direct Debit (Income_Direct_Debit__c)

The Direct Debit is the master record for SmarterPay Direct Debits. As standard it holds the bank account details and collection configuration fields.
The core fields are listed and described below:

FIELD DESCRIPTION
BANK SORT CODE Sort code of the account holder
BANK ACCOUNT NUMBER Account Number of the account holder
BANK ACCOUNT NAME Name of the account holder
STATUS The current status of the direct debit. This is initially set to New Instruction as the direct debit must be setup with BACS before payments are made.
COLLECTION DAY The day the collection is to be made. For example, 1 for the 1st of the month or 25 for the 25th of the month.
COLLECTION STRETCH How many months or weeks between collections. For monthly collections this is set to 1; for quarterly it is 3; for yearly it is 12.
COLLECTION PERIOD Tells the direct debit software what the schedule of the direct debit is. This is either set to Weekly or Monthly.
COLLECTION TYPE Defines what type of direct debit is being setup. Typically, this is Ongoing (no set end to the direct debit).
Fixed can be chosen to end a direct debit at a specific date.
START DATE The date the direct debit should be setup from.
FIRST COLLECTION AMOUNT The very first amount collected by direct debit. This field allows for inflated first amounts.
For example, sometimes the first payment includes a joining fee.
FIRST COLLECTION DATE The date the first amount will be collected.
ONGOING COLLECTION AMOUNT The amount the direct debit should collect on an ongoing basis. This can be changed throughout the lifetime of the direct debit.
NEXT COLLECTION DATE The date of the next direct debit collection. This is typically calculated by the direct debit software, taking into account collection day, stretch and period.
Bank holidays and weekends are also taken into account.




Direct Debit History (Income_Debit_History__c)

The Direct Debit History record is a child of the Direct Debit object. It's purpose is to store a full audit history of everything that has happened on a direct debit to do with collections or BACS reports. Any collection, failure or BACS report (such as ADDACS) are stored on here.

Typically, the very first history record that you would see is a New Instruction to BACS. Without this, a direct debit collection cannot take place. All subsequent records will typically be collections or BACS reports.
The core fields are listed and described below:

FIELD DESCRIPTION
AMOUNT The value that was submitted for collection.
DD STATUS The type of message that was sent or received. For example, New Instruction, Ongoing Collection or Update.
DD COLLECTION DATE The date that the collection was made or the report received.
DD STAGE The state of the collection. Values are 'Submitted', 'Successful' or 'Failed'.
DD FAILED A boolean/checkbox representation of a failed direct debit collection. This is marked as true/checked if the direct debit collection failed.
DD FAILED DESCRIPTION A full description of why the direct debit collection failed.
DD CODE The specific code that was received from BACS on a report. Contains values such as ARUDD-0 or ADDACS-1.



Out of the box, Direct Debits are created using the ‘Direct Debit Setup’ wizard. This is a standard component in the base Direct Debit package. By default, it can be accessed via an Account or Contact record, or via the Direct Debit Tab. Additional fields can be added to the wizard, if necessary, by the field set provided.

Bank details entered into the wizard will be checked for validity using modulus checking against the Extended Industry Sort Code Directory (EISCD). Success or failure is represented by a green tick or a red cross against the problematic field.

The auddis reference and first collection date is confirmed at the end of the wizard. Along with this information is the BACS Direct Debit Guarantee which can be read out to your customer. PDF copies of the direct debit mandate can also be downloaded to print, send via email or post.


SmarterPay automatically upload BACS Reports to Salesforce against the relevant direct debit. If the BACS Report is in relation to a specific payment (ARUDD) then the software will update the Income Debit History record related to that particular transaction. If the report is an update to the direct debit (ADDACS) then a new Income Debit History will be created and the main direct debit may be updated with the relevant information or appropriate status.

The SmarterPay system can be adjusted to behave in specific ways based on the BACS Code received. This allows the system to react in accordance to the users business requirements. For example, a payment failure may result in a represent, or it may not, depending on the requirement of the user.

Because SmarterPay push all BACS Report information into Salesforce, automation can take place based on user business processes. So, for example, if an account was closed an email could automatically send to the customer to ask for new details; or if a payment failed and email could be sent asking for alternate payment.


BACS Codes

REASON CODE DESCRIPTION
ARUDD-0 Refer To Payer
ARUDD-1 Instruction Cancelled
ARUDD-2 Payer Deceased
ARUDD-3 Account Transferred
ARUDD-4 Advance Notice Disputed
ARUDD-5 No Account Or Wrong Account Type
ARUDD-6 No Instruction
ARUDD-7 Amount Differs
ARUDD-8 Amount Not Yet Due
ARUDD-9 Presentation Overdue
ARUDD-A Service user differs
ARUDD-B Account Closed
ADDACS-0 Instruction Cancelled - Refer To Payer
ADDACS-1 Instruction Cancelled By Payer
ADDACS-2 Payer Deceased
ADDACS-3 Instruction Cancelled, Account Transferred
ADDACS-B Account Closed
ADDACS-C Account transferred to a different branch
ADDACS-D Advance notice disputed
ADDACS-E Instruction Amended
ADDACS-R Instruction Reinstated
AUDDIS-1 Instruction Cancelled By Payer
AUDDIS-2 Payer Deceased
AUDDIS-3 Account Transferred
AUDDIS-5 No Account
AUDDIS-6 No Instruction
AUDDIS-B Account Closed
AUDDIS-C Account transferred to a different branch of bank/building society
AUDDIS-F Invalid account type
AUDDIS-G Bank will not accept Direct Debits on account
AUDDIS-H Instruction has expired
AUDDIS-I Payer Reference is not unique
AUDDIS-K Instruction cancelled by bank
AUDDIS-L Incorrect payers account details
AUDDIS-M Transaction code/User status Incompatible
AUDDIS-N Transaction disallowed at payer’s branch
AUDDIS-O Invalid Reference
AUDDIS-P Payers name not present
AUDDIS-Q Service user name is blank
  • Last modified: 2021/09/24 12:35