AR Direct Debit Collections

• Overview
• Setting Up Direct Debits
• DDI Mandates
• Direct Debit Collections
• DD Collection Rejection Processing

Overview

Direct Debit processing in AR allows you to set up Direct debit mandates at either a customer or transaction level and to subsequently make regular collections against those mandates without the need for manual intervention.

The system supports all standard BACS interface file formats for Direct Debit Instructions, Account Changes, transaction Submissions and rejections. The system does not manage the actual transmissions; these must be performed using a BACS approved third party product.

You can set up regular collections against a customer by defining an open mandate against a customer. Such a mandate will enable all eligible outstanding transactions to be collected by Direct Debit at a specified frequency. Similarly you can set up a direct debit to run against a specific PBI Plan to allow each instalment to be collected at regular intervals.

You can also opt to collect using other methods as well as direct debit for a customer by flagging transaction types, or individual transactions as not eligible for direct debit collection. This is particularly useful for one off transactions that a customer may wish to pay by cheque or cash.

Setting Up Direct Debits

The Direct Debit processing module is an optional module and so you must ensure that the system level control is set up to allow Direct Debits to be used.

Direct Debit System Controls

You must then set up Direct Debit system controls to determine how DD processing will be used. The following needs to be determined:

• Numbering for Direct debit mandates. You can choose from manually entered or automatic generation with a nominated prefix.
• Your OIN (Operators Identification Number).
• The BACS processing cycle and days to be used for mandates via an Automatic banking Code.
• A nominated user to receive BEM messages from the mandate processes. This user will be used only if you do not have a credit manager defined for the customer being processed.
• The number of days between setting up a DDI mandate and the date it becomes active, known as the Notification days.
• You need to tell the system if DDI Mandates are to be submitted to BACS for verification before being used, and indicate if this process will be automatic or manual. If you do not use BACS verification, then Mandates will be made active immediately within e5 , and must be manually processed via BACS in order for them to be accepted for use by the BACS system.

Direct Debit Processing Controls

The presence of the Direct Debit Processing Controls will determine whether direct debits are available for the AR Company. These controls may only be created if the DD flag has been set on the system controls.

The system generates a record of the direct debit activity of a customer against the customer's diary. You must provide a diary type and code to be used to generate these entries.

Direct debits need to be numbered when the collection is made. You can specify three options for the direct debit reference. These are to set to the DDI Reference, a generated number with a prefix or the customer account number. Note that the customer account number may also be prefixed if required.

You must specify a maximum number of attempts that the system will make to collect a direct debit. If a DD fails collection, then a rejection will be received from BACS and the DD collection will be set to a failed status. The system will then attempt to automatically collect the DD again on the next run of the BACS collection process. The number of attempts at collection of the same DD is recorded and if this exceeds the DD rejection threshold will cause the system to hold this DD collection for manual intervention.

You must specify if a one stage or two stage collections process is to be used.

• One stage will automatically build direct debit collections and make them immediately available for the next transmission run.
• Two stage enforces a manual check of the DDI collections before allowing them to be submitted to BACS.

You must specify the transaction legend sub-type required for the generated Direct Debit transaction. This may be over-ridden on the DDI Mandate if a separate DD transaction legend is required.

You can also set a minimum and maximum collection value. Any collection value outside these limits will be rejected for Direct Debit processing.

Transaction Legends

You can opt to exclude specific transaction legends from Direct Debit processing by setting the Suppress Direct Debit flag against those transaction legends.

Customers

You must specify against a customer the Bank Account from which any direct debit collection is to be taken. Without an account no direct debit can take place. You will be prompted to enter bank details when setting up a new DDI Mandate for a customer.

DDI Mandates

A Mandate holds all the information relating to a DDI for BACS Direct Debit Processing. The mandate has a key of Company and DDI reference with the DDI reference subject to the BACS reference field validation guidelines as specified by BACS themselves. The reference may be automatically generated or manually entered depending upon the control indicator defined on the DD Processing Controls.

Creating DDI Mandates

Mandates can be created either offline via process AAQ or online.

Mandates can be used specifically for PBI, in which case they are generated directly from the creation of a PBI plan, for use generally within AR (but for a specific customer) or used by other systems.

You must provide a start date, and end date and a number of payments for a DDI Mandate. The start date is mandatory, but the system will calculate one of the other two fields base on the filed entered and the collection frequency or calendar.

You must provide either a collection frequency or a collection calendar for the mandate. The frequency can be set to one of Weekly, Monthly, Quarterly, half yearly and yearly. If a calendar is specified, then activities defined to that calendar will specify the collection dates.

If you are using foreign currency processing, then you can specify a currency code for the mandate or '***' to specify all currencies may be collected against this mandate. Note that at the time of writing, BACS will only accept values in Sterling, and that foreign currency values would use the base equivalent to make collection requests through BACS.

