BZSt CRS Reporting: The Schema v3.0 Switch and Saint-Martin Refile

On 9 September 2026 the Bundeszentralamt fuer Steuern (BZSt) issued CRS Newsletter 04/2026, and it carries four items relevant to BZSt CRS reporting. The Federal Ministry of Finance has published an English translation of the BMF-Schreiben that fixes the officially prescribed dataset and interface; the BMF-Schreiben dated 14 January 2026 requires version 2.0 for transmissions through 31 December 2026 and version 3.0 exclusively from 1 January 2027, and the BZSt has signalled an expected earlier operational cut-off date for version 2.0 acceptance that should be confirmed against current BZSt notices; and a technical misconfiguration caused Saint-Martin records to be rejected in the current reporting period, so those filings have to be sent again.

For a BZSt CRS reporting team, none of the four items is background reading. Under the FKAustG, a reporting financial institution is a financial institution of a participating state that is not a non-reporting financial institution; the financial-institution categories are custodial institutions, depository institutions, investment entities and specified insurance companies. German reporting financial institutions transmit reportable account data to the BZSt each year, directly or through a filing agent. Two of the four items change how that data must be built and submitted, one creates a resubmission task inside the reporting period that has just closed, and one is an operational notice about current form availability in the BZSt online.portal.

Related reading: our walkthrough of how CRS reporting works end to end.

The four items, and the dates that actually bind

CRS Newsletter 04/2026 groups four items under one heading. Read alone, each looks like housekeeping. Read against a reporting calendar, they fall on different timelines: one is a documentation aid available now; one is a schema change that must be implemented for transmissions from 1 January 2027; one is a resubmission that belongs to the reporting period just filed; and one is an operational notice that the process-related forms (vorgangsbezogene Formulare) in the BZSt online.portal are temporarily suspended, while the non-process-related (free) forms remain available.

The dates to put on the calendar are these:

• 14 January 2026: the date of the BMF-Schreiben that published the officially prescribed CRS dataset, now also available in an English-language version on the Federal Ministry of Finance website; the version 3.0 dataset applies to transmissions from 1 January 2027.
• 1 December 2026: an expected BZSt operational date for closing version 2.0 acceptance; verify this against current BZSt notices before treating it as a fixed planning boundary.
• 1 January 2027: the date from which version 3.0 is the required schema for all CRS transmissions, as fixed by the BMF-Schreiben dated 14 January 2026.
• 31 July: the annual deadline by which initial CRS reports for the preceding calendar year must have been successfully transmitted to the BZSt. For the 2025 reporting period that fell on 31 July 2026.

Any BZSt announcement of a 1 December 2026 technical acceptance cut-off should be treated as an operational window and verified against the current BZSt CRS notice. The legal schema switch itself is fixed: the BMF-Schreiben dated 14 January 2026 requires version 2.0 for transmissions through 31 December 2026 and version 3.0 exclusively for transmissions from 1 January 2027. The 31 July deadline is the hard annual date for initial reports, and it does not move for a schema transition.

The v3.0 schema switch is the change that touches your pipeline

The version number understates the work. CRS XML schema version 3.0 is the reporting format Germany has prescribed for the amended CRS data requirements implemented in the FKAustG; the OECD published the amended CRS XML schema on 2 October 2024. The BMF-Schreiben dated 14 January 2026 fixes the switch to schema version 3.0 from 1 January 2027, publishes the officially prescribed dataset, and states that publication will take place in Bundessteuerblatt Part I; it sits in a dedicated BZSt topic area for the CRS schema v3.0 alongside the supporting documents for the transition.

What changes inside the schema drives the mapping work, well beyond the version attribute. The OECD Amended CRS widens the reporting perimeter to capture specified electronic money products and central bank digital currencies, sharpens the definition of investment entity, and adds more granular data on account holders and controlling persons, including the role a controlling person holds and whether an account is new or pre-existing. Those are new and changed data elements, but section 27(2) FKAustG provides a transition for controlling-person and equity-holder function data: for reportable accounts maintained at 31 December 2025 and reporting periods ending no later than 31 December 2027, those functions need be reported only if they are available in the institution’s electronically searchable data. The schema uplift therefore requires mapping and data sourcing subject to that transition. The crypto-asset strand of the same OECD package flows through a separate reporting regime; if that is on your horizon, see our explainer on CARF crypto-asset tax reporting.

