COMMON TECHNICAL PROCEDURES
(Based on the TS-AEOI DAC2-1.11 EU Document)
Για λόγους διαφάνειας και καλύτερης επικοινωνίας δημοσιεύεται τμήμα των τεχνικών
οδηγιών της ΕΕ προς τα κράτη μέλη. Οι οδηγίες αφορούν τη δημιουργία τροποποιητικών
αναφορών DAC2/CRS και παραδείγματα τέτοιων υποβολών και εφαρμόζονται κατά την
ανταλλαγή στοιχείων μεταξύ των κρατών μελών.
Κατ’ αντιστοιχία και για την ανάγκη απλοποίησης του συστήματος θα ισχύουν και για την
υποβολή τροποποιητικών από τα υπόχρεα ελληνικά Χρηματοπιστωτικά Ιδρύματα προς την
ΑΑΔΕ. Επειδή οι οδηγίες αφορούν κράτη μέλη σε πολλά σημεία αναφέρεται ως αποστέλλων
την αναφορά το SS (Sending Member State). Όσον αφορά τις αναφορές που αποστέλλονται
προς την ΑΑΔΕ που SS εννοείται αποστέλλων χρηματοπιστωτικό ίδρυμα. Τα υποδείγματα
των αναφορών που αναφέρονται στο συμπιεσμένο αρχείο CorrectionXMLExamples.zip που
δημοσιεύεται στον ιστότοπο της ΑΑΔΕ μαζί με το παρών κείμενο.
1 TERMINOLOGY
1.1 ABBREVIATIONS AND ACRONYMS
Definition
Meaning
AEOI
Automatic Exchange of Information
Art.
Article
ASCII
American Standard Code for Information Interchange
BOM
Byte Order Mark: a Unicode character to signal whether a text file is big or little
endian
BR
Business Rule
CACT
Committee on Administrative Cooperation for Taxation
CCN
Common Communication Network
CDE
Common Data Element
COA
Confirm on Arrival
COD
Confirm on Delivery
CRS
Common Reporting Standard
CSI
Common System Interface
DAC
Directive on Administrative Cooperation
DG TAXUD
Directorate-General Taxation and Customs Union
DT
Data Type
EC
European Commission
EU
European Union
FA
Financial Account
FATCA
Foreign Account Tax Compliance Act
FI
Financial Institution
FIS
FISCALIS Information Systems
FITS
FISCALIS Information Technology Services
FITSDEV3
FITS Development
FS
Functional Specifications
IBAN
International Bank Account Number
ID
Identifier
IT
Information Technology
ITSM
IT Service Management
ISO
International Organization for Standardization
LCT
Local Client Testing
LDM
Logical Data Model
LST
Local Server Testing
MB
Megabyte
Definition
Meaning
MS
Member State
MSA
MS Administration
MSG
Message
N/A
Not Applicable
NA
National Administration
NFE
Non-Financial Entity
OBAN
Other Bank Account Number
OECD
Organisation for Economic Cooperation and Development
PDM
Physical Data Model
PK
Primary Key
RCT
Remote Conformance Testing
RIT
Remote Interoperability Testing
RR
Receiving MS - MS receiving a MSG (any type of MSG) whatever the process
SC
Specific Contract
SD
System Design
SS
Sending MS - MS sending a MSG (any type of MSG) whatever the process
TIN
Tax Identification Number
ToC
Terms of Collaboration
TS
Technical Specifications
UTC
Coordinated Universal Time
VAT
Value Added Tax
VIES
VAT Information Exchange System
XML
Extensible Mark-up Language
XSD
XML Schema Definition
2 COMMON TECHNICAL PROCEDURES
2.1 COMMON APPROACH FOR PASSIVE NFE
In the case of an account held by a Passive NFE that is a reportable Person and that is also
identified as having in the same MS, one or more Controlling Persons, that is a reportable
person, the SS must report the information related to the Passive NFE and each Controlling
Person. The CRS has described two approaches as regards how to report such a situation.
The system will accept the two approaches. However in order to improve the communication
between MS, and have a common understanding, it is recommended to follow the second
approach described in the CRS and also explained in this section.
The approach consists of reporting the account:


