Validate XRechnung: KoSIT Validator, Schematron errors and what they mean
How the KoSIT Validator checks XRechnungen, what Schematron errors mean and how to automate validation.
How the KoSIT visualization turns an XRechnung into a readable HTML or PDF view without replacing the original.

An XRechnung is an XML file that no human is meant to read directly, and that is exactly the core of the problem when a clerk or a customer still wants to look at the invoice. The solution is called visualization: an XSLT transformation that generates a human-readable HTML or PDF view from the XML structure, without changing anything about the legally authoritative XML original. This article shows how that works technically and what part of it can be automated. As of: August 2026.
An XRechnung contains pure business data in a standardized structure according to EN16931 and the German CIUS extension, but no layout information whatsoever. If you open the file directly, you see nested XML tags instead of an invoice with a header, line items, and totals section. To turn the pure data back into something readable, an additional transformation is needed that defines which field appears where on the page.
The KoSIT provides XSL transformers for this that work in two stages. According to the project's architecture description the XML invoice, whether in UBL or CII syntax, is first converted into a syntax-neutral intermediate form enriched with information about the business terms used from EN16931. In the second step, this intermediate form is used to generate an application-specific HTML representation, whose final appearance is controlled by CSS files that define the position and order of the individual invoice components. According to the project description, these building blocks are explicitly intended as optional components for integration into your own software, not as a ready-made application for download.
What can mainly be automated is the step from the incoming XML file to the HTML or PDF view: a workflow can run the intermediate transformation and the second stage one after another and attach the result directly to an email, a ticket, or a file store as soon as a new invoice arrives. This way, for example, accounting automatically gets a readable view alongside the original XML, without anyone having to manually open a viewer tool. What cannot be automated in the sense of "set up once and forget" is the CSS design itself, because layout decisions such as font size or field order are still made by humans once, when setting up the visualization.
The legally authoritative document remains exclusively the original XML file; the HTML or PDF visualization is only a reading aid. For GoBD-compliant retention, you therefore archive the XML file unchanged; an additionally generated visualization can be stored alongside it, but it does not replace the original. Anyone who instead uses the visualized version as the sole storage location risks losing the machine-readable data that is actually the purpose of the XRechnung for further processing and verification.
No, the transformation follows the same pattern for all XRechnungen, because it builds on the standardized structure according to EN16931. You set up the visualization once and then apply it to every incoming invoice afterward, regardless of the respective sender.
Both syntax forms pass through the same first transformation stage into the syntax-neutral intermediate form; after that, the further path to the HTML view is identical. For end users within the company, the underlying XML syntax of the incoming invoice is therefore no longer visible.
Largely yes, because the header, line items, and totals section can be arranged via the CSS design so that a familiar invoice look results. However, the result matches a specific company's own invoice template exactly only if the CSS file is adjusted individually accordingly.
The building blocks provided by KoSIT are aimed at developers who integrate them into existing software or an n8n workflow. A ready-made click interface without technical integration is not included in the official components; here, individual e-invoicing portals and accounting programs offer their own, sometimes simplified, viewers.
NordFlux builds digital employees for organisations: automations and AI agents that take over repetitive work. You stay in control.
How the KoSIT Validator checks XRechnungen, what Schematron errors mean and how to automate validation.
Receive from 2025, issue from 2027 or 2028: which e-invoice deadline your business faces and what the threshold depends on.
How to build an automatic inbox with n8n that retrieves, recognizes, and forwards e-invoices.
A viewer makes a single XRechnung readable, but it does not solve the real problem: checking, archiving and routing dozens of invoices into the right system every day. NordFlux builds the automated inbound and outbound path for e-invoices, from validation to audit-proof archiving of the XML. In our first conversation, we look at your current invoice workflow and show you what can be automated.