Betalingskenmerk: zo gebruik je het goed in SEPA-betalingen

Je opent na een betaalrun het bankafschrift en ziet een rij transacties met vage omschrijvingen. “Betaling.” “Overboeking.” Soms alleen een afgekapte leveranciersnaam. Het geld is verplaatst, maar het boekhoudwerk niet. Iemand moet nog uitzoeken welke factuur is betaald, welke debiteur kan worden afgeletterd en of de referentie op het afschrift dezelfde is als die in je spreadsheet stond.

In dat gat zit de meeste frictie bij het afletteren. Voor mkb-bedrijven die vanuit Excel of CSV werken, is het probleem zelden de betaling zelf, maar de referentie. Is het betalingskenmerk leeg, inconsistent of in het verkeerde SEPA XML-veld gezet, dan komt de betaling wel aan, maar loopt de verwerking erna vast. In dit artikel lees je wat een betalingskenmerk is, hoe het verschilt van de omschrijving en het EndToEndId, waar je het vindt en hoe je het goed in je betaalbestand zet.

Wat is een betalingskenmerk?

Een betalingskenmerk is een referentie die een betaling koppelt aan het juiste document: een factuur, een aanslag of een klantrekening. In Nederland bestaan er twee smaken:

• Het gestructureerde betalingskenmerk: een vaste cijferreeks met een controlecijfer, zoals de Belastingdienst, energiebedrijven en verzekeraars die op hun facturen zetten. Het wordt automatisch verwerkt; de ontvanger letterd af zonder iemand te laten meekijken. Het betalingskenmerk van de Belastingdienst bestaat bijvoorbeeld uit 16 cijfers, die je zonder spaties invult.
• De omschrijving: vrije tekst, meestal een factuurnummer of klantnummer, die de ontvanger leest of door zijn boekhoudpakket laat herkennen.

In internetbankieren zie je dat terug als keuze: je vult óf een betalingskenmerk óf een omschrijving in, niet allebei. Vraagt een ontvanger om een betalingskenmerk, gebruik dan dat veld; zet je het als omschrijving in, dan kan de automatische verwerking aan de andere kant mislukken.

Een referentie is geen notitie, maar onderdeel van je beheersing. Ze laat je boekhoudpakket of bankimport het ene geldbedrag van het andere onderscheiden zonder dat iemand elke regel leest. Betalen twee klanten op dezelfde dag een vergelijkbaar bedrag, dan is de referentie vaak het enige betrouwbare aanknopingspunt.

Vuistregel: kun je een betaling niet afletteren op basis van referentie en bedrag samen, dan doet de referentie te weinig.

Betalingskenmerk, omschrijving en EndToEndId: de verschillen

Zie een betaling als een pakket. Het EndToEndId is het trackingnummer dat het pakket door de hele keten volgt. De remittance information (betalingskenmerk of omschrijving) is het briefje in het pakket dat de ontvanger vertelt waarvoor de betaling is. Haal je die door elkaar, dan komt het geld wel aan, maar mist de ontvanger de informatie om het te verwerken.

Soort referentie	Wat het doet	In SEPA XML
EndToEndId	Identificeert één betaalopdracht door de hele SEPA-keten	<PmtId><EndToEndId>
Omschrijving (ongestructureerd)	Vrije tekst met zakelijke context, zoals factuurnummer	<RmtInf><Ustrd>
Betalingskenmerk (gestructureerd)	Vaste code met controlecijfer voor automatische verwerking	<RmtInf><Strd>, met type SCOR en uitgever CUR
Machtigingskenmerk	Koppelt een incasso aan de getekende machtiging	<MndtId> in pain.008

Het EndToEndId is bedoeld als uniek kenmerk per betaling dat stabiel blijft, zodat je de betaling later kunt opsporen. Meer uitleg vind je in de woordenlijst over het EndToEndId. Het betalingskenmerk of de omschrijving draagt de zakelijke betekenis. Vraagt een leverancier “vermeld factuurnummer 45678”, dan hoort dat in de remittance information, niet als jouw interne trackingcode.

Bij incasso’s speelt nog een derde referentie: het machtigingskenmerk, dat elke afschrijving aan een getekende machtiging koppelt. Dat heeft een andere rol dan de omschrijving; zie de SEPA-incassoreferentie.

Kernpunt: een betaling kan volledig traceerbaar zijn en toch lastig af te letteren. Dat gebeurt als het EndToEndId gevuld is, maar de omschrijving niet de referentie bevat die de ontvanger verwacht.

