E-Invoice Validator: XRechnung, ZUGFeRD/Factur-X, Peppol BIS 3, EN16931

German businesses have had to be able to receive electronic invoices since January 2025, and the deadline to start issuing them lands in 2027 for larger companies and 2028 for the rest. The rest of the EU is on the same road. So an XML file arrives, your system swallows it or spits it out, and nobody can tell you which of the several hundred numbered rules it broke or where.

The rules are public. They ship as Schematron from the people who wrote the standard: the EN 16931 core rules from the European Commission, XRechnung from KoSIT, Peppol from OpenPEPPOL. Running them is the fiddly part, because they need an XSLT 2.0 engine and a build step. I did that once so you do not have to. Point this Actor at a file and it hands back the same verdict a national validator would, rule by rule.

Auch auf Deutsch / En français / En español / In italiano / In het Nederlands / Po polsku

Deutsch: Prüft Rechnungen im Format XRechnung 3.0 und ZUGFeRD (das eingebettete CII-XML im PDF) gegen die offiziellen Prüfregeln von KoSIT und EN 16931, und nennt jede verletzte Regel mit Nummer und Fundstelle.

Français : Contrôle les factures Factur-X et Peppol BIS 3 en extrayant le XML CII du PDF, puis les valide avec les règles officielles EN 16931, et renvoie chaque règle non respectée avec son identifiant.

Español: Comprueba facturas Facturae 3.2.2 con el esquema XSD oficial, y facturas EN 16931 y Peppol BIS 3 con las reglas oficiales, devolviendo cada regla incumplida con su identificador.

Italiano: Verifica le fatture FatturaPA 1.2.3 con lo schema XSD ufficiale, e le fatture EN 16931 e Peppol BIS 3 con le regole ufficiali, restituendo ogni regola non rispettata con il suo identificativo.

Nederlands: Controleert facturen volgens NLCIUS / SI-UBL 2.0 en Peppol BIS 3 met de officiële validatieregels, en geeft elke gefaalde regel terug met het regelnummer en de plek in het bestand.

Polski: Sprawdza faktury KSeF FA(3) na podstawie oficjalnego schematu XSD Ministerstwa Finansów, a faktury EN 16931 i Peppol BIS 3 na podstawie oficjalnych regul, zwracajac kazda zlamana regule wraz z jej numerem.

What it does

You give it invoice files. It works out what each one is, runs the right official rule sets over it, and returns one row per invoice.

Detection is from the document itself, not from the file name. The root element and its namespace say which of the six supported XML formats you handed over, and the format column in the table below lists all six. A PDF is opened and the embedded invoice XML pulled out of it, which is how a hybrid file works: the human-readable PDF carries the machine-readable XML as an attachment called factur-x.xml, zugferd-invoice.xml or xrechnung.xml.

Then it reads the profile the document claims. UBL says so in CustomizationID and CII in the guideline parameter, and the value is a long URN naming XRechnung 3.0, Peppol BIS Billing 3.0, NLCIUS, Factur-X or plain EN 16931. By default the Actor runs the EN 16931 core rules plus the rules for whatever profile the document declares, so a German invoice gets both the European rules and the German ones. You can override that and force any list of profiles instead.

Every failure comes back with its rule id, the severity the rule itself carries, the message in the language the rule authors wrote it in, and an XPath to the element at fault. So you get BR-DE-15, not "invalid".

The exact artefacts, their versions and the URL each one was downloaded from are recorded in artefacts/SOURCES.md inside the Actor. The Schematron runs through SaxonJS and produces SVRL, the same output any other conformant validator produces. Nothing is reimplemented and no rule is approximated.

What you need

Files. That is all. There is no API key, no account anywhere, no proxy and no browser.

Run it with nothing filled in and you get a demo: four bundled sample invoices from the official test suites, one valid XRechnung, one with three deliberate rule breaks, one Peppol invoice and one Factur-X PDF. Nothing is charged for the demo.

How to run it

A list of files:

{
  "invoices": "https://example.com/invoice-de.xml\nhttps://example.com/facture.pdf\nhttps://example.com/peppol.xml",
  "failOnWarning": false,
  "maxInvoices": 100
}

