XRechnung Visualization Without the XSLT Stack: KoSIT Stylesheets vs One API Call

Sooner or later every team processing XRechnung invoices needs to show one to a human, and the search for "xrechnung visualization" leads to exactly two serious answers. One is the official open-source route: KoSIT, the body behind the XRechnung standard itself, publishes XSLT stylesheets that turn the XML into HTML or PDF. The other is a managed API that does the same in one HTTP call. Both produce a readable invoice; they differ almost entirely in what you have to operate to get it. This comparison is written by the maker of the API route, which is precisely why the stylesheet route gets described accurately and credited first.

What visualization means here

An XRechnung has no visual layer by design: the XML is the invoice, and anything a person reads is derived from it. Visualization is that derivation, ideally one that shows every business term the document carries, labels fields in plain language, handles both of the standard's syntaxes (UBL and CII, including UBL credit notes), and keeps working when KoSIT publishes the next release of the standard. Both routes below meet that bar; the question is where the machinery runs and who maintains it. If you just need to read a file that landed in your inbox today, skip the engineering entirely: the how-to-open-an-XRechnung guide covers the browser tools. This post is for teams wiring visualization into a product or pipeline.

The KoSIT stylesheets: what you get

Credit first, because the project deserves it. xrechnung-visualization is the official visualization component of the XRechnung standard, Apache-2.0 licensed and maintained by the same organisation that maintains the standard itself, which makes it the reference answer to "what should this invoice look like on screen".

Technically it is a two-step XSLT pipeline. Step one transforms the source document (UBL Invoice, UBL CreditNote, or CII) into an intermediate XML model of the EN 16931 semantics, validated against the project's own schema. Step two renders that intermediate model, through xrechnung-html.xsl into a self-contained HTML view, or through xr-pdf.xsl into XSL-FO, which a formatter such as Apache FOP turns into PDF, with configurations for accessible PDF/UA-1 and archival PDF/A-1 output. Labels ship in German and English via a lang parameter, the repository includes an Ant build that wires the whole chain together, and releases track the standard: recent versions target XRechnung 3.0 and pin their toolchain to current Saxon builds. It is a genuinely complete, well-run open-source project.

So the honest framing is not whether the stylesheets are good. It is what running them takes, and that depends heavily on where your code lives.

The stack you operate

The stylesheets are source artifacts, not a service. To turn them into a feature, you operate:

An XSLT processor beyond what your platform ships. The transforms require a modern XSLT processor; in practice that means Saxon, the processor the project itself builds and tests against, and Saxon is a Java library. An XSL-FO engine for PDF. HTML comes straight from XSLT, but PDF goes through XSL-FO, and the open-source formatter is Apache FOP, another Java dependency with its own configuration surface: fonts, the PDF/UA and PDF/A profiles, image handling. The pipeline glue. Two chained transforms with an intermediate schema validation between them, per syntax, with the right stylesheet chosen per root element, plus error handling for the files that do not match any of them. A JVM in your deployment, because Saxon and FOP live there, even if nothing else in your product does.

On a JVM stack with XSLT experience in the team, this is a manageable weekend project plus ongoing ownership. The ongoing ownership is the part that quotes low: fonts that render differently after a FOP upgrade, a Saxon major version bump, the intermediate schema changing between releases, and every one of those multiplied by however many services need the feature.

Outside the JVM it gets harder

Most teams that hit this problem are not on the JVM. Their invoicing product is .NET, Node.js, Python, or PHP, and there the stylesheet route develops a structural problem: the built-in XSLT support in those ecosystems stops at XSLT 1.0, which cannot run these transforms, and none of them has a production XSL-FO engine at all. The realistic options become shelling out to a bundled Java toolchain (now you ship and patch a JRE), running a sidecar rendering service on the JVM (now you operate a second deployment for one feature), or calling a hosted API (now it is one HTTP call, which your stack already does well).

This is the same shape as the validation problem covered in the Mustangproject comparison: the official artifacts of German e-invoicing are built on Java-centric tooling (Saxon for Schematron there, Saxon plus FOP here), and every non-JVM stack pays an operational tax to run them locally. Rendering simply makes the tax visible earlier, because it is often the first feature a receiving-side product needs.