as an account held by a passive NFE with one or more controlling person that is a
reportable person where the element AcctHolderType of the element
AccountHolder (see section Error! Reference source not found.) must be set to
CRS101;
and also as an account held by a passive NFE that is a reportable person where the
element AcctHolderType of the element AccountHolder (see section Error!
Reference source not found.) must be set to CRS103.
The Table 1 describes all the possible values for the element AcctHolderType for a
Passive NFE with one or more controlling persons and the recommended approach is
highlighted in light green.
Passive NFE
Controlling
Person
Is a reportable person
Is a reportable
person
Two records:


Is NOT a
reportable
person
Is NOT a reportable person
One record:

CRS101;
CRS103.
One record:

One record:

CRS10
1.
CRS101.
Not Applicable
CRS103.
Table 1: Account holder type to use for a Passive NFE
2.1.1
EXAMPLE
The example relies on the schema defined in section Error! Reference source not found..
It covers the following scenario:


A Financial Institution in MS A has an account held by a Passive NFE, MS B resident,
with three controlling persons: two of them are MS B residents and the third is MS C
resident.
The Financial Institution reports to his competent authority this Financial Account
information;
In this case the SS sends two Initial messages, one for MS B and another for MS C. The
message towards MS C contains one account including the Passive NFE as holder of type
CRS101 and the MS C controlling person. The message towards MS B contains two
accounts. The first one contains only the Passive NFE as holder of type CRS103 and the
second one contains the Passive NFE as holder CRS101 with the two MS B controlling
persons. Figure 11 highlights this.
1
The figure omits most of the data, and only highlights the main areas of interest.
Initial message - MS B
Initial message - MS C
<CRS_OECD>
<CRS_OECD>
<CrsBody>
<CrsBody>
<ReportingFI>
<ReportingFI>
<ReportingGroup>
<ReportingGroup>
<AccountReport>
<AccountReport>
<AccountHolder>
<Organisation>
<ResCountryCode> = MS B
<AcctHolderType>=CRS103
<AccountHolder>
<Organisation>
<ResCountryCode> = MS B
<AcctHolderType>=CRS101
<ControllingPerson>
<AccountReport>
<AccountHolder>
<ResCountryCode> = MS C
<Organisation>
<ResCountryCode> = MS B
<AcctHolderType>=CRS101
<ControllingPerson>
<ResCountryCode> = MS B
<ControllingPerson>
<ResCountryCode> = MS B
Figure 1: Re-send all child elements
The following example files, in the order they are presented, provide concrete messages for
this scenario:


NFE-Example-Init-MSB.xml
NFE-Example-Init-MSC.xml
2.2 MODIFICATIONS TO SENT DATA
In the course of the exchange of messages, the SS may need to amend data previously sent.
The section describes how the system should specify these changes through the correction
mechanism (section 2.2.1) and how corrections and deletions can be used together
(section 2.2.2).
The message is just an envelope, for a specific reporting period, which contains a set of
records. The message has no business meaning. Concretely, this means that all the records
of the message concern the same reporting period and the message is accepted or rejected
as a unit of work.
2.2.1
CORRECTION MECHANISM
The system supports corrections. This section describes the possible situations and presents
how to handle them.
2.2.1.1 REASONS FOR CORRECTION
The following kinds of error may justify the need for a correction:


