ISO 20022-incassobestand maken: van spreadsheet naar pain.008

Het bestand zag er goed uit in Excel. De totalen klopten. De klantenlijst was al eerder gebruikt. En toch keurde het bankportaal de incassorun af, met een melding die voor een machine leek geschreven. Op dat moment ontdekken de meeste financiële teams dat een ISO 20022-incassobestand geen spreadsheet is die je onder een andere extensie opslaat.

Het lastige zit zelden in de betaallogica. Het zit in het omzetten van rommelige, mensvriendelijke gegevens naar strikte XML die de bank in één keer accepteert. In dit artikel lees je hoe je je brongegevens voorbereidt, je kolommen aan de juiste XML-tags koppelt, het bestand controleert en afkeurmeldingen oplost.

Van spreadsheetchaos naar een geldig pain.008-bestand

In veel mkb-teams staat de betaalinformatie op drie plekken: machtigingsdata in de ene spreadsheet, IBAN’s in een andere en bedragen in een export uit het boekhoudpakket. De dag voor het aanleveren voegt iemand alles samen, uploadt het bestand en is de rest van de middag bezig met uitzoeken waarom de bank het weigert.

Waarom de oude werkwijze breekt

Oudere betaalformaten, zoals ClieOp03 in Nederland, waren vlakke bestanden met soepelere controles. ISO 20022 werkt anders: het verwacht gestructureerde gegevens, exacte tags, consistente kenmerken en regels die over de hele batch kloppen. De implementatierichtlijnen van de European Payments Council leggen vast hoe dat eruit moet zien.

Spreadsheets verbergen structurele problemen. Een kolom “Klantref” bevat afhankelijk van wie hem het laatst bijwerkte een klantnummer, een machtigingskenmerk of een notitie. Excel vindt dat prima. XML niet.

Vuistregel: Moet iemand “gewoon weten” wat een kolom betekent, dan is je bestand nog niet klaar om om te zetten.

Wat een geldig bestand in de praktijk afdwingt

Een geldig SEPA-bestand dwingt duidelijkheid af: één vast machtigingskenmerk, één geldige incassodatum, één rekeningformaat, één volgordetype dat bij de incassohistorie past. Dat voelt in het begin streng, maar het haalt precies de onduidelijkheid weg die tot mislukte runs leidt. Waarom automatische incasso de moeite waard is, lees je in het artikel over de voordelen van automatische incasso.

Je brongegevens voorbereiden

De meeste problemen ontstaan vóórdat er XML aan te pas komt: in het bronbestand. Een bank verwerkt wat er in je bestand staat, niet wat je team bedoelde.

SEPA-incasso is sinds 2014 volledig operationeel en wordt in alle 36 SEPA-landen gebruikt. Die schaal is een reden waarom banken zo streng controleren: ze hebben voorspelbare, gestandaardiseerde invoer nodig.

De velden die je moet beheersen

Maak één schone tabel met één regel per incasso:

• Naam van de betaler, consequent gespeld.
• IBAN van de betaler, opgeslagen als tekst.
• Machtigingskenmerk, uniek per getekende machtiging.
• Datum van ondertekening, in één formaat.
• Bedrag, zonder valutateken.
• Incassodatum, in één formaat.
• End-to-end-kenmerk, voor afletteren en geschillen.
• Gegevens van de incassant, zoals incassant-ID en rekening, uit een vaste bron en niet per batch overgetypt.
• Volgordetype (eerste, terugkerend, laatste of eenmalig), als je die logica gebruikt.

Opschonen voorkomt onnodige afkeur

Probleem in de bron	Wat er later misgaat
Wisselende datumformaten	Ongeldige of inconsistente incassodata
Onzichtbare spaties in IBAN-velden	Controle faalt terwijl het IBAN er goed uitziet
Vrije tekst in gestructureerde kolommen	XML-tags krijgen waarden die de bank weigert
Dubbele regels na kopiëren en plakken	Klanten worden twee keer belast of totalen kloppen niet
Lege cellen uit formules	Verplichte XML-elementen blijven leeg
Speciale tekens uit andere systemen (ë, ö, &)	Het bestand of de verwerking bij de bank loopt vast

