EPC QR-code (GiroCode) versus trackbare QR-code: wat bureaus moeten weten

# EPC QR-code (GiroCode) versus trackbare QR-code: wat bureaus moeten weten voordat ze hem op een factuur zetten

Een klant geeft je een factuursjabloon en vraagt om "een QR-code zodat mensen 'm gewoon kunnen betalen." Ergens in dezelfde briefing staat ook een QR-code die UTM-parameters moet meekrijgen en moet opduiken in het maandelijkse scanrapport van de klant. Dit zijn twee compleet verschillende taken, en veel verwarring in briefings van bureaus ontstaat doordat ze als hetzelfde vierkantje worden behandeld.

De betaal-QR-code is vrijwel zeker een EPC QR-code, in Duitsland beter bekend als GiroCode. Het is een vaste, door banken vastgelegde standaard om een SEPA-overschrijving in gang te zetten, geen trackbare marketingcode, en je kunt hem niet zomaar vervangen door een van je dynamische codes zonder dat hij zijn werk niet meer doet. Deze gids legt uit wat er precies in een EPC QR-code staat, waarom je scans niet kunt volgen zoals bij een dynamische QR-code, waar de twee elkaar juist wel kunnen aanvullen op hetzelfde document, en welk fraudepatroon elk bureau dat facturen van klanten verwerkt zou moeten kennen.

Wat een EPC QR-code eigenlijk is

EPC staat voor de European Payments Council, de brancheorganisatie die de regels van de Single Euro Payments Area (SEPA) beheert. In februari 2013 publiceerde deze een richtlijn die een standaard QR-code-payload definieert voor het starten van een SEPA-overschrijving, gebaseerd op een dataformaat dat de Oostenrijkse betaalfacilitator STUZZA al in 2012 aan banken had voorgelegd. Die standaard heet officieel EPC069-12.

De standaard werd onder verschillende regionale namen overgenomen, en dat is precies waar de verwarring vandaan komt. Duitsland noemt het GiroCode. Oostenrijk noemt het nog steeds Stuzza QR. België en Nederland zeggen doorgaans gewoon "EPC QR-code" of "SEPA QR-code." Het gaat overal om dezelfde EPC069-12-payload; alleen de naam verschilt, de bytes in de code niet. Finland en Duitsland namen het in 2015 op in hun bank-apps, Nederland volgde in 2016, en tegenwoordig wordt het herkend door mobiele bank-apps in de hele eurozone, waaronder apps van Sparkasse, ING, ABN AMRO, Rabobank, N26 en Bunq.

Er bestaan twee versies van de payload. Versie 001 vereist een BIC (de SWIFT-code van de bank) naast het IBAN. Versie 002, actueel sinds 2018, maakte de BIC optioneel voor binnenlandse SEPA-overschrijvingen en is wat elke nieuwe implementatie zou moeten genereren. Als de oude facturatiesoftware van een klant nog steeds versie 001-codes genereert, is dat het signaleren waard: sommige bank-apps zijn gestopt met het valideren van de BIC bij overschrijvingen binnen SEPA, waardoor dat extra veld niet langer nodig is.

Het is de moeite waard om apart te vermelden dat Zwitserland niet op dit lijstje staat. De Swiss QR-bill ziet er vergelijkbaar uit en doet hetzelfde werk voor een overschrijving in Zwitserse franken, maar het is een aparte nationale standaard die wordt beheerd door SIX, geen EPC069-12-payload. Een GiroCode-generator produceert geen geldige Swiss QR-bill, en andersom ook niet.

Welke data er echt in de code staat

Een EPC QR-code is geen link. Er zit geen URL in en er wordt bij het scannen geen server aangeroepen; elk veld dat de bank-app nodig heeft, staat als platte tekst rechtstreeks in de QR-payload, in een vaste volgorde die de standaard voorschrijft. De elf elementen zijn:

