List of Contents: Extended MT940 Customer Statement Message

Extended MT940 Customer Statement Messag e
LIST OF CONTENTS
1. INTRODUCTION .......................................................................................................................................3
2. HOW TO READ THIS DOCUMENT.......................................................................................................3
3. WHAT IS AN EXTENDED MT940? ........................................................................................................4
3.1 WHAT WILL COMPANIES GET? ..................................................................................................................4
3.2 HOW DOES IT LOOK?..................................................................................................................................4
4. WHICH LIMITATIONS DO YOU MEET? ............................................................................................7
4.1 THE KIND OF ENTRIES THAT DANSKE BANK SUPPORT ............................................................................7
4.2 THE SCOPE OF THE MT940-FORMAT ........................................................................................................7
4.3 DO ALTERNATIVES TO THE EXTENDED MT940 EXIST?...........................................................................7
5. REQUIREMENTS TO THE ERP-SYSTEM IMPORTING THE EXTENDED MT940 ....................9
6. IF YOUR COMPANY HAS DECIDED TO USE THE EXTENDED MT940 ....................................10
7. USE OF THE EXAMPLES ......................................................................................................................11
8. SWEDISH ACCOUNT .............................................................................................................................12
8.1 AUTOGIRO (DIRECT DEBIT) .....................................................................................................................14
8.1.1 EXAMPLE AUTOGIRO PAYMENTS ...........................................................................................................14
8.1.2 FORMAT DESCRIPTION FOR AUTOGIRO PAYMENTS ................................................................................15
8.2 BANKGIRO INBETALNINGAR (BANKGIRO RECEIVABLES).....................................................................17
8.2.1 EXAMPLE BANKGIRO RECEIVABLES PAYMENTS ....................................................................................17
8.2.2 FORMAT DESCRIPTION FOR BANKGIRO RECEIVABLES ...........................................................................18
9. NORWEGIAN ACCOUNT ......................................................................................................................20
9.1 KID PAYMENTS ........................................................................................................................................25
9.1.1 EXAMPLE KID PAYMENTS ......................................................................................................................25
9.1.2 FORMAT DESCRIPTION FOR KID PAYMENTS ..........................................................................................26
9.2 KID PAYMENTS WITH ERRORS ................................................................................................................27
9.2.1 EXAMPLE KID PAYMENT WITH ERRORS .................................................................................................27
9.2.2 FORMAT DESCRIPTION FOR KID PAYMENTS WITH ERRORS ....................................................................28
9.3 AUTOGIRO ................................................................................................................................................29
Page 1 of 38
9.3.1 EXAMPLE AUTOGIRO PAYMENTS ...........................................................................................................29

9.3.2 FORMAT DESCRIPTION FOR AUTOGIRO PAYMENTS ................................................................................30
9.4 ELECTRONIC PAYMENTS .........................................................................................................................32
9.4.1 EXAMPLE ELECTRONIC PAYMENTS ........................................................................................................32
9.4.2 FORMAT DESCRIPTION FOR ELECTRONIC PAYMENTS .............................................................................33
9.5 GIRO PAYMENTS.......................................................................................................................................35
9.5.1 EXAMPLE GIRO PAYMENTS ....................................................................................................................35
9.5.2 FORMAT DESCRIPTION FOR GIRO PAYMENTS .........................................................................................36
9.6 STRUCTURED PAYMENTS .........................................................................................................................37
9.6.1 EXAMPLE STRUCTURED PAYMENTS........................................................................................................37
9.6.2 FORMAT DESCRIPTION FOR STRUCTURED PAYMENTS ............................................................................38
Change log
Version
2.4.1
2.4.2
Date
2013-10-07
2015-08-20
Change
Change log added
Name changes to NETS and BankGirot
Page 2 of 38
1.
Introduction
The ERP-systems that most companies use have built-in functions to automatically accomplish reconciliation
of financial transactions. However, the quality of the reconciliation is no better than the quality of the input information. To help companies improve the rate of automatically matched transactions, Danske Bank has
developed the Extended MT940. Within the scope of the Standard MT940, the Extended MT940 should
always provide as much relevant information to the receiver, as Danske Bank could possibly procure.
If the company has disposal of Swedish and/or Norwegian accounts in Danske Bank, use of this first version
of the Extended MT940 should be considered. In the following sections the highlights and limitations of the
Extended MT940 will be treated.
2.
How to read this document
This document is addressed to decision makers and end users of companies using the MT940 sent from
Danske Bank on Swedish and Norwegian accounts. The purpose is to describe the Extended MT940 delivered
by Danske Bank. The description serves several purposes. Consult the following table in order to select those
parts of the description relevant to you.
If you need to
Know what facilities the Extended MT940 offers
Know about the limitations of the Extended MT940
Know about the requirements for use of the Extended MT940
Know what to do, if your company wants to use the Extended MT940
Know the format of a Swedish, Extended MT940
Know the format of a Norwegian, Extended MT940
See some examples of a Swedish, Extended MT940
See some examples of a Norwegian, Extended MT940
Read section(s)
3
4
5
6
8
9
7, 8
7, 9
If you find something unclear or erroneous, we would be very grateful to hear about it. In that case, send an
email with your suggestions to [email protected].
Page 3 of 38
3.
What is an Extended MT940?
3.1
What will companies get?
The MT940 is a standard defined by the S.W.I.F.T organisation. The standard defines an electronic account
statement. Danske Bank provides MT940s on a daily basis sent via either the SWIFT network or a direct connection to the companies owning the accounts.
The Extended MT940 differs from the Standard MT940 in the way, that Swedish and Norwegian global
transactions on accounts in Danske Bank can be replaced by the single credit entries from the respective
clearinghouses, which are Bankgirot (Bankgirocentralen BGC AB) in Sweden and Nets in Norway.
The specifications in the Swedish, Extended MT940 correspond to sum bookings on the account.
The specifications in the Norwegian, Extended MT940 correspond to those given in the paper/E-Mail/Fax
statement called Melding om innbetaling or Melding om kreditering from Nets.
3.2
How does it look?
The format of the Extended MT940 is similar to the format of the Standard MT940. Therefore, a detailed format description will not be shown in this document. Following the Internet-link
http://www.danskebank.com/IntegrationServices and navigating to Formats by standard -> SWIFT MT
will bring the reader to a detailed description of the Standard format as provided by Danske Bank.
In table 3-1 below, the fields of the Extended MT940 are summed up with comments and examples of use.
The mapping shown for the fields 61 and 86 apply to Nets/Bankgirot specification entries only. The mapping
for any other type of entries is unaffected compared to the Standard format. Thus, primarily we have described
the former.
A more detailed description of fields 61 and 86 can be found in sections 8 and 9.
Page 4 of 38
Table 3.1 Extended MT940 fields with examples of contents including an OCR entry from Bankgirot in Sweden.
MT940 Contents of field
Example data
Remarks
field
20
Transaction Reference
3996- 4993172529
Number
25
28C
Account number
9180 4993172529
Statement/Sequence
473/1
Number
60M
Intermediate Opening
If current MT940 sequence is
Balance
not the first in the statement.
60F
Final Opening Balance
C020808SEK3682746,67
61,1
Value Date
0208120809CK75,00NMSC05136551
61,2
Booking Date
0208120809CK75,00NMSC05136551
The booking date is only

