Directory   Messages   Segments   Composites   Data elements   Codes Meaning of the change indicators
  UN/EDIFACT  D.03A (Batch) Syntax version 3 Issue date 2003-06-23  
  Message type specification DIRDEB
DIRDEB 6 Direct debit message  

TBG5 Finance

This specification provides the definition of the Direct debit message (DIRDEB) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.


1.1 Functional definition
Prior to the Direct Debit procedure, some agreement(s) would usually have been concluded :

- agreement between the Creditor and his Bank (mainly to specify the conditions of credit and the kind of direct debit).

- agreement between the Debtor and the Debtor's Bank (i.e. pre- authorization and condition of debit), or between the Creditor and the Debtor.

A Direct Debit is sent by the Creditor to the Creditor's Bank instructing it to claim specified amount(s) from the Debtor(s) and to credit the amount(s) to an account specified in the message, which the Creditor's Bank services for the Creditor in settlement of the referenced transaction(s).

Throughout this document the term 'Creditor' refers to either a Beneficiary or a Payee, likewise the term 'Debtor' refers to either an Ordering Customer or a Payor.

The term 'Bank' may be interpreted as any financial institution.

The term 'pre-authorization' refers to an agreement between a Creditor and a Debtor for

- either automatic debiting, as required,

- or for debiting unless rejected by the debtor in a period of time.

The agreement can also be made between the debtor and his bank, independently of the amount of the DIRDEB.

1.2 Field of application
The Direct debit message may be used for both national and international applications. It is based on universal practice related to administration, commerce and transport, and is not dependent on the type of business or industry.

This message type may be applied, for both national and international settlements, but it is based on the national existing rules of the debit side.

1.3 Principles
- A Direct Debit may cover the financial settlement(s) of one or more commercial trade transactions, such as invoices, credit notes, debit notes, etc. It is not intended for use in securities trading.

- Several credit accounts, execution dates and currencies may be specified.

- Charges may be borne on account(s) different of the account(s) held by the Creditor.

- The Creditor's Bank may need a confirmation/authorization (AUTHOR) from the creditor to be able to process the Direct Debit Message.

- Pre-authorized and non pre-authorized direct debits shall not be mixed within the same message.

- The only way to modify a Direct Debit message is to cancel the whole message or a transaction thereof (e.g. by the use of the FINCAN message). In that respect, one to many order(s) could be cancelled within the message, avoiding to be obliged to cancel the whole message.

The cancellation of a message can only be effected by the originator of the message. The kind of cancellation is dependent upon the process of the message or a transaction of it.

See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 1.


3.1 Standard terms and definitions
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 2.


4.1 Data segment clarification
This section should be read in conjunction with the segment table which indicates mandatory, conditional and repeating requirements.

The following semantic principles applying to the message are intended to facilitate the understanding of the message:

The Direct Debit message is structured in three levels: A, B and C.

   - Level A contains general data related to the whole message and is contained in Segment Groups 1, 2, 3 and 24.

   - Level B contains data from the credit side (one credit account, one currency, one execution day) and data which applies to all the dependent C levels and is contained in Segment Group 4 through Segment Group 10.

   - Level C contains mainly data related to the debit side and, may contain remittance information. This data is considered as unique for each debit transaction and is contained in Segment Group 11 through Segment Group 23.

The structure of the message is designed to allow several B levels, each B level being followed by its related C levels.
  Generated by GEFEG.FX