If you have specified that two-stage processing can be used in the system, then you can opt to select one or two stage processing for each individual mandate created.

You must provide details of the customer that the Mandate is being created for and also the Bank Account that the direct debit will be applied to.

If ICA is in use, then you must provide an ICA element to be used when direct debit transactions are created for DD collections made against the DDI mandate.

You must provide a Bank Code to specify the account that you wish collections for the mandate to be credited to.

The system will maintain and display details of the last collection made against a DDI mandate as well as recording the number of collections made. The date of the next collection will also be shown.

Mandate Status

As a DDI Mandate is processed by the system; it will go through a number of status changes. The following table identifies the statuses that can be applied to Mandates throughout their life cycle.

DDI Mandate Processing

There are a number of key processes involved in DDI Mandate processing.

The first submits to BACS a list of new DDI's for approval by BACS.  Details of all DDI's with the Requested status are built into a transmission file. A notification letter is produced for each new DDI mandate and sent to the Customer's address. These letters may also be sent via e-mail or HTML/XML by changing the QED mapping associated with the process. The letters may also be reprinted using the action from the DDI Mandate list.

The second process will read the BACS responses for submitted DDI's. The process will take the data returned and depending upon the status of the submission either set the DDI as active or in error. A diary entry will be created in the customer's diary to indicate the BACS response and when in error a BEM diary entry issued to the customer’s credit manager.

Two further processes manage updates to DDI Mandates. Whenever the bank details are changed on a DDI mandate, a process will be used to submit the amendments to BACS for approval. A process also retrieves the returned data from BACS and any errors found on the amendment file generate a BEM diary entry to the customer's credit manager.

Direct Debit Collections

When DDI mandates have been set up and are active, then the DDI collection process will look for all mandates that are to be collected on the run date, and pick up all valid transactions for those mandates to create a DDI collection schedule for each mandate.

If a one-stage process is in use, then the transactions identified will immediately be used to create a BACS submission file for transfer to BACS to activate the collections.

If a two-stage process is in use, then the collections will be held until you check the collection and allow it to be submitted for collection. You can review the details of a collection at this point and select transactions to be removed from the collection if required.

DD Collection Extraction

The system extracts transactions for collection based on the following criteria:

• If transaction is an instalment it must have the current DDI mandate on the PBI Plan Header
• The transaction must not be present on another DD collection or Payment Processing Schedule
• The Customer on the transaction must not be locked
• The Customer must not have the hold mandate collections flag set
• The transaction must have an outstanding balance
• The transaction due date must be between the DDI Mandate Start and End Dates
• The transaction must not have the suppress mandate collections flag set
• The Legend on the transaction must not have the suppress mandate collections flag set
• The Transaction due date must not be before collection date
• For cross elements, the Transaction Element must have a relationship with the DDI element

DD Collection Maintenance and Processing

You can review any DD Collection through the Collection maintenance list and edit screens. These will provide details of all collections still held on the system, including current and historic collections. Old collection details can be archived from the system however.

You can maintain the details of collections that are set to use two-stage processing through these screens. Maintenance of collections allows you to remove or amend the value to be collected against individual transactions included in the collection. An action will be provided to automatically set the status of all eligible collections that are built on the list to become 'awaiting BACS production', without having to individually update each collection.

When a collection is ready for transmission to BACS, then the BACS submission process will pick up the details of the transactions on the collection and generate a file ready for transmission to BACS using a third party BACS approved software package. The process will also create a Direct Debit transaction on each customer account processed and allocate this to the transactions to be collected.

Direct Debit Collection Status

Each DDI collection goes through a number of status changes throughout their life cycle. The following table indicates the statuses that a DDI collection can take.

DD Collection Rejection Processing

The BACS system works on the premise that all collections will be successful. However, there are occasions when collections fail. In such instances, the BACS system will send a message to the originator of the collection via the banking system that a collection has been rejected and the reason why.

The e5 AR system provides a process that will read and process the file of DD collection rejections sent by the banks. The process accepts the DD collection details from BACS and automatically updates the DD collection header to indicate the DD rejection failure. A diary entry is created in the customer's diary to indicate the reason for the DD rejection and a BEM event will be created to notify the customer's credit controller.

The transactions are then be backed out and reset to their outstanding values prior to the DD collection. A reversal DD transaction is also be created to back out any GL postings that were made. If the number of failed DD collection attempts has not exceeded the threshold on the DD controls then a re-send request will be issued to BACS for re-collection of the DD. If the number of failed attempts has exceeded the threshold, the DD collection will remain as failed. Such failed collections require user intervention to correct the problem.

See also

Accounts Receivable Home Page