The release treadmill

XRechnung moves on a schedule: KoSIT publishes standard releases twice a year, and the visualization project releases alongside to track them. Sub invoice lines arrive in one release, label fixes and toolchain bumps in the next. Each time, the self-hosted pipeline repeats the same loop: watch the announcement, take the new stylesheets, re-run your rendering tests (fonts, layouts, both syntaxes, credit notes), and redeploy every service that renders. None of it is hard; all of it is recurring, unplannable-around, and multiplied across services. The treadmill is the steady-state cost of the route, and it never ends because the standard never stops moving.

The API route: one call

The managed alternative collapses the stack to an HTTP request:

curl -X POST https://api.invoicexml.com/v1/render/xrechnung/to/pdf \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  --output xrechnung-preview.pdf

The same call in C#, the stack where the XSLT route hurts most:

using var http = new HttpClient();
http.DefaultRequestHeaders.Authorization = new("Bearer",
    Environment.GetEnvironmentVariable("INVOICEXML_API_KEY"));

using var form = new MultipartFormDataContent();
form.Add(new ByteArrayContent(await File.ReadAllBytesAsync("xrechnung.xml")),
    "file", "xrechnung.xml");

var response = await http.PostAsync(
    "https://api.invoicexml.com/v1/render/xrechnung/to/pdf", form);
response.EnsureSuccessStatusCode();

await File.WriteAllBytesAsync("xrechnung-preview.pdf",
    await response.Content.ReadAsByteArrayAsync());

Syntax detection (UBL, CII, credit notes) happens server-side from the root element; versions old and new render because the layout is built from the EN 16931 business terms; labels come in English, German, or French via the language field; and the "Electronic invoice details" section surfaces the e-invoicing-specific fields (identifiers, references, listed attachments) that reviewers actually need to see. Processing is stateless: the file lives in memory for the duration of the request and is discarded with the response. When the standard moves, the server moves with it, and your integration does not change.

Side by side

When the stylesheets are the right choice

An honest comparison names the cases where the open-source route wins. Data may not leave your infrastructure: if policy forbids any external processing even of stateless calls, self-hosting is the answer and the stylesheets are the best self-hosted option. You need pixel-level control of the rendition: the XSL is yours to fork, and a public-sector portal that must match a corporate design manual may need exactly that. You are already a JVM shop rendering at scale: with Saxon and FOP competence in-house, the marginal cost of the stack drops sharply, and per-call pricing may lose to owned infrastructure at very high volume. Outside those cases, and especially outside the JVM, the equation tilts hard toward the API: the feature ships the same afternoon, and the treadmill becomes someone else's job, backed by professional support rather than a GitHub issue queue.

Beyond XRechnung: CII, UBL, and mixed inboxes

The KoSIT stylesheets are scoped to XRechnung, which is the right scope for a standards body and often too narrow for an inbox. Real reception pipelines also see standalone CII documents from ZUGFeRD-centric partners and Peppol BIS UBL from the network, and the render API treats them all as one family: the format-specific routes share a single engine, and POST /v1/render/xml/to/pdf takes any supported syntax and detects it from the root namespace. If your pipeline handles more than XRechnung, the any-XML rendering guide shows the one-route wiring; for the Peppol reception side specifically, see Peppol invoice to PDF.

Get started

The fastest way to compare is on your own documents: drop a real XRechnung on the online preview and judge the output directly. For integration, create a free InvoiceXML account → and get 100 credits for free, no credit card required.

Related resources:

• How to open an XRechnung file and read it as a PDF
• Render any e-invoice XML to PDF with one API call
• Mustangproject alternatives: an honest comparison
• XRechnung API: the complete toolkit for German B2G
• XRechnung rendering API reference
• Full API documentation

InvoiceXML is a REST API for European e-invoice compliance covering XRechnung, ZUGFeRD, Factur-X, Peppol UBL, and CII. Stateless processing, GDPR compliant by architecture, and callable from any stack in minutes.