One pasted invoice, checked against a profile you name rather than the one it declares:

{
  "inlineXml": "<?xml version=\"1.0\"?><Invoice xmlns=\"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2\">...</Invoice>",
  "profiles": ["en16931", "peppol-bis-3"]
}

The OUTPUT record in the key-value store holds the run summary: invoices processed, how many were valid, how many events were charged and how many documents each profile checked.

There is also a Standby endpoint that speaks MCP, so an agent can call validate_einvoices as a tool with URLs or pasted XML and get the same rows back directly.

Output fields

Field	What it holds
input	the URL you gave, or inlineXml
format	ubl-invoice, ubl-creditnote, cii, facturae, fatturapa, ksef or unknown
declared_profile	the profile the document claims: xrechnung, peppol-bis-3, nlcius, facturx-zugferd, en16931
declared_specification	the raw specification URN, exactly as written in the file
profiles_checked	the rule sets that actually ran
profiles_skipped	rule sets that have no official artefact for this syntax, named so silence never reads as a pass
valid	true when at least one rule set ran and nothing fatal failed
fatal_count, warning_count	findings by severity
failures	every finding: profile, rule_id, severity, message, location
invoice_number, issue_date, seller_name, buyer_name, total	read out of the document so the row is readable without opening the file
pdf_attachment	for a hybrid PDF, the name of the attachment the XML came from
error	why a file could not be read at all, or null
checked_at	when the run happened

Pricing

Pay per event: one invoice-validated charge per invoice actually read and validated. A URL that will not fetch, a file that is neither XML nor PDF, a PDF with nothing embedded in it, or XML that will not parse costs you nothing. Neither does the demo. The price is per invoice however many rule sets run over it, so checking a German invoice against both EN 16931 and XRechnung is one event, not two.

Limits

Covered and verified against the official test suites: EN 16931 core for UBL and CII (validation 1.3.16), XRechnung 3.0 for UBL and CII (KoSIT Schematron 2.6.0), Peppol BIS Billing 3.0 for UBL (3.0.21, the 2026 May release that became mandatory on 17 August 2026), NLCIUS / SI-UBL 2.0 (2.0.3.13, in effect from the same date), and Factur-X and ZUGFeRD hybrid PDFs by extracting the embedded CII. Facturae 3.2.2, FatturaPA 1.2.3 and KSeF FA(3) are checked against their official XSD schemas, which for those three formats is the rule set.

Not covered, and I would rather say so than fake it. The Factur-X and ZUGFeRD profile Schematron is published inside the FNFE-MPE and FeRD specification package rather than at a free stable URL, so a hybrid PDF is checked against the EN 16931 CII rules and not against the profile's own extra rules. Romania's RO_CIUS has no freely downloadable Schematron, so e-Factura is not covered at all. Peppol CII is not covered, because Peppol BIS Billing 3.0 is a UBL profile. Spain's Verifactu is a different regime that certifies invoicing software rather than invoice files, and nothing here says anything about it.

One more thing worth being straight about. This checks the standard's rules, and the national rules where the standard has been extended. It does not tell you a tax authority will accept the invoice. A tax office also checks registration, VAT numbers against its own register, timing and duplicates, and it can reject a file that passes every rule here. Treat a green row as "the format and the arithmetic are right", which is where most rejections actually come from, and not as clearance.

Files are capped at 20 MB each and a run at 1000 invoices. Invoice contents are never logged.

Pair it with a workflow

If you run n8n, my free templates on https://n8n.io/creators/fractional-hq take rows like these and turn them into a supplier chase, a rejection notice or a queue of files to fix, without another tool in the chain.

If you want to see how this was built and where I drew the line on what it covers, I wrote it up at https://fractionalhq.uk/use-cases/einvoice-validation

Built by Fractional HQ

I run Fractional HQ, a one-man studio for design and automation. I do not write code by hand: I architect, review and hold the standard while AI agents do the typing. That method runs my own estate: seven brands, a Postgres operations system, more than 100 scheduled jobs, published n8n templates, Zapier Silver certified.

Want this wired into your CRM and outreach, or built and handed over working? Get in touch: https://fractionalhq.uk/brief