De elektronische kassabon reist verder dan de papieren variant. Hij gaat per e-mail naar de klant, komt in een klantsysteem terecht en blijft daar jaren staan. Requirement 3.3 verbiedt het bewaren van authenticatiegegevens na de autorisatie; onderdeel 3.3.2 laat zulke gegevens alleen in de fase daarvóór bestaan, en dan uitsluitend versleuteld. Een bonarchief zit per definitie ná die fase, dus daar hoort geen enkel authenticatieveld meer thuis. Het kaartnummer mag er hooguit afgeknot op staan, binnen de grens van Req. 3.4.1. De AVG voegt de opslagbeperking van art. 5 lid 1 sub e toe, terwijl AWR art. 52 alleen de kasadministratie zelf verlangt.
Wanneer dit van toepassing is
Een winkelketen mailt digitale bonnen naar klanten en bewaart een kopie in het klantsysteem. Uit een steekproef blijkt dat enkele bonnen nog een verificatiecode dragen. Het hele archief moet worden nagelopen en geschoond.
Hoe anonym.plus dit afhandelt
- Open het bonarchief of de mailexport in de toepassing op uw werkstation.
- De OCR leest bijgevoegde bonafbeeldingen en PDF-bijlagen lokaal uit.
- De herkenning markeert authenticatievelden, kaartnummers en klantgegevens.
- Controleer of elk resterend kaartnummer afgeknot is weergegeven.
- Laat kassanummer, artikelregels, bedrag en tijdstip ongemoeid.
- Sla het geschoonde archief lokaal op en vervang de oude kopie volgens beleid.
Wat u moet aanleveren
- Het bonarchief als PDF-map, mailexport, afbeeldingen of kassa-uitdraai.
- Een actie: weglakken, vervangen of gedeeltelijk maskeren.
- Optioneel: een lijst met velden die de kasadministratie nodig heeft.
Entiteitstypen die in financiele documenten worden gedetecteerd
| Categorie | anonym.plus-entiteitstype | Voorbeeld |
|---|---|---|
| Kaart | CREDIT_CARD | **** **** **** 1111 → blijft afgeknot |
| Verificatiecode | ID | CVC 412 → [VERWIJDERD] |
| Klant | PERSON | Tim de Boer → [KLANT] |
| Bonontvangst | EMAIL_ADDRESS | t.deboer@voorbeeld.nl → [E-MAIL] |
| Handelaar | ID | NL123456789B01 → blijft staan |
| Kassa | REFERENCE_NUMBER | Kassa 04 / bon 118273 → blijft staan |
Bereikte naleving
- Houdt het bonarchief vrij van authenticatiegegevens, die na de autorisatie onder PCI DSS v4.0 Req. 3.3.1 niet meer bewaard mogen worden.
- Erkent dat Req. 3.3.2 versleuteling alleen toestaat in de fase vóór autorisatie — een archief valt daar per definitie buiten.
- Laat resterende kaartnummers uitsluitend afgeknot staan, binnen de grens van Req. 3.4.1.
- Combineert de opslagbeperking van AVG art. 5 lid 1 sub e met de kasadministratie die AWR art. 52 zeven jaar verlangt.
Anonimiseer elektronische kassabonnen offline — bekijk abonnementen & begin gratis →
Beperkingen & aandachtspunten
Een e-bon leeft ook in verzonden mail en in back-ups van het klantsysteem. Neem die kopieën mee in de opschoning, anders blijft het oude veld ergens staan.
Veelgestelde vragen
Waarom mag een archief geen versleutelde authenticatiedata bevatten?
Omdat Req. 3.3.2 die uitzondering strikt beperkt tot de fase vóór de autorisatie. Daarna geldt het verbod uit 3.3.1 onverkort, ongeacht de toegepaste versleuteling.
Mag de klantenbon het volledige kaartnummer tonen?
Nee. Requirement 3.4.1 begrenst elke weergave tot het BIN en de laatste vier cijfers. Voor een klantenbon volstaan de laatste vier.
Wat blijft er over voor de Belastingdienst?
De kasadministratie: artikelregels, bedragen, btw-tarieven, tijdstip en bonnummer. AWR art. 52 vraagt die gegevens, geen kaartvelden.