CESOP in Germany: § 22g UStG reporting to the BZSt

In Germany, CESOP is a VAT-law duty with a tax-office channel, not a payments-supervisor return. § 22g of the Value Added Tax Act (UStG) makes payment service providers record cross-border payments and send them, quarter by quarter, to the Federal Central Tax Office (Bundeszentralamt für Steuern, BZSt), which passes them on to the EU’s Central Electronic System of Payment information. The obligations look like the EU text, but the German version adds its own access route, a one-month correction clock and a fine regime. This piece walks through who is caught, what goes in the record, how the file reaches the BZSt, and three cases a payments firm actually meets.

1. The legal basis

CESOP rests on two EU acts adopted on 18 February 2020: Council Directive (EU) 2020/284, which added the payment-provider duties to the VAT Directive (Articles 243a to 243d of Directive 2006/112/EC), and Council Regulation (EU) 2020/283, which amended Regulation (EU) No 904/2010 to create the central system and the exchange between tax administrations. A Commission Implementing Regulation of 6 April 2022 sets the technical details of the system.

Germany transposed the directive through the Annual Tax Act 2022, which inserted § 22g into the UStG. The duty applies to cross-border payments from 1 January 2024. The Federal Ministry of Finance issued an administrative letter on the new rules on 28 December 2023, and the BZSt publishes the legal texts, the XML schema, the user manual and an FAQ on its CESOP pages. Questions go to the BZSt’s CESOP unit (Referat St III 9) in Bonn.

2. Who has to report to the BZSt

§ 22g(7) UStG defines the payment service provider by reference to the Payment Services Supervision Act (ZAG). It covers:

• providers under § 1(1) sentence 1 nos. 1 to 3 ZAG — credit institutions, e-money institutions and payment institutions — and persons exempt under Article 32 of Directive (EU) 2015/2366, where they have their seat, head office or a branch in Germany;
• providers that serve Germany without being established there, either under the freedom to provide services or through an agent — the host-state limb taken from the directive.

The payment services in scope are those in § 1(1) sentence 2 nos. 3 to 6 ZAG: direct debits and credit transfers (including when they draw on a credit line), card-based payments, the issuing and acquiring of payment instruments, and money remittance. A “payment” is a payment transaction within § 675f(4) of the Civil Code (BGB) or a money remittance, subject to the ZAG’s own exclusions in § 2(1).

The BZSt FAQ reads this as three tests that must all be met: you are a payment service provider, you provide one of these services, and you are involved in a payment from a payer in one Member State to a payee in another Member State, a third territory or a third country. Intermediary providers are not carved out; the FAQ says there is no limit on the number of providers on the payee’s side that can be caught.

3. The trigger: more than 25 payments, counted the German way

The recording duty bites only where a provider handles more than 25 cross-border payments to the same payee in a calendar quarter (§ 22g(1) sentence 2). The counting rule has three parts worth reading closely:

• Per Member State and per identifier. The count is run separately for each Member State and for each payee identifier — IBAN, or another identifier that locates the payee — and for each business identifier of a provider acting for a payee without an account.
• Per payee where you know. If the provider knows that one payee holds several identifiers, the count is run per payee instead.
• Location by identifier. Payer and payee location come from the IBAN or an equivalent identifier. Only if none exists does the location of the provider, taken from its BIC, stand in (§ 22g(2)).

Domestic payments are excluded, and so are payers in the special VAT territories listed in Article 6 of the VAT Directive. Because the threshold can only be judged once the quarter is over, the BZSt states that recording starts with the first cross-border payment, not with the 26th.

In practice the exemption in § 22g(3) decides most of the population. Where the payee’s provider, identified by its BIC, is established in the EU, the report is that provider’s job. The payer’s provider reports only where the payee is served by a provider outside the EU — the typical case being card or transfer payments to a merchant or marketplace banked in a third country.

4. What the record contains

§ 22g(1) lists the content, and § 22g(4) adds the reporting provider’s own BIC or other business identifier. The table maps the statute to the data a payments firm usually holds.

The file itself follows the EU CESOP XML schema. The BZSt’s production environment runs schema version 4.03, with 4.02 still accepted as backward compatible; versions 4.00 and 4.01 are no longer supported at EU level. The Commission’s “CESOP Guidelines for Reporting” (version 1.2) explain how to fill the fields; the BZSt states that they are guidance only and not the German administration’s official position.

5. Getting the file to the BZSt

CESOP reports go only through the BZSt’s mass-data interface, the DIP (Digitaler Posteingang) in the BZSt online portal. There are two ways in: an automated XML exchange, or a manual upload in the portal, capped at 200 MB per upload. The steps for a first filing are:

1. Get a certificate. Registration on the BZSt online portal needs a valid ELSTER certificate or a BZSt certificate. A foreign provider with no German tax number registers with the BZSt form instead and receives a BZSt number by letter and a BZSt secret by e-mail, then applies for the certificate with the activation ID and code.
2. Activate the DIP. The data transmitter — the provider itself or a third party sending for it — files the application for activation of the mass-data interface. Until the DIP is activated, no CESOP message can be sent.
3. Test. A customer test environment accepts messages of up to 10 MB and returns a validation result through the same interface. The BZSt also offers the EU validation module for download, which you integrate into your own systems to check files before sending.
4. Send and collect the status. The BZSt says status messages normally come back within a few hours or days. They are retrieved through the interface, not e-mailed.

The deadline is the end of the calendar month after the quarter (§ 22g(4)): 30 April, 31 July, 31 October and 31 January. There is no statutory nil return, but the BZSt recommends sending an empty report anyway, to avoid reminders and follow-up questions.

6. Corrections, retention and fines

Two German rules sit on top of the EU text. First, a provider that finds transmitted data wrong or incomplete must correct or complete it within one month of discovering the error (§ 22g(5)). Second, the records must be kept electronically for three calendar years after the end of the year of the payment (§ 22g(6)).

§ 26a(2) nos. 8 to 10 UStG make it an administrative offence to transmit late, incompletely or incorrectly, to miss the one-month correction, or to destroy records early. Each can be fined up to EUR 5,000 (§ 26a(3)), and the BZSt is the competent authority. The amount is modest; the practical risk is that a quarter-level data defect is repeated in every quarter until someone notices.

7. Worked case: a passported EMI serving German merchants

Facts: an e-money institution authorised in another Member State acquires card payments for small German online shops under the freedom to provide services. Its cardholders’ payments come mainly from France, Austria and the Netherlands.

What the rule says: the institution is the payee’s provider and is established in the EU, so the reporting duty sits with it. It owes its home Member State a CESOP file, and — because it provides payment services in Germany without being established there — § 22g(7) also brings it into the German regime as a host-state provider. Section 4.4 of the Commission’s Guidelines governs which payments go into which Member State’s file.

What the practitioner does: builds a filing map per Member State before any data work, registers with the BZSt via the form route (no German tax number), activates the DIP, and runs the per-payee count on the German merchants’ IBANs or merchant IDs. Merchants with 25 or fewer cross-border payments in the quarter drop out; those above are reported with every payment and refund in the quarter.

Outcome: two CESOP files per quarter with different populations, each validated against the same schema but through different national channels.

8. Worked case: the payer’s side and a third-country marketplace

Facts: a German payment institution holds accounts for consumers. In one quarter its customers send 31 credit transfers to a marketplace whose account is held with a provider in a third country, and 40 transfers to a merchant whose account is with a Spanish bank.

What the rule says: for the Spanish-banked merchant, the payee’s provider is in the EU, so § 22g(3) removes the recording duty from the German institution; the Spanish provider reports. For the marketplace, no EU provider sits on the payee side, so the German institution — as payer’s provider — must record and report the 31 payments, because they exceed 25.

What the practitioner does: classifies every outgoing cross-border payment by the BIC country of the payee’s provider first, then counts. The 40 EU-side payments are kept in the count logic (§ 22g(3) requires it) but not in the file.

Outcome: one reportable payee, 31 payment records, filed by 31 October for a third-quarter population.

9. Worked case: a refund defect found after filing

Facts: in November, a reconciliation shows that refunds to German merchants’ customers were missing from the third-quarter file because the refund flag was not mapped.

What the rule says: § 22g(5) gives one month from discovery to correct. Missing it is a separate offence under § 26a(2) no. 9, independent of the original error.

What the practitioner does: logs the discovery date, sends a correction message through the DIP referencing the original records (the EU schema requires new, unique message and document references for every send), and fixes the mapping before the fourth-quarter build.

Outcome: the file is corrected within the window, and the evidence trail shows when the error was found and when it was fixed.

FAQ

What to do, today

• Head of regulatory reporting: confirm whether you are in the German regime as home, branch or host-state provider, and write it into the filing map.
• Operations: check that the ELSTER or BZSt certificate is valid and that the DIP activation names the right data transmitter.
• Data team: test the per-identifier and per-payee count against § 22g(1) sentence 4, and keep the § 22g(3) payer-side payments in the count.
• Compliance: add a “date discovered” field to the CESOP error log so the one-month correction clock can be evidenced.

Related: Building the CESOP file · CESOP in the Netherlands · CESOP in Spain: Modelo 379