WooCommerce PDF Invoices 5.16.4
OpenOpen
Results
39.7% of Factur-X invoices from a popular WooCommerce invoice plugin fail schema validation
We fed the same 600 synthetic shop orders through WooCommerce, Odoo 19 and twelve libraries, then checked all 16,200 invoices against KoSIT/XRechnung, CEN EN 16931, Peppol BIS 3.0.20 and the amount actually charged. The rule sets often disagree.
✓ passes / accepted % failure rate n/a scenario not applicable
| Generator / config | Segment | KoSIT accept % | XSD invalid % | CEN calc fail % | Peppol R120 fail % | Due ≠ order total % |
|---|---|---|---|---|---|---|
| WooCommerce PDF Invoices 5.16.4 — Factur-X | B2B | 63.7 | 36.3 | 0 | 0 | 0 |
| WooCommerce PDF Invoices 5.16.4 — Factur-X | B2C | 57.0 | 43.0 | 0 | 0 | 0 |
| WooCommerce PDF Invoices 5.16.4 — Peppol BIS 3 | both | n/a | 0 | 0 | 0 | 0 |
| Odoo 19 — Factur-X, round_globally | B2B | n/a | 0 | 32.7 | 80.7 | 2.0 |
| Odoo 19 — Factur-X, round_globally | B2C | n/a | 0 | 42.7 | 0 | 4.7 |
| Odoo 19 — Factur-X, round_per_line | B2B | n/a | 0 | 0 | 80.7 | 0 |
| Odoo 19 — Peppol BIS 3 / XRechnung | both | n/a / 100 | 0 | 0 | 0 | 0 |
| Mustang 2.26.0 — library-computed totals | B2B | 100 | 0 | 0 | 0 | 90.7 |
| Mustang 2.26.0 — library-computed totals | B2C | 100 | 0 | 0 | 0 | 66.7 |
| horstoeko/zugferd 1.0.133, drafthorse 2025.2.0 (reference totals) | both | 100 | 0 | 0 | 0 | 0 |
| josemmo/einvoicing 0.3.1 — library-computed totals, 2 dp rounding matrix | B2B | 100 | 0 | 0 | 0 | 90.7 |
| josemmo/einvoicing 0.3.1 — library-computed totals, 2 dp rounding matrix | B2C | 100 | 0 | 0 | 0 | 66.7 |
| speedata/einvoice 0.0.23 — library-computed totals (CII + UBL) | B2B | 100 | 0 | 0 | 0 | 90.7 |
| speedata/einvoice 0.0.23 — library-computed totals (CII + UBL) | B2C | 100 | 0 | 0 | 0 | 66.7 |
| ZUGFeRD-csharp 18.0.1 — XRechnung CII, no delivery date (PR #981) | both | 0 | 100 | 0 | 0 | 0 |
| ZUGFeRD-csharp 18.0.1 — XRechnung UBL / CII with delivery date (reference totals) | both | 100 | 0 | 0 | 0 | 0 |
| num-num/ubl-invoice 2.4.1 — Peppol BIS 3 (Belgium), reference totals | both | n/a | 0 | 0 | 0 | 0 |
| akretion factur-x 7.7 — Factur-X PDF (France), XML read back, reference totals | both | 100 | 0 | 0 | 0 | 0 |
| easybill/zugferd-php 6.0.0 — XRechnung CII, reference totals | both | 100 | 0 | 0 | 0 | 0 |
| invopop/gobl 0.510.0 + gobl.cii 0.80.0 — EN 16931 CII, totals computed by GOBL | b2b | 100 | 0 | 0 | 0 | 6.0 |
| invopop/gobl 0.510.0 + gobl.cii 0.80.0 — EN 16931 CII, totals computed by GOBL | b2c | 100 | 0 | 0 | 0 | 1.3 |
| invopop/gobl 0.510.0 + gobl.ubl 0.97.0 — Peppol BIS 3 UBL, totals computed by GOBL | both | n/a | 0 | 0 | 0 | 1.3–6.0 |
| PyCheval 0.3.3 — Factur-X EN 16931 CII, reference totals | both | 100 | 0 | 0 | 0 | 0 |
| python-en16931 0.2 — Peppol BIS 3 UBL, library-computed totals, coupon as document discount | B2B | n/a | 0 | 0 | 0 | 92.0 |
| python-en16931 0.2 — Peppol BIS 3 UBL, library-computed totals, coupon as document discount | B2C | n/a | 0 | 0 | 0 | 72.7 |
300 B2B + 300 B2C synthetic carts per configuration (DE, 19%/7% VAT, coupons, shipping). "n/a" = no XRechnung scenario applies (not a rejection). Peppol rules only bind Peppol BIS documents; findings show inconsistency between rule sets, not legal invalidity. Full method and limitations in the repository.
Methodology
How we test
Same input for everyone
600 synthetic shop orders per configuration (300 B2B + 300 B2C; DE, 19%/7% VAT, coupons, shipping), fed identically into every generator.
Official validators
KoSIT/XRechnung configuration, CEN EN 16931 schematron (UBL and CII), XSD schema and Peppol BIS 3.0.20 rules.
Money check
Beyond the rules: we compare the amount due in the invoice with the amount actually charged for the order.
Upstream reports
Reported to maintainers
Bugs found while building the matrix, reported with a repro and a suggested fix.
josemmo/einvoicing 0.3.1
OpenOpen
speedata/einvoice (≤ v0.0.20), UBL writer
FixedFixed (PR #186), released in v0.0.23 — re-tested: 9/9 UBL repro invoices KoSIT-acceptable; related #187–#190 also fixed
Mustang 2.26.0
FixedFixed on master (PR #1318), unreleased
horstoeko/zugferd 1.0.132
FixedReleased in v1.0.133 (re-tested: E/AE/K/G/O exemption reasons KoSIT-acceptable)
ZUGFeRD-csharp
Known issueKnown issue, workaround: set only one of PersonName/DepartmentName (CII-SR-465/466)
Monthly report
State of EU e-invoice interoperability — October 2026
13,200 invoices, 10 generators, French Factur-X scenarios, upstream status.
Upstream confirmations
What maintainers said
Exactly what is stated in the public threads (checked 25 Oct 2026).
Odoo 18.0 — CII unit price precision
PR openWe ran the fix through our 600-order harness; the Odoo developer thanked us for running it and for the detailed numbers.
Odoo 18.0 — CII totals from line net amounts
PR openSame harness run; the Odoo developer thanked us for the thorough run and confirmed the observed behaviour is intended and mirrors the UBL export.
Odoo 18.0 — cash rounding in CII grand total
ClosedClosed on 24 Oct 2026.
WooCommerce PDF Invoices — RoundingAmount order
OpenIndependently reproduced in the thread with KoSIT validator 1.6.3 (XRechnung 3.0.2 configuration).
ZUGFeRD-csharp — PersonName + DepartmentName
Known issueThe maintainer confirmed it is a known issue; workaround: set only one of the two fields.
Get checked
Get your invoices checked
Fixed prices. We confirm scope in writing before you pay — PayPal or SEPA bank transfer (invoice with bank details sent by email).
Free check
0 €
One invoice
Findings summary within 2 business days. No account, no payment.
One-time check
290 €
Up to 10 invoices
Full report with rule IDs and fix guidance per invoice, within 3 business days.
Library / vendor audit
790 €
Your generator's output
Systematic test cases across VAT categories S, E, AE, K, G, O, allowances/charges and rounding. Includes one re-test after your fix.
Please do not send invoices containing real personal data. Free self-service: the GitHub Action runs the same checks in your CI.