EPC QR Code Generator

What is an EPC QR code?

An EPC QR code holds the details of a SEPA credit transfer as plain text, arranged in a fixed order so that any banking app implementing the standard can read it and pre-fill a payment form. The payer scans, checks what the app shows, and confirms. The code moves no money by itself; it removes typing.

The format is defined by the European Payments Council in document EPC069-12, Quick Response Code: Guidelines to Enable the Data Capture for the Initiation of a SEPA Credit Transfer. The current data version is 002, sometimes written as EPC QR Code v2.0. The specification caps the payload at 331 bytes and recommends error-correction level M — those two numbers are related, because 331 bytes is exactly what a version 13 symbol carries at level M.

You will meet the same code under local brand names. In Germany it is the GiroCode, promoted by the German banking industry; in Austria banks and Stuzza have pushed it on invoices and donation forms for years; Dutch, Belgian, Finnish and Slovenian billers use it too. The payload is identical in every case. There is also an older, incompatible German scheme called BezahlCode built on a bank:// URI; if an app reads one and not the other, this is usually why.

Why it is so common on German, Austrian and Dutch bills

Three reasons, none of them about technology fashion. First, in these markets the default way to settle an invoice is a bank transfer initiated by the payer, not a card payment or a direct debit — so the payer is the one doing data entry. Second, the data they must copy is brutal: a German IBAN is 22 characters, a Dutch one is 18, and the reference number is often another 12–20 digits. Getting one character wrong means a returned payment or an unreconcilable receipt. Third, the code costs the biller nothing: no acquirer, no merchant account, no per-transaction fee, no scheme rules. A biller adds 3 cm of ink to an invoice they were already printing and gets faster, cleaner payments. Charities noticed this early, which is why German and Austrian donation mailings are covered in them.

When to use it

• Printed and PDF invoices. Put the code next to the payment block so the payer never retypes the IBAN or the invoice number.
• Donation appeals. Leave the amount empty so the donor chooses, and use the purpose code CHAR.
• Membership dues and subscription renewals. One code per member with their membership number as the structured reference makes reconciliation nearly automatic.
• Utility, insurance and municipal statements. High volume, fixed amounts, long reference numbers — the ideal case.
• Rent and service charge notices. Amount fixed, reference stable, payer pays monthly from their phone.
• Tradesperson invoices left on site. A plumber's paper invoice with a code gets paid the same evening far more often than one without.
• School trips, clubs and associations. Parents pay a €18.50 fee without a treasurer chasing anyone.
• Collection boxes, notice boards and event posters. Print the code large, leave the amount open, and keep the beneficiary name readable in text beside it.

Where it does not fit: anything outside the euro area's SEPA credit transfer rails. The scheme identification is SCT and the amount field is prefixed EUR, so there is no way to express a Swiss franc or pound sterling instruction. Switzerland uses its own Swiss QR-bill; Nordic markets largely use domestic mobile payment schemes.

How to create one

1. Get the beneficiary name exactly as the account is held. Not the trading name, not the abbreviation someone remembers — the name on the account, trimmed to 70 characters.
2. Copy the IBAN and remove every space. Uppercase, no separators. Verify the check digits before you print anything; a wrong IBAN in a mailing of 3,000 statements is an expensive week.
3. Decide whether to fix the amount. Fixed for invoices, empty for donations and open-ended collections. If you leave it out, the field must be genuinely empty — a bare EUR with no digits is invalid, so check the payload rather than trusting the form.
4. Choose one reference field, not both. A structured creditor reference (row 10) or free text (row 11). Filling both is the single most common cause of a reference silently disappearing.
5. Generate the code and read the payload back if your tool can show it. The first four lines must be BCD, 002, 1, SCT.
6. Test with at least two real banking apps from different banks. Implementations vary in how strictly they parse, and a code that only works in one app will generate support calls.
7. Print the IBAN, amount and reference in text next to the code. This is not redundancy for its own sake: it lets a payer compare what their app shows against what the document says, and it serves people whose bank has not implemented the standard.
8. Check the physical size against the table below before signing off the print run.

The data format: all 12 fields

The payload is a text block. Each field sits on its own line, separated by a single line feed (LF, 0x0A), always in this order. Fields are positional: if you skip an optional field that sits before a field you do use, you must still leave its line empty.

BCD
002
1
SCT
BPOTBEB1
Vlaams Rode Kruis
BE72000000001616
EUR125.00
CHAR
RF18539007547034
Invoice 2026-0417
Thank you for your support

