About this plugin
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 and you have to work out which of two hundred
business rules you broke.
Deklera starts at that problem, not at the XML.
Install it, open the report, and it tells you in plain language which of your
recent orders would be rejected and why. Then it produces the document your
country requires — XRechnung in Germany, Factur-X in France,
KSeF FA(3) in Poland — and, on the Pro plan, checks it against the
official EN 16931 rule set before it is issued.
Want to see what the official rule set says about an invoice before you install
anything? Paste one here, no sign-up, nothing stored:
io/deklera/check/
The pre-flight check
This is what the plugin is for. It scans your orders and reports, for each
problem: what happened, why it matters, the exact rule reference, and where to
fix it. No jargon, no “invalid order”.
Real examples from the report:
- “This is a cross-border EU business sale with no VAT, but the customer VAT
” — BT-48 / BR-AE-09. Without it the exemption cannot be
justified and the invoice is rejected.
- “The invoice lines add up to €120.00 but the order total is €112.50, a
” — BT-112 / BR-CO-15. Validators reject totals that
do not reconcile, even by one cent.
Findings are grouped by root cause, so a store-wide problem is reported once —
not repeated on every order.
Other things it catches:
- Sales to EU consumers where no VAT was charged at all
- Missing store VAT number, incomplete store address
- VAT categories that contradict the rate applied
- Orders with no customer name or no billing country
When Deklera has to make a judgement call — is this a service or goods? — it
says so and marks the order for review instead of guessing silently. You can
override it with a filter.
Generating documents
Deklera maps each order to the EN 16931 semantic model and produces the format
your country requires:
- France — Factur-X: a PDF/A-3 file with the XML embedded inside it. The
x publishes
under its own name, so a German recipient that accepts ZUGFeRD accepts these
files
- Germany — XRechnung 3.0, the pure-XML E-Rechnung the public sector and
a growing number of B2B recipients require
- Poland — KSeF FA(3), the faktura ustrukturyzowana, submitted to the
national platform
- Other countries — EN 16931 CII, the European baseline. Read the FAQ below before relying on it.
The tax category (standard, reverse charge, intra-community supply, export) is
derived from where the seller and buyer are, not guessed from the rate alone.
Where a decision is uncertain, Deklera says so instead of silently guessing.
Documents are archived and never overwritten. Regenerating creates a new
version; the old one stays, because quietly replacing an issued invoice is not
something an audit will forgive.
What this plugin does not do
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 unsent file is not an invoice at all. If you are looking for a
plugin that sends invoices to a network, this is not it, and you should not buy
it expecting that.
It also 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 Deklera 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.
Who this is for
Shops that already know they need e-invoicing and want to find out, now,
whether their order data is ready — rather than discovering it one rejection
at a time.
France requires e-invoicing from September 2026, small businesses from
September 2027. Poland’s KSeF already covers most VAT-registered businesses.
Germany accepts XRechnung and ZUGFeRD today, and under the
E-Rechnungspflicht every business there has had to be able to receive an
e-invoice since January 2025.
External services
Official validation service (Pro only, optional)
The Pro version can validate each document against the official EN 16931
Schematron rule set. This validation cannot run inside WordPress: the rule set
0.
When enabled, the invoice XML is sent over HTTPS to a validation service
operated by the plugin author. The XML contains your invoice data, including
seller and buyer names, addresses, VAT numbers and line items. It is processed
in memory to produce the validation report and is not stored.
This service is off by default and only runs on the Pro plan after you enter
an endpoint and licence key.
- Service: Deklera validation service
- Terms: https://github.com/ekremtekerek/deklera/blob/main/docs/TERMS.md
- Privacy: https://github.com/ekremtekerek/deklera/blob/main/docs/PRIVACY.md
KSeF (Poland only, required for Polish stores)
If your store is based in Poland, each generated FA(3) invoice is submitted to
the Polish Ministry of Finance’s National e-Invoice System (KSeF). This is not
optional for Polish stores: an FA(3) file has no legal standing until KSeF
accepts it and assigns a number.
The invoice is encrypted on your site before it leaves it, and sent over HTTPS.
It contains your invoice data: seller and buyer names, addresses, tax
identifiers and line items. You choose the environment; the test environment
has no legal effect.
- Service: KSeF (Krajowy System e-Faktur), Ministerstwo Finansów
- Test: https://api-test.ksef.mf.gov.pl
- Production: https://api.ksef.mf.gov.pl
- Terms: https://ksef.mf.gov.pl
Stores outside Poland never contact KSeF.
The free version performs no other external requests, apart from the language
pack downloads that WordPress itself makes.