EU e-invoicing for WooCommerce
Producing e-invoice XML is the easy part. The hard part is that WooCommerce order data is rarely clean enough for it — and you find out weeks later, when an invoice comes back rejected.
3 of your last 6 orders would be rejected.
Deklera scans your orders and reports each problem in plain language: what happened, why it matters, the exact rule reference, and where to fix it. Not “invalid order”.
This is a cross-border EU business sale with no VAT, but the customer VAT number is missing.
When VAT is not charged on an intra-community supply, the buyer VAT identifier is mandatory. Without it the exemption cannot be justified and the invoice is rejected.
How to fix: Open the order and add the VAT number to the billing details, then start collecting it at checkout.
Rule: BT-48 / BR-AE-09
The invoice lines add up to €120.00 but the order total is €112.50, a difference of €7.50.
Validators reject an invoice whose totals do not reconcile, even by one cent. This usually comes from an order-level discount, a coupon or a refund that is not represented on any line.
Rule: BT-112 / BR-CO-15
This order was treated as an intra-community supply of goods.
Goods use category K and services use category AE. Deklera decides this from whether the items are shippable or virtual, which is a reasonable guess but not always right.
Rule: BT-151
Findings are grouped by root cause, so a store-wide problem is reported once — not repeated on every order. And where Deklera has to make a judgement call, it says so instead of guessing silently.
EN 16931 CII is the European baseline, not a national profile. Several member states mandate their own format and their own platform — Italy's FatturaPA through the SdI is the clearest example — and Deklera does not produce those. The three countries above are the ones measured against their official validators; if yours is not among them, confirm that EN 16931 CII is accepted before you rely on it.
The tax category — standard, reverse charge, intra-community supply, export — is derived from where the seller and the buyer actually are, not guessed from the rate alone.
The invoice is written in the buyer’s language, not yours. A German customer receives Rechnung, Nettobetrag, USt-IdNr.; a French one Facture and Total HT. German, French and Polish are built in, and the legal wording — reverse charge, intra-community supply — uses the phrasing each country expects on the face of the invoice.
Documents are archived and never overwritten. Regenerating creates a new version and the old one stays, because quietly replacing an issued invoice is not something an audit will forgive. Every file is stored with a hash, so you can prove it has not changed.
Anyone can claim their output is valid. These are the results of running it through the rule sets the authorities themselves publish.
Germany — XRechnung 3.0.2
The output was run through KoSIT’s official validator configuration, the same Schematron a German authority applies. The first run failed six rules — every one of them a field the EU standard leaves optional and Germany makes mandatory. All six are now satisfied.
0 findings
France — Factur-X
In France the file itself is checked, not only the data: the XML lives inside a PDF/A-3 document. veraPDF, the reference implementation for PDF/A, validates the finished invoice, and the embedded XML clears the official EN 16931 rule set for CII syntax.
PDF/A-3b: PASS · EN 16931: 0 errors
Poland — KSeF
A Polish invoice does not legally exist until KSeF has accepted it, so the only meaningful test is a real submission. An invoice was generated, queued, sent to the national test environment and registered — through the same code path a customer uses.
KSeF number assigned
You can run the same check yourself. Paste any e-invoice — from this plugin or from another — into the public checker and see what the official rule set says about it. It is free and needs no sign-up.
These are measurements of real output, repeated on every release and recorded in the repository. They say the document is formally acceptable. They cannot say your figures are right — that part is yours.
It does not transmit invoices, except to KSeF. Deklera produces the document and checks it; delivery goes through your own accredited provider — a PDP in France, a Peppol access point elsewhere. Poland is the exception, because there an invoice does not legally exist until KSeF has accepted it, so Polish stores get submission built in. If you are looking for a plugin that sends invoices to a network everywhere else, this is not it, and you should not buy it expecting that.
It does not guarantee legal compliance. No software can. Whether a specific invoice is accepted depends on your registration, your provider and rules that change over time.
What it can honestly promise is narrower and more useful: it tells you when your data will fail the standard, and it checks the finished document against the official rule set before you issue it.
Most WooCommerce invoice plugins already produce the file, and several produce it for nothing. So does Deklera: the entire free version is the format work — pre-flight report, Factur-X, XRechnung, credit notes, versioned archive — and nothing in it is switched off.
That is the entry ticket, not the product. Producing a file is easy. Knowing whether the data behind it will survive the rules is not, and it is the part that costs you weeks when it goes wrong.
So Deklera does the part nobody else checks. The report tells you which orders would be rejected before you issue them. Pro runs the finished document through the official rule set — the one that compiles to XSLT 2.0, which PHP cannot execute, which is why it runs as a service rather than on your site.
If you already pay to send invoices over Peppol, this does not replace that. It is the check you run first, so that what you send comes back accepted.
Everything the plugin itself can do works without a licence — scanning, generating Factur-X and XRechnung, credit notes, archiving, automatic generation when an order completes. Nothing in the code is switched off.
| Plan | Price | What it adds |
|---|---|---|
| Free | €0 | Full e-invoicing: pre-flight report, document generation, credit notes, versioned archive with integrity checks. |
| Pro | €49/yr | Validation against the official rule set before a document is issued — EN 16931, plus Germany’s XRechnung rules for German stores. |
| Agency | €149/yr | Everything in Pro, across all the stores you manage. |
Freemius gives 7 days to change your mind: if something makes the plugin unusable and it cannot be fixed, you get your money back.
Pro buys one thing, because it is the one thing the plugin cannot do on its own. The official rule set compiles to XSLT 2.0 and PHP’s XSL extension only supports XSLT 1.0, so the check runs on a hosted service rather than on your site. It is off by default.
The free version answers the only question that matters right now: is your order data ready? Install it, open the report, and find out in a minute.
Open the live demo Download the free version
The demo runs a real WordPress and WooCommerce inside your browser, seeded with orders that are not ready to be invoiced. Nothing is installed and nothing leaves your machine.
The free version is awaiting review for the WordPress.org plugin directory; until it is listed there, install the zip above by hand. Pro licences are available now through Freemius, who handle payment and EU VAT as merchant of record.
The user guide explains what the findings mean, where documents are stored, how credit notes and the Polish KSeF flow work, and what Pro adds. Source and issues are on GitHub.