EPC QR Code (GiroCode) Explained: What Is Inside a SEPA Payment QR

An EPC QR code, known in German-speaking countries as a GiroCode, is a QR code that carries a complete SEPA Credit Transfer instruction: who is being paid, the IBAN the money goes to, how much, and what the payment is for. A banking app that scans one fills in the transfer form from the code, so the payer only confirms. The format is defined by the European Payments Council in a document called EPC069-12, and it is far stricter than most people expect. It is not a link, it is not free text, and it is not a general purpose barcode. It is eleven or twelve lines of plain text in a fixed order, with a hard byte budget and a mandatory error correction level.

We rebuilt our payment QR generator around that specification and then wrote a decoder that reads codes back and says what is wrong with them. This is what we learned about the format along the way, including one mistake of our own that is worth naming out loud.

What Is an EPC QR Code (GiroCode)?

The EPC QR code exists to remove typing from a bank transfer. Before it, paying an invoice in the euro area meant copying a 22 character IBAN, an amount, and a reference number by hand, which is exactly the situation where a transposed digit sends money to a stranger. The code moves all of that into a scan.

It is a euro area instrument. The instruction inside it is a SEPA Credit Transfer, so the scheme assumes euro and assumes a SEPA participant on the receiving end. That constraint matters more than it sounds, and we come back to it below.

What Data Does an EPC QR Code Contain?

Twelve data elements, one per line, separated by line feeds, always in this order. The first seven are mandatory:

• Service tag. Always the literal BCD. This is how a scanner knows it is looking at an EPC code and not something else.
• Version. 001 or 002. Version 001 requires the beneficiary bank's BIC; version 002 makes it optional, which is why almost everything issued today is 002.
• Character set. A digit from 1 to 8. Number 1 is UTF-8; the rest are ISO 8859 variants. A decoder that ignores this element and assumes UTF-8 will mangle every umlaut and every accented name in a code that declared something else.
• Identification. Always SCT, for SEPA Credit Transfer.
• BIC of the beneficiary bank. Optional in version 002.
• Beneficiary name. Up to 70 characters.
• IBAN of the beneficiary account.
• Amount, written as the currency code followed by the value, for example EUR12.50. Between 0.01 and 999999999.99.
• Purpose code, rarely used.
• Structured reference, an ISO 11649 creditor reference.
• Unstructured reference, free text up to 140 characters.
• Beneficiary to originator information, up to 70 characters.

The two reference elements are mutually exclusive. A code that fills in both is not valid, because the standard gives the payment one reference, not two, and a bank reading it has no rule for choosing between them.

Which Field Holds the Payee Name, and Why Does It Matter?

Element six is the beneficiary: the person or company being paid. It is not the bank. This sounds obvious written down, and we got it wrong anyway.

Our earlier generator filled element six with the name of the bank that the IBAN resolved to, because that name was already on screen and looked like the right thing to put there. The result was a technically well formed code that told a banking app to prefill a payment to Commerzbank rather than to the invoice issuer. Nothing errored. The code scanned perfectly. It was simply describing the wrong payee.

The generator now asks for the beneficiary name, and if you do not give one it emits a plain IBAN code instead of an EPC one, because the standard makes that element mandatory and a blank beneficiary is not a payment instruction. If you are building your own encoder, this is the field to look at twice.

Why Must an EPC QR Use Error Correction Level M?

QR codes come in four error correction levels, L, M, Q and H, which trade capacity against how much damage the symbol can survive. Intuition says a payment code should use the toughest one available.

EPC069-12 says M, and it says it as a requirement rather than a recommendation. That makes H just as non conformant as L. The reason is interoperability: banking apps size their decoding expectations around the standard, and a code that quietly upgrades its error correction changes its version and module count for the same payload. Our generator lets you pick a level for a plain IBAN code, but an EPC payment code is fixed at M and the page says so rather than silently overriding you.

How Much Data Fits in an EPC QR Code?

331 bytes, and that number is not arbitrary. It is the byte capacity of a version 13 QR symbol at error correction level M. The standard caps the payload there so that no conformant EPC code needs a symbol larger than version 13.

Bytes, not characters. A beneficiary name in Cyrillic or with Turkish dotted capitals eats more of the budget than the same number of Latin letters. When a payload would overflow, our generator drops the reference and tells you it did, rather than producing a code that encodes a truncated IBAN.

How Small Can You Print an EPC QR Code?

There is a claim circulating that EPC codes have a 25 mm minimum printed size. We went looking for that in the specification and could not find it, so we do not repeat it.

What is sourceable is a floor on the module, meaning the individual black square. The Swiss QR-bill implementation guidelines put it at 0.4 mm and the GS1 general specifications at 0.396 mm. From there the minimum print size follows arithmetically from how many modules your particular payload produces, which is why our generator computes it per code and prints the answer in millimetres next to the export options instead of quoting a single number for every code.

Can You Use an EPC QR Code Outside the Euro Area?

Technically you can encode any IBAN and any currency into the payload. Whether anything will read it is a different question. The scheme is a SEPA Credit Transfer instruction, so a Turkish lira amount on a Turkish IBAN is outside what EPC069-12 describes, and a banking app in that market is using a national QR scheme that expects an entirely different layout.

We chose not to block it. Locking the payment fields for non SEPA countries meant users could not even see what the tool did. Instead the fields stay editable, the code still generates, and an amber warning states plainly that a non SEPA IBAN or a non euro amount may not be recognised and that a plain IBAN code is universally scannable. Telling someone what the limitation is beats pretending the limitation is a bug in their input.

How Do You Check a Payment QR Code Someone Sent You?

A QR code is opaque by design. You cannot look at one and see whose account it names, which is the entire basis of quishing, the payment fraud built on QR codes. A sticker over a genuine code on a parking meter, or a code in an invoice email, prefills a transfer to an account you never chose.

Our payment QR decoder reads a code back and prints every element with its byte count, then runs the IBAN through the same validator as the rest of the site, so you see the country, the structure check, the national check digit and the bank behind the account before you pay anything. Two deliberate refusals are worth mentioning. It never turns a decoded string into a clickable link, because that is precisely the mechanism the fraud relies on. And it identifies a Swiss QR-bill without reading it, because the element order in a QR-bill belongs to SIX and pretending our EPC map applies to it would produce confident nonsense.

The honest limit: no decoder can tell you whether the named beneficiary really owns the named account. That check is Verification of Payee, and only the account holding bank can perform it.

Sources & References

• European Payments Council: EPC069-12 guidelines for encoding a SEPA Credit Transfer in a QR code
• European Payments Council: SEPA Credit Transfer scheme rulebook and implementation guidelines
• ISO/IEC 18004: QR code bar code symbology, including versions and error correction levels
• ISO 13616-1: structure of the International Bank Account Number (IBAN)
• ISO 11649: structured creditor reference to remittance information (the RF reference)
• SIX: Swiss QR-bill implementation guidelines, source of the 0.4 mm module size floor

Last updated: August 2026