What it is
XSLT — XML Stylesheet Language Transformations — is a W3C standard for transforming XML documents. A stylesheet is itself an XML document containing templates that match nodes in the input (using XPath) and emit output. The output can be XML (e.g. UBL converted to CII), HTML (a human-readable invoice viewer), plain text (a CSV export), or arbitrary serialized formats including JSON in XSLT 3.0.
Three versions are in active use:
XSLT is declarative — you describe what the output should look like for each kind of input node, not the step-by-step procedure for producing it. The XSLT engine handles the traversal order, template matching, and output sequencing.
Why XSLT shows up in EU e-invoicing
There are three places an ERP vendor will encounter XSLT during EN 16931 work, and the right one to focus on depends on which side of the pipeline the vendor sits.
1. Schematron compilation
The official EN 16931 Schematron, every CIUS Schematron (XRechnung, Peppol BIS Billing 3.0, the Dutch SI-UBL profile, the French specs), and the country-specific extensions are all distributed as .sch files containing XPath 2.0 assertions. Running raw Schematron at validation time is expensive — every assertion has to be re-parsed and re-bound on each invoice.
The standard solution is ISO Schematron's iso_svrl_for_xslt2.xsl, a meta-stylesheet that compiles a Schematron file into an XSLT 2.0 stylesheet. Validation then becomes: apply the compiled XSLT to the invoice, get back an SVRL (Schematron Validation Report Language) document listing the failed assertions. This compiles once at build time and runs in single-digit milliseconds per invoice.
Every serious EN 16931 validator — the Connecting Europe Facility reference validator, KoSIT's validator, the Peppol Test Bed validator, every commercial validator I'm aware of — works this way. "Schematron support" almost always means "compiled Schematron, executed as XSLT."
2. Viewer transformations (UBL/CII → HTML/PDF)
Machine-readable XML is not human-readable. When an EN 16931 invoice arrives at an accounts-payable clerk's screen, somebody has to render it. The dominant approach in Germany — and increasingly across the EU — is to use XSLT to transform the invoice into HTML or XSL-FO (which then renders to PDF).
KoSIT's xrechnung-visualization project is the de facto reference. It ships XSLT 2.0 stylesheets that convert any XRechnung-conformant UBL or CII invoice into an HTML view (with codelist labels resolved from UN/CEFACT recommendations) or a PDF via Apache FOP. The stylesheets are open source and many ERP vendors and government portals embed them directly rather than building their own viewers.
France's PPF specification and several Peppol authorities reference KoSIT's viewer as the recommended rendering implementation. "Render an EN 16931 invoice as a PDF" is rarely a custom build; it is almost always a KoSIT XSLT stylesheet plus a FOP renderer.
3. ERP-format-to-EN-16931 mapping
Most ERP systems have an internal invoice representation that is not UBL and not CII. Converting from "the way our system thinks about invoices" to UBL or CII is a transformation problem, and XSLT is one of the standard tools for it — particularly when the source is already XML (a legacy EDIFACT-XML wrapper, an internal canonical-XML format, or a SAP IDoc-XML export).
The alternative is procedural code in Java/.NET/Python with an XML builder. Both work; XSLT wins when the mapping rules are stable and the team owns a Saxon licence (or uses Saxon HE).
XSLT engines and the EN 16931 toolchain
For XSLT 2.0 and 3.0 (the versions EN 16931 needs), there is effectively one production-grade engine and a handful of niche alternatives.
XslCompiledTransform), Java (javax.xml.transform.TransformerFactory default), Python (lxml), Go (encoding/xml has none — third-party only). All XSLT 1.0; none can execute the EN 16931 compiled Schematron.The practical consequence: if your EN 16931 validation pipeline does not have Saxon (or an equivalent XSLT 2.0+ engine) in the dependency graph, it is not running real Schematron validation. It is running something else — a hand-translated subset of the rules, an XPath 1.0 approximation, or a regex parade. None of those will catch the same errors the official artefacts catch.
XSLT vs. XPath vs. XSD vs. Schematron — the validation toolchain
These four are often confused. In an EN 16931 pipeline they have distinct roles:
An invoice gets parsed (well-formed XML), validated against XSD (structure), validated against XSLT-compiled Schematron (business rules, written in XPath, expressed as a stylesheet), and rendered to HTML via a separate XSLT stylesheet. Four W3C standards layered into one validation-and-viewing pipeline. Every one of them is mandatory for a serious implementation.
Relation to EN 16931
XSLT is not itself referenced by EN 16931. The standard mandates UBL 2.1 or CII D16B as the XML syntax and references Schematron for the business rules — XSLT is the implementation technology that ties them together. But every realistic EN 16931 implementation depends on XSLT in at least one of the three places above, and most depend on it in all three. For an ERP vendor scoping an EN 16931 integration, "do we have an XSLT 2.0 toolchain?" is a foundational architecture question, not an implementation detail.