XRechnung 3.0.2 Bugfix Release: What Changed in the Validation Rules

XRechnung 3.0.2 is still the version in force, but the official validation rules have been stricter since 31 August 2026. The XRechnung 3.0.2 Summer 2026 Bugfix bundle turns an invalid URL in BT-124 into an error, adds warnings for date formats and raises duplicate contact details in CII to errors. There are no new mandatory fields.

This article is for suppliers invoicing German public authorities, software vendors and accounts payable teams who see a new message on an invoice that passed before. All rule changes come from the changelogs of the KoSIT repositories, as of 19 October 2026.

What did KoSIT release on 31 August 2026?

The Coordination Office for IT Standards (Koordinierungsstelle für IT-Standards, KoSIT) lists the "XRechnung Bundle 3.0.2 Summer 2026 Bugfix" on xeinkauf.de (opens in a new tab), dated 31 August 2026 and valid from that day. A bundle groups the technical components that belong to a specification. The specification itself is unchanged: XRechnung 3.0.2, dated 20 June 2024.

KoSIT states that there was no normative XRechnung release in summer 2026 and therefore no version change. XRechnung 3.0 stays in force until at least 31 July 2027.

The bundle updates three components:

The validator engine itself was released as version 1.6.3 on 20 August 2026. How engine and configuration fit together is explained in our guide to the KoSIT validator.

Which validation rules became stricter?

The table lists every rule change from the changelogs with its new level. "Error" means the report recommends rejecting the invoice. "Warning" and "information" do not block acceptance.

BR-TMP-2: external links need a scheme

BT-124 holds the address of an external document, such as a delivery note on the supplier's server. The rule has existed since XRechnung Schematron 2.3.0 of 21 March 2025, where it was a warning. Version 2.6.0 raises it to "fatal".

So a value like www.example-supplier.com/delivery-note-4711.pdf without https:// now leads to a reject recommendation. KoSIT's changelog warns that "this version might break your validation and business workflow". If you never fill BT-124, nothing changes for you.

BR-TMP-6 and BR-TMP-7: date formats

Both rules cover nine date fields:

• BT-2 (invoice issue date) and BT-7 (VAT point date);
• BT-9 (payment due date) and BT-26 (preceding invoice issue date);
• BT-72 (actual delivery date);
• BT-73 and BT-74 (invoicing period start and end);
• BT-134 and BT-135 (invoice line period start and end).

In UBL, BR-TMP-6 requires exactly the pattern YYYY-MM-DD. The XML Schema type xs:date also allows a time zone, such as 2026-10-19+02:00. Such a value passes the schema check but now raises a warning. Check how your software writes dates before the warning becomes an error. An example (abridged, not validator output):

<!-- triggers BR-TMP-6 -->
<cbc:IssueDate>2026-10-19+02:00</cbc:IssueDate>
<!-- passes BR-TMP-6 -->
<cbc:IssueDate>2026-10-19</cbc:IssueDate>

In CII, BR-TMP-7 requires the attribute format="102" and eight digits: <udt:DateTimeString format="102">20261019</udt:DateTimeString>.

The changelog adds a clear note: BR-TMP-4 to BR-TMP-7 run as warnings for now and "will be raised to 'fatal' with an upcoming release". KoSIT gives no date.

Duplicate contact points in CII

In CII, the contact point BT-41 can sit in ram:PersonName or in ram:DepartmentName. The CEN rule CII-SR-465 fires when the seller has both elements, and CII-SR-466 does the same for the buyer (BT-56). In the CEN rules this is a warning. Configuration 2026-08-31 sets both rules to "error" in the three XRechnung CII scenarios.

A CII invoice that writes a contact name and a department into both elements now fails. UBL is not affected, because BT-41 there is a single cbc:Name element.

Attachments: corrected rules for BT-123 and BT-125