Waar vind je het juiste betalingskenmerk?

De meeste referentieproblemen beginnen vóór het XML-bestand bestaat: iemand kopieerde het verkeerde veld.

Op een inkoopfactuur zoek je in deze volgorde:

1. Een expliciet betalingskenmerk (“vermeld bij betaling”): altijd gebruiken, in het daarvoor bedoelde veld.
2. Het factuurnummer, als er geen apart kenmerk is.
3. Een klant- of contractnummer, gebruikelijk bij energie, telecom en lease.

Betaal je meerdere facturen tegelijk, gebruik dan een compacte verzamelreferentie en stuur de specificatie apart als je proces dat ondersteunt. Vervang een gevraagde externe referentie nooit door een intern label dat alleen jouw bedrijf begrijpt.

Bij inkomende betalingen verschijnt de referentie per kanaal anders: in internetbankieren als omschrijving of kenmerk, in een export soms verdeeld over meerdere velden, in je boekhoudpakket als memo of beschrijving. Leg daarom drie weergaven van dezelfde transactie naast elkaar: de oorspronkelijke factuur, de transactie in internetbankieren en het afletterscherm in je pakket. Zo zie je welk veld de reis overleeft.

Vuistregel: kan je team dezelfde referentie niet aanwijzen op de factuur, bij de bank én in het grootboek, dan heb je nog een koppelprobleem.

Het betalingskenmerk goed in je SEPA-bestand zetten

Een referentie helpt pas als de waarde uit je spreadsheet in het juiste XML-veld belandt. Richt je bronbestand zo in dat elke regel drie vragen beantwoordt: wie krijgt geld, hoeveel, en welke referentie reist mee? Gebruik aparte kolommen voor leveranciersnaam, IBAN, bedrag, factuurnummer, betalingskenmerk van de leverancier en intern betalings-ID. Ook als waarden overlappen, houd ze gescheiden; dat geeft je keuze bij het koppelen.

De belangrijkste regel:

• Je interne, unieke betalings-ID gaat naar EndToEndId.
• De referentie voor de leverancier (factuurnummer of omschrijving) gaat naar RmtInf/Ustrd; een gestructureerd betalingskenmerk hoort in RmtInf/Strd.

Kolom in Excel	SEPA-veld	Doel
Intern betalings-ID	EndToEndId	Unieke traceerbaarheid van de opdracht
Factuurnummer leverancier	RmtInf/Ustrd	Vertelt de ontvanger welke factuur je betaalt
Betalingskenmerk (16 cijfers)	RmtInf/Strd	Automatische verwerking bij de ontvanger
Klantnummer bij leverancier	RmtInf/Ustrd indien nodig	Extra onderscheid als factuurnummer niet volstaat
Batch-ID	Niet voor de ontvanger	Interne controle, geen vervanging van de omschrijving

De fout die je het vaakst ziet: één kolom “Referentie” overal aan koppelen omdat de naam goed klinkt. Eén kolomnaam kan twee betekenissen verbergen: een interne betaalsleutel en een referentie voor de leverancier.

Een voorbeeld

Leverancier	IBAN	Bedrag	Intern betalings-ID	Factuurreferentie
Leverancier B.V.	NL00EXAMPLEIBAN	€ 250,00	PAY-2025-0001	INV-987

<CdtTrfTxInf>
  <PmtId>
    <EndToEndId>PAY-2025-0001</EndToEndId>
  </PmtId>
  <Amt>
    <InstdAmt Ccy="EUR">250.00</InstdAmt>
  </Amt>
  <Cdtr>
    <Nm>Leverancier B.V.</Nm>
  </Cdtr>
  <CdtrAcct>
    <Id>
      <IBAN>NL00EXAMPLEIBAN</IBAN>
    </Id>
  </CdtrAcct>
  <RmtInf>
    <Ustrd>INV-987</Ustrd>
  </RmtInf>
</CdtTrfTxInf>

EndToEndId draagt de identiteit van de betaling; daarop zoek je later als de bank, de leverancier of de accountant vragen stelt. Ustrd draagt de zakelijke referentie die de leverancier nodig heeft om de factuur af te letteren. Verwissel je ze, dan wordt het bestand misschien gewoon geaccepteerd, maar ziet de leverancier PAY-2025-0001 in plaats van INV-987.

