SEPA XML-bestand maken vanuit een spreadsheet (2026)

Betaalruns aan het eind van de maand gaan nog steeds op heel gewone manieren mis. Een financieel medewerker exporteert een spreadsheet, schoont een paar kolommen op, kopieert rekeninggegevens van het ene blad naar het andere en merkt dan dat het bankportaal een SEPA XML-upload wil in plaats van het bestand dat klaarstaat. Het resultaat: herstelwerk, de knagende angst voor verborgen fouten en een batch die niemand met vertrouwen durft te versturen.

Een SEPA XML-bestand maken met een goede tool lost dat op. Een rommelig spreadsheetproces wordt een vaste workflow die aansluit op wat banken eisen. Voor het mkb gaat het daarbij niet om XML als techniek, maar om het voorkomen dat een mislukt bestand salarissen, leveranciersbetalingen of incasso’s op het slechtste moment ophoudt.

Van spreadsheetchaos naar een helder SEPA-bestand

De teams die het meest worstelen zijn niet slordig, maar overbelast. Ze hebben een redelijke spreadsheet, een naderende uiterste aanlevertijd en geen zin om XML-tags met de hand te bouwen of afkeurmeldingen te ontcijferen.

Met de verplichte overstap op SEPA-overboekingen en SEPA-incasso’s onder EU-verordening 260/2012 werd ISO 20022 XML de standaard. Oude nationale formaten zoals ClieOp03 verdwenen. Sindsdien moet elk batchbestand aan die standaard voldoen.

Een goede tool doet drie dingen:

• Gestructureerde brongegevens omzetten uit Excel, CSV of JSON naar geldige SEPA XML.
• Overtypen beperken, zodat dezelfde betaalgegevens niet in meerdere systemen worden ingevoerd.
• De workflow herhaalbaar maken, zodat de maandafsluiting niet afhangt van die ene collega die de regels kent.

Vuistregel: Ben je vóór elke upload “nog even het bestand aan het opschonen”, dan ligt het probleem niet bij XML maar bij het proces dat de XML voedt.

Je brongegevens voorbereiden

De meeste problemen ontstaan in het bronbestand. Is de spreadsheet inconsistent, dan is de output dat ook.

Eén standaard per soort veld

• Datums: één notatie in het hele bestand.
• Bedragen: in de XML staat een punt als decimaalteken. Nederlandse Excel toont een komma; laat je tool dat omzetten en gebruik geen duizendtalscheidingstekens in de bron.
• Namen en adressen: geen vreemde symbolen, verborgen regeleinden of tekens uit e-mails en pdf’s. Let op &, trema’s en accenten.
• Kenmerken: kort, duidelijk en consequent.
• IBAN’s: als tekst opgeslagen, zodat Excel niets afkapt of herformatteert. Controleer ze vooraf met de IBAN-validator.

Bouw de spreadsheet om te koppelen, niet om te lezen

1. Eén regel per betaling.
2. Eén kolom per gegeven.
3. Geen samengevoegde cellen, subtotalen, kleurcodes of opmerkingen in het uploadblad.
4. Interne notities apart van de betaalgegevens.
5. Naam, rekening en factuurnotities niet in één cel.

Kernpunt: Het bestand dat het makkelijkst te lezen is, is zelden het bestand dat het makkelijkst goed om te zetten is.

Spreadsheetvelden en SEPA XML-tags

Kolom	SEPA XML-tag	Omschrijving en voorbeeld
Factuurnummer	EndToEndId	Kenmerk per transactie, bijv. het factuurnummer van de leverancier
Naam begunstigde	Cdtr/Nm	Naam van de ontvanger, bijv. “Kantoorartikelen De Vries BV”
Rekeningnummer	CdtrAcct/Id/IBAN	IBAN van de ontvanger
Bankcode	CdtrAgt/FinInstnId/BIC	BIC van de bank van de ontvanger, alleen als dat nodig is
Bedrag	InstdAmt	Bedrag in euro, bijv. 1250.50
Uitvoeringsdatum	ReqdExctnDt	Gewenste verwerkingsdatum van de batch
Naam opdrachtgever	Dbtr/Nm	Je bedrijfsnaam zoals bekend bij de bank
Omschrijving	RmtInf/Ustrd	Vrije tekst, bijv. factuurnummer of omschrijving

