EPC Standard & SEPA-QR – Technical Structure Explained

The Technical Structure of the EPC Payload

The EPC payload is a plain-text string with fields separated by newline characters. Each line contains exactly one field. The order of the fields is fixed and mandatory. Here is a complete example:

BCD
002
1
SCT
SSKMDEMMXXX
Max Mustermann GmbH
DE02120300000000202051
EUR1250.00

Invoice 2024-0042

Now let's examine each line in detail:

Line 1: Service Tag (BCD)

The first line always contains exactly the string BCD (Bank Customer Data). This is a fixed identifier that tells any QR code reader that this payload follows the EPC bank transfer standard.

Line 2: Version (001 or 002)

The second line specifies the version of the EPC standard used. Currently, two versions are in active use: 001 and 002. Version 001 was the original specification; version 002 introduced minor changes and clarifications. If in doubt, use 002 as it is the more recent standard.

Line 3: Character Set Encoding (1–8)

The third line specifies the character encoding. The value 1 indicates UTF-8, which supports the full Unicode character set including umlauts and accented characters. UTF-8 (value 1) is the recommended choice for modern implementations.

Line 4: Identification Code (SCT)

The fourth line contains the payment scheme identification. For SEPA Credit Transfers, this is always SCT (SEPA Credit Transfer).

Line 5: BIC (optional since 2016)

The fifth line contains the BIC (Bank Identifier Code) of the recipient's bank. Since the completion of the SEPA migration in 2016, the BIC is no longer mandatory for domestic transfers within SEPA countries. Leaving this line empty is valid and widely supported.

Line 6: Recipient Name (max. 70 characters)

The sixth line contains the full name of the payment recipient. The maximum length is 70 characters. This field is mandatory.

Line 7: IBAN

The seventh line contains the full IBAN of the payment recipient. This field is mandatory. No spaces should be included – e.g. DE02120300000000202051.

Line 8: Amount (format EUR12.34)

The eighth line contains the transfer amount in the format EURx.xx – the ISO 4217 currency code followed immediately by the amount with a period as decimal separator. Examples: EUR12.34, EUR1250.00, EUR0.50. This field is optional.

Line 9: Purpose Type (usually empty)

The ninth line can contain a purpose type code from the ISO 20022 External Code List. In practice, this field is almost always left empty for standard invoice payments.

Line 10: Creditor Reference (usually empty)

The tenth line can contain a structured creditor reference (ISO 11649 RF reference). This is used in some countries (particularly Finland and Belgium) for automated payment reconciliation. In Germany, the free-text reference on line 11 is preferred.

Line 11: Payment Reference (max. 140 characters)

The eleventh line contains the free-text payment reference. This is the text that will appear on bank statements. The maximum length is 140 characters. Best practice is to include the invoice number here – e.g. Invoice 2024-0042 dated 2024-03-15.

EPC Versions Compared

For new implementations, version 002 with UTF-8 encoding is the recommended choice. It is forward-compatible with version 001 readers and does not require a BIC.

Error Correction and QR Code Quality

Error correction level M (15%)

QR codes support four error correction levels: L (7%), M (15%), Q (25%) and H (30%). The EPC standard specifies error correction level M for GiroCodes. This means up to 15% of the QR code's data cells can be damaged or covered while the code remains fully readable.

Impact on scannability

• Print quality: At least 300 DPI is recommended for printed codes
• Minimum size: At least 2 × 2 cm for printed invoices; 200 × 200 px for digital
• Quiet zone: White border of at least 4 modules on all sides
• Contrast: Black modules on white background; avoid grey or coloured backgrounds
• Undistorted: QR codes must not be stretched, rotated or skewed
• Payload length: Shorter payloads produce less dense QR codes that scan more reliably

Technical Implementation

Here is a JavaScript example showing how to generate a valid EPC payload from payment data:

function generateEpcPayload({
  name,       // Recipient name (max 70 chars)
  iban,       // Recipient IBAN
  bic = '',   // BIC (optional)
  amount = 0, // Amount in EUR (0 = no amount)
  reference = '', // Payment reference (max 140 chars)
  version = '002',
}) {
  const amountStr = amount > 0
    ? 'EUR' + amount.toFixed(2)
    : '';

  const lines = [
    'BCD',         // Service tag
    version,       // Version
    '1',           // UTF-8 encoding
    'SCT',         // SEPA Credit Transfer
    bic,           // BIC (optional)
    name.slice(0, 70),   // Recipient name
    iban,          // IBAN
    amountStr,     // Amount (optional)
    '',            // Purpose type (leave empty)
    '',            // Creditor reference (leave empty)
    reference.slice(0, 140), // Payment reference
  ];

  return lines.join('\n');
}

To generate the actual QR code image from this payload in JavaScript, you can use libraries like qrcode (npm) or qr-code-styling. Our GiroCode Generator uses a similar approach, running entirely in the browser without sending any data to a server.

Common Mistakes with the EPC Standard

Wrong character encoding

If the payload is encoded in a character set other than what is specified in line 3, special characters will be garbled. Always ensure that the encoding declared in line 3 matches the actual encoding used. For UTF-8 (value 1), ensure your string handling library encodes the payload as UTF-8 bytes.

Payment reference too long

The payment reference (line 11) has a strict maximum of 140 characters. If you exceed this limit, the QR code may be rejected or the reference silently truncated. Always validate the reference length before encoding.

Wrong amount format

The amount must use a period (.) as the decimal separator, not a comma. Wrong: EUR1.250,00. Correct: EUR1250.00 (period as decimal, no thousands separator). The amount must have exactly two decimal places.

Invalid IBAN

Using an IBAN that fails the Mod-97 check digit validation will cause banking apps to reject the payment. Always validate the IBAN before embedding it in a GiroCode.

Missing newlines between fields

The EPC payload uses Unix-style line breaks (\n, LF) to separate fields. Using Windows-style line breaks (\r\n, CRLF) or mixing line break styles will cause parsing errors in some banking apps.

Exceeding the maximum payload size

The total payload must not exceed 331 bytes when encoded in UTF-8. Exceeding this limit may produce a QR code that is too dense to scan reliably at small sizes.

Use GiroCode Professionally – Software Recommendations

Anyone who wants to use GiroCodes professionally on invoices will eventually need good accounting or invoicing software. Creating GiroCodes manually is fine for occasional use – but for regular invoicing, an automated solution quickly pays off.

We recommend two proven tools that natively support GiroCodes:

* Affiliate link – If you purchase through this link, we receive a small commission at no extra cost to you.

For occasional use or as a starting point, we recommend our free GiroCode Generator – completely local, no registration required.