SEPA XML valideren: een vaste werkwijze tegen afgekeurde bestanden
2026-05-04
De betaalrun moet vanmiddag weg. De CSV zag er in Excel goed uit. Het bankportaal denkt daar anders over. Wat terugkomt is zelden behulpzaam: een schemafout, een ontbrekend veld dat niemand bij finance herkent, of een incassobestand dat wel gemaakt werd maar toch op de voorcontrole strandt. En dan begint het zoeken, terwijl leveranciers, klanten of de salarisdeadline dichterbij komen.
Daarom wil je SEPA XML valideren vóórdat je bank dat doet. Een validator is geen speeltje voor ontwikkelaars en ook niet alleen iets voor grote betaalafdelingen. Het is een controlepunt voor elk team dat overboekings- of incassobestanden maakt uit Excel, CSV, ERP-exports of JSON. Goed gebruikt wordt het maken van bestanden een herhaalbaar proces waar finance op vertrouwt en dat technische teams kunnen automatiseren.
Waarom SEPA XML valideren niet optioneel is
Een afkeur komt zelden door één grote fout. Meestal is het een stapel kleine dingen die stroomopwaarts niemand zag: een datum in het verkeerde formaat, een leeg verplicht incassoveld, een kolomkop die na een update veranderde.
Handmatig controleren geeft vals vertrouwen. Opent het bestand, lijken de totalen te kloppen en “werkte het sjabloon van vorige maand grotendeels”, dan neemt iedereen aan dat het goed is. XML werkt niet op aannemelijkheid, maar op exacte structuur, verplichte velden en inhoud die de bank accepteert.
Vuistregel: Valideer je pas nadat de bank een bestand heeft afgekeurd, dan heb je geen validatieproces maar een herstelproces.
De echte afweging
Een mix van spreadsheets, losse scripts en portaaluploads voelt flexibel, maar heeft drie zwakke plekken:
- Brongegevens schuiven: een kolom wordt hernoemd of verplaatst en de koppeling breekt zonder melding.
- Kennis zit bij één persoon: de enige collega die het bankformaat begrijpt, wordt de bottleneck.
- Fouten komen bij de bank terecht: problemen die intern gevangen hadden moeten worden, zie je pas bij de externe controle.
Een validator geeft finance een vast controlepunt en ontwikkelaars een voorspelbare interface. Dat telt extra als je bestanden uit verschillende bronnen komen: ERP-exports, CSV’s van je administratiekantoor, incassolijsten en oude exports. Dan is validatie de enige betrouwbare manier om tot consistente XML te komen.
Je gegevens voorbereiden
Begin met een stabiele export
Gebruik steeds dezelfde export uit hetzelfde systeem, met dezelfde kolommen in dezelfde volgorde. Elke keer een “net iets andere” export maakt elke koppeling kwetsbaar.
Schoon de velden op die het vaakst falen
| Veld | Wat er misgaat | Wat je doet |
|---|---|---|
| Datums | Wisselende notaties (09-10-2025, 9/10/25, 2025-10-09) | Eén formaat in de bron; in de XML wordt het JJJJ-MM-DD |
| Bedragen | Komma als decimaalteken, duizendtalpunten, €-tekens | Kale getallen; in de XML komt een punt (1250.50) |
| Namen en omschrijvingen |
&, trema’s, accenten, slimme aanhalingstekens, regeleinden |
Opschonen of laten omzetten; lengtes bewaken |
| IBAN’s | Spaties, afgekapte tekens, verkeerd opgeslagen als getal | Als tekst opslaan en vooraf controleren met de IBAN-validator |
Een bronsjabloon dat overdrachten overleeft
Leg vast welke kolommen er moeten zijn, hoe ze heten, welk formaat elke kolom heeft en wie het sjabloon mag wijzigen. Zo blijft het werken als een collega op vakantie is of een nieuwe medewerker de run overneemt. Komen gegevens uit een ouder pakket, leg dan ook vast hoe oude velden en betekenissen naar SEPA-velden vertalen, voordat ze in de XML belanden.
Validatie in vijf stappen
Stap 1: bronbestand laden. Upload je Excel, CSV of JSON. Kijk meteen of alle regels zijn ingelezen en of het aantal klopt met je bron.
Stap 2: kolommen koppelen aan SEPA-velden. Controleer bij het koppelen:
- of verplichte velden (naam, IBAN, bedrag, datum, kenmerk) allemaal gekoppeld zijn;
- of incassovelden (machtigingskenmerk, datum ondertekening, volgordetype) bij incasso’s aanwezig zijn;
- of geen kolom aan het verkeerde veld hangt, zoals een klantnummer in het kenmerkveld.
Stap 3: valideren vóór elke upload. Controleer schema, verplichte velden, formaten, IBAN’s en controletotalen. Een bestaand incassobestand haal je door de gratis SEPA-incasso XML-validator.
Stap 4: ook waarschuwingen lezen. Niet alleen harde fouten tellen. Ingekorte namen, omgezette tekens of weggelaten optionele velden zijn signalen dat je bron beter kan.
Stap 5: testen als een productieteam. Test met de records die eerder faalden, niet met schone voorbeeldgegevens. Bewaar bronbestand, XML en validatierapport samen.
Kernpunt: Teams die validatie in elke batch inbouwen, werken rustiger dan teams die het als eenmalige installatieklus zien.
Veelvoorkomende validatiefouten ontcijferen en oplossen
Het bekende patroon: finance exporteert een batch, de validator meldt een technische fout, en iemand past de XML met de hand aan omdat de salarisrun niet kan wachten. Het bestand gaat bij de tweede poging misschien door, maar het proces blijft kapot. Volgende maand komt dezelfde fout terug.
Sorteer de fout voordat je hem oplost
- Structuurfouten: elementen op de verkeerde plek, ontbrekend of dubbel.
- Ontbrekende verplichte velden: leeg in de bron of niet gekoppeld.
- Formaatfouten: de waarde is er, maar niet in een vorm die schema of bank accepteert.
- Migratiefouten: gegevens uit een oud formaat zijn geldige XML geworden, maar met de verkeerde betekenis.
| Melding of symptoom | Veelvoorkomende oorzaak | Oplossing |
|---|---|---|
| Bestand faalt op schema | Verkeerde structuur of koppeling die gegevens in het verkeerde blok zet | Sjabloon en koppeling nalopen, opnieuw genereren |
| Verplicht veld ontbreekt | Leeg in de bron of niet gekoppeld | Veld in de bron vullen en opnieuw valideren |
| Ongeldig rekeningveld | Typefout, kapotte export of inconsistente stamgegevens | Origineel record corrigeren en bestand opnieuw maken |
| Volgordetype geweigerd | Soort incasso past niet bij de machtiging | Bepalen of het eerste, terugkerend, laatste of eenmalig is en de bron aanpassen |
| Datum ondertekening onjuist | Ontbreekt, verkeerd formaat of uit de verkeerde kolom | Datumveld standaardiseren en opnieuw koppelen |
| Totalen of aantallen kloppen niet | Controlevelden niet opnieuw berekend | Batch opnieuw opbouwen en controlevelden checken |
| Bestand is geldig maar bank weigert | Bankspecifieke eisen | Vergelijk met een eerder geaccepteerd bestand en test in de voorcontrole van je bank |
Eerst de bron of het sjabloon
Herhaalde fouten wijzen meestal op een koppelprobleem, niet op vijftig losse regelfouten. Ontbreekt bij elke transactie hetzelfde veld, dan bewijst één XML-correctie alleen dat één handmatige ingreep één keer werkte. De juiste volgorde: patroon herkennen, bron of sjabloon corrigeren, opnieuw genereren, opnieuw valideren.
Incassobestanden falen specifieker
Incasso’s combineren XML-regels met machtigingslogica. Een bestand kan structureel geldig zijn en toch falen omdat het volgordetype (FRST, RCUR, FNAL, OOFF) niet past bij de levenscyclus van de machtiging, of omdat machtigingskenmerk, datum, incassant-ID of incassodatum niet kloppen. Hoe je een incassobestand vanaf de bron goed opbouwt, lees je in een SEPA-incassobestand maken. Wat elke redencode na een stornering betekent, staat in het artikel over SEPA-storneringscodes.
Een vaste routine onder druk
- Classificeer de fout: structuur, verplicht veld, formaat of migratie.
- Bepaal de omvang: één regel wijst op slechte brongegevens, een herhaalde fout op koppeling of export.
- Bekijk de invoer: spreadsheet, ERP-export of JSON. Herstel daar eerst.
- Maak de XML opnieuw: niet het vorige bestand blijven oplappen.
- Test opnieuw met de foute records.
Goede foutmeldingen helpen twee mensen tegelijk: finance ziet welk veld moet worden aangepast, de ontwikkelaar ziet welke regel of welk payloadelement de fout veroorzaakte.
Validatie automatiseren met de API van GenerateSEPA
Met een API vervang je de cyclus van uploaden en controleren door aanroepen vanuit je eigen systeem. Je stuurt de betaalgegevens als JSON naar de API van GenerateSEPA, die ze omzet en controleert. Elke batch krijgt dezelfde controleregels, ongeacht wie hem voorbereidt.
| Wat verbetert | Hoe |
|---|---|
| Consistentie | Dezelfde regels voor elke batch |
| Snelheid | Fouten direct terug in je eigen applicatie |
| Audit | Elke aanroep en elk resultaat vastgelegd in je systeem |
| Minder handwerk | Geen exports, uploads en downloads meer |
Beveiliging hoort erbij
Vraag van een validatiedienst versleuteling tijdens transport, een helder bewaarbeleid en een duidelijke rol als verwerker onder de AVG. Leg in je eigen logs geen volledige IBAN’s of omschrijvingen vast.
In een typische opzet blijft je ERP de bron van de betaalgegevens en de goedkeuring, de API zorgt voor omzetten en controleren, en het resultaat gaat naar je bank. Meer criteria voor zo’n dienst lees je in een SEPA-leverancier kiezen.
Van validatie naar een rustig betaalproces
| Stap | Wat je doet | Wanneer |
|---|---|---|
| 1. Vaste export | Zelfde systeem, zelfde kolommen | Elke batch |
| 2. Opschonen | Datums, bedragen, tekens, IBAN’s | Vóór het omzetten |
| 3. Koppelen | Eenmalig, daarna hergebruiken | Eerste keer en bij wijzigingen |
| 4. Valideren | Schema, velden, totalen | Vóór elke upload |
| 5. Fouten bij de bron oplossen | Niet in de XML | Bij elke fout |
| 6. Archiveren | Bron, XML en rapport samen | Na elke run |
Valideer je bestanden voortaan voordat je bank dat doet. Probeer GenerateSEPA 7 dagen gratis: je Excel of CSV wordt gecontroleerd en omgezet naar een geldig SEPA XML-bestand.
Veelgestelde vragen
- Wat controleert een SEPA XML-validator?
- Hij controleert of de structuur overeenkomt met het ISO 20022-schema, of alle verplichte velden gevuld zijn, of het bestand goed gevormd is en of datums, kenmerken, IBAN's en bedragen het juiste formaat hebben. Bij incasso's controleert hij ook machtigingsgegevens en controletotalen.
- Waarom keurt de bank een SEPA-bestand af dat er goed uitziet?
- Omdat bekijken geen valideren is. Een bestand kan er in een browser of editor netjes uitzien en toch falen op het schema, op controletotalen, op machtigingslogica of op bankspecifieke regels. Echte controle gaat tegen het XSD-schema en de operationele eisen.
- Moet je fouten direct in het XML-bestand herstellen?
- Nee. Handmatig aanpassen van de XML is hooguit nuttig om een fout te analyseren. Herstel de brongegevens of de koppeling, maak het bestand opnieuw en valideer opnieuw. Zo blijft je audittrail intact en komt dezelfde fout niet terug.
- Kun je SEPA XML-validatie automatiseren via een API?
- Ja. Je systeem stuurt de betaalgegevens als JSON naar de API, die ze omzet en controleert. Zo gebruikt elke batch dezelfde controleregels en ben je niet afhankelijk van handmatige controles.
