Documentation · Tax transparency

CRS.

Common Reporting Standard submissions for non-DAC2 jurisdictions.

Manual Tax Reporting Engine → CRS · Version 2.1 · 3 screenshots
NoteThis guide assumes you know how to sign in, navigate the Solutions menu, complete Settings and work with sessions. Those are covered in the Getting Started guide and are not repeated here.

What this module does

The Common Reporting Standard is the OECD framework for the automatic exchange of financial account information. Where DAC2 handles the EU implementation, the CRS module handles the jurisdictions outside it.

The module is built on the same ingestion, validation and conversion architecture as DAC2. If you have used DAC2, everything here will be familiar — the differences are the jurisdictions supported, the submission type codes, and one significant difference in how the export behaves.

The jurisdictions available to you are set by your entitlement and by the jurisdiction on your corporate profile. If a jurisdiction you report to is not offered, contact your REGREP account manager.

NoteIf CRS appears greyed out in the Tax Reporting Engine menu, the module is not enabled for your firm. Contact your REGREP account manager.

Before you start

ImportantComplete Settings → Corporate Information before creating a session. The reporting financial institution's legal entity name, LEI, entity type, country of incorporation, company type, TIN, GIIN and FATCA filer status are written into the XML package directly from these fields.

Solutions → Regulatory Reporting → Tax Reporting Engine → CRS.

Sessions

The CRS session list
Figure 1 — The CRS session list.
  1. 1The jurisdiction this module reports to, taken from your corporate profile.
  2. 2A correction session showing its parent and an incremented version.

Each session records its name, reporting year, report type, version, parent session where one applies, submission type and creation date. Two row actions are available: open, and delete.

Note

Warning — this cannot be undone

Deleting a CRS session removes it and its uploaded data permanently, and there is no archive to fall back on. Keep any session whose package has been filed — it is your record of the submission, and a later correction needs it as its parent.

A new submission

Add Session, configured as an original submission
Figure 2 — Add Session, configured as an original submission.
FieldWhat to enter
Session NameA descriptive name including the year and whether it is an original or a correction.
Session YearThe tax reporting year the data covers.
Submission TypeNew Submission - CRS-701.
VersionFixed at 1 for an original submission.

A correction

Where an error is found in a submission already filed, create a correction session rather than editing the original.

FieldWhat to enter
Session NameSomething identifying what is being corrected.
Session YearThe same year as the parent session.
Submission TypeCorrection submission - CRS-702.
Dependent / Parent SessionThe original session containing the error.
VersionIncrements automatically.

Uploading and validating

A new session opens on the upload screen. Drag your reporting file onto it, or select to browse. CRS accepts both .xlsx and .xml, which is a difference from DAC2 — an existing OECD XML file can be loaded for validation and re-packaging rather than rebuilt from a spreadsheet.

The three processing cards after a successful upload
Figure 3 — The three processing cards after a successful upload.
  1. 1Data Input — what was read from your file.
  2. 2Regulatory Validations — what passes the CRS rules.
  3. 3XML Conversion — building the submission package.

Data Input

Confirms the file was structurally readable and reports the record counts: total rows, accounts, parties, undocumented, closed and dormant accounts, and TINs detected. Check these against your source system before going further — a count that is materially different from what you expect means the extract is wrong.

UPLOAD NEW replaces the file and re-runs the whole process.

Regulatory Validations

Checks the ingested records against the CRS reporting rules and reports valid records, errors, TINs identified and valid TINs.

  1. Select DOWNLOAD ERRORS to export the error log with the reason for each failure.

  2. Correct the records in your source data.

  3. Re-upload with UPLOAD NEW.

  4. Repeat until the error count is zero or every remaining error is one you have consciously accepted.

ImportantThe error log contains the failing records, which means account holder names and tax identification numbers. Treat the downloaded file as personal data — see section 5.

Exporting — read this before you file

The XML Conversion card behaves differently depending on the jurisdiction, and getting this wrong produces a package the receiving authority will reject.

