What is the EPC standard?
The European Payments Council (EPC) defines technical standards for payments in the SEPA area. One of these standards describes how a SEPA bank transfer is encoded in a QR code – as a SEPA-QR or GiroCode. The goal is for banks and payment providers across Europe to understand the same format so that they can reliably create transfers from a QR code.
The EPC standard specifies both the order of the fields and their maximum lengths and allowed character sets. This ensures that a GiroCode generated in one SEPA country can be read correctly by a banking app in another.
Structure of the EPC payload (line by line)
An EPC payload typically consists of several lines of text, for example:
BCD 002 1 SCT BICBANKXXX Max Mustermann DE02120300000000202051 EUR12.34 Invoice 2024-001
The most important lines at a glance:
- Line 1 – Service tag (BCD): identifies the format as a bank QR code in the EPC scheme.
- Line 2 – Version: Versions such as
001and002are currently in use. They define which fields are expected. - Line 3 – Encoding: indicates the character set, e.g.
1for UTF‑8. - Line 4 – SEPA scheme: usually
SCT(SEPA Credit Transfer) for standard transfers. - Line 5 – BIC: bank identifier code of the recipient's bank (in many cases optional today).
- Line 6 – Name of the recipient: account holder, e.g. company name or person.
- Line 7 – IBAN: full IBAN of the recipient.
- Line 8 – Amount: optional amount in the format
EUR12.34. - Line 9 – Payment reference: free text such as invoice number or member ID.
Versioning: 001 vs 002
In practice you will often see versions 001 and 002. Both describe very similar fields but differ in details of the specification and potential extensions.
For most use cases – especially in the German market – it is sufficient to use a version that common banking apps support. Many generators therefore use a widely compatible version that works without issues with major banks.
Error correction level M
When generating a QR code you have to choose an error correction level. For GiroCodes this is typically M. It ensures that the code can still be read if parts of it are slightly covered, dirty or blurred.
The choice of error correction is important: if it is too low, the code becomes vulnerable to read errors; if it is too high, the code becomes unnecessarily large. The EPC standard defines a practical compromise here.
Maximum lengths and character set
Each field has a maximum length to ensure compatibility. For example, the recipient's name is limited to a certain number of characters, and the payment reference may only use a defined maximum length.
The character set is restricted as well. Exotic symbols or emojis are usually not allowed to avoid processing issues. In practice you should stick to simple letters, digits and common punctuation.
Other formats: GiroCode, BezahlCode, STUZZA QR
Besides GiroCode there are other QR formats used in payments:
- BezahlCode: a format developed in Germany that can represent not only transfers but also direct debits or contact information.
- STUZZA QR: a format popular in Austria that also supports SEPA payments but with its own specifics.
For classic SEPA credit transfers in Germany the GiroCode / SEPA-QR according to the EPC standard has become a de-facto standard. Many banking apps support it directly, making it particularly suitable for invoices and payment requests.