Invalid syntax: the structure of the received file is not valid. For example, the file is not
in XML format, is not well-formed XML or does not match the schema described in
this document;
Invalid semantic: the received file contains errors related to business rules that are
not checked by the XSD (for example, the format of the Account Number), or related
to other unexpressed business rules (for example, a person residing in Valencia, Italy
while Valencia is actually in Spain). These rules can further be divided in the following
categories:
o The error is picked up automatically by the validation module;
o The error is found by a member of the RR MSA after the system has
processed and integrated the message;
o The error is found by the SS but not yet by the RR.
If the validation module encounters one or more syntax errors, the RR ignores the received
file and returns a status message with the found errors (see section Error! Reference source
not found.). The SS must then correct its implementation and send back the message. Since
the first message was ignored, a correction message is not needed (unless the file was
already a correction, in which case the new file remains of the same type). For traceability
purposes, the new message must have a different MessageRefId than the rejected one,
even if it mostly holds the same content.
If the validation module encounters one or more semantic or technical errors (see
section Error! Reference source not found.), the RR can decide how it wishes to proceed. If
the error is deemed grave enough, it rejects the message, and it and the SS proceeds as if
there was a syntax error (i.e. the RR ignores the file and the SS must send a new one). If the
errors are not considered as grave, the RR integrates the data in its national system and
sends a Status message indicating acceptance of the received message, but mentioning the
detected errors. Note that the RR must accept or reject the message as a whole, and cannot
integrate only part of the data while indicating an error.
Whenever possible, the RR should reply with as many errors as possible, not stopping at the
first one (e.g. two business rule errors would lead to a single Status message with two errors).
However, since an error in message syntax compromises the parsing of all data after the
location of the error, it may be that only part of the errors can be reported during a first pass
through the message. Further errors would then be detected once the first ones have been
corrected.
If a semantic error is found after the system has processed and integrated the message into
the database, the SS should spontaneously send a correction message as described in the
following sections.
2.2.1.2 CORRECTABLE ELEMENTS
Only the top-level element is correctable. In the XSD, there are two top-level elements, the
ReportingFI and the AccountReport. The system must consider these two top-level
elements separately. The correction of one of the two top-level elements must not impact the
other related top-level element.
If a correction targets a previously sent child element of a top-level element, the system must
re-send the related parent top-level element and all its children. This is applicable for
ReportingFI and AccountReport. This results in a waste of space when the correction
concerns only part of the information, but it has the following advantages:




Since the top-level element is self-contained, the validation does not need access to
the database in order to check that the correction does not violate business rules;
The SS can generate the correction with only minor changes to the routines already
used to generate the Initial messages;
The RR can easily integrate the correction by invalidating separately for each toplevel element the previously recorded information, and then call the routines already
used to integrate the Initial messages;
This procedure does not require a specific XSD for the sake of corrections.
In order to be able to identify the elements to correct, the definition of these top-level
elements includes an element of type Error! Reference source not found., which
include elements named DocTypeIndic, DocRefId and CorrDocRefId. For a Correction
message, the system allows the following combinations of DocTypeIndic for the correctable
elements, taking into account that the AccountReport element is not mandatory:
w/o
AccountRepo
rt
-
AccountReport
OECD1
OECD2
OECD3
OK
OK
OECD0
OECD1
OECD2
OK
OECD3
OK
ReportingFI
OECD0
OK
OK
OK
Table 2: Combinations of DocTypeIndic for the correctable elements within a Correction
message
When a correction targets only the AccountReport element and there is no modification of
the related ReportingFI, the DocTypeIndic “OECD0-Resend Data” is used for the
ReportingFI element. This type is only allowed for ReportingFI element.
If the validation module encounters another combinations than these presented above, the
RR ignores the received file and returns a status message with the relevant technical error
code (see section Error! Reference source not found.).
2.2.1.3 STRUCTURE OF A CORRECTION MESSAGE
A correction message has essentially the same structure as an Initial message, as it follows
the same schema. There is only a minor difference in the Header: the MessageTypeIndic
must be set to CRS702.
There are also three differences in the Body:



