WooCommerce E-Invoicing Plugin Comparison: XRechnung, ZUGFeRD, Factur-X for WooCommerce
Four plugin categories solve the same problem differently. We show which plugin fits which workflow — without marketing fluff.
Competitor details last checked: August 8, 2026
invoice-api.xhub in 60 seconds
Why developers pick the REST API over classic accounting software.
Feature comparison
| Feature | WC PDF Invoices | WC Germanized | sevDesk plugin | Lexware plugin | invoice-api.xhub |
|---|---|---|---|---|---|
| Generate XRechnung XML (DE) | No — PDF only | With Pro plugin (premium) | Indirect — exports to sevDesk, generated there | Indirect — exports to lexoffice, generated there | Yes — BIS 3.0 / EN 16931, B2G-ready with Leitweg-ID |
| Generate ZUGFeRD PDF/A-3 (DE/AT) | No | With Pro plugin (premium) | Indirect | Indirect | Yes — version 2.3 / 2.4, hybrid |
| EU country-specific formats (Factur-X, FatturaPA, etc.) | No | No — DACH-focused | No | No | Q3 2026 — automatically available in plugin |
| Who carries the risk when the recipient rejects the invoice | You — plugin vendors do not warrant conformance in individual cases | You | You | You | You — or xhub.io, if the integration was delivered as a project |
| Master-data mapping (routing ID, recipient identifiers, edge cases) | Not provided for | Partially — maintained via custom fields | Maintained in the bookkeeping tool | Maintained in the bookkeeping tool | Plugin covers standard cases — grown data models need a project |
| Plugin price | Free + Pro from €69/year for PDF customisation | Free + Pro from €79/year for e-invoicing | Free (sevDesk subscription required) | Free (lexoffice subscription required) | Free (GPLv2+) |
| External service required | No — fully local | No — fully local | Yes — sevDesk ($/month) | Yes — lexoffice ($/month) | Yes — invoice-api.xhub.io ($/month volume-based) |
| §14 UStG-compliant numbering (gap-free, race-safe) | Manual configuration | Yes | Yes (via sevDesk) | Yes (via lexoffice) | Yes — atomic custom DB table |
| HPOS-compatible (WooCommerce 8+) | Yes | Yes | Partial | Partial | Yes |
| Async (Action Scheduler) | Synchronous | Synchronous | Webhook-based | Webhook-based | Yes — never blocks checkout |
| Refund → automatic credit-note | Manual | Yes | Yes | Yes | Yes |
| Custom invoice templates | Yes — HTML/CSS template | Yes — premium | In sevDesk | In lexoffice | Yes — template designer in console |
| GDPR hooks (data export / erasure) | Partial | Yes | Indirect | Indirect | Yes — wp_privacy_personal_data_* |
| Full bookkeeping (DATEV export, bank reconciliation) | No | Limited | Yes | Yes | No — focused on e-invoice generation |
When to choose which category
- You only need PDF invoices, no XRechnung obligation → WooCommerce PDF Invoices & Packing Slips is enough (free)
- You sell only in DE and need broad Germanized features (VAT display, delivery times, etc.) → WooCommerce Germanized Pro
- You need full bookkeeping with DATEV/bank reconciliation → sevDesk plugin or Lexoffice plugin (e-invoicing as a side-effect)
- You need specialised e-invoicing with all EU formats and no bookkeeping overhead → Invoice-api.xhub for WooCommerce
When to choose invoice-api.xhub
- You need to comply with the 2027/28 XRechnung/ZUGFeRD send mandate and want a specialised API solution rather than an all-in-one ERP
- You sell cross-border in the EU and need Factur-X (FR), FatturaPA (IT), Facturae (ES) as they roll out — Q3 2026
- You already have a bookkeeping system and don't need a second one — just the correct e-invoice files
- Action-Scheduler-async is a must-have because your checkout has to stay fast
- You want free OSS plugin code, no license-key drama
Which WooCommerce e-invoicing plugin fits your shop?
The plugin landscape for WooCommerce invoice generation shifted after the 2025 EU e-invoicing mandate. Four categories dominate:
- Classic PDF generators (e.g. WooCommerce PDF Invoices & Packing Slips) — generate standard PDFs, don't satisfy the XRechnung mandate.
- All-in-one DE compliance suites (e.g. WooCommerce Germanized) — broad frontend compliance, e-invoicing as a premium add-on.
- Bookkeeping bridge plugins (e.g. sevDesk, Lexoffice) — export orders to the external bookkeeping system; the system then generates the e-invoice.
- Specialised e-invoicing API plugins (us) — focused on standards-compliant XRechnung/ZUGFeRD generation; deliberately without bookkeeping overhead.
Which category fits — the table above shows the hard data. The short heuristic:
- You only need PDF and no XRechnung? → Category 1 is enough.
- You sell only in DE and want frontend + backend from one source? → Category 2.
- You already use sevDesk/Lexoffice and are happy with their output? → Category 3.
- You sell EU-wide, need structured formats, and don't want a second bookkeeping tool? → Category 4 (us).
Multiple categories in parallel is legitimate — e.g. Germanized for frontend compliance + us for e-invoice output, or Lexoffice for bookkeeping + us for the invoice files going to your customers.
When the plugin alone isn't enough
The plugin question is the smaller half. A plugin can only structure what WooCommerce holds — and that is exactly where most migrations fail:
- The routing ID (Leitweg-ID) of your public-sector customers is nowhere in the customer record.
- Credit notes need a reference to the original invoice that your shop never stored.
- Tax categories work in the standard case but not for reverse charge, small-business exemption, or intra-community supply.
- Meta fields and plugin combinations grown over years don't map onto EN 16931.
- The recipient accepts the invoice technically but rejects it on substance — and nobody notices until the payment fails to arrive.
This is neither a plugin problem nor an API problem. It's data work, and it happens once.
Two routes:
| Do it yourself | Have it delivered as a project | |
|---|---|---|
| Plugin + API | free (GPLv2+) + service plan | included in the project |
| Master-data mapping | your effort | us |
| Testing with real recipients | your effort | us |
| Responsibility for conformance | yours | contractually xhub.io |
| Timeframe | open-ended | 4–6 weeks to go-live |
If you want to know which case your shop falls into: send us one of your invoices. We check it with the same procedure the recipients use (KoSIT validation) and tell you within a day what passes and what's missing. Free and without obligation.
Frequently asked questions
Is WooCommerce PDF Invoices & Packing Slips enough for the 2025 XRechnung mandate?
No. That plugin generates PDFs — the XRechnung mandate for B2B invoices from 2025 onwards requires structured XML (BIS 3.0 / EN 16931). Pure PDFs do not satisfy the mandate. You need either a specialised plugin (like ours) or a ZUGFeRD hybrid solution.
What is the difference between this plugin and WooCommerce Germanized?
Germanized is an all-in-one DE compliance plugin: VAT display, T&C checkbox, delivery times, optional e-invoicing extension in the Pro tier. We do ONLY e-invoicing — but specialised (all 3 live formats, all 28 countries planned, in-house template designer, atomic numbering). If you already have Germanized, you can keep it and run us in parallel — Germanized handles frontend compliance, we handle backend e-invoice output.
Can I run sevDesk or Lexoffice plugin in parallel with yours?
Yes. The bookkeeping plugins export WooCommerce orders to the bookkeeping tool. Our plugin separately generates the structured e-invoice. Running both in parallel is clean because responsibilities are split: bookkeeping in sevDesk/Lexoffice, e-invoice file generation via us. Some shops do exactly this.
Am I locked in to your service if I switch later?
No. The plugin is GPLv2+ and open source. We store the generated XML/PDF files on the order — you keep them even without an active subscription. If you switch, your existing invoice files stay in WooCommerce; only new invoices stop being generated. Lock-in free.
The plugin runs, but the invoice still gets rejected. Why?
Almost always the master data, not the format. Typical causes: the recipient's routing ID (Leitweg-ID) is missing or sits in the wrong field, the tax category doesn't match the transaction, credit notes lack the reference to the original invoice, or mandatory fields were never maintained in the shop. A plugin can only structure what WooCommerce holds. In grown shops — custom meta fields, historical edge cases, several markets — that's a mapping problem, not a plugin problem. Send us a sample invoice and we'll tell you what's actually wrong.
Who is liable if the e-invoice isn't conformant?
Legally, always the invoice issuer — that holds for every plugin and every API on the market, ours included. No plugin vendor can take responsibility for your master data. What we can offer: if xhub.io delivers the integration as a project, we take contractual responsibility for invoices from your shop being accepted by the recipient, tested against real documents before go-live. If you build it yourself with the plugin and the API, that responsibility stays with you.
What does your service cost?
Service plans start at modest monthly tiers based on generated volume. Current pricing: console.invoice-api.xhub.io. The plugin itself is and always remains free on every channel.