Changes to the Common Reporting Standard User Guide and CRS XML Schema v1.0
February 2017
Introduction
The Standard for Automatic Exchange of Financial Account Information in Tax Matters (in short, Automatic Exchange of Information, or AEOI) was developed by the Organisation for Economic Co-operation and Development (OECD) to assist countries in the detection and prevention of ‘offshore’ tax evasion. It is a global initiative for the automated exchange of financial account information between international tax treaty partners. New Zealand has committed to supporting this initiative.
The Standard for Automatic Exchange of Financial Account Information in Tax Matters (the “Standard”) is a document that the OECD has published to assist jurisdictions with their implementation of AEOI. The Standard contains the Model Competent Authority Agreement and Common Reporting Standard, Commentaries on the MCAA and the CRS, and guidance on the technical solution.
Part of the technical solution to support the Standard is an XML schema, which is to be used for the automatic exchange of financial account information between NZ’s exchange partners. This schema can also be used by NZ financial institutions to submit their disclosure information to Inland Revenue. The Common Reporting Standard User Guide to using this schema can be found in Annex 3 of the Standard.
Subsequent to the publishing of the Standard, delegates to the Expert Sub-Group on Mutual Administrative Assistance in Tax Matters (the “ESG”) have requested certain changes to how the schema is used. The changes to the Common Reporting Standard User Guide were approved by the Expert Sub-Group on Mutual Administrative Assistance in Tax Matters and Working Party 10, and will need to be reflected in XML disclosures that New Zealand financial institutions submit to Inland Revenue.
Correcting and deleting information
These changes have been made to how financial institutions and reporting jurisdictions can correct disclosure information that has already been submitted:
- The CorrMessageRefId is no longer required, as every correctable element can be identified by its unique DocRefId. This means that the CorrMessageRefId cannot be used to delete an entire disclosure. Instead, a corrected disclosure should be sent deleting all of the records (using the original DocRefIds) of the original disclosure.
- Uncorrected information (such as when resubmitting reporting FI information) will not require the use of a new DocRefID.
- The Resend function in the DocTypeIndic element of the schema can now be used. Therefore, the following changes should be made to page 253 of the User Guide:
DocTypeIndic
This element specifies the type of data being submitted. Allowable entries are:
- OECD0 = Resend Data (only used when resending the Reporting FI element)
- OECD1 = New Data
- OECD2 = Corrected Data
- OECD3 = Deletion of Data
- OECD10 = Resent Test Data (only used when resending the Reporting FI element)
- OECD11 = New Test Data
- OECD12 = Corrected Test Data
- OECD13 = Deletion of Test Data
Combinations of DocTypeIndics allowed
When correcting a previously submitted disclosure, these combinations of DocTypeIndics are allowed:
| Account Report | ||||||
| OECD1 | OECD2 | OECD3 | OECD0 | Account Report can be omitted? |
||
| Reporting FI | OECD1 | |||||
| OECD2 | ✓ | ✓ | ✓ | |||
| OECD3 | ✓ | |||||
| OECD0 | ✓ | ✓ | ||||
For example, using the table as a guide, a disclosure that has a corrected Reporting FI element (DocTypeIndic=OECD2) can contain both corrected (OECD2) and deleted (OECD3) Account Reports, or could even contain no Account Report element. However, a corrected Reporting FI element cannot contain new data records (OECD1).
Example 1 – Change to Reporting FI and Account Report information
This example illustrates a situation where a change needs to be made to a previously submitted disclosure. A correction is being made to the Reporting FI address and to one of the controlling persons’ date of birth.
(Full size | SVG source)
Points to note about the correction:
- The CorrMessageRefID element is not used for CRS. This is because the DocRefID of a record is unique and therefore sufficient for identifying the record.
- The AccountReport element in the corrected disclosures should be repeated in its entirety, with only the corrected elements changing from the previous disclosures. In this example, all account information and controlling persons must be repeated in the corrected disclosure, even though only one controlling person element is being corrected.
Example 2 – Multiple corrected disclosures
This example illustrates a situation where a change needs to be made to a previously submitted disclosure, and then a second change made to the same disclosure.
(Full size | SVG source)
Points to note about the correction:
- The CorrMessageRefID element is not to be used for CRS. This is because the DocRefID of a record is unique and therefore sufficient for identifying the record.
- The ReportingFI element must always be included in a disclosure, regardless of whether it requires correction. In this example, the ReportingFI element does not change in the corrected disclosures, therefore the DocTypeIndic is OECD0 (Resent Data) and the DocRefId remains the same.
- The CorrDocRefId in the second correction references the disclosure immediately preceding it, instead of the original disclosure. This should always be the case for CRS reporting.
- Only the AccountReports that require correction should be included in the corrected disclosure. Any AccountReport element that requires correction and is included in the corrected disclosure should be included in its entirety, with only the corrected fields and values changing from the previous disclosure.
Example 3 – Change to Reporting FI information only
This example demonstrates a corrected disclosure, where only the Reporting FI address needs to be corrected.
(Full size | SVG source)
Points to note about the correction:
- The CorrMessageRefID element is not used for CRS. This is because the DocRefID of a record will always be unique and is therefore sufficient for identifying the record.
- The DocTypeIndic for the ReportingFI element is OECD2 (Corrected Data) in the corrected disclosure. This is because the ReportingFI address details have changed from the original disclosure.
- Only AccountReports that require correction need to be included in corrected disclosures. In this example, the AccountReport does not require correcting, so it has not been included.
Example 4 – Deleting an entire disclosure
This example shows how an entire disclosure can be deleted.
(Full size | SVG source)
Points to note about the correction:
- Every account report that requires deletion should be included in the corrected disclosure, with a DocTypeIndic of OECD3 (deletion of data).
- The Reporting FI element can only be deleted if all of the associated Account Reports from the original disclosure have also been deleted.