Kernpunt: Schone gegevens winnen van slimme koppelingen. Is je bronbestand onbetrouwbaar, dan is de XML gewoon een formelere versie van hetzelfde probleem.

Een bronbestand dat werkt

Een goed bronbestand is saai, en dat is precies de bedoeling:

1. Eén regel is één incasso. Geen subtotalen of notities in het gegevensbereik.
2. Eén betekenis per kolom. Geen kolommen die per batch iets anders bevatten.
3. Tekst blijft tekst. Zeker IBAN’s, machtigingskenmerken en kenmerken.
4. Geen samengevoegde cellen.
5. Alleen gecontroleerde exports. Zo min mogelijk overtypen.
6. Bewaar de invoerversie. Bij afkeur wil je precies weten welke gegevens het bestand opleverden.

Zet je regelmatig CSV-bestanden om, lees dan hoe je CSV omzet naar SEPA XML.

Spreadsheetkolommen koppelen aan SEPA XML-tags

Een spreadsheet is plat, een SEPA XML-bestand is hiërarchisch. Je hernoemt niet alleen kolommen: je zet elke waarde in de juiste laag van het document. Een ISO 20022-incassobestand heeft drie niveaus: GroupHeader, PaymentInformation en DirectDebitTransactionInformation.

Denk in kast, laden en mappen

• Het bestand is de hele archiefkast.
• De betaalgroep is een la met incasso’s die dezelfde instellingen delen.
• Elke transactie is een map voor één betaler.

Wie spreadsheetregels zonder dat model in de XML zet, haalt batch- en transactiegegevens door elkaar. Dat is een veelvoorkomende reden waarom handgemaakte bestanden falen.

Wat hoort op welk niveau

Brongegeven	XML-niveau	Doel
Bestandskenmerk	GroupHeader	Identificeert de batch
Aanmaaktijdstip	GroupHeader	Wanneer het bestand is gemaakt
Aantal transacties	GroupHeader	Controle van de batch
Controletotaal	GroupHeader	Somcontrole
Incassodatum	PaymentInformation	Gedeelde datum voor een groep
Naam incassant	PaymentInformation	Wie incasseert
Incassant-ID	PaymentInformation	Machtigt de incassant binnen het schema
Rekening incassant	PaymentInformation	Rekening waarop wordt bijgeschreven
Local instrument	PaymentInformation	Core of B2B
Machtigingskenmerk	DirectDebitTransactionInformation	Koppelt de incasso aan de toestemming
Datum ondertekening	DirectDebitTransactionInformation	Historie van de machtiging
Naam betaler	DirectDebitTransactionInformation	Identificeert de betaler
IBAN betaler	DirectDebitTransactionInformation	Rekening van de betaler
End-to-end-ID	DirectDebitTransactionInformation	Kenmerk voor afletteren
Bedrag	DirectDebitTransactionInformation	Bedrag per incasso
Volgordetype	PaymentInformation (groepering)	Eerste, terugkerend, laatste of eenmalig

Een vereenvoudigd voorbeeld

<Document>
  <CstmrDrctDbtInitn>
    <GrpHdr>
      <MsgId>BATCH-2026-04-001</MsgId>
      <CreDtTm>2026-04-10T09:30:00</CreDtTm>
      <NbOfTxs>2</NbOfTxs>
    </GrpHdr>
    <PmtInf>
      <PmtInfId>INC-APR-001</PmtInfId>
      <ReqdColltnDt>2026-04-15</ReqdColltnDt>
      <DrctDbtTxInf>
        <PmtId>
          <EndToEndId>FAC1001</EndToEndId>
        </PmtId>
        <MndtRltdInf>
          <MndtId>MACHT0001</MndtId>
        </MndtRltdInf>
        <DbtrAcct>
          <Id>
            <IBAN>NL...</IBAN>
          </Id>
        </DbtrAcct>
      </DrctDbtTxInf>
    </PmtInf>
  </CstmrDrctDbtInitn>
</Document>

Daarom heb je een koppellaag nodig: één platte regel bevat waarden voor alle drie de niveaus.