The practical error to avoid is scheduling the v3.0 work as a late-2026 IT change. The version 3.0 dataset description was published in January 2026 and applies to transmissions from 1 January 2027, while the OECD amended CRS XML schema was published on 2 October 2024, so the specification is available to build against today. A team that waits for the December changeover to begin mapping compresses a data-sourcing exercise into the same weeks in which it also has to freeze its version 2.0 environment.

The version 2.0 to 3.0 changeover: legal dates and what to confirm

The BMF-Schreiben dated 14 January 2026 requires version 2.0 for transmissions through 31 December 2026 and version 3.0 from 1 January 2027. A separate technical suspension of CRS submissions during December 2026 should be treated as operative only when confirmed in a current BZSt operational notice.

Outstanding correction filings, deletion filings and catch-up initial reports that need to go through the version 2.0 schema should be transmitted and confirmed before 31 December 2026; if the BZSt confirms an earlier operational cut-off for version 2.0 acceptance, treat that earlier date as the effective planning boundary. Confirm the current acceptance windows against the BZSt CRS schema v3.0 pages before committing a freeze plan to the change calendar.

There is a second-order point for anyone who also files under the US regime. FATCA runs on its own XML schema and its own migration history, and the CRS version 3.0 date does not move it, so a shared reporting platform needs the two schema roadmaps tracked separately. German FATCA reporting runs on its own XML schema and separate migration roadmap; under the German FATCA-USA-UmsV its annual reporting deadline is also 31 July.

The English-language version of the BMF-Schreiben

Item one of the newsletter is the most modest and the easiest to misread. The Federal Ministry of Finance has published an English translation of the BMF-Schreiben that announces the officially prescribed dataset and the officially determined interface for reports to the BZSt under the FKAustG. For a cross-border group whose tax-technology or reporting function does not operate in German, that translation removes a real friction point when specifying a build or briefing a vendor.

The BMF page provides both the 14 January 2026 BMF-Schreiben and an English-language version. The BMF-Schreiben publishes the officially prescribed dataset under section 5(1) FKAustG, and the dataset description specifies the reporting structure and application date.

This item creates no new obligation and no new deadline. It is worth a short note to whoever owns the German CRS mapping and to any external filing agent, so that the reference copy in circulation is the current one, and the item is otherwise a documentation update.

Saint-Martin: the records to send again

Item three is a task for the reporting period just filed. The newsletter reports that, because of a technical misconfiguration, records for the state of Saint-Martin, the French part, were rejected in the current reporting period even though Saint-Martin is listed in the exchange country list (Staatenaustauschliste). Financial institutions whose corresponding records were rejected are asked to transmit them again.

The word to notice is rejected. Under the BZSt communication handbook, data for a reporting year that has not yet been transmitted or that was rejected after transmission must be submitted using the initial-report filing type (Erstmeldung). So the resubmission of the affected Saint-Martin records goes in as an initial report (Erstmeldung); the correction form (Korrekturmeldung) is not used for data that was rejected. For a correction, CorrDocRefID must reference an accepted, non-rejected AccountReport from an initial or correction delivery for the same reporting period.

Two checks make the task safe. First, confirm which records were actually rejected before resending, so you do not push the whole Saint-Martin population back through: the processing protocol in the BZSt online.portal, visible under the overview of your own submissions, shows the status of each delivery. Second, because the 31 July 2026 deadline for 2025 data has passed, handle any required resubmission promptly and retain the processing evidence. The FKAustG provides for the authority-to-authority exchange on 30 September, but that does not by itself guarantee that a late refile will be included in that exchange. Teams that manage cross-border payment data reporting will recognise this pattern of validation rejections and mandated refiles from the CESOP world; the mechanics differ, but the discipline of reading the processing report before resending is the same, as our note on CESOP filing errors and fixes sets out.

Channels, certificates, and the annual deadline that frame BZSt CRS reporting

None of these items changes the plumbing of German CRS reporting, but each one lands on that plumbing, so it is worth restating what a reporting institution is working with. For the v3.0 setup, the 14 January 2026 BMF-Schreiben specifies three transmission structures: the CRS form for individual-data reporting, automated mass-data transmission via DIP, and manual mass-data XML upload. CRS Newsletter 02/2026 confirmed that the BOP (BZSt-Online-Portal) mass-data upload has been activated for CRS production filings; a test environment for the BOP upload route had not yet been established at that point.

