CRG Message Specifications REMADV Stripped Version, November 2001
SPECIFICATIONS OF THE REMITTANCE ADVICE MESSAGE
REMADV
Contents
· 1 Introduction & Scope
· 2 Structure Overview
· 3 Business Information
· 3.1 Index to Good Business Practice Requirements
· 3.2 Definitions
· 4 Segment Specification
· 5 Message Format Specification
· 5.1 Segment Listing
· 5.2 Branching Diagram
This document has been stripped after acceptance of the proposed changes by the Corporate Reference Group working party on November 16, 2001.
It is based on the “UK Message Specification – REMADV” APACS document of 1998/04/27.
All elements, which are specified as “not used”, are deleted in this document (unless required in the composite fields).
Main changes are:
- deletion of specific UK references
- addition of “requested execution date”
- date format 102 (CCYYMMDD) is default and only format supported
- back reference to Payment order in RFF+CR
- added Payer as optional party in the payment process, in order to differentiate with the “on-behalf-of” party
- specified COM segment in international dialling mode
- clear rules how to specify currencies and exchange rates
- deleted DTM segment specifying the FX-rate date applied
- clear rules how to specify amounts
- added discount amount applied per document as optional element
- added Invoicee and Invoicer at document level to specify the parties involved in the commercial process, if different from financial parties
- defined date of document as mandatory field
- deletion of reference texts at document level
- deletion of line item specifications
- added total amount in Payment order currency
Royal Philips Electronics
Corporate Treasury
Robert K. Bol
+31402780472
page 2 (2)
CRG Message Specifications REMADV Stripped Version, November 2001
1 INTRODUCTION & SCOPE
This message implementation guideline covers the remittance advice message.
This message implementation guideline (MIG) for REMADV is based on the usage of the remittance advice part of the EEG04 draft MIG for the Multiple Payment (PAYMUL) message. It has been modified, by marking certain conditional elements and deleting segments which are ‘not used’ and by identifying the most relevant code values, to comply with Trade Messages specification for a 'minimum requirements, good business practice' remittance advice.
1.1 Scope
The purpose of this message is to communicate a detailed specification relating to a payment or other form of financial settlement on a particular date in respect of goods or services provided between the buyer or his agent and the seller or his agent. The electronic format should enable the receiver of the message to automatically reconcile the specification of the payment with the open items in his accounts receivable.
The Remittance Advice message may be used in one of two ways. In both cases, using the separate Remittance Advice means that the Beneficiary has an additional matching process to link the credit and the invoices it is settling. Keeping payment and remittance information together throughout the cycle avoids the additional matching process. But inter-bank communication has limited capacity to forward the remittance details. Also (electronic or paper) bank statements provide limited capacity.
In one scenario, a Payment Order with integral remittance information is sent by a customer, the Ordering Party, to their bank, the Ordered Bank, to instruct the bank to make payment(s). One payment can be ordered by PAYEXT, one or more payments to one or more Beneficiaries by PAYMUL.
The Beneficiary has elected (or by limited capacity of the bank statement is forced) to receive electronic payment and remittance information separately. The Beneficiary's bank creates a credit advice (CREMUL or CREEXT) without remittance information and creates a Remittance Advice message using the remittance information from Payment Order, that has been carried across in the inter-bank payment. Essentially the format of the remittance information enclosed within the Payment Order is the same as in the Remittance Advice. The main task is to add sender and receiver information and to cross-refer payment and remittance.
In the alternative scenario, the customer or Ordering Party forms separate Payment Order and Remittance Advice messages, and is consequently responsible for adequately cross-referring them. The Ordering Party sends the Payment Order to the Ordering Party's bank for onward transmission to the Beneficiary via the Beneficiary's bank, and sends the Remittance Advice direct to the Beneficiary
1.2 Rules for Use
A Remittance Advice is a notice of an intention to pay, or of payment made.
A Remittance Advice may cover one financial transaction and or more commercial trade related transactions such as invoices, credit notes, debit notes, etc.
A single Remittance Advice relates to either a national or an international settlement.
Remittance details shall be specified in only one currency. In case a payment has been ordered in a currency different from the remittance details, the FX-rate applied will be specified..
Each Remittance Advice shall relate to only one settlement date.
In addition, following the principles of Good Business Practice :-
The Remittance Advice message shall not be used to identify monetary adjustments made directly to payment amount due. To follow strict accounting and VAT control principles, adjustment shall be made by use of a separate Debit or Credit Note which then appears as another 'settled transaction' in the Remittance Advice.
The Good Business Practice approach is highly recommended.
page 4 (4) Chapter 1 - Introduction
CRG Message Specifications REMADV Stripped Version, November 2001
2 STRUCTURE OVERVIEW
2.1 Overview
Many messages can be sent in an EDI interchange. The ‘interchange sack’ is formed by the UN/EDIFACT segments UNB and UNZ, while the ‘message envelope’ is provided by the segments UNH and UNT.
The Remittance Advice (REMADV) message has three main sections.
A. Header Section
This level contains general information relating to the message as a whole, such as its identifying number, issue date, related payment order and so on.
B. Remittance Detail
This level conveys the remittance information about the related documents/transactions and (not in the limited CRG version) about individual lines within those documents/transactions. Remittance information can also include the totals of the remittance detail amounts.
C. Summary Section
This section occurs once at the end of the message and provides summary amounts.
The diagram shows general blocks of information. The diagrams on the following pages show the different pieces of business information in each block
These are followed by an index of all the pieces of information, in which each piece is annotated to show its place within the UN/EDIFACT message.
2.2 Interchange Message Infrastructure Information
The interchange ‘sack’ needs a label, and the adjacent picture identifies its information content.
In EDIFACT, this aspect of the interchange is contained in two segments, an interchange header segment (UNB) and an interchange trailer segment (UNZ). The interchange identity is repeated in the header and in the trailer to allow checking that the interchange is intact, while the number of messages acts as a control count. One or more messages can be placed within an interchange ‘sack’. They can be different message types.
The next picture shows the message ‘envelope’. This also comprises two segments, a message header segment (UNH) and a message trailer segment (UNT). As with the Interchange Identity, the Message Identity No. is repeated in both the header and trailer, so that the end-to-end integrity of the message can be checked. The number of segments enables a further check to be made. The Message Type ID and Version tells the receiving software exactly what layout the message data conforms to. In this case, the Message Type Id. is REMADV, and it conforms to the D96A message structure.
Clearly there must only be one interchange header (UNB) and trailer (UNZ) in an interchange. Similarly there must be only one message header (UNH) and message trailer (UNT) for a single message. However, there can be several messages in an interchange; each UNH-?-UNT set is a message. The information identified in the diagrams is conveyed within the segments as follows:
Name of Information Chapter/Section UN/EDIFACT Segment/Element
Interchange Syntax 4.1 UNB S001/0001
Interchange Sender 4.1 UNB S002/0004
Interchange Receiver 4.1 UNB S003/0010
Interchange Preparation Date/time 4.1 UNB S004/0017
Interchange ID No. 4.1 UNB 0020
and in 4.21 UNZ 0020
Interchange Count of Messages 4.21 UNZ 0036
Message Format 4.2 UNH S009/0065
Message Format Version 4.2 UNH S009/0052-4
Message ID No. 4.2 UNH 0062
and in 4.20 UNT 0062
Message Count of Segments 4.20 UNT 0074
page 6 (6) Chapter 2 - Structure Overview
CRG Message Specifications REMADV Stripped Version, November 2001
2.3 Business Information Blocks
The message is denoted as a remittance advice by the message name. The remittance advice is given a unique number by its originator, and the date of issue is stated. Each remittance advice relates to one individual payment order. It gives payment references which are meaningful to the beneficiary, and to the ordering party in case of queries. Other references can also be given.
The means of payment can also be detailed.
.
The commercial parties involved can be specified, being identified by a party identification number from some recognised scheme, such as the EAN customer number system, or by a name and address.
Contact details such as contact name and telephone number can also be given.
The financial details of the parties involved can be specified, using either the BIC or the branch sort code, together with the account number and account holder name. If necessary, the currency of the account can also be specified.
The remittance information can be as simple as quoting a single invoice number and the amount due/amount remitted. Or it can be as complex as a list of referred documents/transactions.
Each referred document is identified by its type (e.g. invoice) and its unique reference number. The amount due and the amount remitted can be stated for each document, and a currency can also be detailed. If an adjustment has been made to the amount, making a difference between amounts due and remitted, the reason for the adjustment can be stated.
The total remittance amount can be declared in the summary part of the message.
page 8 (8) Chapter 2 - Structure Overview
CRG Message Specifications REMADV Stripped Version, November 2001
3 BUSINESS INFORMATION
3.1 Index
The pieces of business information identified in the blocks on the preceding pages are conveyed within the UN/EDIFACT message REMADV as is indicated in the column UN/EDIFACT Segment/element.
These elements are a subset of the UN/EDIFACT message REMADV. They represent the information requirements to meet the Good Business Practice specification. The full detail for the segment can be found in the chapter/section shown, e.g. 4.3.
Name of Information Chapter/Section UN/EDIFACT Segment/Element
A HEADER
Message name 4.3 BGM C002/1001
Message Number. 4.3 BGM 1004
Message issue date/time 4.4 DTM C507/2380
(alias Document date)
References 4.5 RFF C506/1154
Payment order number
Dates 4.4 DTM C507/2380
Payment due date
Requested execution date
Currency 4.12 CUX C504//6345
of commercial document
of payment
Exchange rate 4.12 CUX 5402
Payment Means 4.7 PAI C534/4461
Party information
Financial party role 4.6 FII 3035
Ordered Bank
Beneficiary's Bank
Account number 4.6 FII C078/3194
Account name 4.6 FII C078/3192
Bank identification code (BIC) 4.6 FII C088/3433
Branch sort code 4.6 FII C088/3434
Account country 4.6 FII 3207
Commercial party role 4.9 NAD 3035
Ordering Party
Beneficiary
Payor
Commercial party identification no. 4.9 NAD C082/3039
Commercial party name
Party/company name 4.9 NAD C080/3036
Commercial party address
Street name/no./PO box no. 4.9 NAD C059/3042
Town/city 4.9 NAD 3164
County 4.9 NAD 3229
Post code 4.9 NAD 3251
Country 4.9 NAD 3207
Contact function 4.10 CTA 3139
Accounts payable contact
Accounts receivable contact
Contact name 4.10 CTA C056/3412
Contact code 4.10 CTA C056/3413
Contact communication no. 4.11 COM C076/3148
Contact communication channel 4.11 COM C076/3155
Remittance text 4.8 FTX C108/4440
B REMITTANCE DETAIL
Referred document type 4.14 DOC C002/1001
Referred document identity no. 4.14 DOC C503/1004
Referred document amount 4.15 MOA C516/5004
Referred document amount currency 4.15 MOA C516/6345
Referred document related date 4.16 DTM C507/2380
Referred document party role 4.17 NAD 3035
Invoicer
Invoicee
Referred document Party id. 4.17 NAD C082/3039
Referred document Party - Company name 4.17 NAD C080/3036
Referred document Party - Address
Street name/no./PO box no. 4.17 NAD C059/3042
Town/city 4.17 NAD 3164
Post code 4.17 NAD 3251
Country 4.17 NAD 3207
C SUMMARY
Remittance total amount 4.19 MOA C516/5004
Remittance total amount currency 4.19 MOA C516/6345
3.2 Definitions - A Glossary of Terms
Account country
The country in which an account is held.
Account currency
The currency in which an account is held.
Account name
The identifying name given to an account.
Account number
The identifying number of an account
Amount due/payable
The amount which is due to be paid. This may appear in several places in a single message; as the amount to be paid against an individual referred document in the remittance section, as the amount to be paid against an individual payment order, and as the total amount to be paid for a whole batch of individual payment orders.
Bank identification code (BIC)
An international coding scheme for identifying banks, also known as SWIFT code.
Beneficiary's Financial Institution
The Financial Institution with whom the beneficiary maintains an account on which he receives the funds.
Beneficiary's Identification Number
The beneficiary's identification number is a number identifying the party benefiting from the payment. It may be:
· the bank account number,
· a commercial party id., according to some recognised scheme
· any other type of identifier.