• Service tag: de letterlijke tekenreeks "BCD," die de lezende app vertelt dat dit een EPC-payload is.
• Versie: "001" of "002."
• Tekenset: een numerieke code, vrijwel altijd 1 voor UTF-8.
• Identificatie: de letterlijke tekenreeks "SCT" (SEPA Credit Transfer).
• BIC: de identificatiecode van de bank van de begunstigde. Optioneel onder versie 002.
• Naam begunstigde: maximaal 70 tekens.
• IBAN: het rekeningnummer van de begunstigde, het enige veld dat elke implementatie als verplicht behandelt.
• Bedrag: alleen euro's, opgemaakt als EUR gevolgd door maximaal twee decimalen. Optioneel; als dit veld leeg blijft, kan de betaler zelf een bedrag invoeren.
• Doelcode: een optionele SEPA-doelcategorie, in de meeste facturatie-opzetten leeg gelaten.
• Gestructureerde crediteurenreferentie: een ISO 11649-referentie die begint met "RF," gevolgd door twee controlecijfers en tot 21 verdere alfanumerieke tekens, met een maximum van 25 tekens in totaal. Wordt vooral in Finland en België gebruikt voor geautomatiseerde afletting tegen debiteurenposten.
• Ongestructureerde betalingsinformatie: vrije tekst, met een maximum van 140 tekens, meestal het factuurnummer. Wordt gebruikt in plaats van de gestructureerde referentie overal waar het ISO 11649-formaat niet de lokale conventie is.

De hele payload heeft een harde limiet van 331 bytes zodra deze in UTF-8 is gecodeerd, en de standaard legt het foutcorrectieniveau vast op M, wat betekent dat de code nog werkt als ongeveer 15 procent ervan beschadigd of onleesbaar is voordat scannen niet meer lukt. Dat is een bewuste keuze op specificatieniveau, geen instelling die een generator je laat aanpassen. Als je ons artikel over hoeveel data een QR-code kan bevatten hebt gelezen, geldt hier hetzelfde principe in het klein: een korte, vaste payload met een vastgezet foutcorrectieniveau scant betrouwbaarder dan een lange, en de standaard is geschreven om die betrouwbaarheid te garanderen in plaats van dit aan de generator over te laten.

Waarom je scans van een EPC QR-code niet kunt volgen

Dit is het punt waar briefings het vaakst op stuklopen. Een trackbare marketing-QR-code, zoals ScanKit die genereert, bevat een korte URL die naar een redirect-server verwijst. Elke scan is een HTTP-verzoek dat de server ziet en logt voordat de browser van de telefoon wordt doorgestuurd naar de echte bestemming. Dat verzoek is wat een scanaantal, een tijdstempel, een apparaattype en een locatie oplevert.

Een EPC QR-code doet dat verzoek nooit. De payload is de betaalgegevens zelf, die lokaal worden verwerkt door de bank-app zodra de camera ze inleest. Er zit geen server tussen, geen redirect, en niets wat een platform, ScanKit incluis, kan loggen. Vragen of een EPC QR-code "in analytics verschijnt" komt eigenlijk neer op vragen of een stuk papier naar huis kan bellen; dat kan het niet, met opzet, want het hele idee achter de standaard is dat een betaalinstructie niet mag afhangen van de vraag of de server van een derde partij online is.

Dit betekent ook dat je een EPC QR-code niet kunt aanpassen nadat hij is afgedrukt, zoals dat wel kan met de bestemming van een dynamische QR-code. Verander je het factuurbedrag, dan klopt de IBAN-checksum niet meer met wat er gecodeerd staat; je moet de code steeds opnieuw genereren en afdrukken, voor elke factuur weer. Op dat punt gedraagt hij zich precies als een statische QR-code: wat op het moment van genereren klopte, ligt permanent vast.

EPC QR-code versus trackbare QR-code: wanneer heb je welke nodig

Zet ze naast elkaar en de keuze is eenvoudig zodra je scheidt waar elk van de twee eigenlijk voor dient.

• Gebruik een EPC QR-code als het doel is geld te laten bewegen: een factuur, een donatieverzoek, een verlenging van een lidmaatschap, alles waarbij de bank-app van de betaler zelf een IBAN-overschrijving moet voorinvullen. Het werkt alleen binnen de eurozone en alleen voor een bankoverschrijving, niet voor een kaartbetaling.
• Gebruik een trackbare QR-code als het doel meten is of een wisselende bestemming: verkeer naar een landingspagina sturen, een reviewlink, een menu, een boekingsformulier, of overal waar je een scanaantal, een uitsplitsing naar bron, of de mogelijkheid wilt om zonder herdrukken naar iets nieuws door te sturen.
• Gebruik allebei, op hetzelfde document, wanneer een factuur een optie "betalen per overschrijving" nodig heeft en een klant ook wil weten hoeveel ontvangers de factuur online openden, doorklikten naar een betaalportaal, of een gerelateerd aanbod bekeken. Ze bedienen verschillende regels op dezelfde PDF en concurreren nooit om dezelfde scan.
• Probeer niet één code beide taken te laten doen. Een code kan niet tegelijk een vaste IBAN-payload bevatten en doorsturen via een trackingserver; de EPC-standaard heeft geen veld voor een callback-URL, en een URL in de betalingsregel proppen levert alleen tekst op die een bank-app toont, geen link die hij opent.