BZSt online.portal login supports ELSTER, a BZSt certificate or bundID. For automated mass-data transmission, the interface change is part of the v3.0 build: the 14 January 2026 BMF-Schreiben changes the transmission structure from ELMA to DIP and requires schema version 3.0 for transmissions from 1 January 2027; the v3.0 dataset restricts the DIP identity provider to BZST-CERT or ELSTER, so mass-data reporters should verify the credential used by their DIP process separately. The same instrument separately permits manual mass-data XML upload through the BZSt online.portal without a DIP envelope.

The annual deadline anchors everything. Initial reports for a reporting period must have been successfully transmitted by 31 July of the following calendar year, so 2025 data was due on 31 July 2026 and 2026 data will be due on 31 July 2027. Correction and deletion filings are not tied to the 31 July date and can be submitted afterwards. The completeness rules that govern what goes into a report are set by the FKAustG, not by the handbooks; section 8 of the FKAustG generally requires TIN information and, for natural persons, date and place of birth, subject to the statutory exceptions for certain existing accounts, jurisdictions that do not issue TINs, and the conditions governing reporting of place of birth.

Frequently Asked Questions

Does the 1 January 2027 schema v3.0 date change the deadline for my 2025 reporting-period data?

No. Data for the 2025 reporting period was due by 31 July 2026 and was built on schema version 2.0. The version 3.0 requirement from 1 January 2027 applies to submissions made under the new schema; it changes the format and content of future filings and leaves the 31 July annual deadline itself in place.

I filed Saint-Martin records this year and they were accepted. Do I need to resend anything?

No. The newsletter asks only institutions whose Saint-Martin records were rejected because of the misconfiguration to transmit them again. Accepted records are unaffected. Confirm the status against the processing protocol in the BZSt online.portal before acting.

When I resend rejected Saint-Martin records, is that a correction filing or an initial report?

It is an initial report. The BZSt handbook directs that the initial-report form is used where data was not yet transmitted or was rejected after transmission; the correction form applies only to data that was previously accepted and carries an existing reference identifier.

Which country code is affected, and is Saint-Martin still an exchange partner?

Saint-Martin, the French part, remains within the 2026 CRS exchange-country scope. For the refile, use the country code specified for Saint-Martin in the current BZSt CRS participating-state list rather than carrying forward the historic France mapping from an earlier list.

Do I need the English translation of the BMF-Schreiben to file correctly?

No. The binding instrument is the German BMF-Schreiben dated 14 January 2026, and validation runs against the German dataset description. The BMF website provides an English-language version alongside the German BMF-Schreiben. The filing specification is the officially prescribed dataset published under section 5(1) FKAustG.

Does schema v3.0 mean crypto-assets now go into my CRS report?

The OECD Amended CRS that version 3.0 implements widens scope to specified electronic money products and central bank digital currencies and adds more granular account and controlling-person data. Crypto-asset transaction reporting itself runs through the separate Crypto-Asset Reporting Framework, outside the CRS return, so the two are best scoped as related but distinct build streams.

Can I start building and testing against version 3.0 now?

The version 3.0 dataset description has been available in the BZSt CRS schema v3.0 topic area since it was published in January 2026, and the OECD amended CRS XML schema has been public since October 2024, so specification and internal build can begin now. Confirm the current BZSt testing arrangements before transmitting test data; the prescribed DIP structure supports separate TEST and PROD environments, with test data to be transmitted using TEST and production data using PROD.

Can I submit a correction or deletion through the BZSt online.portal CRS form during the current period?

The BZSt CRS Newsletter 04/2026 notes that process-related forms (vorgangsbezogene Formulare) in the BZSt online.portal are temporarily suspended; the non-process-related (free) forms remain available. Confirm the current form-availability status against the BZSt online.portal before submitting any correction or deletion filing via the portal form.

Related Articles