#	Field	Example	Rules
1	Service tag	BCD	Mandatory, always these three characters. An app that sees anything else should reject the code.
2	Version	002	Mandatory. Use 002, which made the BIC optional. Version 001 required a BIC, and there is no reason to use it now.
3	Character set	1	Mandatory. 1 = UTF-8, 2 = ISO 8859-1, then 3–8 for other ISO 8859 variants. Use 1 and make sure the encoder really emits UTF-8.
4	Identification	SCT	Mandatory. Marks the instruction as a SEPA credit transfer. No other value is defined.
5	BIC	BPOTBEB1	Optional with version 002, 8 or 11 uppercase characters. Only needed for beneficiaries in non-EEA SEPA countries; leave the line empty inside the EEA.
6	Beneficiary name	Vlaams Rode Kruis	Mandatory, max 70 characters. Must match the account holder. Avoid & and line breaks; see the character notes below.
7	Beneficiary IBAN	BE72000000001616	Mandatory, max 34 characters, uppercase, no spaces. Must pass the ISO 7064 mod-97 check.
8	Amount	EUR125.00	Optional, max 12 characters including the prefix. Uppercase EUR, dot as decimal separator, no thousands separators, range 0.01 to 999999999.99.
9	Purpose code	CHAR	Optional, 4 characters from the ISO 20022 external purpose list — for example CHAR (charity), GDDS (goods), SCVE (services), TAXS (tax), OTHR.
10	Structured reference	RF18539007547034	Optional, max 35 characters. A creditor reference, typically ISO 11649 form (RF + two check digits + up to 21 characters) or a national equivalent. Mutually exclusive with row 11.
11	Unstructured remittance text	Invoice 2026-0417	Optional, max 140 characters. Free text that travels with the payment. Mutually exclusive with row 10.
12	Beneficiary to originator information	Thank you for your support	Optional, max 70 characters. Displayed to the payer by the app as a hint; it is not part of the transfer instruction.

The details that decide whether an app accepts it

Amount formatting. EUR125.00 is correct. EUR 125.00 with a space, 125.00EUR, eur125.00 and the European habit of writing EUR125,00 with a comma are all wrong, and different apps fail differently: some show a blank amount, some refuse the code, some round. Writing two decimals is optional (EUR125 is valid) but worth doing, because the payer sees the amount and expects cents.

Beneficiary name characters. The safe set is the SEPA basic Latin set: a–z A–Z 0–9, space, and / - ? : ( ) . , ' +. Even with UTF-8 declared in row 3, umlauts and accents get transliterated somewhere along the payment chain, and an ampersand in a company name is a reliable way to break a parser. If you see rejections, write Mueller GmbH rather than Müller GmbH, and Meyer und Sohn rather than Meyer & Sohn. Never include a leading or trailing space.

Line endings. Use bare LF. A generator running on Windows that emits CRLF produces a payload where every field carries a stray carriage return; strict apps reject it outright, tolerant ones import fields with invisible junk. This is the most annoying failure to diagnose, because the code looks perfect.

Trailing fields. You may end the payload after the last field you actually use — an eleven-line block that stops after the remittance text is fine. What you may not do is reorder or omit an intermediate line.

Sizing, placement and printing

EPC codes are denser than a typical URL code, so size matters more than people expect. The payload length sets the symbol version, and the version sets how small each module becomes at a given printed width. At error-correction level M:

Payload size	QR version	Grid	Module width at 30 mm	Verdict
~90 bytes (name, IBAN, amount)	6	41 × 41	0.61 mm	Comfortable on any printer
~120 bytes (+ short reference)	7	45 × 45	0.57 mm	Fine
~150 bytes	8	49 × 49	0.53 mm	Acceptable, keep the print clean
~180 bytes	9	53 × 53	0.49 mm	Borderline — enlarge to 35 mm
331 bytes (maximum)	13	69 × 69	0.39 mm	Too tight; needs 38–40 mm

Module widths include the four-module quiet zone on each side. The practical lesson: a 140-character remittance message costs you real millimetres. Trim the free text to the invoice number and a couple of words, and a 30 mm code stays easy to scan.

Where the code lives	Scan distance	Minimum width	Notes
A4 invoice, next to the payment block	25–30 cm	25–30 mm	Bottom right of the page, IBAN in text beside it
PDF invoice read on a laptop, scanned by phone	30–40 cm	30–35 mm at 100% zoom	Embed as vector so it stays sharp when zoomed
Donation letter or reply slip	25–30 cm	30 mm	Leave the amount empty; keep the purpose code
Collection box or counter card	40–60 cm	50–60 mm	Laminate it, and check it has not been covered
A4 or A3 poster	1–1.5 m	100–150 mm	Chest height; matte finish to avoid glare
Statement window envelope insert	25 cm	25 mm	Keep 8 mm clear of folds and perforations

Stick with level M as the specification recommends. Raising it to Q sounds safer but adds modules, so unless you also enlarge the printed code you make things worse. Print in 100% black on white, keep the quiet zone empty, place vector artwork at final size, and label the code — "Scan to pay with your banking app" plus the amount in text. Inverted or coloured codes are a coin flip across banking apps; do not risk it on a payment instruction.

Common mistakes and how to fix them