According to KoSIT, CII-SR-475 and CII-SR-476 check in the wrong context in CEN Schematron 1.3.16 (CEN issue 508 (opens in a new tab)). The configuration lowers both to "information". BR-TMP-4 and BR-TMP-5 run the same checks in the correct context, as warnings for now. How attachments in BG-24 are built is shown in our guide to XRechnung attachments.

One relaxation: PEPPOL-EN16931-R008

Peppol rule R008 forbids empty elements. In UBL, however, the schema requires cac:OrderReference/cbc:ID (BT-13) whenever the sales order reference (BT-14) is given. Since 2.6.0, R008 no longer reports an empty BT-13 in that case.

What changed in the validation report?

One change affects the assessment, not the rules. When processing aborts, the report used to say "Es wird empfohlen das Dokument zurückzuweisen" (rejection recommended). Since configuration 2026-08-31, it says "Das Dokument sollte nicht automatisiert angenommen werden" (do not accept automatically). If your integration parses the report text, add the new wording.

What does the bugfix release mean for whom?

Whether a message matters for VAT is a separate question. The German Ministry of Finance distinguishes format errors, business rule errors and content errors; see e-invoice format error for how each is treated.

What stays the same?

• The specification identifier in BT-24 for XRechnung 3.0 does not change.
• There are no new mandatory fields and no new BR-DE rules.
• The eleven scenarios of the configuration remain: XRechnung (CIUS, Extension, CVD) and plain EN 16931 for UBL Invoice, UBL CreditNote and CII.
• The difference between error and warning remains: only errors lead to a reject recommendation.

Timeline: from XRechnung 3.0.2 to 4.0

What the 4.0 pre-release changes in fields and rules is covered in our article on XRechnung 4.0.

Action items

1. Export one test invoice in UBL and, if you use it, one in CII from your invoicing software.
2. Validate both with a tool that uses configuration 2026-08-31.
3. Search the XML for ExternalReference/URI (UBL) or ram:URIID (CII) and check that every value starts with https:// or another scheme.
4. Check every date field for the plain format without a time zone.
5. In CII: if the seller or buyer has both ram:PersonName and ram:DepartmentName, drop one.
6. Treat the new warnings BR-TMP-4 to BR-TMP-7 as future errors and report them to your software vendor.

For case-by-case troubleshooting, see how to fix XRechnung validation errors.

Open questions

• Date of the upgrade to errors: when BR-TMP-4 to BR-TMP-7 become errors is not fixed. KoSIT only refers to an upcoming release (changelog 2.6.0).
• CEN fix: whether and when CEN corrects CII-SR-475 and CII-SR-476 is open; after that, BR-TMP-4 and BR-TMP-5 may be dropped.
• Transition to 4.0: KoSIT plans to announce the transition periods with the final XRechnung 4.0 bundle.

How to check your XRechnung with docutools.pro

1. Open the XRechnung validator and upload your .xml file. The file is sent to our server for the check. The free plan covers two uploads a day up to 500 KB; the Pro plan removes these limits.
2. Since 29 September 2026, the "KoSIT validation" runs with exactly configuration 2026-08-31, so with XRechnung Schematron 2.6.0, CEN Schematron 1.3.16 and the new severity levels. Compared with the KoSIT validator 1.6.3, it gave the same results on 119 test files.
3. You see "KoSIT-conformant / Valid XRechnung" or "Not KoSIT-conformant", with the list of errors and warnings and their rule codes. Explanations of common codes are in the XRechnung error codes reference.
4. To find the affected elements, open the file in the XML viewer. It runs in your browser and shows the tree with every date and contact element.

The viewer does not produce a validation report to keep on file; use the KoSIT validator itself for that. More guides are under validation and errors.

Sources

• KoSIT: XRechnung versions and bundles (opens in a new tab)
• KoSIT: changelog of the XRechnung validator configuration (opens in a new tab)
• KoSIT: changelog of the XRechnung Schematron (opens in a new tab)
• KoSIT: changelog of the XRechnung visualization (opens in a new tab)
• KoSIT validator: releases (opens in a new tab)

Last reviewed: October 2026

This article is general information, not tax or legal advice.