available when using the
MT940SW format, the special
SAP MT940 does not display
this date.
61,3
Debit / Credit mark
0208120809CK75,00NMSC05136551
C or D
61,4
Funds Code
0208120809CK75,00NMSC05136551
3 character of ISO Currency
rd
Code
61,5
Amount
0208120809CK75,00NMSC05136551
61,6
Transaction Type
0208120809CK75,00NMSC05136551
NMSC otherwise
Identification Code
61,7
Reference for the Account
0208120809CK75,00NMSC05136551
Owner
61,8
See following sections for

further examples
Account Servicing
Institutions Reference
NRTI for a credit note
Used for continuation of sub

1
field 61,7 , if contents of that

field are more than 16
characters.
61,9
Supplementary Details
Used for Nets transactions

only
86
62M
Information to Account
05136551
See following sections for
Owner
OCOC200208120016300001
further examples
Intermediate Closing
If current MT940 sequence is
Balance
followed by another sequence

in the same statement.
62F
Final Closing Balance
C020809SEK3235097,62
Note that Danske Banks standard use of fields 61,8 and 61,9 are quite the opposite of, what the SWIFT
standard prescribes.
1
Page 5 of 38
MT940 Contents of field
Example data
Remarks
field
64
Closing Available Balance
C020809SEK3243830,65
86
Information to Account
This account is part of a
Owner
Group CashPool ...
Global for the statement
Page 6 of 38
4.
Which limitations do you meet?
4.1
The kind of entries that Danske Bank support
In sections 8 and 9 we have outlined the different kinds of entries/transactions that the Extended MT940
supports.
Regarding the Swedish Extended MT940 some facilities are not supported:
The Extended MT940 does not support domestic Euro-specifications on Swedish accounts.
If a company makes transfers via Bankgirot, which are internal to that company, specifications from
Bankgirot do not match our bookings correctly. In short term, avoiding such internal transfers via
Bankgirot would of course solve the problem.
4.2
The scope of the MT940-format
Danske Bank provides as much information from Nets and Bankgirot as possible in the Extended MT940.
However, for each entry the space to hold the information is limited by the MT940 Standard. Most
information, like name and address of payer, will be put into the field Information to Account Owner with
the field number 86. Field 86 is capable of containing 6 by 65 characters of information. In most situations
this is sufficient, but sometimes it is not, and then information will be lost to the receiver.
Because of the limited capacity of field 86, we will pack the information, and separate some items by the
character sequence / (blank, slash, blank). The packing includes replacing multiple, consecutive blank
characters with a single blank.
In spite of the data packing, loss of information will happen now and then. To reduce the informational consequences of this loss, we have found the following priority of information in field 86 appropriate:
1. Payment references.
2. Message lines from payer.
3. Identification of debit account.
4. Name and address of payer.
4.3
Do alternatives to the Extended MT940 exist?
As an electronic statement the SWIFT MT940 is less flexible than the corresponding EDIFACT statement
called a FINSTA (FINancial STAtement). For example textual messages in a FINSTA could be much larger.
Furthermore a FINSTA allows a more firm structure of the information associated to a given entry. Danske
Bank offers FINSTAs as an alternative to MT940s. However, currently detailed specifications of Swedish and
Norwegian global amounts are only available in the Extended MT940.
Details in payment information might also be obtained from the EDIFACT / CREMUL format, that Danske
Bank offers. But essentially a CREMUL is just a list of in payments without balance information and without
Page 7 of 38
payment entries (debits). For Swedish accounts, a CREMUL could be produced in a HTML readable format in
case a company is not able to interpret the CREMUL-format. In fact, the HTML-CREMUL is what we might
propose in emergency situations, where the in payment specifications are temporarily unavailable via the
Extended MT940.
Page 8 of 38
5.
Requirements to the ERP-system importing the Extended MT940
Use of the Extended MT940 requires features of the MT940-importing ERP-system to handle the following
aspects of the Extended MT940:
The ERP-system must support the Standard MT940 as per the SWIFT Standard.
Though the global entries of Danske Bank will always be credit amounts (positive numbers), the
specification amounts could very well be negative. For example, this is the case when the account owner
grants a credit note to some creditor. Credit notes are recognised by the Transaction Type Identification
Code of field 61 containing the value RTI.
Now and then specification amounts will be zero.
Some specification amounts associated to the same global amount might be equal. In that case the
contents of the message field can usually be used to distinguish between the equal amounts.
In one MT940 the amounts are sorted, starting with the lowest, very often negative amounts. This implies
that specification entries belonging to the same global amount might be mixed with entries not
associated to that global amount.
In principle the number of entries into which a global transaction can be broken, is from one to any
number.
An aspect of using field 86 to hold information concerning a given entry is, that especially the
specification file from Nets contains optional fields. This means that the format of the MT940 field 61 and
86 is not well defined. Moreover, as field 86 is a free format text field, it might occasionally be hard to
identify the exact meaning of the information in that field. In the process of automatically matching data
from the companys own ERP-system with data in the MT940, it is essential that key data can be
identified in the MT940. Therefore, the information of the more firmly structured field 61 sometimes
provides the best matching key.
Page 9 of 38
6.
If your company has decided to use the Extended MT940
If your company wants to use the Extended MT940, you should address your usual contact in Danske Bank.
We will need the company to sign an agreement form. From the time Danske Bank receives the signed form,
we will normally need 2 weeks until your company will receive the first Extended MT940.
There are a few things to be aware of about the first MT940:
If the company already receives
MT940s from Danske Bank
If the type of MT940 that the company
already receives, includes specifications
for a cash pool account
If the company wants a Swedish,