De koppelfouten die ertoe doen

Batchvelden die per regel verschillen. Verschilt de naam van de incassant, de incassodatum of de incassant-ID tussen regels die in één groep horen, dan moet een converter de batch splitsen of afkeuren. Bij handwerk zie je dat pas bij het aanleveren.

Interne labels als betaalkenmerk. Een CRM-sleutel in EndToEndId wordt misschien geaccepteerd, maar bij storneringen en vragen herkent niemand het kenmerk.

Eén spreadsheet voor alles. Hetzelfde werkblad voor incasso’s, afboekingen en klantnotities werkt voor de administratie, niet voor betaalbestanden. Gebruik een vaste export of een apart werkblad.

Vuistregel: Wat een veld betekent, telt meer dan of het er staat. Alle kolommen hebben is niet genoeg als ze de verkeerde inhoud dragen.

Meldt de bank een probleem met ReqdColltnDt, MndtId of EndToEndId, dan helpt het als je team weet welk bedrijfsgegeven het moet nalopen. Draai je maandelijks dezelfde runs, sla dan een geteste koppeling op en gebruik die opnieuw. Hoe dat in een speciale tool werkt, lees je in het artikel over de pain.008-generator.

Controleren vóór je aanlevert

Een gegenereerd XML-bestand kan fout zijn op manieren die je op het scherm niet ziet. Controleer daarom op twee niveaus: is het bestand technisch correct, en kloppen de opdrachten inhoudelijk?

Technische controle

Je controleert of de XML goed is opgebouwd en aan het schema voldoet. Een bestand faalt technisch als:

• verplichte tags ontbreken, bijvoorbeeld een leeg rekeningblok;
• elementen op de verkeerde plek staan, zoals een transactiewaarde in de batchsectie;
• formaten ongeldig zijn, bij datums, kenmerken of rekeningen;
• de XML kapot is, door ontbrekende afsluittags of ongeldige tekens.

Dat leidt meestal tot directe afkeur.

Inhoudelijke controle

Een technisch geldig bestand kan inhoudelijk fout zijn. Controleer:

• Machtigingsgegevens compleet: kenmerk en datum kloppen.
• Incassodata logisch: passend bij je aanlevermoment en de termijnen van je bank.
• Volgordetype past bij de machtiging: eerste, terugkerende en eenmalige incasso’s zijn niet uitwisselbaar.
• Headertotalen kloppen met de transacties.
• Kenmerken zijn uniek waar dat moet.

Kernpunt: Een bestand dat er in een teksteditor goed uitziet, kan in alles wat voor de bank telt fout zijn.

Een vaste routine vóór het uploaden

1. Bevries het bronbestand zodra de batch is goedgekeurd.
2. Genereer de XML alleen uit die bevroren versie.
3. Controleer tegen het schema, met je tool of de SEPA-incasso XML-validator.
4. Vergelijk een steekproef van regels met de XML.
5. Controleer aantallen, totalen en data op batchniveau.
6. Bewaar bron- en XML-bestand samen voor controle en foutzoeken.

Afkeurmeldingen van de bank oplossen

Afkeurmeldingen zijn kort omdat ze voor systemen zijn geschreven. Vertaal elke melding naar één vraag: welk brongegeven of XML-veld veroorzaakte dit, en wat moet er precies worden aangepast?

Melding	Meestal betekent het	Wat je aanpast
Ongeldig IBAN	Rekening onvolledig of vervuild met onzichtbare tekens	Bronveld nalopen, spaties weghalen, als tekst opslaan, controleren en opnieuw genereren
Ongeldige incassodatum	Geen bankwerkdag of in strijd met de termijnen	Datum verplaatsen naar een geldige werkdag en opnieuw maken
Dubbel MsgId	Batchkenmerk is al eerder gebruikt	Nieuw, uniek bestandskenmerk
Volgordetype geweigerd	Terugkerend waar de bank eerste verwachtte, of andersom	Machtigingshistorie nalopen en volgordetype corrigeren
Aantal in header klopt niet	De header noemt een ander aantal dan er in het bestand staat	Controletotalen opnieuw berekenen uit de definitieve gegevens
Machtigingskenmerk ontbreekt	Transactie zonder geldig kenmerk	Bronveld vullen en koppeling naar de juiste tag controleren

