What a WooCommerce VAT invoice plugin actually needs to get right
A PDF with a logo on it is the easy 20%. The numbering series, the B2B fields and reverse charge are the part that keeps an accountant happy.
“Generate an invoice PDF” sounds like a template problem. The template is the easy part. Here is what actually determines whether a store’s invoices survive an audit.
A numbering series that cannot skip or collide
An invoice number has to be sequential with no gaps: a gap is the first thing a tax inspector looks for. That means the numbering has to be generated at the moment of invoicing, not reused if an order is cancelled, not assigned twice if two orders complete in the same second. Continuous or per-year series (WX-2026-000123) both need to be atomic against concurrent orders, which is a database-locking problem, not a formatting one.
Real seller and buyer requisites, not just a name and address
A consumer invoice and a business invoice are not the same document. A business buyer needs their company registration number and VAT number printed on the invoice, captured at checkout, not typed in afterwards by support. A checkout that only has a “company name” text field is not enough: the invoice plugin and the checkout need to agree on where that data lives.
EU reverse charge, handled automatically or not at all
Sell to a VAT-registered business in another EU country and the invoice needs 0% VAT with reverse-charge wording, not your domestic rate. This is not a stylistic choice: under Article 196 of the EU VAT Directive (2006/112/EC), liability for the VAT shifts to the buyer on qualifying cross-border B2B services, and Article 226(11a) requires the invoice to actually state “reverse charge.” Getting this wrong either overcharges a legitimate B2B customer or under-charges tax that was actually due, and it has to key off a validated VAT number, not a checkbox the buyer ticks themselves.
Where the PDF actually gets rendered
Sending order and customer data to a third-party PDF-rendering API is one more place invoice data can leak, and one more dependency that can go down at the exact moment an order completes. Rendering the PDF on your own server, with a bundled library, means an invoice fires whether or not any external service is reachable.
Invoices · Automatic VAT invoice PDFs, attached to the order e-mail. See how it works →
It has to survive how the order data is actually stored
WooCommerce stores can run on legacy post-based orders or High-Performance Order Storage (HPOS), and increasingly the latter. An invoice plugin reading order meta the old way can silently break the moment a store switches. Testing against both, not just whichever one the plugin happened to be written against, is not optional.
What this adds up to
This is the exact list Invoices was built against: its own atomic numbering series, real B2B requisites captured at checkout, automatic reverse-charge detection, PDF rendering with a bundled Dompdf so nothing leaves your server, and it runs the same under HPOS or the classic order tables.
Frequently asked questions
Do I have to validate the buyer’s VAT number before applying reverse charge?
Yes. Reverse charge only applies to a VAT-registered business buyer. A number that fails validation means the sale gets treated as a normal consumer transaction at your domestic VAT rate, not zero-rated.
Does this work if my store already runs on HPOS?
It should, but only if the plugin was built and tested against HPOS specifically. Plugins written only for the legacy post-based order tables can silently stop reading order meta correctly once a store migrates.
Does an invoice plugin replace an accountant?
No. It should get the numbering, requisites and reverse-charge logic right by default so an accountant is not fixing invoices after the fact, but it does not replace filing or advice from one.