Extended MT940
If the company wants a Norwegian,

Extended MT940
If the company wants to test the

Extended MT940
The statement number of the first Extended MT940 will be one

higher than the last in the Standard format.
The Extended MT940 will sum the cash pool sweeping transactions
for a given account by
- Account number of related account
- Value date
- Booking date
From the first day the company receives the Extended MT940,
Bankgirot will no longer be able to send a file containing the same
specifications directly to the company.
From the first day the company receives the Extended MT940 Nets
will no longer be able to send a file containing the same specifications directly to the company. Nor will Nets be able to deliver a
paper statement containing those specifications.
Danske Bank does not provide a special test MT940. This is
because Nets and Bankgirot cannot provide test specifications in a
form suitable to Danske Banks MT940 environment. Instead we
have enclosed some examples with comments given below.
Page 10 of 38
7.
Use of the examples
In section 8 and 9 we will turn to some examples starting with the Swedish transaction types. For each
example we will show a full MT940 illustrating a particular transaction type. We have enclosed the
corresponding MT940 files for the reader to enter into a test ERP-system.
Data from Bankgirot and Nets are similar but not identical in structure. Therefore we have separated the
descriptions accordingly. Complete but fictive MT940s are shown, and after each MT940 we comment on that
particular message. We have tried to catch and show as many aspects of the Extended MT940 as possible and
simultaneously to limit the volume of the examples. The Extended MT940 will always be compared to the
Standard MT940, as the reader is supposed to be more familiar with the latter. Tables describing the full set of
data that we receive from Bankgirot and Nets follow the examples.
The structure of the descriptions differs slightly between the Swedish and Norwegian examples. The Swedish
examples are divided into separate examples for each transaction type. To each example an MT940-file is
attached. The Norwegian examples are built upon one, large example file including all transaction types.
However, the formats of entries of a given transaction type are described in turn.
The reader is encouraged to examine all examples for the country in interest in order to get the full benefit
from the examples. It would even be useful to examine the full set of examples, because the examples
illustrate general, country independent points in somewhat different manners.
Page 11 of 38
8.
Swedish account
Specifications for Swedish accounts are delivered to Danske Bank from Bankgirot in Sweden. A transaction
specification from Bankgirot can be of of two different types. Both are supported in the Extended MT940, and
they are shown in table 8-1. A given global transaction is categorised into one of these two types.
Table 8-1 The two different, fundamental transaction types from BGC.
Transaction type
Autogiro (Direct Debit)

Bankgiro Inbetalningar (Receivables)
The contents of the MT940 fields 61 and 86 slightly depend on the transaction type, so lets investigate the
transaction types in turn. Only the contents of those sub fields of field 61 that differ from the description in
table 3-1 have been included.
Page 12 of 38
Page 13 of 38
8.1
Autogiro (Direct debit)
Autogiro is Swedish direct debit product in SEK. There are two different formats (an old and a new) . Both
formats are supported by Danske Bank. With Autogiro you have different formats for notification of mandates
and. Regarding the Extended MT940, only the in payments can be broken up and that is the layout Payment
specifications.
Examples of Autogiro are shown below. The comments will guide you through the example. In section Error!
Reference source not found. we have given a more formal description of the format. The raw MT940 is
available in a separate document called Extended MT940 examples and txt documents. Follow the link in
that document called Autogiro example.txt.
8.1.1 Example Autogiro payments
The following example reflects the bookings on a fictive account 1241-55-09356 in Danske Bank shown in
table 8.4-1. The emphasised line is the global amount to be broken into detailed entries. In table 8.4-2 we have
shown an example of the standard MT940 compared to the Extended MT940. The notes of that table refer to
explanations beneath the table.
Table 8.4-1 Bookings including global Autogiro payment.
Booking
Value
Text
date
date
13.04
13.04
13.04
14.04
Opening balance
AUTOGIRO 51770825
13.04
14.04
Transf. 12307114578
Amount
Balance
(SEK)
(SEK)
40,01
2.540,22
2.580,23
10.000,00
12.580,23
Page 14 of 38
Table 8.4-2 Example of MT940 in standard and extended version. The two versions show the same transactions, but the
latter contains specifications instead of global amounts and vice versa. For an explanation of field numbers, refer to table
3-1. The entries shown correspond to the bookings of table 8.1-1.
Standard MT940
Extended MT940
Field
Note
Field
Note
Text
Text
20
3996-41-01-07656
20
3996-41-01-07656
25
DABADKKK-1241-55-09356
25
DABADKKK-1241-55-09356
28C 00112/006
28C 00112/006
60F D060412SEK2540,22
60F D060412SEK2540,22
61
0604130412CK40,01NMSC7899973276
2.1
61
0604130412CK30,01NMSC7899973276
86
7899973276 / 51770825
2.2
86
7899973276 / 51770825
86
DABADKKK
86
DABADKKK
86
1241-55-09356
86
1241-55-09356
86
DANSKE BANK
86
DANSKE BANK
61
0604130412CK10000,00NMSC7899973276
3.1
61
0604130412CK10,00NMSC7898873209
86
7899973276 / 51770825
3.2
86
7898873209 / 51770825
86
DABADKKK
86
DABADKKK
86
1241-55-09356
86
1241-55-09356
86
DANSKE BANK
HOLMENS KANAL 2-12
HOLMENS KANAL 2-12
86
DANSKE BANK
1.1
62M D060412SEK12580,23
61
0604130412CK100000,00NMSC7899973276
1.2
64
86
7899973276 / 51770825
86
DABADKKK
86
1241-55-09356
86
DANSKE BANK
C060412SEK0,
HOLMENS KANAL 2-12
HOLMENS KANAL 2-12
HOLMENS KANAL 2-12
62F D060412SEK12580,23
64
Note
C060412SEK0,
Explanation
1.1 1.2 Global amount. The amount will always be a positive number.
2.1,3.1
These emphasised lines contain the specifications of the global amount (note 1.1 1.2).
The global amount is not included in the extended MT940.
2.2,3.2
In this line, information has been packed. The single items have been separated by slashes.
8.1.2 Format description for Autogiro payments