Symptom	Cause	Fix
App scans the code, then says the data is invalid	CRLF line endings, or a missing or misspelled line 1–4	Emit LF only and confirm the payload starts BCD / 002 / 1 / SCT
Amount field arrives blank or wrong	EUR 125,00, 125.00 EUR, or a bare EUR with no digits	Write EUR125.00 with no space and a dot, or leave the whole line empty
Payment arrives with no reference	Rows 10 and 11 both filled	Use one: structured reference in row 10 or free text in row 11
Beneficiary name truncated or rejected	Over 70 characters, or contains &, umlauts or accents	Use the short legal name, transliterate (ü to ue), replace & with und or and
Works in one bank's app, fails in another	Payload over 331 bytes, forcing a symbol above version 13	Drop optional fields and shorten the remittance text until you are under 331 bytes
IBAN not accepted	Spaces, lowercase letters, or a typo that breaks the mod-97 check	Strip spaces, uppercase everything, validate the checksum before printing
Code looks muddy and cameras hesitate	A near-maximum payload printed at 20–25 mm	Shorten the payload or print at 38–40 mm; always export vector
Payments land but cannot be reconciled	No reference at all, or a reference the accounting system does not recognise	Always carry the invoice or member number, in the exact format your ledger matches on
Printed codes point at a closed account	Static code, IBAN changed after a bank switch	The code cannot be edited — keep the old account open through the transition and reissue documents

Security and privacy notes

Nothing is transferred by scanning. The code is text. The payer's app fills a form, shows the beneficiary name, IBAN, amount and reference, and still requires whatever authentication the bank mandates — PIN, biometrics or a second device under PSD2 strong customer authentication. Any communication implying that a scan alone completes a payment is wrong.

The IBAN is published, so treat it that way. A code on a public poster exposes your account number to everyone who walks past, which is also true of the IBAN printed on the same poster. An IBAN alone does not let someone withdraw money, but it is enough to attempt a direct debit in some contexts, so reconcile statements and be aware of your bank's dispute windows for unauthorised debits.

Tampering is the real attack. Fake codes stuck over genuine ones on invoices, parking machines and donation boxes redirect payments to another account. Defences that work: print the code as part of the document artwork, show the beneficiary name and IBAN in readable text beside it so payers can compare against what their app displays, laminate or enclose public installations, and inspect them regularly. Payers should read the beneficiary name in the app before confirming — that screen is the last honest checkpoint.

Remittance text is not private. Whatever you put in rows 10 to 12 can appear on the payer's bank statement and in their household's shared account view. Do not write anything that reveals health, legal or otherwise sensitive context; Invoice 2026-0417 tells your ledger everything it needs without telling the payer's family anything.

Rendering happens over the network. This generator builds the payload in your browser but renders the image through a third-party QR rendering service, which means the payload text is transmitted to produce the picture. For ordinary invoice data that is unremarkable; if your payload would be sensitive, generate codes with offline tooling instead. See our privacy policy for details.

This page explains a data format. It is not payment, tax or financial advice, and it does not replace your bank's or your auditor's requirements for invoicing.

FAQ

What does EPC stand for?

The European Payments Council, the body that publishes SEPA scheme rulebooks. Its document EPC069-12 defines the QR payload described on this page, which is why the codes are called EPC QR codes.

Is an EPC QR code the same as a GiroCode?

Yes. GiroCode is the German market name for the same EPC069-12 payload. Austrian, Belgian and Dutch billers use identical data. Only the branding and the printed logo differ.

Does scanning move money automatically?

No. The app pre-fills a SEPA credit transfer and the payer must review and authenticate it. If an app ever executed a transfer straight from a scan, that would breach the strong customer authentication rules banks operate under.

Can I use a currency other than euro?

No. The identification field is SCT — SEPA credit transfer — and the amount is prefixed EUR. For Swiss francs you need the Swiss QR-bill, which is a different specification with a different layout.

Is the BIC required?

Not with version 002 for beneficiaries inside the EEA, where IBAN-only transfers are standard. Include it for non-EEA SEPA countries such as Switzerland, Monaco or San Marino, where some banks still expect it.

Can I leave the amount empty?

Yes, and for donations you should. The payer then types the amount. Make sure the line is genuinely empty rather than containing a lone EUR, which is not a valid amount field.

Structured reference or free text?

Use the structured reference (row 10) when your accounting system matches on a creditor reference such as an ISO 11649 RF number, because it arrives in a dedicated field. Use free text (row 11) for human-readable notes. Never fill both.

How long can the payload be?

331 bytes, which corresponds to a version 13 symbol at error-correction level M. Note that bytes, not characters: an umlaut in UTF-8 costs two. Going over the limit produces codes that some apps quietly refuse.

Can I update a printed EPC code later?

No. Everything — IBAN, amount, reference — is baked into the symbol, so a change means reprinting. This is a reason to keep an account open during a bank migration and to avoid printing amounts on material with a long shelf life.

Which apps can read these codes?

Most banking apps in Germany, Austria, Belgium, the Netherlands, Finland and Slovenia, plus many multi-bank apps elsewhere in the euro area. Coverage is not universal, so always print the IBAN, amount and reference in text as a fallback.

Related QR code guides

URL QR code · PDF QR code · vCard QR code · Google review QR code · Restaurant menu QR code