Jurisdictions that expect one file per reportable jurisdiction

  1. Use the Countries filter to choose a specific reportable jurisdiction, or All.

  2. Download the package in the format you need.

DownloadUse it for
DOWNLOAD XMLThe OECD-compliant XML for submission to the tax authority.
DOWNLOAD JSONA structured format for API integration or internal records.
DOWNLOAD EXCELA readable summary of the validated data, for internal review and sign-off.

Jurisdictions that expect a single consolidated package

Important

Some authorities work differently. Where the Countries filter is not shown, the receiving authority expects a single consolidated package rather than one file per jurisdiction.

All foreign reportable account holders, across every tax jurisdiction, are combined into one master OECD XML output. Select DOWNLOAD XML to produce it.

NoteIf the Countries filter is missing and you expected to filter by country, nothing is broken — it is hidden deliberately where the authority wants one consolidated package. If it is missing and you did not expect that, check which jurisdiction your corporate profile is set to: the filter is driven by it.

Before you submit

ImportantOpen the XML and confirm the reporting institution block carries the correct legal entity name, LEI, TIN and GIIN. These come from Settings, are invisible in the counts on screen, and are a common cause of rejection.
NoteREGREP produces the submission file; it does not transmit it. Filing is done through the tax authority's own portal.

Handling personal data

CRS files contain named individuals, their addresses, dates of birth, tax residences, tax identification numbers and account balances. That is personal data under the GDPR and equivalent regimes, and financial data about identifiable people.

  • Upload only what the reporting obligation requires.

  • Treat the downloaded error log and Excel summary exactly as you treat the source file — they hold the same personal data and are the copies most likely to end up in an email.

  • Keep downloaded packages where your firm keeps regulated records, not in a personal downloads folder.

  • Delete local working copies once the submission is filed and your retention copy is in place.

  • Restrict CRS module access to the people who need it, through Team Management.

NoteYour firm's retention policy governs how long packages and source files are kept. For REGREP's own statement on storage, protection and retention of uploaded files, request it through Help → Contact Support.

A complete submission

  1. Confirm Settings → Corporate Information is complete and saved, and that the LEI validates.

  2. Confirm which jurisdiction you are reporting to, and whether it expects a consolidated package or one file per jurisdiction.

  3. Create the session: name, year, CRS-701, version 1.

  4. Upload the account data (.xlsx or .xml).

  5. Check the Data Input counts against your source system.

  6. Work through the errors until you are satisfied.

  7. Have the submission reviewed by someone other than the preparer, using the Excel download.

  8. Download the XML and check the reporting institution details inside it.

  9. File through the tax authority's portal.

  10. Record the submission reference against the session and retain it.

Troubleshooting

SymptomLikely cause and fix
The Countries filter is missingExpected behaviour where the authority wants one consolidated package. Otherwise, check the country of incorporation in Settings.
The upload is rejectedThe file is not .xlsx or .xml, or its structure does not match the expected template.
Record counts are lower than expectedThe source extract is incomplete or was filtered during export. Reconcile before continuing.
Many TINs invalid for one jurisdictionUsually a formatting problem — leading zeros stripped by Excel is the classic cause.
Errors persist after correctionConfirm you re-uploaded with UPLOAD NEW rather than leaving the original file in place.
The authority rejects the packageCheck the reporting year, submission type, LEI and TIN in the XML header. For a resubmission use a CRS-702 correction linked to the original, not a new CRS-701.

Document control

VersionDateChange
2.1January 2026Target jurisdictions are no longer listed individually. The export chapter now describes the two behaviours — one package per reportable jurisdiction, or a single consolidated package — rather than naming the jurisdictions in each case.
2.0January 2026Rewritten to start at the module. Navigation and Settings move to the Getting Started guide. The consolidated-export rule is documented as a jurisdiction behaviour and separated from demo-environment defaults, which no longer appear. Adds a data protection section, guidance on the .xml input option, a full submission workflow and troubleshooting.
1.0Original CRS manual.

REGREP is an independent software provider. This manual describes how to operate the platform and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.

Other guides

The rest of the documentation set.

All documentation