Why QR invoice payments are an invoice-workflow problem
A static QR code in a PDF template is not enough. The QR payment data has to match the current invoice amount, payment reference, bank account, currency, due date, payment status, and customer-facing document. Otherwise QR codes create a faster way to make the wrong payment.
A sales-ready WooCommerce invoice plugin should treat QR payments as part of the invoice record: generated when the invoice is unpaid, reused consistently in reminders, hidden or updated after payment, and exported with VAT/accounting evidence. That is the buying problem Lattice Invoices is being positioned to solve.
QR-code invoice payment readiness checklist
1. Put bank details and payment references in one source of truth
A QR payment code is only helpful when the invoice PDF, email, My Account download, reminder email, and export all use the same IBAN, beneficiary name, amount, currency, invoice number, and payment reference.
Buyer question: Can the invoice plugin generate payment data from invoice metadata instead of manual text fields?
2. Decide when the QR code appears
Unpaid BACS, proforma, Net terms, and pay-by-invoice orders usually need QR payment instructions. Paid card orders, refunded orders, zero-value orders, and fully credited invoices usually should not show a fresh payment prompt.
Buyer question: Can QR codes be shown only for unpaid invoice states and hidden after payment or crediting?
3. Keep VAT invoice numbering separate from payment convenience
QR payment codes should not force final invoice numbers too early. A B2B order may need a proforma or payment request first, then a final VAT invoice when the configured accounting trigger is reached.
Buyer question: Can the workflow support proforma QR payment requests without breaking final invoice numbering?
4. Handle partial payments, overpayments, and refunds
If a customer pays the wrong amount or only part of the amount, the invoice workflow still needs retained PDFs, payment evidence, correction notes, credit notes, reminder state, and exportable reconciliation rows.
Buyer question: Can finance trace QR-code payments, partial payments, refunds, and credit notes from the order?
5. Export QR-payment evidence for accounting
The accountant should receive the invoice number, order ID, due date, bank transfer reference, QR payment state, paid/unpaid amount, VAT totals, credit-note links, and retained PDF URL without rebuilding state from order notes.
Buyer question: Does export include payment reference and invoice status, not only order totals?
Three QR invoice scenarios to test before buying
BACS order with an unpaid invoice PDF
Trigger: A customer selects bank transfer or pay-by-invoice at checkout.
Workflow: Generate a proforma or final invoice according to policy, add IBAN and structured payment reference, render a QR payment code on the PDF and email, and keep the invoice downloadable from My Account.
Net 30 customer receives a reminder
Trigger: The due date passes and the order remains unpaid.
Workflow: Send a reminder email with the same invoice number, amount due, payment reference, QR payment link/code, and audit trail entry so finance can prove follow-up later.
Customer pays partially or needs a credit note
Trigger: The bank payment does not match the invoice total, or a line item is disputed after payment.
Workflow: Retain the original invoice, log payment evidence, issue a linked credit note or correction document when value changes, and export the reconciled state for accounting.
Manual QR workaround vs invoice-ready payment workflow
| Weak workflow | Lattice Invoices direction |
|---|---|
| QR code image is pasted into a PDF template and reused across invoices, with no invoice-specific amount or reference. | Payment QR data is generated per invoice from the invoice number, amount due, currency, bank details, customer, and payment reference. |
| Paid card orders and refunded orders still show bank-transfer QR payment instructions. | QR payment prompts appear only for unpaid/proforma/BACS/Net terms states and disappear or change after payment, refund, write-off, or credit note. |
| Payment references live in order notes, while the accountant export only contains WooCommerce order totals. | Invoice export includes invoice number, payment reference, paid/unpaid state, due date, VAT totals, credit notes, and PDF archive reference. |
| Support manually resends PDFs and asks customers to copy bank details from old emails. | Customer downloads, reminder emails, and resend controls expose the same current QR payment data and leave a traceable audit trail. |
FAQ
What is a WooCommerce QR code invoice payment workflow?
It is a bank-transfer invoice workflow where the invoice PDF and invoice emails include machine-readable payment details, often EPC/SEPA-style QR payment data, so the customer can pay the exact amount with the right reference.
Does a QR code replace a WooCommerce payment gateway?
No. A QR payment code is usually a convenience layer for bank transfer, proforma, Net terms, or pay-by-invoice orders. It still needs invoice state, payment matching, reminders, credit notes, and accounting export around it.
Should QR codes appear on paid invoices?
Usually not as a payment request. Paid invoices may retain payment evidence, but unpaid payment prompts should be conditional so customers do not pay twice after a card, PayPal, Mollie, or bank-transfer payment has cleared.
Where does Lattice fit in QR-code invoice payments?
Lattice Invoices early access is positioned around the complete WooCommerce invoice workflow: VAT/BTW fields, proformas, final invoice PDFs, due dates, payment references, reminders, credit notes, customer downloads, and accounting export readiness.