Picture what your client does with the invoice you just sent. Opens the PDF, switches to their banking app, copies the account number, copies the amount, copies the payment reference, checks it, sends it. Six steps, four of which are transcribing digits from one window into another.
A QR payment code turns that into two steps: scan and confirm. That is the whole trick. Nothing about it is clever — it removes the part of the process nobody wants to do, which is therefore the part that gets postponed. And with invoices, "later" and "overdue" are the same word.
What the code actually contains
A payment QR code is a plain text string encoded as an image. It carries the account in IBAN form, the amount, the currency, a payment reference and optionally a message. The banking app reads it and pre-fills a transfer with those values. Nothing is transmitted to anyone but the client's own bank.
Which matters more than it sounds: this is not a payment button. There is no third party in the flow, no percentage taken, and the client never leaves their bank. That is why it works for businesses that would never pay for a payment gateway — the code is just a pre-filled form.
Which fields to fill in
The code can carry more than most people fill in, and two of those fields decide whether the payment arrives matched to an invoice or as an anonymous amount on a bank statement.
- The account in IBAN form. Local account formats do not work inside the code — it has to be an IBAN.
- Amount and currency. Leave the amount out and your client types it by hand, which is exactly the step you were removing.
- The payment reference. This is the field that lets you match the payment to the invoice. Without it you get an amount and a date on your statement and nothing else.
- The due date, if you want the transfer pre-dated rather than sent immediately.
- A message containing the invoice number — a useful backup for when a client overwrites the reference.
Three ways to get it onto the invoice
They differ mainly in how much manual work survives.
- An online generator. Fill in the account, amount and reference, get an image, paste it into the document. Fine for two invoices a month. At twenty it is twenty opportunities to paste last month's code into this month's invoice — a mistake nobody catches, because a PDF is checked by eye and a QR code cannot be read by eye.
- A template with an image placeholder. The same problem in nicer packaging: the code is produced outside the document and copied into it.
- Software that renders it from the invoice's own fields. The code comes from the same amount and the same reference that are printed on the invoice, so the two cannot disagree. Here the manual work does not shrink, it disappears.
The difference between the first option and the third is not convenience. It is that in the first two, a state exists where the invoice says one amount and the code says another — and the client scans the code, because that is what it is there for.
How much faster do you actually get paid
Promising a number of days would be a claim we cannot support — it depends entirely on who you invoice. The mechanism is clear enough to reason about, though, and it tells you where this helps and where it does nothing.
| Who pays | Effect |
|---|---|
| Sole trader or small firm, paying from their phone | Largest. The invoice often gets paid while it is being read. |
| Owner who batches payments in the evening | Noticeable. Removes the step that slows them down per invoice. |
| Accounts department with an approval chain | Small. Payment leaves an accounting system; nobody scans anything. |
| Client in a market with a different standard | None. Their app cannot read the code. |
The practical conclusion: this is a tool for small and mid-sized clients, and those are also the clients who pay late through inattention rather than policy. Against a corporate customer on 60-day terms it does nothing at all, and the answer there is a different one.
The other half of the saving is yours
QR payments get discussed as a convenience for the client. The larger saving is usually on your side, and it starts the moment the money lands. The client scanned the code, so the reference is correct — and a correct reference is what makes a payment matchable to an invoice automatically.
Without it, the end of the month looks like this: open the statement, look at amounts, guess who each one came from, tick things off a list by hand. With it, the statement becomes a set of invoices that marked themselves paid, and what is left over is the exceptions — which is the only list you actually wanted to look at.
The code, the reference and the matching are one feature
In Oplero the QR payment code is rendered onto every invoice PDF from the invoice's own fields, the payment reference carries through to matching, and a forwarded bank notification marks the invoice paid.