EPC QR Codes on Invoices: A Guide for European Businesses

EPC QR codes — the European Payments Council's guideline for encoding a credit transfer — are the square you keep seeing at the bottom of invoices from Austria, Germany and the Netherlands. One scan hands a bank app a complete pre-filled transfer. This piece covers the structure and what makes these codes fail. It is not tax, accounting or legal advice; whether your invoices must carry one is a question for your accountant.

What the code contains

The payload is plain UTF-8 text: fields in a fixed order, one per line, separated by line breaks. No XML, no JSON, no URL. That simplicity is why printers and accounting packages have adopted it so widely — you can generate one with a text template and any QR encoder.

The order is not negotiable. A parser reads by position, not by name, so a field in the wrong slot corrupts everything after it.

#	Field	Example	Limit
1	Service tag	BCD	Fixed, 3 characters
2	Version	001 or 002	3 digits
3	Character set	1 (UTF-8) or 2 (ISO 8859-1)	1 digit
4	Identification	SCT for SEPA credit transfer	3 characters
5	BIC of the beneficiary bank	DEUTDEFF	8 or 11 characters, optional under version 002
6	Beneficiary name	Musterfirma GmbH	70 characters
7	Beneficiary IBAN	DE02120300000000202051	34 characters
8	Amount	EUR125.80	EUR prefix plus up to 15 digits
9	Purpose code	usually left empty	4 characters, optional
10	Structured creditor reference	RF18539007547034	35 characters
11	Unstructured remittance info	Invoice 2026-0148	140 characters
12	Beneficiary-to-originator info	rarely used	70 characters

Two fields that trip people up

Field 8, the amount. The currency code comes first, with no space, followed by a number using a dot as decimal separator: EUR125.80, not 125.80 EUR and not 125,80. No thousands separators, no currency symbol. Missing amount is permitted with an empty line only where the scheme allows it.

Fields 10 and 11 are mutually exclusive. Use the structured reference or free-text remittance, never both — plenty of bank apps reject a code carrying both.

Character limits are hard limits, not suggestions

The guideline sets maximum lengths that parsers enforce. Exceeding one typically means the whole code is refused, not silently truncated.

• Beneficiary name: 70 characters. Legal entity names generally fit. Add a department line inside this field and you are gambling.
• IBAN: 34 characters. Every SEPA IBAN fits; the field is sized for the longest permitted in any country.
• Structured reference: 35 characters. An ISO 11649 creditor reference such as RF18539007547034 is well inside it.
• Unstructured remittance: 140 characters. Enough for "Invoice 2026-0148 dated 2026-08-30" and not much more.

Character set consistency matters as much as length. If you declare UTF-8 in field 3, the payload must genuinely be UTF-8; an invoicing system emitting accented characters in another encoding produces codes that get rejected or show mangled names. Stick to letters, digits and the punctuation the SEPA scheme allows.

Why German-speaking countries lead adoption

That is invoice culture more than regulation. Austria and Germany send plenty of paper invoices paid by manual transfer, and several large banking groups added EPC scanning to their apps early, so the benefit was obvious. Where card, direct debit or instant payments already dominate, the marginal gain is smaller and adoption moved slower.

For cross-border suppliers the practical consequence is simple: if Austrian or German customers receive your invoices, expect to be asked for one. Whether any given invoice must carry a code depends on rules that vary by country and change over time — that belongs with your accountant.

What actually happens when someone scans

Manage the expectation, because the name creates the wrong one. Scanning an EPC code does not move money and does not authorise anything. The sequence is:

1. A banking app reads the text payload and checks the BCD tag and version.
2. It validates the IBAN checksum and, if present, checks the BIC belongs to that IBAN's bank.
3. It opens a transfer form pre-filled with beneficiary, IBAN, amount and reference.
4. The user reviews everything, possibly changes it, then confirms with whatever authentication their bank requires.

The last step always involves the account holder, which is why these codes are safe to publish on documents that get emailed around widely.

Common failure reasons

Symptom	Usual cause
Bank app says unreadable or unsupported	Wrong field order, or a missing trailing empty line so the last two fields collapse together
Rejected immediately after parsing	BIC does not correspond to the IBAN; drop the BIC under version 002 rather than guessing
Amount ignored or shown wrong	Format error — missing EUR, comma instead of dot, or a thousands separator
Beneficiary name mangled	Encoding mismatch between field 3's declaration and the actual bytes
Reference lost	Both field 10 and field 11 populated
Scans on one bank app, fails on another	App-specific strictness around empty optional fields; try leaving every unused field empty and keeping the trailing newlines

Scan every new invoice template yourself — in two banking apps if you can — before it goes live, and re-test after any change to your invoicing software.

Layout on the document

1. Place it in the lower area of the first page, near the payment details it summarises — near enough that the connection is obvious.
2. Size it for a scan from a desk: about 4–5 cm square on A4 is comfortable. These payloads are short, often under 200 characters, so density is rarely the issue.
3. Keep it out of the gutter if the document gets stapled or bound — skew from the fold is worse than size for scanning reliability.
4. Print at 300 dpi or better. A low-resolution export from a spreadsheet is a recurring cause of "the code is there but nothing scans it."
5. Do not print it in light grey to match your branding. Black on white, always.
6. Label it. "Scan to pay with your banking app" tells anyone unfamiliar what to do with the square.

Error correction level M is a sensible default: enough tolerance for scanner shadow or a folded corner without much extra density. See error correction explained for the reasoning.

FAQ

How many fields does an EPC QR code have?

Twelve, in strict order, one per line. Position determines meaning, so inserting or skipping a field shifts everything after it.

What is the correct amount format?

The currency code immediately followed by the amount with a dot as decimal separator: EUR125.80. No symbol, no space, no thousands separator, no comma.

Do I need to include the BIC?

Under version 002 it is optional, and for domestic SEPA transfers banks generally derive it from the IBAN. Including an incorrect BIC is worse than leaving the field empty.

Can I fill in both the structured reference and free-text remittance?

No. Fields 10 and 11 are mutually exclusive. Populating both is one of the most frequent causes of otherwise valid codes being rejected.

What are the character limits?

Beneficiary name 70, IBAN 34, structured reference 35, unstructured remittance 140, beneficiary-to-originator info 70. Exceeding limits usually causes rejection rather than truncation.

Does scanning actually send the payment?

No. The scan fills in a transfer form in the user's banking app. The account holder still reviews and confirms it, with their bank's usual authentication.

Am I required to put an EPC code on my invoices?

That depends on your country's invoicing rules, your customers and the formats they accept — not on the QR standard itself. Ask your accountant or tax adviser; this article only covers how the code works technically.