Why invoice-after-payment is a revenue workflow, not a checkbox
A checkbox that says generate invoice after payment sounds simple, but real WooCommerce stores have mixed payment methods. Card orders are paid immediately, BACS orders may wait days, Net 30 buyers need documents before payment, and refunds need credit notes after the final invoice exists.
A sales-ready invoice plugin needs to decide which document exists at each state: no document, proforma, payment request, final invoice, credit note, write-off, or correction. That is why Lattice Invoices content focuses on workflow readiness instead of only PDF styling.
Invoice-after-payment readiness checklist
1. Define the accounting trigger before choosing a plugin
Some stores need a proforma before bank transfer, then a final VAT invoice only after payment. Others issue the final invoice at checkout, order processing, completion, subscription renewal, or manual approval. The invoice plugin must make this trigger explicit.
Buyer question: Can the plugin issue proformas and final invoices from different WooCommerce order events?
2. Keep invoice numbers sequential even when payment fails
If a failed card, unpaid BACS order, abandoned invoice, or cancelled subscription consumes a final invoice number too early, finance may end up with gaps, void documents, or manual corrections. After-payment issuance reduces that risk, but only when the workflow is deliberate.
Buyer question: What happens to invoice numbers when payment fails, is cancelled, or is later refunded?
3. Separate payment request PDFs from VAT invoice PDFs
A customer may need a payment request with bank details before money arrives. That document should not accidentally become the retained final VAT invoice unless the store policy says so.
Buyer question: Can the plugin label pre-payment documents as proforma or payment request and then issue the final invoice after payment?
4. Preserve refund and credit-note evidence
Issuing after payment does not remove the need for credit notes. A paid order can still be partially refunded, written off, adjusted, or corrected, and every change needs a retained PDF plus audit trail.
Buyer question: Does the plugin link refunds and credit notes back to the original paid invoice?
5. Make the customer and accountant views match
The My Account download, email attachment, resend action, invoice archive, and accountant export should all show the same invoice state: proforma, awaiting payment, paid final invoice, credited, written off, or corrected.
Buyer question: Can support, customers, and accountants see the same invoice status without manual order notes?
Three invoice timing scenarios to test before buying
Card order paid immediately
Trigger: Stripe, PayPal, Mollie, or Klarna confirms payment during checkout.
Workflow: Issue the final VAT invoice only after the successful payment event, attach it to the correct WooCommerce email, store the PDF for customer download, and export the paid invoice row for accounting.
BACS or Net terms order before payment
Trigger: A customer chooses bank transfer or pay-by-invoice terms and needs documents before money arrives.
Workflow: Send a proforma or payment request first, include bank details and due date, then issue the final invoice after payment is marked received according to store policy.
Paid invoice is refunded later
Trigger: Finance processes a full or partial refund after the final invoice already exists.
Workflow: Retain the original invoice, create a linked credit note with the refund amount and VAT correction, expose both PDFs to the customer when appropriate, and export both documents.
Weak timing checkbox vs invoice-ready workflow
| Weak workflow | Lattice Invoices direction |
|---|---|
| A final invoice PDF is generated as soon as the order is created, even if payment never succeeds. | Invoice timing is configurable: proforma before payment, final VAT invoice after confirmed payment, and clear handling for cancelled or failed orders. |
| Support manually changes PDF labels from invoice to proforma when a B2B buyer asks for bank-transfer paperwork. | Document type is state-driven, so payment requests, proformas, final invoices, and credit notes are generated from the order workflow. |
| The customer receives one PDF by email while the accountant export references a different invoice state. | Email attachments, My Account downloads, PDF archive, audit trail, and export rows share the same invoice state and document IDs. |
| Refunds are tracked in WooCommerce order notes, but no linked credit note PDF exists. | Refunds generate credit-note records that keep the original invoice intact and make VAT correction evidence exportable. |
FAQ
Should WooCommerce create invoices before or after payment?
For many EU VAT stores, the safest workflow is a proforma or payment request before payment and a final VAT invoice after payment. The right answer depends on local accounting policy, payment method, and whether the store sells B2B on Net terms.
What is the risk of generating invoices too early?
Generating final invoices before payment can create unused invoice numbers, cancelled invoice documents, confusing customer PDFs, and manual correction work when a card payment fails or a bank-transfer order is never paid.
Can an after-payment workflow still support bank transfer orders?
Yes, but the pre-payment document should usually be a proforma or payment request. The final invoice can then be issued when payment is received or when the store policy says revenue should be recognized.
Where does Lattice fit in after-payment invoice workflows?
Lattice Invoices early access is positioned around configurable WooCommerce invoice timing: VAT/BTW checkout fields, proformas, final paid invoice PDFs, credit notes, customer downloads, reminders, and accounting export readiness.