• CRS Reporting Explained: how the Common Reporting Standard due-diligence and reporting cycle works from account classification to filing.
• FATCA Reporting: the US information-exchange regime that runs on its own XML schema; the German FATCA reporting deadline is also 31 July.
• CARF Crypto-Asset Tax Reporting: the OECD crypto framework that travels alongside the Amended CRS.
• DAC7 Platform Operator Reporting: the parallel EU information-exchange obligation for digital platform operators.
• CESOP Filing Errors and Fixes: how validation rejections and refiles play out in the EU payment-data reporting regime.
• EU Tax Simplification and the DAC Recast: where the exchange-of-information framework is heading next.

Key Takeaways

• Build to CRS XML schema version 3.0 now: the version 3.0 dataset description was published in the 14 January 2026 BMF-Schreiben and applies to transmissions from 1 January 2027.
• Verify the BZSt operational cut-off date for version 2.0 acceptance against current BZSt notices before committing to a freeze plan; the BZSt has signalled 1 December 2026 as an expected boundary. The legal requirement is version 2.0 through 31 December 2026 and version 3.0 from 1 January 2027.
• Clear any outstanding v2.0 corrections, deletions and catch-up initial reports before 31 December 2026; if the BZSt confirms an earlier operational cut-off, treat that earlier date as the effective deadline.
• Refile only the Saint-Martin records the BZSt processing protocol shows as rejected, and file each one as an initial report.
• Treat the Saint-Martin resubmission as prompt work: those rejected records sit outside the 31 July deadline that has already passed for the 2025 reporting period.
• Distribute the English-language version of the BMF-Schreiben, available on the Federal Ministry of Finance website, to cross-border teams and vendors as a reference copy; the officially prescribed dataset is published under section 5(1) FKAustG.
• Keep the 31 July annual deadline fixed in the plan: 2025 data was due 31 July 2026, and 2026 data is due 31 July 2027, whatever the schema move does.
• Confirm the DIP identity credential ahead of the December freeze: the v3.0 DIP channel accepts only BZST-CERT or ELSTER; BZSt online.portal login additionally supports bundID but that credential is not valid for automated DIP mass-data transmission.
• Check form availability before filing corrections or deletions through the BZSt online.portal: the newsletter notes that process-related forms (vorgangsbezogene Formulare) are temporarily suspended; confirm current form status against the BZSt online.portal before submitting.

Sources and References

• Bundeszentralamt fuer Steuern, CRS Newsletter 04/2026 (9 September 2026): bzst.de
• Bundeszentralamt fuer Steuern, CRS Newsletter 02/2026 (16 March 2026), on the schema v3.0 dataset description and the 14 January 2026 BMF-Schreiben: bzst.de
• Bundeszentralamt fuer Steuern, CRS Newsletter 01/2026 (20 February 2026), on the exchange country list and the data-transmission channels: bzst.de
• Bundeszentralamt fuer Steuern, Kommunikationshandbuch CRS Teil 2 (BZSt online.portal), on the 31 July deadline and the initial, correction, deletion and cancellation filing types: bzst.de
• Bundeszentralamt fuer Steuern, Common Reporting Standard overview: bzst.de
• Finanzkonten-Informationsaustauschgesetz (FKAustG), Gesetz zum automatischen Austausch von Informationen ueber Finanzkonten in Steuersachen: gesetze-im-internet.de
• OECD, Amended Common Reporting Standard XML Schema (October 2024): oecd.org
• OECD, Crypto-Asset Reporting Framework and amended Common Reporting Standard: IT format and interpretative guidance (October 2024): oecd.org

What to put on the CRS calendar now

The newsletter reduces to four items. The Saint-Martin resubmission is due as soon as the affected records are identified in the processing protocol, filed as initial reports. Version 2.0 is required for transmissions through 31 December 2026 per the BMF-Schreiben; if the BZSt confirms an earlier operational cut-off for version 2.0 acceptance, treat that earlier date as the effective filing deadline. Version 3.0 becomes the required schema from 1 January 2027, built against a dataset description published in the 14 January 2026 BMF-Schreiben and available to develop against since. The English-language version is a reference copy to distribute. One item is operational and immediate: process-related forms (vorgangsbezogene Formulare) in the BZSt online.portal are currently suspended; confirm the current form-availability status before filing any correction, deletion or cancellation through the portal form, and use the non-process-related (free) forms that the newsletter confirms remain available. Confirm any earlier BZSt operational cut-off date against current BZSt notices and verify the v3.0 transition arrangements before you freeze anything, then work backwards from 31 July 2027.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.