In table 8.4-3 we have shown the data items that Danske Bank receives from Bankgirot for each specification
entry. Note that some items might be empty depending of what was provided by the sender. Finally, the
Page 15 of 38
format of the MT940 fields related to each specification entry is described in table 8.4-4.
Table 8.4-3 Data items for each specification entry as received from Bankgirot. The example data is copied from the
entry in table 8.4-2 labelled 3.1 3.2.
Item
Description of item
Example data
number
1.
2.
3.
4.
5.
6.
Credit Account
BGC Number of beneficiary
Invoice/Payment Reference
Currency Code
Amount
Booking Date
12415509356
51770825
7899973276
SEK
30,01
060413
Table 8.4-4 Mapping of the data items of table 8.4-3 to the MT940, field 61 and 86. Some items are not used for this
transaction type. MT940 sub fields not shown are formatted like the standard MT940, and thus not described here.
MT940 Field name
Field
Item number from
Remarks
specification file
61,1
Value Date
61,7
Reference to Account Owner
86,1-6 Information to Account Owner,
Not available
3
Value Date of global amount is used.

If item is empty then NONREF.
2, 3
Line 1 6
Page 16 of 38
8.2
Bankgiro Inbetalningar (Bankgiro Receivables)
Bankgiro Inbetalningar (Bankgiro Receivables) is the product for advising inpayments via Bankgirot.
Bankgiro Receivables is a complete deposit service which advice all payments paid via Bankgirot, despite
Autogiro (Direct debit).
Examples of Bankgiro Receivables are shown below. The comments will guide you through the examples.
The raw MT940 is available in a separate document called Extended MT940 examples and txt documents.
Follow the link in that document called Bankgiro Receivables example.txt.
8.2.1 Example Bankgiro Receivables payments
The following example reflects the bookings on a fictive account 1202-25-71170 in Danske Bank shown in
table 8.5-1. The emphasised line is the global amount to be broken into detailed entries. In table 8.5-2 we have
shown an example of the standard MT940 compared to the Extended MT940. The notes of that table refer to
explanations under the table.
Table 8.5-1 Bookings including global Bankgiro Deposits payment.
Booking
Value
Text
date
date
13.04
13.04
13.04
14.04
Opening balance
BI 51660885 00001
13.04
14.04
Transf. 12410011452
Amount
Balance
(SEK)
(SEK)
20,10
3.000,00
3.020,10
10.000,00
13.020,10
Page 17 of 38
Table 8.5-2 Example of MT940 in standard and extended version. The two versions show the same transactions, but the
3.1. The entries shown correspond to the bookings of table 8.5-1.
Standard MT940
Extended MT940
Field
Note
Field
Note
Text
Text
20
3996-02-25-71170
20
3996-02-25-71170DABADKKK/
25
DABADKKK/1202-25-71170
25
DABADKKK/1202-25-71170
28C 00001/002
28C 00001/002
60M C060304SEK3000,00
60M C060304SEK3000,00
1.1 61
050926CK
1.2 86
MSC?20 BI 51660885 00001
20,10NMSC BI 51660885 00001
2.1
61
050926CK
2.2
86
MSC?20REF NR 1012345607 / RAD 1 MED REF 1098765405 /
10,00NMSC1012345607
01020888
61
050926CK
86
MSC?20 Transf. 12410011452
10000,00NMSC Transf. 12410011452
3.1
61
050926CK
3.2
86
MSC?201012345607 / 00000000?30DABADKKK?311201-15-
10,10NMSC1012345607
72770?32DANSKE BANK
62F C060227SEK13020,10
61
050926CK 10000,00NMS1012345607
86
MSC?20REF NR 1012345607 / RAD 1 MED REF 1012345607
62F C060227SEK13020,10
Note
Explanation
1.1 1.2 Global amount. The amount will always be a positive number.
2.1,3.1
These emphasised lines contain the specifications of the global amount (note 1.1 1.2).
The global amount is not included in the extended MT940.
2.2,3.2
In this line, information has been packed. The single items have been separated by slashes.
8.2.2 Format description for Bankgiro Receivables

In table 8.5-3 we have shown the data items that Danske Bank receives from Bankgirot for each specification
entry. Note that some items might be empty depending of what was provided by the sender. Finally, the
format of the MT940 fields related to each specification entry is described in table 8.5-4.
Page 18 of 38
Table 8.5-3 Data items for each specification entry as received from Bankgirot. The example data is copied from the
entry in table 8.5-2 labelled 2.1 2.2.
Item
Description of item
number
1.
Credit Account
2.
BGC Number of beneficiary
3.
Invoice/Payment Reference
4.
5.
Currency Code
Amount
6.
7.
Booking Date
Name and address of payer
Example data
12022571170
01020888
Reference per payment type:
20: 1012345607
21:
22: REF NR 1012345607
23:
SEK
10,00 (The payment can be negative if the
payment type is 21 or 23)
060304
MT940 Field name
Field
Item number from
Remarks
specification file
61,1
Value Date
61,7
86,1-6 Information to Account Owner,
Not available
3
Value Date of global amount is used.