Als een klant vraagt om "een QR-code die zowel betaalt als de scan bijhoudt," is het eerlijke antwoord dat zo'n enkele code onder de huidige EPC-standaard niet bestaat. De praktische oplossing is twee codes: de EPC-code voor de overschrijving, en een kleine trackbare code (of dezelfde die elders in de campagne wordt gebruikt) die linkt naar een online factuur of betaalstatuspagina waar je in plaats daarvan de betrokkenheid kunt meten.

Het fraudegevaar dat bureaus die klantfacturen verwerken moeten kennen

Omdat een EPC QR-code het IBAN rechtstreeks bevat en de meeste mensen rekeningnummers niet meer controleren voordat ze een overschrijving goedkeuren, is het een reëel fraudedoelwit geworden. Het Zwitserse National Cyber Security Centre heeft een patroon gedocumenteerd waarbij aanvallers een e-mailaccount compromitteren, een legitieme factuur onderscheppen, het IBAN vervangen en de QR-code opnieuw genereren zodat die klopt, en vervolgens de vervalste PDF opnieuw versturen vanaf het gekaapte adres. De vormgeving van de factuur ziet er identiek uit; alleen het rekeningnummer en de payload van de code zijn veranderd.

Een fysieke variant van hetzelfde idee, een frauduleuze QR-sticker rechtstreeks over een afgedrukte code plakken, is dezelfde techniek die wordt gebruikt tegen parkeermeters en laadpalen, en werkt net zo goed op een verstuurde factuur of een betalingsherinnering die op een deur is geplakt. Onze gids over QR-codebeveiliging voor bureaus behandelt de algemene verdediging voor afgedrukte codes; specifiek voor EPC-codes zijn de praktische aanvullingen:

1. Genereer nooit de EPC QR-code van een klant opnieuw op basis van een doorgestuurde e-mail zonder het IBAN telefonisch of via een kanaal buiten die e-mailthread te bevestigen.
2. Moedig klanten aan om na het scannen de naam van de begunstigde te controleren die hun bank-app toont, niet alleen het bedrag, want een naam die niet klopt is vaak het eerste zichtbare teken van een gewisseld IBAN.
3. Als je terugkerende facturen voor een klant beheert, houd het IBAN en de generatielogica dan in één beheerd systeem in plaats van individuele medewerkers ad hoc codes te laten genereren in verschillende tools.

Er een goed genereren en testen

Elke EPC069-12-generator heeft op zijn minst de naam van de begunstigde, het IBAN en de keuze voor versie 002 nodig. Al het overige is optioneel, maar een paar standaardinstellingen zijn het bewust instellen waard:

• Laat het bedragveld leeg bij terugkerende of variabele facturen, zodat de betaler zelf het juiste bedrag invoert; leg het bedrag alleen vast bij eenmalige verzoeken met één vast bedrag, zoals een vast lidmaatschapsbedrag.
• Gebruik de gestructureerde crediteurenreferentie (ISO 11649) als de boekhoudsoftware van de klant hier automatisch tegen kan afletten; anders is het ongestructureerde betalingsveld met het factuurnummer eenvoudiger en werkt het overal.
• Volg de eigen drukrichtlijnen van de standaard: een minimale fysieke afmeting van ongeveer 2 bij 2 centimeter, een drukresolutie van minstens 300 DPI, en een rustzone van minstens vier modules witruimte aan elke kant, dezelfde regel voor vrije marges die elke QR-code, getrackt of niet, betrouwbaar scanbaar houdt.
• Scan de definitieve code met twee of drie verschillende bank-apps voordat een oplage de deur uitgaat, niet met slechts één. De ondersteuning van optionele velden zoals BIC en gestructureerde referenties verschilt nog steeds licht per bank, en een code die in de ene app perfect wordt voorinvuld, kan in een andere app af en toe een veld leeg laten.

Niets hiervan vereist een marketing-QR-platform. Het vereist een EPC069-12-conforme generator (er bestaan verschillende gratis exemplaren) en dezelfde drukdiscipline die je op elke code zou toepassen die op papier terechtkomt.

Veelgestelde vragen

Wat is een EPC QR-code?

Het is een QR-code gebouwd volgens de EPC069-12-standaard van de European Payments Council, die de gegevens om een SEPA-overschrijving voor te vullen, naam begunstigde, IBAN, bedrag en referentie, rechtstreeks in de code codeert, zodat een bank-app deze kan lezen zonder een server te hoeven raadplegen.