Controle vóór het uploaden

• Kolomnamen: duidelijk. “IBAN begunstigde” is beter dan “Bankveld 2”.
• Geen dubbele regels: een dubbele leveranciersregel wordt een dubbele betaling.
• Tekencodering: vreemde tekens komen meestal uit gekopieerde gegevens, niet uit de tool.
• Eigen gegevens: naam en rekening van je bedrijf kloppen met je bankinstellingen.
• Testbestanden apart: geen proefregels tussen echte transacties.

Je eerste SEPA-bestand maken, stap voor stap

Bestand uploaden en soort betaling kiezen

Upload je Excel of CSV en kies eerst het soort bestand: een overboekingsbestand (pain.001) en een incassobestand (pain.008) zijn niet uitwisselbaar. Houd salarissen en leveranciers bij voorkeur in aparte batches; dat is makkelijker te controleren en uit te leggen.

Elk verplicht veld bewust koppelen

Hier haasten veel gebruikers zich. Doe dat niet. Controleer altijd:

• je eigen rekeninggegevens;
• namen van de begunstigden;
• IBAN- en bankvelden;
• bedragen;
• uitvoeringsdatum;
• omschrijving.

Lijkt een veld optioneel, kijk dan of je bank het in de praktijk toch nodig heeft. Sommige banken zijn strenger dan het schema.

MsgId en CreDtTm goed zetten

MsgId is het kenmerk van het bestand: uniek en niet langer dan toegestaan (35 tekens). CreDtTm is het aanmaaktijdstip in ISO 8601-formaat. Een dubbel MsgId en een tijdstip in de toekomst zijn bekende oorzaken van afkeur.

Een praktisch patroon voor MsgId: bedrijfscode, soort betaling, datum en volgnummer, bijvoorbeeld ACME-SCT-20260415-001. Hergebruik nooit oude kenmerken uit eerdere uploads of tests.

Controleren vóór het exporteren

Goede tools controleren de structuur voordat ze de XML maken: ontbrekende gegevens, te lange velden en fouten in rekeningnummers. GenerateSEPA leest Excel, CSV en JSON in, koppelt ze aan SEPA XML en controleert onderweg. Het gaat niet om het merk, maar om een tool die je bestand controleert vóór je bank dat doet.

Vuistregel: Een afkeur van de bank is de traagste en duurste plek om te ontdekken dat je bronbestand fout was.

Exporteren en een spoor bewaren

1. Download het bestand met een duidelijke interne naam.
2. Bewaar de bronspreadsheet bij de XML.
3. Leg vast wie het voorbereidde, wie het goedkeurde en wanneer het werd aangeleverd.
4. Bewaar eventuele controlerapporten.

Automatiseren met een API-koppeling

Handmatig uploaden werkt voor veel mkb-bedrijven. Het wordt lastig als betalingen frequent zijn, over meerdere bv’s lopen of sterk aan je ERP hangen. Dan wordt een API een operationele verbetering.

Het grootste voordeel is consistentie. Een API dwingt vaste gegevensafspraken af: je ERP levert gedefinieerde velden, de dienst controleert ze en de XML wordt elke keer op dezelfde manier gemaakt. Een API loont bij:

• terugkerende runs: salarissen, leveranciers, incasso’s;
• meerdere bronsystemen: ERP, CRM, abonnementsplatform;
• goedkeuring vooraf: betalingen worden in een intern systeem gefiatteerd;
• technisch eigenaarschap: een ontwikkelaar of partner kan de koppeling onderhouden.

Een voorbeeldverzoek

{
  "message_id": "ACME-SCT-20260415-001",
  "creation_datetime": "2026-04-15T07:00:00",
  "debtor_name": "Acme BV",
  "debtor_iban": "NL00BANK0123456789",
  "execution_date": "2026-04-16",
  "payments": [
    {
      "end_to_end_id": "FAC-1001",
      "creditor_name": "Leverancier Een BV",
      "creditor_iban": "NL00BANK9876543210",
      "amount": "1250.50",
      "remittance_information": "Factuur 1001"
    }
  ]
}

De veldnamen verschillen per aanbieder; het patroon is hetzelfde. Zo ontstaat het bestand uit goedgekeurde records in plaats van uit een handmatig bijgehouden spreadsheet.