If item is empty then NONREF.
2, 3,7
Line 1 6
Page 19 of 38
9.
Norwegian account
Specifications for Norwegian accounts are delivered to Danske Bank from Nets in Norway. As a basis for the
Extended MT940, Danske Bank uses Nets service called eGiro innbetaling via the file format EDIFACT/
CREMUL.
A transaction specification from Nets can be of six different, fundamental types, all of which are supported in
the Extended MT940, and they are shown in table 9-1. A given global transaction is categorised into one of
these six types depending on its text reference.
If a company receives a standard MT940 on a Norwegian account, there will in general be no global
transactions. Instead, every single transaction will be present in the MT940. But in contrast to the Extended
MT940, the amount of information for each single transaction will be rather poor compared to the
corresponding information on paper received from Nets. In particular this is true for accounts in Danske Bank,
Norway.
While examining the transaction types in turn, the reader may wonder, why the features of those types seem to
overlap. Strictly speaking, the reason for having six transaction types is more historical than based on
systematic arguments. So, dont get confused, just accept realities.
In the following sections we have briefly defined the transaction types in turn. For further information on the
various transaction types, contact Nets (www.nets.eu).
Table 9-1 The six different, fundamental transaction types from Nets.
2
Transaction type
Valid KID payment (type code 230)
Payment with invalid KID (type code 231)
AutoGiro payment (type code 232)
Electronic payment (type code 233)
Giro payment (type code 234)
Structured payment (type code 240)
The contents of the MT940 fields 61 and 86 slightly depend on the transaction type, so lets investigate the six
transaction types in turn. Only the contents of those sub fields of field 61 that differ from the description in
table 3-1 have been included.
All payment types are represented in the following example, which covers one days bookings on the fictive
account 81791005000. Of course, not all types need be present on a given booking day. On the other hand, a
given type can occur with more than one entry. The bookings are shown in table 9-2.
In the CREMUL format, transaction types are identified by so called BOLS codes, which are essentially the
text codes giving the texts shown in the table column Text reference of global transaction. The BOLS codes
are shown in () like (type code 231).
Page 20 of 38
Table 9-2 Bookings on account 81791005000 with booking date June 27 th 2003.
Booking
Value
Date
date
27.06
27.06
27.06
Text
Amount
Balance
(NOK)
(NOK)
27.06
Opening balance
CREMUL Elektr.indb.Total
6.000.000,00
91.308.888,8885.308.888,88-
27.06
CREMUL m/KID Total 01927
46.319,65
85.262.569,23-
27.06
27.06
CREMUL m/fejl KID Total
49.635,00
85.212.934,23-
27.06
27.06
Corr., prev. exec. Trans
5.000.000,00-
90.212.934,23-
27.06
27.06
27.06
27.06
Overfrsel
CREMUL Elektr.indb.Total
50.033,66
3.646.583,83
90.162.900,57-
27.06
27.06
CREMUL AutoGiro Total 00
2.911.264,27
83.605.052,47-
27.06
27.06
CREMUL Giro indb. Total
151.723,00
83.453.329,47-
27.06
27.06
CREMUL m/strukt Total
0,00
83.453.329,47-
86.516.316,74-
The specifications of these bookings were reported in an Extended MT940. The raw MT940 is available in a
separate document called Extended MT940 examples and txt documents. Follow the link in that document
called Norwegian example.txt.
In table 9-3 the contents of the file is shown compared to the corresponding MT940 in standard format. The
emphasised lines of the standard MT940 part of the table are the global amounts to be broken into detailed
entries. Comments to table 9-3 can be found in the following sections.
Page 21 of 38
Table 9-3 Example of MT940 in standard and extended version. The two versions show the same transactions, but the
3-1. The entries shown correspond to the bookings of table 9-2. Note that some MT940 lines of the standard format are
divided into two rows in the table, because the Text column is not wide enough.
Standard MT940
Field
Note
Field
Note
0a
Text
Extended MT940
Text
20
3996-79.10.05000
20
3996-79.10.05000
25
8179.10.05000
25
8179.10.05000
28C 00258/00001
28C 00258/00001
60F D030626NOK91308888,88
60F D030626NOK91308888,88
61
0306270627DK5000000,NMSCBBSREF 878160498
61
0306270627DK5000000,NMSCBBSREF 878160498
86
Corr., prev. exec. Trans / BBSREF 878160498
86
Corr., prev. exec. Trans / BBSREF 878160498
61
49293391160
0000049293391160
Danske Bank
Danske Bank
0306270627CK46319,65NMSCBBSREF 90000000//
2.3a
61
0306270627DK10000,NRTI890033765
09216711201
0b
86
CREMUL w/KID 09216711201 / BBSREF 90000000
2.3b
1a
61
0306270627CK49635,NMSCBBSREF 90000000//
2.3c
1b
86
CREMUL w/err 01202917191 / BBSREF 90000000
2.3d
052260303067
61
0306270627CK50033,66NMSCBBSREF
3A.2a 61
0306270627CK0,NMSC3020575564
BBSREF 741690594
3A.2b
757499575
FANA SPAREINSTITUT, HER + NA, FELLESDATA
3A.2c 86
3020575564 / GALLE ANDELSFARM BA / FAKTURA 3111044
0306270627CK151723,NMSCBBSREF 90000000//
3A.2d
16.222,08 NOK 16222,08 BILAGSN R HOS OSS T 155.129,59 /
3A.2e
45315020278
*98200005
86
890033765 / 198 AG / 33175270570 / 9112083 / 3160024
01202917191
741690594//Transfer
86
4a
61
09278011951
4b
86
CREMUL Giro 09278011951 / BBSREF 90000000
2a
61
0306270627CK2911264,27NMSCBBSREF 90000000// 3A.2f
GALLE ANDELSFARM BA
07919852011
2b
86
3Aa 61
CREMUL AGiro 07919852011 / BBSREF 90000000
3A.2g
0306270627CK3646583,83NMSCBBSREF 90000000// 1.1a
POSTBOKS 2487 / POSTTERMINALEN / 3103 TNSBERG
61
0306270627CK4184,5NMSC1682159
08012791947
3Ab 86
CREMUL Elec. 08012791947 / BBSREF 90000000
1.1b
3Ba 61
0306270627CK6000000,NMSCBBSREF 90000000//
1.1c
*90000000
86
1682159 / 1100020010683436703 / 81056401148
08719194720
3Bb 86
5a
61
CREMUL Elec. 08719194720 / BBSREF 90000000
1.1d
0306270627CK0,NMSCBBSREF 90000000//
2.2a
HOVEDGRD PRODUKT
61
0306270627CK10000,NMSC890033765
09942797011
5b
86
CREMUL Struc 09942797011 / BBSREF 90000000
2.2b
*98200005
Page 22 of 38
Standard MT940
62F D030627NOK83453329,47
2.2c
64
D030627NOK83453329,47
2.2d
86
For your inform. IBAN no. NO5181791005000
1.2a
Field
Note
Field
Note
Text
Extended MT940
86
61
86
1682159 / 1100020010683432354 / 81056401148