Wat is een GiroCode?

GiroCode is de Duitse naam voor dezelfde EPC069-12-standaard. Oostenrijk noemt het Stuzza QR; België en Nederland noemen het doorgaans een EPC QR-code of SEPA QR-code. De onderliggende payload is identiek, ongeacht de regionale naam.

Is een GiroCode hetzelfde als een EPC QR-code?

Ja. GiroCode is een regionale merknaam voor de EPC069-12-payload, geen andere technische standaard.

Welke banken en landen ondersteunen het scannen van een EPC QR-code?

Bank-apps in Oostenrijk, België, Finland, Duitsland en Nederland waren vroege gebruikers, waarbij Finland en Duitsland het vanaf 2015 uitrolden en Nederland vanaf 2016. De meeste grote bank-apps in de eurozone, waaronder Sparkasse, ING, ABN AMRO, Rabobank, N26 en Bunq, ondersteunen tegenwoordig scan-to-pay vanuit een EPC QR-code, al kan de ondersteuning van optionele velden zoals BIC licht verschillen per bank.

Kun je scans van een EPC QR-code volgen?

Nee. De payload wordt lokaal verwerkt door de bank-app; scannen activeert nooit een HTTP-verzoek naar een server, dus er is niets wat een redirect-platform of analysetool kan loggen. Dit is een structurele eigenschap van de standaard, geen beperking van een specifieke generator.

Hoeveel data past er in een EPC QR-code?

De volledige payload heeft een maximum van 331 bytes zodra deze in UTF-8 is gecodeerd, verdeeld over elf vaste velden, waaronder een limiet van 70 tekens voor de naam van de begunstigde en een limiet van 140 tekens voor de betalingsinformatie.

Kan ik het bedrag op een EPC QR-code aanpassen nadat deze is afgedrukt?

Nee. Elk veld, inclusief het bedrag en de IBAN-checksum, ligt vast op het moment van genereren. Het bedrag wijzigen betekent een nieuwe code genereren en afdrukken; er is geen manier om de payload van een afgedrukte EPC-code achteraf aan te passen.

Is een EPC QR-code veilig tegen fraude?

De standaard zelf is niet het zwakke punt; het risico zit in een fraudeur die het IBAN in de factuur-PDF vervangt en een bijpassende code opnieuw genereert voordat hij deze opnieuw verstuurt, vaak vanaf een gecompromitteerd e-mailaccount. De naam van de begunstigde controleren die na het scannen wordt getoond, en IBAN's verifiëren via een kanaal buiten de oorspronkelijke e-mail, zijn de praktische verdedigingen.

Wat is het verschil tussen een EPC QR-code en een Swiss QR-bill?

Ze zien er vergelijkbaar uit en dienen hetzelfde doel, het voorinvullen van een bankoverschrijving, maar het zijn verschillende standaarden. De EPC QR-code volgt EPC069-12 voor SEPA-overschrijvingen binnen de eurozone; de Swiss QR-bill is een aparte nationale standaard voor overschrijvingen in Zwitserse franken, beheerd door SIX. Een generator die voor de ene standaard is gebouwd, produceert geen geldige code voor de andere.

Welk foutcorrectieniveau gebruiken EPC QR-codes?

Niveau M, vastgelegd door de standaard, waarmee de code nog werkt bij ongeveer 15 procent schade of afdekking voordat hij onleesbaar wordt.

Kunnen een EPC QR-code en een trackbare QR-code op dezelfde factuur staan?

Ja, en dat is vaak de juiste opzet: de EPC-code regelt de daadwerkelijke bankoverschrijving, terwijl een aparte trackbare code kan verwijzen naar een online factuur, een betaalstatuspagina of een gerelateerd aanbod, wat je scandata oplevert zonder de betaalpayload zelf aan te raken.

De korte versie

Een EPC QR-code, in Duitsland GiroCode genoemd en in Oostenrijk Stuzza QR, is een vaste EPC069-12-payload die een SEPA-bankoverschrijving rechtstreeks in een bank-app voorinvult. Er zit geen URL in, er wordt geen server aangeroepen, en daardoor kun je scans niet volgen of de code na het afdrukken aanpassen, in tegenstelling tot een dynamische QR-code. Behandel hem als een betaalinstrument, niet als een marketingkanaal: verifieer het IBAN via een tweede kanaal voordat je de code van een klant opnieuw genereert, laat het bedragveld leeg bij terugkerende facturen, test de definitieve code in meer dan één bank-app, en grijp naar een aparte trackbare code wanneer het eigenlijke doel meten is in plaats van betalen.