Business value

If a company makes widespread use of direct debits (DD), there is a good chance a number of DD’s will bounce. There is a variety of reasons, including NSF, revoked mandate, manual cancellation, etc.

The Dutch banks have all implemented this logic slightly differently, but in general it can be stated that in the MT940, these cancellations are identified through the tag ‘RTRN’, followed by the reason for the cancellation.

If the system finds such a cancellation, it executes this logic:

1. Determines the original open transaction (= invoice)
   1. Unsettles the direct debit
   2. Updates the field ‘Attempts’, informing the user how many times has been tried to collect money through DD
2. The direct debit and the return are settled in the banking journal
3. Based on the mandate-information in the MT940, the mandate is sought

If found, the number of payments on the mandate is reduced with 1

Example process ING

The full process is illustrated below, using the ING-format.

Setup customer direct debit mandates

Create open transactions

Create invoice for the customer.

Customer payment journal

Using a customer payment journal, the Direct Debit is triggered.

After posting this journal, the open transaction is settled.

Those transactions are also visible from the customer form tab Direct debit mandates > Transactions

Import MT940 with RTRN Code

 The MT940 of ING would look like this:

RTRN/MD063 identifies the Return Reason

USMF-000000002 identifies the mandate number

ARPM00772 identifies the direct debit voucher number

Return Information

The system could find the voucher, through the ARPM00772 code (note: the current code for ING is looking for the substring between EREF/ and the – (=dash), because the dash is generated by ING).

So, make sure you do NOT have a dash in your number sequence for your voucher number.

On posting, the system will use the recognized voucher to reverse the original transaction, which will re-open both the original invoice transaction and the original payment transaction. Next, it will settle the payment transaction with the current bank transaction. Based on the Mandate Id, the number of direct debits is reduced. 

After posting the bank journal, the original invoice is showing the cancellation, and the number of direct debit returns (on the Payment tab).

More detail can be found by clicking the button Customer return history on the customer transaction.

Customer payment journal (second round)

Because the first Direct Debit and the Return cancel each other out, the original invoice is available again for the payment proposal.

Import MT940 with RTRN Code (second round)

Importing an MT940-statement, which happens to include an RTRN-line again, settles the second DD and opens the original invoice again, including the updated number of returns. 

Differences RABO MT940

Known exceptions for RABO are:

• Different MT940 format.
  Class DYSBNKLedgerInAccountStatementNL_MT940RaboS has been slightly modified
  
• Return codes only contain 4 characters
  The code found for RABO is not truncated
  
• The ID-prefix is still present
  The original DD-voucher is found, using the ID-prefix

• Customer Return reason - tag RTRN, result DNOR

• Payment Voucher - tag EREF, result ID-694376

• Mandate Id - tag MARF, result 327694-2014

Differences CAMT053

• Customer Return reason - tag <Cd>

• Payment Voucher - tag <EndToEndId>

• Mandate Id - tag <MandtId>

Setup

Customer return reasons

In Accounts Receivable > Setup > Customer return reasons specify the Customer return reasons, which the MT940 may contain as different banks use different codes.

Customer direct debit mandates

Go to Accounts receivable > Customers > All customers > tab: Direct debit mandates and create a mandate.