HOVEDGRD PRODUKT
61
0.1b
0.1c
0306270627CK45450,5NMSC1682159
*90000000
1.2d
0.1a
890033765 / 198 AG / 33175270570 / 9112083 / 3160024

052260303067
1.2b
1.2c
Text
0306270627CK46319,65NMSC95114510
419056171
86
0.1d
95114510 / 07096018 / 46250720807

HILTMANN OLLE
61
0306270627CK50033,66NMSCBBSREF 741690594//Transfer
86
BBSREF 741690594
FANA SPAREINSTITUT, HER + NA, FELLESDATA
4.1a
61
4.1b
4.1c
0306270627CK151723,NMSC5506160863
*66789396
86
5506160863 / 30132476119
3B.1a 61
0306270627CK2514756,49NMSC20690167911
3B.1b
204519074
3B.1c 86
20690167911 / Roma 47 Norge AS BETALT 27.06.03 / 73042470905
3B.1d
Roma 47 Norge AS
3B.1e
Postboks 9248 Etterstad
3B.1f
0605 OSLO
2.1a
61
2.1b
2.1c
0306270627CK2911264,27NMSC711122973
*98200004
86
711122973 / 198 AG / 17775002115 / 9112083 / 3160024
2.1d
052260303067
3B.2a 61
0306270627CK3484243,51NMSC2038900369
3B.2b
747700795
3B.2c 86
2038900369 / CARL VEIMANN AS / fakt kr 3712981,35
3B.2d
3.484.243,51 minus tilgode 228737,84 forfall 27,06,2003 /
3B.2e
70010634928
3B.2f
CARL VEIMANN AS
3B.2g
BAKKEVEI 11 C
3B.2h
POSTBOKS 101 ALNABRU / 0614 OSLO
3A.1a 61
0306270627CK3646583,83NMSC2370302588
3A.1b
472090541
3A.1c 86
2370302588 / KONCERT KROEN AS / FAKT.NR.3110152
3A.1d
508.713,53 FAKT.DATO.28.05.2003 FAKT.NR .3112410
Page 23 of 38
Standard MT940
Field
Note
Field
Note
Text
Extended MT940
Text
3A.1e
3.000.000,00 FAK T.DATO.28.05.2003 FAKT.NR.3111392
3A.1f
137.870,30 FAKT.DATO.28.05.2003 / 82094670492
3A.1g
KONCERT KROEN AS / RSETERBAKKEN 1 / 6422 MOLDE
5.1a
61
0306270627CK100,00NMSC0175430
5.1b
86
0175430 / 5415671236892343 / 20030627 / 4824155
5.1c
Elektroniske AS
5.2a
61
0306270627CK200,00NMSC0143570
5.2b
86
0143570 / 3434136856751292 / 20030627 / 4824155
5.2c
Elektroniske AS
5.3a
61
0306270627DK300,00NMSC5804301
5.3b
86
5804301 / 2574736956733201 / 20030627 / 4824155
5.3c
Elektroniske AS
62F D030627NOK83453329,47
64
D030627NOK83453329,47
86
For your inform. IBAN no. NO5181791005000
Page 24 of 38
9.1
KID payments
A KID is short for KundeIDentifikation or customer identification. This Nets term is widely used in
Norway, and it is more general than just to identify a customer. Its use depends very much of the user, who
made a payment service agreement with Nets. But it is common that the KID identifies both the payment and
the payer to the beneficiary. Examples of KID payments are shown in table 9-3 and commented in section
9.1.1 . The comments will guide you through the example. In section 9.1.2 we have given a more formal
description of the format.
9.1.1 Example KID payments
The following notes refer to table 9-3.
Note
Explanation
0a b
Global transaction for KID payment in standard MT940 format.
0.1a d
Specification entry to global transaction. In this quite unusual case theres only one specifying
entry. So, of course the amounts of the entry must be equal to the corresponding global amount.
For a detailed description of the single items that make up the entire entry, see table 9.1-2 and 9.13.
Page 25 of 38
9.1.2 Format description for KID payments