Met GenerateSEPA zet je Excel-, CSV- of JSON-bestanden om naar SEPA XML en koppel je vóór de export elke kolom aan het juiste SEPA-veld. Zo blijven referenties consistent voordat het bestand naar de bank gaat. Zie ook CSV omzetten naar SEPA XML en, voor incasso’s, een voorbeeld van een pain.008-bestand.

Veelgemaakte fouten met betalingskenmerken

Veel teams denken dat referentieproblemen klein zijn omdat de bank het bestand toch accepteert. Dat is de verkeerde toets. De echte toets is of de betaling na verwerking correct af te letteren is.

Fout	Gevolg	Betere aanpak
Algemene tekst als “betaling”	Handmatig afletteren en vragen van de ontvanger	Factuurnummer of gevraagd betalingskenmerk gebruiken
Heel lange referenties	Afgekapt op afschrift of onderweg	Alleen de minimale onderscheidende gegevens
Eén referentie voor veel betalingen	Onduidelijk audittrail	Elke betaalopdracht uniek identificeerbaar maken
Interne codes naar de leverancier	Leverancier kan het geld niet toewijzen	De externe referentie sturen die de leverancier verwacht
Betalingskenmerk als omschrijving ingevuld	Automatische verwerking bij de ontvanger mislukt	Gestructureerd kenmerk in het kenmerkveld (Strd)

Houd referenties kort, uniek genoeg voor de situatie en stabiel over systemen heen. Vermijd leestekens, regeleinden en spaties die uit spreadsheets meekomen. Korter en duidelijker wint meestal van langer en “informatiever”: de extra woorden worden als eerste afgekapt. Weet je niet zeker of het bestand klopt, controleer het dan vóór de upload; zie SEPA-bestanden valideren.

Checklist voor referenties in je betaalbestanden

Stap	Wat je doet	Wanneer
1. Bronbestand inrichten	Aparte kolommen voor intern ID, factuurnummer en betalingskenmerk	Eenmalig
2. Volgorde vastleggen	Gevraagd betalingskenmerk, anders factuurnummer, anders klantnummer	Bij elke factuur
3. Koppelen	Intern ID naar EndToEndId, referentie naar RmtInf	Bij elke export
4. Kort houden	Geen zinnen, geen overbodige tekens	Bij invoer
5. Valideren	Bestand controleren vóór de upload	Elke batch
6. Nalopen	Factuur, bank en grootboek naast elkaar leggen bij afwijkingen	Maandelijks

Is het bronbestand schoon, dan voelt SEPA XML niet langer technisch: het wordt een beheerste vertaling van spreadsheetkolommen naar velden die de bank begrijpt. Zet je volgende betaalbestand om met de juiste koppeling en probeer GenerateSEPA 7 dagen gratis.

---

Veelgestelde vragen

Wat is het verschil tussen een betalingskenmerk en een omschrijving?

Een betalingskenmerk is een gestructureerde cijferreeks met een controlecijfer die de ontvanger automatisch verwerkt, zoals bij de Belastingdienst. Een omschrijving is vrije tekst, bijvoorbeeld een factuurnummer. In internetbankieren kies je één van beide; vraagt de ontvanger om een betalingskenmerk, gebruik dan dat veld.

Wat is het verschil tussen het EndToEndId en het betalingskenmerk?

Het EndToEndId is het trackingnummer van de betaling en volgt de opdracht door de hele SEPA-keten. Het betalingskenmerk of de omschrijving vertelt de ontvanger waarvoor de betaling is. Het ene dient de traceerbaarheid, het andere het afletteren, dus haal ze niet door elkaar.

Welke kolom koppel ik aan EndToEndId?

Koppel je interne, unieke betalings-ID aan EndToEndId en de referentie voor de leverancier, meestal het factuurnummer, aan de remittance information. Eén betaling kan meerdere facturen of een creditnota dekken, dus het interne ID moet uniek blijven. De bekendste fout is één kolom Referentie aan alle velden koppelen.

Kan een verkeerd betalingskenmerk een betaling laten mislukken?

Meestal accepteert de bank het bestand en komt het geld aan. Maar een vaag, dubbel of afgekapt kenmerk zorgt ervoor dat de ontvanger de betaling niet automatisch kan verwerken. Dat leidt tot handmatig afletteren en vragen achteraf, ook al is het geld gewoon overgemaakt.

---

Gerelateerde artikelen