De oplossing zit meestal stroomopwaarts

Pas bij een ongeldig IBAN niet de XML aan, maar de klantgegevens of het bronbestand. Anders faalt de volgende batch om dezelfde reden. Is het MsgId dubbel, dan zit het probleem in je proces: iemand hergebruikt een bestandsnaam of een oud sjabloon.

Twee patronen om op te letten: volgordefouten na een migratie, waarbij de machtigingshistorie verloren ging, en headerproblemen na handmatige aanpassingen, waarbij iemand regels verwijderde terwijl totalen al waren berekend. Behandel een SEPA XML-bestand nooit als een document dat je even met de hand aanpast, maar als output van een gecontroleerde gegevensset.

Je ISO 20022-bestanden automatisch maken met GenerateSEPA

De maand sluit, finance heeft de incasso’s goedgekeurd en iemand moet nog een spreadsheet omzetten naar een bankklaar XML-bestand zonder totalen, machtigingen of kenmerken te breken. Op dat moment wordt handwerk een operationeel risico.

Automatisering haalt de terugkerende beslissingen weg die later tot afkeur leiden:

• Herbruikbare koppelingen: één keer instellen welke kolom bij welke tag hoort.
• Normaliseren: datums, bedragen en tekst in het formaat dat de XML verwacht.
• Controle vóór export: ontbrekende machtigingskenmerken en foute IBAN’s vang je vóór het uploaden.
• Verschillende bronformaten: Excel, CSV en JSON.
• Voorspelbare output: dezelfde invoer levert altijd dezelfde XML-structuur.

Wat je team nodig heeft	Handmatig	Via een API
Invoer	Bestanden exporteren en opschonen	Gestructureerde gegevens direct uit je systeem
Koppeling	In spreadsheets of lokale sjablonen	Centraal in je applicatie of opgeslagen profielen
Controle	Mensen plus bankportaal	Automatisch vóór het aanleveren
Audittrail	Verspreid over mappen en mails	Vastgelegd in logs en historie

Finance uploadt het bronbestand, koppelt de kolommen en downloadt het pain.008-bestand; technische teams sturen dezelfde gegevens via de API. Probeer GenerateSEPA 7 dagen gratis met je eigen Excel- of CSV-bestand.

---

Veelgestelde vragen

Wat is een ISO 20022-incassobestand?

Het is een gestructureerd XML-bestand waarmee je een batch incasso-opdrachten naar je bank stuurt. Het volgt het pain.008-bericht uit de ISO 20022-standaard, met een vaste hiërarchie van groepsheader, betaalinformatie en losse transacties. Banken in de SEPA-zone eisen dit formaat voor incasso's.

Waarom keurt mijn bank mijn incassobestand steeds af?

Veelvoorkomende oorzaken zijn ongeldige IBAN's, wisselende datumformaten, een dubbel bestandskenmerk (MsgId) en een verkeerd volgordetype. Ook onzichtbare tekens uit spreadsheets of vrije tekst in gestructureerde velden leiden tot afkeur. Brongegevens opschonen en het bestand vooraf controleren voorkomt het meeste.

Hoe koppel je spreadsheetkolommen aan SEPA XML-tags?

SEPA XML heeft drie niveaus: GrpHdr voor batchgegevens, PmtInf voor gedeelde incasso-instellingen en DrctDbtTxInf voor de gegevens per betaler. Elke kolom hoort bij één niveau. Je incassant-ID en rekening horen bij PmtInf, machtigingskenmerk en IBAN van de betaler bij de transactie.

Kun je ISO 20022-bestanden automatisch maken vanuit Excel of CSV?

Ja. Met GenerateSEPA upload je Excel, CSV of JSON en koppel je de kolommen eenmalig aan de SEPA-velden; die koppeling wordt onthouden. IBAN's worden vóór het maken van het bestand gecontroleerd. Wil je het in je eigen systeem inbouwen, dan kan dat via de API.

---

Gerelateerde artikelen