E-Invoice Validator: XRechnung, Peppol and EN16931 avatar

E-Invoice Validator: XRechnung, Peppol and EN16931

Pricing

from $3.00 / 1,000 invoices

Go to Apify Store
E-Invoice Validator: XRechnung, Peppol and EN16931

E-Invoice Validator: XRechnung, Peppol and EN16931

I check invoice XML and hybrid PDFs before they reach your finance workflow. Get failed rule IDs, severity and file locations. EN16931, XRechnung and Peppol checks; other formats have the coverage shown below.

Pricing

from $3.00 / 1,000 invoices

Rating

0.0

(0)

Developer

Jessy Mariau

Jessy Mariau

Maintained by Community

Actor stats

0

Bookmarked

1

Total users

0

Monthly active users

3 days ago

Last modified

Share

Find the rule that rejected an invoice before it reaches your finance workflow. Supply XML or a hybrid PDF and get a row with each failed rule ID, severity, message and location in the file.

Try the bundled sample invoices: leave the input empty and run. The demo makes no Actor event charge. For your own documents, 100 invoices cost $0.30 in Actor events, regardless of how many supported rule sets run. Files that cannot be read or parsed are not charged.

Coverage before you start

Document or profileChecks that run
EN16931 UBL and CIIOfficial core Schematron
XRechnung 3.0Core plus KoSIT rules for UBL/CII
Peppol BIS Billing 3.0Core plus Peppol rules for UBL
NLCIUS / SI-UBL 2.0Supported Dutch rules
Factur-X / ZUGFeRD hybrid PDFEmbedded CII extraction and EN16931 core; no additional profile Schematron
Facturae 3.2.2, FatturaPA 1.2.3, KSeF FA(3)Official XSD schema checks only

A passing row describes the checks performed. It does not guarantee acceptance by a tax authority. See the pinned versions and exclusions under Limits.

Results from the bundled demo

These results came from the bundled sample files on 8 September 2026. They are test invoices, not customer documents. Warnings include information-level findings.

SampleValid under checks runFatal findingsWarnings / information
XRechnung validYes01
XRechnung deliberately invalidNo51
Peppol UBL validYes00
Factur-X PDF, EN16931 core onlyYes00

In the invalid sample, BR-02 identifies the missing invoice number and BR-CO-15 identifies inconsistent VAT totals. The failures array includes the official messages and XPath locations, so a supplier can work on the specific fields.

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

FieldWhat it holds
inputthe URL you gave, or inlineXml
formatubl-invoice, ubl-creditnote, cii, facturae, fatturapa, ksef or unknown
declared_profilethe profile the document claims: xrechnung, peppol-bis-3, nlcius, facturx-zugferd, en16931
declared_specificationthe raw specification URN, exactly as written in the file
profiles_checkedthe rule sets that actually ran
profiles_skippedrule sets that have no official artefact for this syntax, named so silence never reads as a pass
validtrue when at least one rule set ran and nothing fatal failed
fatal_count, warning_countfindings by severity
failuresevery finding: profile, rule_id, severity, message, location
invoice_number, issue_date, seller_name, buyer_name, totalread out of the document so the row is readable without opening the file
pdf_attachmentfor a hybrid PDF, the name of the attachment the XML came from
errorwhy a file could not be read at all, or null
checked_atwhen 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 cover XML structure rather than every national business or submission rule.

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

Use it from an AI agent

I also expose the validator to AI agents over MCP. Connect to https://fractionalhqforyou--eu-einvoice-validator.apify.actor/mcp and the agent will find one tool, validate_einvoices, that accepts invoice URLs or pasted XML and returns the same rows a console run writes. The same per-event price applies. Where your client only supports the Apify MCP server, load apify/actors-mcp-server with fractionalhqforyou/eu-einvoice-validator as the Actor.

E-invoicing is one of a few EU compliance checks a finance or ops team has to pass, and these Actors handle the neighbours.

Built by Fractional HQ

Independent design and automation by Jessy Mariau. For setup or a custom integration, send a brief.