EPC QR codes (GiroCode) vs trackable QR codes: what agencies need to know before they go on an invoice

# EPC QR codes (GiroCode) vs trackable QR codes: what agencies need to know before they go on an invoice

A client hands you an invoice template and asks for "a QR code so people can just pay it." Somewhere in the brief there is also a QR code that should carry UTM parameters and show up in the client's monthly scan report. These are two completely different jobs, and a lot of confusion in agency briefs comes from treating them as the same square.

The payment one is almost certainly an EPC QR code, better known in Germany as a GiroCode. It is a fixed, bank-defined standard for triggering a SEPA transfer, not a trackable marketing code, and it cannot be swapped out for one of your dynamic codes without losing the thing that makes it work. This guide covers what an EPC QR code actually contains, why it cannot be scan-tracked the way a dynamic QR code can, where the two genuinely can sit side by side on the same document, and the fraud pattern every agency handling client invoices should know about.

What an EPC QR code actually is

EPC stands for the European Payments Council, the industry body that governs the Single Euro Payments Area (SEPA) rulebook. In February 2013 it published a guidance document defining a standard QR code payload for initiating a SEPA Credit Transfer, built on a data-capture format Austria's payment facilitator STUZZA had already put in front of banks in 2012. That standard is formally numbered EPC069-12.

The scheme was picked up under different regional names, which is the main source of confusion. Germany calls it GiroCode. Austria still calls it Stuzza QR. Belgium and the Netherlands generally just say "EPC QR code" or "SEPA QR code." All of them are the same EPC069-12 payload; the branding differs, the bytes inside the code do not. Finland and Germany added it to their banking apps in 2015, the Netherlands followed in 2016, and it is now recognised by mobile banking apps across the euro area, including apps from Sparkasse, ING, ABN AMRO, Rabobank, N26 and Bunq, among others.