In table 9.1-2 we have shown the data items that Danske Bank receive from Nets for each specification entry.
Note that some items might be empty depending of what was provided by the sender. Finally, in table 9.1-3
the format of the MT940 fields related to each specification entry is described.
Table 9.1-2 Data items for each specification entry as received from Nets. The example data is copied from the entry in
table 9-3 labelled 0.1a 0.1d. Apart from a few unimportant items, the example represents the total information of one
specifying transaction.
Item
Description of item
Example data
number
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Value Date
Nets Reference Date
Nets reference number
Date of reception at Nets
Credit Account number
Debit Account number
Archive Reference
KID Reference
Amount
Name and address of beneficiary
Payer ID
Senders name and address
Receivers name and address
Document number
Text reference on Credit Account
20030627
20030627
01202917191
20030626
81791005000
46250720807
419056171
95114510
46319,65
(Empty)
(Empty)
07096018
HILTMANN OLLE
(Empty)
2003062715150015
FRA: HILTMANN OLLE BETALT: 26.06.03
MT940
Field name
field
Item number from
Remarks
specification file
61,2
Booking Date
Not available
61,7
61,9
Account Servicing Institutions
Booking Date of global amount!
Reference
86,1-6
Information to Account Owner,
8, 12, 6, 13
If item 13 is empty, then 11 is used.
Line 1 6
Page 26 of 38
9.2
KID payments with errors
This transaction type is identical to the KID payments type. The global transactions of KID payments and KID
payments with errors differ in their booking texts, whereas the individual, detailed entries are usually
indistinguishable. So, whether a KID payment has a wrong KID or not is only possible to determine from the
contents of the specifications, if a KID reference is simply not present. In that case, the text No KID will
appear instead of a KID reference. Otherwise, the ERP-system will fail to match the entry to any of its own
invoice registrations, unless it uses other data items for the match, such as amount combined with payer ID.
Examples of KID payments with error are shown in table 9-3 and commented in section 9.2.1 . The comments
will guide you through the example. In section 9.2.2 we have given a more formal description of the format.
9.2.1 Example KID payment with errors
Note
Explanation
1a-b
Global transaction for KID payment with error in standard MT940 format.
1.1a-d
Specification entry to global transaction. In this quite usual case theres only one specifying
entry. For a detailed description of the single items that make up the entire entry, see table 9.2-2
and 9.2-3.
Page 27 of 38
9.2.2 Format description for KID payments with errors

Item
Description of item
Example data
number
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Value Date
Nets Reference Date
Archive Reference
KID Reference
Amount
Payer ID
Document number
20030627
20030627
07110929300
20030627
81791005000
81056401148
*90000000
1682159
4184,5
(Empty)
HOVEDGRD PRODUKT
1100020010683436703
(Empty)
(Empty)
2003062715150015
TANJA NORSK /
HOVEDGRD PRODUKT
MT940
Field name
field
Item number from
Remarks
specification file
61,2
Booking Date
Not available
61,7
61,9
Reference
86,1-6
8, 12, 6, 13
Line 1 6
Page 28 of 38
9.3
Autogiro
Another expression for Autogiro is Direct Debit. The payer allows the beneficiary to draw the amount due to
the beneficiary on the payers account through Nets. Nets administrates the agreement. Once the agreement
has been settled, the beneficiary can draw the outstanding debts without any interference by the payer. One
very common use of Autogiro transactions is subscriptions: Magazine fees, rent, insurance premium etc.
Examples of Autogiro payments are shown in table 9-3 and commented in section 9.3.1 . The comments will
guide you through the example. In section 9.3.2 we have given a more formal description of the format.
9.3.1 Example Autogiro payments
Note
Explanation
2a-b
Global Autogiro transaction.
2.1a-d,
Two specification entries. The entries do not appear right after each other. As the entries have been
2.2a-d,
sorted in the MT940 with the lowest amounts first, entries of any kind can follow any other kind.
&
2.3a-d
2.1a-d
A detailed description of this entry is given in table 9.3-1. It is worth noting, that information in
Autogiro transactions has the form of numerical references, not names and addresses or text
references.
2.2c-d
In this case, the last item of field 86 in the MT940 actually consists of two separate numbers.
2.3a-d
This entry has a negative amount and balances entry 2.2a-d. It is supposed to illustrate a situation,
where a customer (payer) has cancelled an agreement, but the invoice was already sent, so the
beneficiary made a credit note.
Page 29 of 38
9.3.2 Format description for Autogiro payments

Item
Description of item
Example data
number
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Value Date
Nets Reference Date
Archive Reference
Payment Order Reference
Amount
Payer ID
Document number
20030627
20030627
00971034969
20030627
81791005000
Not available
*98200004
711122973
2911264,27
Not available
Not available
3160024
052260303067
Not available
Not available
2003062715150015
17
Senders Reference
Not available
18
Autogiro Creditor Reference
198
19
Autogiro Debtor Reference
17775002115
20
Autogiro Agreement Number
9112083
Not available
AG
Page 30 of 38
MT940
Field name
field
Item number from
Remarks
specification file
61,2
Booking Date
61,7
Not available
8

If empty, item 18 is used
If item 18 is empty, item 19 is used
If item 19 is empty, item 20 is used
61,9
Reference
86,1-6
8, 18, 19, 20, 12
Line 1 6
Page 31 of 38
9.4
Electronic payments
This is a very general kind of payments. Except for Autogiro, it more or less covers the features of all other
payment types. It seems to be designed to meet the requirements of pure electronic transfers as for example
initiated by office banking systems. Therefore, the possible amount of information is larger than for any other
payment type.
Examples of Electronic payments are shown in table 9-3 and commented in section 9.4.1 . The comments will
guide you through the example. In section 9.4.2 we have given a more formal description of the format.
9.4.1 Example Electronic payments
Note
Explanation
3Aa-b &
Global Electronic Payment transactions. Up to four transactions of the same type are possible for
3Ba-b
Norwegian Netstransactions. Early morning, morning, afternoon and final settlement.
3A.1a-g & Two entries corresponding to global 3Aa-b.

3A.2a-g
3B.1a-f &
Two entries corresponding to global 3Ba-b.
3B.2a-h
3A.1c-h
For this transaction type, field 86 of the MT940 is very likely sooner or later to get too small. All six
lines have been used in this case. This is due to the long message from the sender. See table
9.4-1 for further details on this specific entry. The message lines are concatenated, and therefore
the message doesnt appear as pretty as the sender probably meant it to be. Anything else would
use further space, which we cannot afford to waste.
3A.2a
A zero amount just to show, that zero payments are possible too.
Page 32 of 38
9.4.2 Format description for Electronic payments