Wat niet werkt: slechte brongegevens automatiseren. Zijn je leveranciersgegevens inconsistent, dan levert een API alleen sneller consistente rommel. Eerst de stamgegevens op orde, dan automatiseren.

Oude exportformaten en veelvoorkomende fouten

Niet elk bedrijf heeft een modern financieel pakket. Een systeem vervangen alleen om bankbestanden te maken is vaak onrealistisch. De praktische route: houd het pakket dat je bedrijf draaiende houdt, exporteer naar Excel of CSV en zet die export om met een tool die vóór het aanleveren controleert.

Probleem	Wat het meestal betekent	Snelle oplossing
Ongeldige XML-structuur	Een verplicht element ontbreekt of staat verkeerd	Opnieuw controleren in de tool en verplichte koppelingen nalopen
IBAN niet gevonden	Rekeningveld leeg, onvolledig of verkeerd opgemaakt	Brongegevens nalopen en IBAN’s vooraf valideren
Dubbel transactiekenmerk	Een kenmerk of bestands-ID is al eerder gebruikt	Nieuw uniek kenmerk en nieuw bestands-ID
Totaal klopt niet	Bedragen sluiten niet aan op het controletotaal	Totalen opnieuw berekenen en het bestand opnieuw maken
Uitvoeringsdatum geweigerd	Geen bankwerkdag of verkeerd opgemaakt	Geldige werkdag kiezen, één datumformaat

Pas bij afkeur niet de XML zelf aan, tenzij het niet anders kan. Herstel de brongegevens of de koppeling en maak het bestand opnieuw. Anders zegt de spreadsheet het ene, de geüploade XML het andere, en weet niemand welk bestand het officiële is.

Beveiliging en je laatste controle

Betaalbestanden bevatten gevoelige gegevens. Let bij een cloudtool op:

• versleutelde overdracht;
• beperkte bewaartermijn van geüploade bestanden;
• geen lokale installaties die per werkplek verouderen;
• duidelijke toegangsrechten voor voorbereiden, controleren en aanleveren;
• controle vóór het aanleveren.

Checklist vóór het uploaden

Stap	Wat je controleert
1. Rekening	De juiste rekening van je bedrijf voor deze batch
2. Uitvoeringsdatum	Past bij je betaalplanning en is een bankwerkdag
3. Kenmerken	Duidelijk en uniek, ook het MsgId
4. Rekeninggegevens	Alle IBAN’s gevalideerd
5. Totalen	Kloppen met je goedkeuring of betaallijst
6. Archief	Bron- en XML-bestand samen bewaard
7. Laatste validatie	Bestand nog één keer gecontroleerd, zie een SEPA-bestand valideren

Stel je betaalbatches nog met de hand samen? Probeer GenerateSEPA 7 dagen gratis en maak je eerste SEPA-bestand uit je eigen Excel of CSV.

---

Veelgestelde vragen

Heb je een tool nodig om een SEPA-bestand te maken als je bank een invoerscherm heeft?

Niet altijd. Maar handmatig invoeren in je internetbankieren wordt traag en foutgevoelig zodra je regelmatig leveranciers, salarissen of incasso's in batches verwerkt. Een tool loont als je herhaalbaarheid, een audittrail en minder overtypwerk wilt.

Kun je een SEPA-bestand maken met alleen Excel?

Excel kan de brongegevens bevatten, maar maakt zelf geen betrouwbare SEPA XML. Je hebt een converter of een systeem nodig dat de spreadsheetkolommen aan de juiste XML-velden koppelt en de gegevens controleert.

Wat is de grootste oorzaak van afgekeurde SEPA-bestanden?

Slechte brongegevens. Dubbele kenmerken, inconsistente rekeninggegevens, verkeerde decimaaltekens en het ontbreken van controle vooraf veroorzaken de meeste problemen die later als XML- of bankfout zichtbaar worden.

Kies je voor uploaden of een API-koppeling?

Uploaden past als je batches overzichtelijk zijn en door finance worden voorbereid. Een API past als goedgekeurde betaalgegevens al in je ERP of eigen software staan en je handwerk wilt schrappen.

---

Gerelateerde artikelen