A corrected element will have a DocTypeIndic value of OECD2 or OECD3 (OECD1
for Initial messages);
Regarding the ReportingFI, the DocTypeIndic will have for value OECD2/OECD3
if it has been modified/deleted since the previous sending, OECD0 if the ReportingFI
was not modified (split of message or late reporting for example);
Its CorrDocRefId references the DocRefId of the element to correct (this element
is not specified in Initial messages).
Since the DocRefId is unique in time and space (section Error! Reference source not
found.), the correcting records must have different DocRefIds than those of the records
being corrected.
A correction message can contain either corrections (OECD2) or deletions (OECD3) or both
and also resent ReportingFIs (OECD0) but not new data (OECD1).
2.2.2
RELATIONSHIP BETWEEN MESSAGES
This section describes how messages exchanged through the correction mechanism
described above interact with one another.
Since messages specify the reporting period for which it relates, a correction message may
correct records originating from any previous Initial or Correction messages for the same
reporting period.
2.2.2.1 CORRECTION OF AN INITIAL MESSAGE
The correction of an Initial message is the most common situation. The correction is used to
correct the elements that was not correct (from a technical point or business point of view), or
to delete elements from the Initial message.
A unique MessageRefId is created respecting the format defined in the section Error!
Reference source not found..
A new DocRefId is created for each correctable element and should follow the format
described in section Error! Reference source not found..
The CorrDocRefId must reference the DocRefId of the elements to be corrected / deleted
from the Initial message.
2.2.2.2 CORRECTION OF A CORRECTION MESSAGE
Corrections of corrections are legitimate. In that case, the CorrDocRefId of the second
correction of the entity must reference the DocRefId of the first correction.
This is required in order to determine uniquely the order in which the RR system must apply
the corrections. Suppose two corrections reference the same entity and, for some technical
reason (e.g. infrastructure or architecture constraints), arrive out of order 2. The RR system
would first integrate the second correction, then the first one, effectively dismissing the
second (and most recent) correction.
If the RR receives messages that it considers as probably being out of order, it should – as a
best practice – wait for some time before discarding the message, in case the previous
messages arrive some time later 3. If such a message does not arrive, it should contact the SS
using the Send (Technical) Query Operational Procedure defined in the Terms of
Collaboration [Error! Reference source not found.].
2.2.2.3 ERROR HANDLING
If the SS does not respect any of the above constraints, the RR must reply with a Status
message mentioning that the corrected entity is not known or not valid anymore (see
section Error! Reference source not found.), depending on the available information.
2.2.3
EXAMPLES
The following sections provide examples of concrete correction scenarios, and highlight
correction rules applicable to each of them. The examples rely on the schema defined in
section Error! Reference source not found..
Each example presents one or more figures to illustrate the situation. These figures omit most
of the data, and only highlight the main areas of interest.
Each example is illustrated by one or more XML messages. The Table 3 lists the XML
messages annexed to this document, and indicates to which section they relate.
2
3
#
File
Section(s)
1
Correction-Example-Init-2AR1FI.xml
2.2.3.1, 2.2.3.2, 2.2.3.8
2
Correction-Example-Corr-TwoSuc-1.xml
2.2.3.1, 2.2.3.2
3
Correction-Example-Corr-TwoSuc-2.xml
2.2.3.1
4
Correction-Example-Corr-TwoSuc-3.xml
2.2.3.2
CCN, for example, does not offer a guarantee that messages will be delivered in order.
The actual effort to put in this procedure is left at the appreciation of the MS. Since this event is possible but very
unlikely, it is probably not useful to build a complex automated system to resolve this issue.
#
File
Section(s)
5
Correction-Example-Init-MultiCP-1.xml
2.2.3.5
6
Correction-Example-Init-MultiCP-2.xml
2.2.3.5
7
Correction-Example-Corr-MultiCP-1.xml
2.2.3.5
8
Correction-Example-Corr-MultiCP-2.xml
2.2.3.5
9
Correction-Example-Init-1AR1FI.xml
2.2.3.3, 2.2.3.6, 2.2.3.9, 2.2.3.10, Error!
Reference source not found.
10
Correction-Example-Corr-CorrChild.xml
2.2.3.3
11
Correction-Example-Init-2AR1FI-2.xml
2.2.3.4
12
Correction-Example-Corr-2CorrElement.xml
2.2.3.4
13
Correction-Example-Init-2AR1FI-3.xml
2.2.3.7, Error! Reference source not
found.
14
Correction-Example-Corr-RemChild-FI.xml
2.2.3.7
15
Correction-Example-Corr-RemTopLevel.xml
2.2.3.8
16
Correction-Example-Corr-AddChild.xml
2.2.3.9
17
Correction-Example-Init-1AR1FI-2.xml
2.2.3.10
Table 3: Annexed XML messages
In the examples below the following convention has been used to highlight the elements that
need to be corrected or just resent:


The green colour is used when the ReportingFI has to be resent even if no
modifications are required. In this situation, the element is identified with the same
DocRefId as the immediately preceding version of the ReportingFI and the code
OECD0 is used. It is worth to note that the RR must not persist the information
related to the ReportingFI;
The red colour is used to identify the elements that require to be corrected (Initial
message) or are corrected (Correction message).
2.2.3.1 TWO SUCCESSIVE CORRECTIONS OF THE SAME ACCOUNT
This example covers the following scenario:



The SS sends an Initial message with one financial institution and two accounts;
It then sends a first Correction message correcting the payment amount of the first
account;
It finally sends a second Correction message, correcting the account balance yet
again for the first account.
There are four areas of interest here highlighted by Figure 2:




The CorrDocRefId of the account refers to the immediately preceding entity, not to
any preceding one (in particular, not systematically to the first one);
The DocTypeIndic of the account is set to OECD1 within an Initial message and to
OECD2 within a Correction message;
The SS must always resend the financial institution (according to the XSD, see
section Error! Reference source not found.) associated to the account being
corrected, even though it did not require modifications. The DocTypeIndic is set to
OECD0 and the DocRefId is the same as the immediately preceding entity;
The SS must only resend the corrected account. The second one, which does not
require corrections, is not part of the Correction message.
Figure 2: Two successive corrections of the same account.
The following example files, in the order they are presented, provide concrete messages for
this scenario:



Correction-Example-Init-2AR1FI.xml;
Correction-Example-Corr-TwoSuc-1.xml;
Correction-Example-Corr-TwoSuc-2.xml.
2.2.3.2 TWO SUCCESSIVE CORRECTIONS OF DATA FROM THE SAME MESSAGE
This example covers the following scenario:



The SS sends an Initial message with one financial institution and two accounts;
It then sends a first Correction message correcting the address of the financial
institution;
It finally sends a second Correction message, correcting the first account (new
account payment).
Figure 3 highlights the three areas of interest:



The SS must always resend the financial institution (according to the XSD, see
section Error! Reference source not found.) associated to the account being
corrected, even though it did not require modifications. The DocTypeIndic is set to
OECD0 and the DocRefId is the same as the immediately preceding entity;
The SS must only resend the corrected account. The other one, which does not
require corrections, is not part of the Correction message;
The SS can send the corrected financial institution without the accounts if they do not
require corrections.
Figure 3: Two successive corrections of data from the same message
The following example files, in the order they are presented, provide concrete messages for
this scenario:



Correction-Example-Init-2AR1FI.xml;
Correction-Example-Corr-TwoSuc-3.xml;
Correction-Example-Corr-TwoSuc-1.xml.
2.2.3.3 CORRECTION OF A CHILD ELEMENT OF THE ACCOUNTREPORT ELEMENT
This example covers the following scenario:


The SS sends an Initial message with a financial institution, and an account
composed of a number, an holder, two controlling persons residing within the same
country and a balance;
It then wants to correct the address of the first controlling person.
In this case, the SS must correct the account from the Initial message, and send it back with
the corrected controlling person data. It must also include the financial institution since this
element is mandatory, as well as the second controlling person, the number, the holder and
the balance; even though they did not require modifications (omitting it would lead to
confusion with the example from section 2.2.3.4). Figure 4 highlights this.
Figure 4: Re-send all child elements
The following example files, in the order they are presented, provide concrete messages for
this scenario:


Correction-Example-Init-1AR1FI.xml;
Correction-Example-Corr-CorrChild.xml.
2.2.3.4 CORRECTION OF TWO CORRECTABLE ELEMENTS WITHIN THE SAME MESSAGE
This example covers the following scenario:


The SS sends an Initial message containing two accounts and the associated
financial institution. The first account is composed of a number, an holder, a
controlling person and a balance. The second account is composed of a number, an
holder and a balance. The financial institution is composed of a name and an
address;
It then wants to correct the address of the financial institution and the balance of the
first account.
In this case, the SS must correct the financial institution and the first account from the Initial
message. The financial institution must contain the corrected address as well as the name.
The first account must contain the corrected balance, as well as the number, the holder and
the controlling person. The second account is not re-sent. Figure 5 highlights this.
Figure 5: Correction of the two correctable elements within the same message
The following example files, in the order they are presented, provide concrete messages for
this scenario:


Correction-Example-Init-2AR1FI-2.xml;
Correction-Example-Corr-2CorrElement.xml.
2.2.3.5 CORRECTION OF A PERSON CONTROLLING AN ORGANISATION TOGETHER WITH
PERSONS FROM OTHERS MSS.
This example covers the following scenario:


The financial institution reports to his competent authority, an account whose holder
is a Passive NFE with two controlling persons from different MSs. Both controlling
persons are reportable persons;
Then the SS sends two Initial messages, one per country of residence for tax
purposes of the controlling persons;