table 9-3 labelled 3A.1a 3A.1h. Apart from a few unimportant items, the example represents the total information of
one specifying transaction.
Item
Description of item
Example data
number
1
2
3
4
5
6
7
8
9
10
11
12
13
Value Date
Nets Reference Date
Archive Reference
Amount
Payer ID
20030627
20030627
02919017158
20030627
81791005000
82094670492
472090541
2370302588
3646583,83
(Empty)
(Empty)
(Empty)
KONCERT KROEN AS
RSETERBAKKEN 1
6422 MOLDE
TANJA OB
POSTBOKS 54 KERN
0508 OSLO
2003062715150015
14
15
16
Document number
17
Senders Reference
KONCERT KROEN AS
FAKT.NR.3110152
508.713,53
FAKT.DATO.28.05.2003
FAKT.NR.3112410
3.000.000,00
FAKT.NR.3111392
137.870,30
Page 33 of 38
MT940
Field name
field
Item number from
Remarks
specification file
61,2
Booking Date
Not available
61,7
61,9
Reference
86,1-6
8, 16, 17, 6, 13
Line 1 6
Page 34 of 38
9.5
Giro payments
This transaction type involves some kind of payment form, which the beneficiary sends to the payer with
some payment references pre printed. These references appear in the information from Nets for this type.
Examples of Giro payments are shown in table 9-3 and commented in section 9.5.1 . The comments will guide
you through the example. In section 9.5.2 we have given a more formal description of the format.
9.5.1 Example Giro payments
Note
Explanation
4a-b
Global Giro transaction.
4.1a-c
A single specification entry. Usually more than one is seen. The amount of information is rather
poor.
Essentially, the payment order reference is all we have together with the amount.
Page 35 of 38
9.5.2 Format description for Giro payments

table 9-3 labelled 4.1a 4.1c. Apart from a few unimportant items, the example represents the total information of one
Item
Description of item
Example data
number
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Value Date
Nets Reference Date
Archive Reference
Amount
Payer ID
Document number
Senders Reference
20030627
20030627
01927901605
20030627
81791005000
30132476119
*66789396
5506160863
151723,00
(Empty)
(Empty)
Not available
(Empty)
(Empty)
2003062715150015
Not available
Not available
MT940
Field name
field
Item number from
Remarks
specification file
61,2
Booking Date
Not available
61,7
61,9
Reference
86,1-6
8, 6, 13
Line 1 6
Page 36 of 38
9.6
Structured payments
A structured payment is nearly the same as "KID payments". The difference between "structured payments"
and "KID payments" is that a global entry for a structured payment can be detailed much more than is the case
for global entries of "KID payments". As a consequence credit notes (negative amounts) might occur in
specification entries. The use of structured payments depends very much of the user, who made a payment
service agreement with Nets. But it is common that the KID identifies both the payment and the payer to the
beneficiary. Examples of structured payments are shown in table 9-6.2 and commented in section 9.6.1 . The
comments will guide you through the example. In section 9.6.2 we have given a more formal description of
the format.
9.6.1 Example structured payments
Note
Explanation
5a-b
Global transaction for structured payment in standard MT940 format.
5.1a
Specification entries to global transaction. In this case there are three specifying entries, containing
5.3c
"KID payments". So, the sum of amounts on "KID payments" must be equal to the corresponding
global amount.
5.1a c
For a detailed description of the single items that make up the entire entry, see table 9.6-2 and 9.63.
5.3a c
This entry has a negative amount and balances entries 5.1a 5.2c. It is supposed to illustrate a
situation, where a customer (payer) has cancelled an agreement, but the invoices were already
sent, so the beneficiary made a credit note.
Page 37 of 38
9.6.2 Format description for structured payments

table 9-3 labelled 5.1a 5.1c. Apart from a few unimportant items, the example represents the total information of one
Item
Description of item
Example data
number
1
2
3
4
5
6
7
8
9
Value Date
Credit account number
Amount (debit/credit)
Archive Reference
KID Reference
Document date
Beneficiary number
20030627
81051234567
100,00
0175430
(Empty)
5415671236892343
20030627
4824155
Elektroniske AS
MT940
Field name
field
Item number from
Remarks
specification file
61,2
Booking Date
61,5
Amount
Not available
3

Amount of specification payment.
Credit (if credit note) or debit.
61,7,
account owners reference
For example invoice number
61,8
86,1-6
4, 5, 6, 7, 8, 9
Line 1 6
Page 38 of 38

List of Contents: Extended MT940 Customer Statement Message

Uploaded by

Copyright:

Available Formats

List of Contents: Extended MT940 Customer Statement Message

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

List of Contents: Extended MT940 Customer Statement Message

Uploaded by

Copyright:

Available Formats

Extended MT940 Customer Statement Messag e

Extended MT940 Customer Statement Messag e

9.3.1 EXAMPLE AUTOGIRO PAYMENTS ...........................................................................................................29

Extended MT940 Customer Statement Messag e

How to read this document

Extended MT940 Customer Statement Messag e

What is an Extended MT940?

What will companies get?

How does it look?

Extended MT940 Customer Statement Messag e

If current MT940 sequence is

not the first in the statement.

Final Opening Balance

The booking date is only

Debit / Credit mark

3 character of ISO Currency

Reference for the Account

See following sections for

NRTI for a credit note

Used for continuation of sub

field 61,7 , if contents of that

Used for Nets transactions

See following sections for

If current MT940 sequence is

followed by another sequence

Final Closing Balance

Extended MT940 Customer Statement Messag e

MT940 Contents of field

Closing Available Balance

This account is part of a

Group CashPool ...

Global for the statement

Extended MT940 Customer Statement Messag e

Which limitations do you meet?

The kind of entries that Danske Bank support

The scope of the MT940-format

Do alternatives to the Extended MT940 exist?

Extended MT940 Customer Statement Messag e

Extended MT940 Customer Statement Messag e

Requirements to the ERP-system importing the Extended MT940

Now and then specification amounts will be zero.

Extended MT940 Customer Statement Messag e

If your company has decided to use the Extended MT940

If the company wants a Swedish,

If the company wants a Norwegian,

If the company wants to test the

The statement number of the first Extended MT940 will be one

Extended MT940 Customer Statement Messag e

Use of the examples

Extended MT940 Customer Statement Messag e

Autogiro (Direct Debit)

Extended MT940 Customer Statement Messag e

Extended MT940 Customer Statement Messag e

Autogiro (Direct debit)

Extended MT940 Customer Statement Messag e

HOLMENS KANAL 2-12

HOLMENS KANAL 2-12

HOLMENS KANAL 2-12