EPC QR code explained: the SEPA payment code on European invoices

You open an invoice from your accountant. In the corner sits a QR code with the words "Scan to pay". You open your banking app, point the camera at it, and the transfer form is filled in: name, IBAN, amount, reference. You check the details and confirm. That code follows a European standard, and knowing how it works helps you use it well on your own invoices.

What an EPC QR code is

The European Payments Council (EPC) publishes the rules for SEPA payments. One of its documents describes how a 2D code can carry the data for a SEPA credit transfer. The current version is EPC069-12, version 3.1, titled "Quick Response Code: Guidelines to Enable the Data Capture for the Initiation of a SEPA Credit Transfer". It was issued and took effect on 19 March 2024.

The document is a guideline, not an obligation. It states that "it is optional for PSPs adhering to the SCT scheme to implement this feature". In other words, each bank decides whether its app reads the code. Many banking apps in the euro area do. Check yours, and test with a second one before you print.

The use case is clear in the text. The payee prints the code on an invoice. The payer scans it and the app captures the data. For codes shown at a shop terminal, the EPC document page points to a different document, EPC024-22. That one is out of scope here.

What is inside the 331 bytes

An EPC QR code holds plain text, one field per line, in a fixed order. The fields, as version 3.1 defines them:

• Header: the service tag "BCD", a version (001 or 002), a character set and the identification "SCT".
• BIC: 8 or 11 characters. Mandatory in version 001. In version 002 it is only required in some cases, such as payments with participants outside the EEA.
• Beneficiary: the name, up to 70 characters, and the IBAN, up to 34 characters. The guideline says "Only IBAN is allowed."
• Amount: optional, in euro, from 0.01 to 999,999,999.99.
• Remittance: either a structured creditor reference of up to 35 characters or free text of up to 140 characters, never both. An optional 4-character purpose code comes before it.
• Note to the payer: optional, up to 70 characters.

The whole payload may not exceed 331 bytes. The guideline asks for error correction level M, which restores about 15 percent of damaged code words, and allows QR version 13 at most. That keeps the code small enough for an invoice footer.

One more rule matters for layout. The guideline assumes the same data appears in plain text next to the code, so the payer can compare what the app shows with what the invoice says.

A practical tip for the reference field: use a structured creditor reference where your accounting software supports one, such as the ISO 11649 format the guideline mentions. It stays well under 35 characters, keeps the code small, and lets your bookkeeping match incoming transfers to invoices automatically. Free text works too, but customers sometimes edit it in the app before they confirm, and then the match fails.

What an EPC QR code cannot do

The code is useful because it is simple. That also sets its limits.

• It does not pay. It fills in a form. The payer still checks and confirms the transfer in the banking app.
• It is not a link. There is no web address inside, so a phone camera without a banking app shows text, not a page.
• It does not report back. The banking app reads the code on the phone. You, the payee, learn nothing about who scanned it or when.
• It cannot change. Once printed, the IBAN and amount are fixed. A new amount means a new code.

Take a language school that sends 400 term invoices in September. Each invoice gets its own EPC QR code with that family's amount and invoice number as reference. When a parent pays, the school sees the transfer in its bank account with the right reference. That is the whole job of the code, and it does that job well.

EPC QR code versus a payment link QR

Payment providers offer another kind of payment code. Mollie, for example, describes on its page about paying with a QR code how the code links to a payment page with the details filled in. You create it under Payment requests in the dashboard, or through the API so invoices carry a code automatically. The page lists cards, PayPal, Apple Pay and SEPA bank transfers among the methods.

The two approaches differ in a few ways:

• Content: the EPC code carries the transfer data itself. The payment link code carries a web address to the provider's page.
• Reader: the EPC code needs a banking app that supports it. The link works with any camera app.
• Methods: the EPC code starts a SEPA credit transfer only. The provider page can offer several methods.
• Who sits in between: with the EPC code, nobody. With a payment link, the provider handles the page and the payment.

Neither is better in general. A business with mostly private customers who pay by card may prefer the link. A firm that invoices other companies by bank transfer often prints the EPC code. Some print both.

Why an EPC QR code must stay static

People who use dynamic QR codes for marketing sometimes ask whether the payment code can be dynamic too. It cannot, and it should not be. A banking app expects the BCD payload in the code itself. If you put a redirect address in the square, the app sees a URL, not a transfer, and the scan fails.

There is a security reason as well. Invoice fraud often works by swapping payment details. A payment code that points to an editable redirect would give anyone with access to that redirect a way to change where money goes. Keep the payment code exactly as your accounting software or bank generates it. Print the IBAN in text next to it. Our article on QR code phishing explains how customers learn to spot fake codes.

Where a dynamic code fits next to it

EUQR does not make EPC QR codes. Your accounting package or bank does. What EUQR adds is everything around the payment that may change after the invoice is printed.

Back to the language school. Next to the EPC code it prints a second, labelled code: "Timetable and course materials". That is a dynamic QR code to the parent portal. When the portal moves in January, the school changes the destination and the September invoices still work. A third code opens a PDF page with the school's terms, which the office replaces when they change. For the PDF invoice sent by email, a short link from the EUQR link shortener, such as qreu.eu/timetable, does the same job for parents who read on their phone.

Those editable codes also show something the payment code never will: how often each one is scanned, as aggregate counts without cookies or raw IP addresses. You learn whether parents use the portal link, not who they are.

A short checklist for the invoice footer

1. Let your accounting software or bank generate the EPC code. Do not build the payload by hand.
2. Test the printed code with at least two banking apps before a large print run.
3. Print beneficiary name, IBAN, amount and reference in plain text beside the code.
4. Give the payment code the most space and a clear quiet zone.
5. Label every code in words, so nobody scans the portal code to pay.
6. Keep editable codes for things that change: portals, terms, manuals.

This is not legal or financial advice. For questions about payment terms or invoicing rules, ask your bank or accountant. If you want to add an editable code beside your payment code, the EUQR plans start at €0.99 per month.