Two versions of the payload exist. Version 001 requires a BIC (the bank's SWIFT code) alongside the IBAN. Version 002, current since 2018, made the BIC optional for domestic SEPA transfers and is what any new implementation should generate. If a client's old invoicing software is still stamping out version 001 codes, that is worth flagging: some banking apps have started dropping BIC validation for intra-SEPA transfers, and carrying the extra field is no longer necessary.

It is worth a separate mention that Switzerland is not on this list. The Swiss QR-bill looks similar and does the same job for a Swiss franc transfer, but it is a distinct national standard maintained by SIX, not an EPC069-12 payload. A GiroCode generator will not produce a valid Swiss QR-bill, and vice versa.

What data actually lives inside the code

An EPC QR code is not a link. It contains no URL and touches no server when scanned; every field the bank app needs is written directly into the QR payload as plain text, in a fixed order defined by the standard. The eleven elements are:

• Service tag: the literal string "BCD," which tells the reading app this is an EPC payload.
• Version: "001" or "002."
• Character set: a numeric code, almost always 1 for UTF-8.
• Identification: the literal string "SCT" (SEPA Credit Transfer).
• BIC: the beneficiary bank's identifier. Optional under version 002.
• Beneficiary name: up to 70 characters.
• IBAN: the beneficiary's account number, the one field every implementation treats as mandatory.
• Amount: euros only, formatted as EUR followed by up to two decimal places. Optional; leaving it blank lets the payer type in their own figure.
• Purpose code: an optional SEPA purpose category, left blank in most invoicing setups.
• Structured creditor reference: an ISO 11649 reference beginning "RF," followed by two check digits and up to 21 further alphanumeric characters, capped at 25 characters total. Used mainly in Finland and Belgium for automated reconciliation against accounts receivable.
• Unstructured remittance information: free text, capped at 140 characters, typically the invoice number. Used instead of the structured reference everywhere the ISO 11649 format is not the local convention.

The whole payload has a hard ceiling of 331 bytes once UTF-8 encoded, and the standard fixes the error correction level at M, meaning it can recover from roughly 15 per cent of the code being damaged or obscured before it stops scanning. That is a deliberate, spec-level choice, not something a generator lets you adjust. If you have read our piece on how much data a QR code can hold, the same principle applies here in miniature: a short, fixed payload with a locked error-correction level scans more reliably than a long one, and the standard is written to guarantee that reliability rather than leave it to the generator.

Why you cannot track EPC QR code scans

This is the point that trips up briefs the most. A trackable marketing QR code, the kind ScanKit generates, encodes a short URL that points at a redirect server. Every scan is an HTTP request the server sees and logs before it forwards the phone's browser to the real destination. That request is what produces a scan count, a timestamp, a device type and a location.

An EPC QR code never makes that request. The payload is the payment data itself, parsed locally by the banking app the moment the camera reads it. There is no server in the loop, no redirect, and nothing for any platform, ScanKit included, to log. Asking whether an EPC QR code "shows up in analytics" is really asking whether a piece of paper can phone home; it cannot, by design, because the whole point of the standard is that a payment instruction should not depend on a third party's server being online.

This also means an EPC QR code cannot be edited after it is printed the way a dynamic QR code's destination can. Change the invoice amount and the IBAN checksum no longer matches what is encoded; you have to regenerate and reprint the code, every time, for every invoice. It behaves exactly like a static QR code in that respect: whatever was true at generation time is permanently baked in.

EPC QR code vs a trackable QR code: when you need each

Put the two side by side and the decision is straightforward once you separate what each one is actually for.

• Use an EPC QR code when the goal is to move money: an invoice, a donation request, a membership renewal, anything where the payer's own banking app should pre-fill an IBAN transfer. It only works within the euro area and only for a bank transfer, not a card payment.
• Use a trackable QR code when the goal is measurement or a variable destination: driving traffic to a landing page, a review link, a menu, a booking form, or anywhere you want a scan count, a source breakdown, or the ability to redirect somewhere new without reprinting.
• Use both, on the same document, when an invoice needs a "pay by bank transfer" option and a client also wants to know how many recipients opened the invoice online, clicked through to a payment portal, or viewed a related offer. They serve different rows on the same PDF and never compete for the same scan.
• Do not try to make one code do both jobs. A code cannot simultaneously carry a fixed IBAN payload and redirect through a tracking server; the EPC standard has no field for a callback URL, and stuffing a URL into the remittance line just produces text a banking app displays, not a link it will open.

If a client asks for "a QR code that both takes payment and tracks the scan," the honest answer is that no such single code exists under the current EPC standard. The practical fix is two codes: the EPC code for the transfer, and a small trackable code (or the same one used elsewhere in the campaign) linking to an online invoice or payment status page where you can measure engagement instead.

The fraud risk agencies handling client invoices should know

Because an EPC QR code carries the IBAN directly and most people no longer proofread account numbers before approving a bank transfer, it has become a genuine fraud target. Switzerland's National Cyber Security Centre has documented a pattern where attackers compromise an email account, intercept a legitimate invoice, swap the IBAN and regenerate the QR code to match, then resend the doctored PDF from the hijacked address. The visual design of the invoice looks identical; only the account number and the code's payload have changed.

A physical variant of the same idea, pasting a fraudulent QR sticker directly over a printed one, is the same technique used against parking meters and EV chargers, and it works just as well on a mailed invoice or a payment reminder taped to a door. Our guide to QR code security for agencies covers the general defence stack for printed codes; for EPC codes specifically, the practical additions are:

1. Never regenerate a client's EPC QR code from a forwarded email without confirming the IBAN by phone or through a channel outside that email thread.
2. Encourage clients to check the beneficiary name their banking app displays after scanning, not just the amount, since a mismatched name is often the first visible sign of a swapped IBAN.
3. If you manage recurring invoices for a client, keep the IBAN and generation logic in one controlled system rather than letting individual staff regenerate codes ad hoc in different tools.

Generating and testing one properly

Any EPC069-12 generator needs, at minimum, the beneficiary name, the IBAN and version 002 selected. Everything else is optional, but a few defaults are worth setting deliberately:

• Leave the amount field blank on recurring or variable invoices so the payer enters the correct figure themselves; only fix the amount for one-off, single-value requests like a fixed membership fee.
• Use the structured creditor reference (ISO 11649) if the client's accounting software can reconcile against it automatically; otherwise the unstructured remittance field with the invoice number is simpler and works everywhere.
• Follow the standard's own print guidance: a minimum physical size of around 2 by 2 centimetres, a print resolution of at least 300 DPI, and a quiet zone of at least four modules of white space on every side, the same clear-margin rule that keeps any QR code, tracked or not, reliably scannable.
• Before a print run goes out, scan the finished code with two or three different banking apps, not just one. Field support for optional elements like BIC and structured references still varies slightly between banks, and a code that pre-fills perfectly in one app can occasionally leave a field blank in another.

None of this needs a marketing QR platform. It needs a compliant EPC069-12 generator (several free ones exist) and the same print discipline you would apply to any code going on paper.

Frequently asked questions

What is an EPC QR code?

It is a QR code built to the European Payments Council's EPC069-12 standard, encoding the data needed to pre-fill a SEPA Credit Transfer, beneficiary name, IBAN, amount and reference, directly into the code so a banking app can read it without a server round trip.

What is a GiroCode?

GiroCode is the German name for the same EPC069-12 standard. Austria calls it Stuzza QR; Belgium and the Netherlands generally call it an EPC QR code or SEPA QR code. The underlying payload is identical regardless of the regional name.

Is a GiroCode the same as an EPC QR code?

Yes. GiroCode is a regional brand name for the EPC069-12 payload, not a different technical standard.

Which banks and countries support EPC QR code scanning?

Banking apps in Austria, Belgium, Finland, Germany and the Netherlands were early adopters, with Finland and Germany rolling it out from 2015 and the Netherlands from 2016. Most major euro-area banking apps, including Sparkasse, ING, ABN AMRO, Rabobank, N26 and Bunq, support scan-to-pay from an EPC QR code today, though coverage of optional fields such as BIC can vary slightly by bank.

Can you track scans of an EPC QR code?

No. The payload is parsed locally by the banking app; scanning it never triggers an HTTP request to any server, so there is nothing for a redirect platform or analytics tool to log. This is a structural property of the standard, not a limitation of any particular generator.

How much data can an EPC QR code hold?

The full payload is capped at 331 bytes once UTF-8 encoded, across eleven fixed fields including a beneficiary name limit of 70 characters and a remittance information limit of 140 characters.

Can I change the amount on an EPC QR code after it has been printed?

No. Every field, including the amount and the IBAN checksum, is fixed at generation time. Changing the amount means generating and printing a new code; there is no way to edit a printed EPC code's payload after the fact.

Is an EPC QR code safe from fraud?

The standard itself is not the weak point; the risk is a fraudster swapping the IBAN in the invoice PDF and regenerating a matching code before resending it, often from a compromised email account. Confirming the beneficiary name shown after scanning, and verifying IBANs through a channel outside the original email, are the practical defences.

What is the difference between an EPC QR code and a Swiss QR-bill?

They look similar and serve the same purpose, pre-filling a bank transfer, but they are different standards. The EPC QR code follows EPC069-12 for euro-area SEPA transfers; the Swiss QR-bill is a separate national standard for Swiss franc transfers, maintained by SIX. A generator built for one will not produce a valid code for the other.

What error correction level do EPC QR codes use?

Level M, fixed by the standard, which recovers from roughly 15 per cent damage or obstruction before the code becomes unreadable.

Can an EPC QR code and a trackable QR code appear on the same invoice?

Yes, and it is often the right setup: the EPC code handles the actual bank transfer, while a separate trackable code can point to an online invoice, a payment status page or a related offer, giving you scan data without touching the payment payload itself.

The short version

An EPC QR code, called GiroCode in Germany and Stuzza QR in Austria, is a fixed EPC069-12 payload that pre-fills a SEPA bank transfer directly inside a banking app. It carries no URL, touches no server, and therefore cannot be scan-tracked or edited after printing, unlike a dynamic QR code. Treat it as a payment instrument, not a marketing channel: verify the IBAN through a second channel before regenerating a client's code, keep the amount field blank on recurring invoices, test the finished code in more than one banking app, and reach for a separate trackable code whenever the actual goal is measurement rather than payment.