Finally the financial institution reports a corrected controlling person for the account
sent initially.
In this case, the SS must correct the account with the corrected controlling person. Since the
ControllingPerson is not a correctable element, the system cannot determine directly in
the information received if there was a change. Therefore the SS must send the account to all
countries who received it initially even if the controlling person does not require modification.
The financial institution is also included since this element is mandatory. Figure 6 highlights
this.
Figure 6: Controlling Persons from different MSs
The following example files, in the order they are presented, provide concrete messages for
this scenario:




Correction-Example-Init-MultiCP-1.xml
Correction-Example-Init-MultiCP-2.xml
Correction-Example-Corr-MultiCP-1.xml
Correction-Example-Corr-MultiCP-2.xml
2.2.3.6 REMOVAL OF A CHILD ELEMENT OF THE ACCOUNTREPORT
This example covers the following scenario:


The SS sends an Initial message with a financial institution, and an account
composed of a number, an holder, two controlling persons and a balance;
It then wants to remove the first controlling persons.
In this case, the SS must correct the account from the Initial message, and send it back
without the deleted controlling person but with the other controlling person, the number, the
holder, the balance and the financial institution since this element is mandatory. Figure 7
highlights this.
Figure 7: AccountReport-Omit removed children
The following example files, in the order they are presented, provide concrete messages for
this scenario:


Correction-Example-Init-1AR1FI.xml;
Correction-Example-Corr-RemChild.xml.
2.2.3.7 REMOVAL OF A CHILD ELEMENT OF THE REPORTINGFI
This example covers the following scenario:

The SS sends an Initial message with two accounts and the associated financial
institution having a name and two addresses;

It then wants to remove the second address of the financial institution.
In this case, the SS must correct the financial institution from the Initial message, and send it
back without the deleted address but with the other address, and the name. The accounts are
not re-sent. Figure 8 highlights this.
Figure 8: ReportingFI-Omit removed children
The following example files, in the order they are presented, provide concrete messages for
this scenario:


Correction-Example-Init-2AR1FI-3.xml;
Correction-Example-Corr-RemChild-FI.xml.
2.2.3.8 REMOVAL OF A TOP-LEVEL ELEMENT
This example covers the following scenario:


The SS sends an Initial message with two accounts and the associated financial
institution. Each account is composed of a number, an holder and a balance;
It then wants to remove the first account.
In this case, the SS must correct the first account indicating that it must be deleted
(DocTypeIndic is set to OECD3), omit the second account since it does not require
corrections, and send it back with the child elements of the corrected account as well as the
financial institution since this element is mandatory. Figure 9 highlights this.
Figure 9: AccountReport-Removal top-level element
The following example files, in the order they are presented, provide concrete messages for
this scenario:


Correction-Example-Init-2AR1FI.xml;
Correction-Example-Corr-RemTopLevel.xml.
An exception can occur for the removal of a Top-level element if the correction message
removes only the financial institution without the associated accounts. In this case, the system
must not allow this operation because it does not make sense to keep the account(s) without
the corresponding financial institution. The system must thus answer with a rejection Status
message, using the appropriate error code (section Error! Reference source not found.).
It is also worth to note that the removal of a financial institution is persisted only if all the
associated accounts have been already removed.
2.2.3.9 CREATION OF A CHILD ELEMENT
This example covers the following scenario:


The SS sends an Initial message containing an account and the associated financial
institution. The account is composed of a number, an holder and a balance;
It then wants to add a payment to that account.
In this case, the SS must correct the account from the Initial message specifying a new
payment and send it back with the number, the holder, the balance and the financial
institution since this element is mandatory. Figure 10 highlights this.
Figure 10: Create a child element
The following example files, in the order they are presented, provide concrete messages for
this scenario:


Correction-Example-Init-1AR1FI.xml;
Correction-Example-Corr-AddChild.xml.
2.2.3.10 CREATION OF A NEW TOP-LEVEL ELEMENT FOR THE ACCOUNTREPORT
This example covers the following scenario:


The SS sends an Initial message with one account and the associated financial
institution;
It then wants to send another account.
In this case, the SS creates a new Initial message, with only the new account and the already
sent financial institution.. Figure 11 highlights this.
Figure 11: Creation of a new top-level element for the AccountReport
The following example files, in the order they are presented, provide concrete messages for
this scenario:


Correction-Example-Init-1AR1FI.xml;
Correction-Example-Init-1AR1FI-2.xml.
This scenario does occur only in specific circumstances such as late reporting or in the case
of split messages.