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. |
Creating a Direct Debit
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.
Working with BACS Reports
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 |