XML-validatie: 5 veelgemaakte fouten en hoe u ze oplost
XML-validatiefouten kunnen uw betalingen of facturen blokkeren. Hier zijn de 5 meest voorkomende problemen die we zien en hoe u ze snel kunt oplossen.
Waarom XML-bestanden valideren?
Een slecht gevormd of niet-conform XML-bestand wordt systematisch afgewezen door uw bank of zakenpartner. Preventieve validatie bespaart u kostbare heen-en-weercommunicatie en betalingsvertragingen.
De 5 meest voorkomende fouten
Onjuiste codering
Het bestand is niet in UTF-8 of bevat onjuist gecodeerde speciale tekens (accenten, €-symbool). Dit veroorzaakt onmiddellijke parsing-fouten.
Ontbrekende of onjuiste XML-naamruimte
De XML-naamruimte (xmlns) komt niet overeen met de verwachte schemaversie. Verschillende versies van pain.001 of UBL hebben verschillende naamruimten.
Onjuist controlegetal (CtrlSum)
Voor SEPA-bestanden moet de CtrlSum exact gelijk zijn aan de som van alle afzonderlijke bedragen. Afronding op 3 in plaats van 2 decimalen is genoeg om het bestand ongeldig te maken.
Ontbrekende verplichte velden
Sommige velden lijken optioneel in het schema, maar zijn verplicht onder Peppol- of EPC-bedrijfsregels (bijv. BIC van de debiteur in bepaalde contexten).
Ongeldig datumformaat
Datums moeten het ISO 8601-formaat volgen. Een datum zoals "10/02/2026" wordt afgewezen; het moet "2026-02-10" zijn.
Automatiseer uw validatie
Integreer XML-validatie in uw bestandsgeneratieproces. ValidateFin biedt een API die u vanuit uw ERP- of boekhoudsystemen kunt aanroepen om elk bestand automatisch te valideren vóór verzending.
Het tweede niveau is validatie van bedrijfsregels. Dit zijn domeinspecifieke regels die verder gaan dan wat het schema kan uitdrukken. Voor SEPA-bestanden publiceert de EPC (European Payments Council) implementatierichtlijnen met regels zoals: de CtrlSum moet gelijk zijn aan de som van alle afzonderlijke bedragen, de RequestedExecutionDate moet een toekomstige werkdag zijn, en het IBAN van de debiteur moet in de SEPA-zone liggen. Voor UBL-facturen definieert de EN 16931-norm bedrijfsregels zoals: de totale regelbedragen moeten gelijk zijn aan het factuurtotaal, de btw-categoriecode moet consistent zijn met het belastingtarief, en Peppol voegt verdere landspecifieke regels toe.
Een robuuste validatieworkflow controleert beide niveaus: eerst XSD-conformiteit (om structurele fouten vroeg op te vangen), dan bedrijfsregels (om logische fouten op te vangen). ValidateFin implementeert beide: de SEPA-validator controleert aan de hand van de officiële EPC XSD-schema's en past de SEPA-bedrijfsregels toe, terwijl de UBL-validator controleert aan de hand van het UBL 2.1-schema en de EN 16931-bedrijfsregels.
XML-beveiliging: XXE en injectieaanvallen voorkomen
XML-bestanden kunnen veiligheidsrisico's met zich meebrengen als ze niet zorgvuldig worden verwerkt. Het gevaarlijkste is de XML External Entity (XXE)-aanval, waarbij een kwaadaardig XML-bestand een DOCTYPE-declaratie bevat die verwijst naar externe bronnen — waardoor bestanden van de server kunnen worden gelezen, netwerkverzoeken kunnen worden gedaan, of denial-of-service kan worden veroorzaakt door entiteitsuitbreiding (de 'billion laughs'-aanval).
Veilige XML-parsing vereist: het volledig blokkeren van DOCTYPE-declaraties (elk financieel XML-bestand met een DOCTYPE is verdacht), het beperken van de diepte van entiteitsuitbreiding, het beperken van de maximale bestandsgrootte (ValidateFin beperkt tot 10 MB), en het beperken van de nestdiepte (ValidateFin beperkt tot 64 niveaus). Deze beveiligingen zijn vooral belangrijk voor webgebaseerde validators waarbij gebruikers willekeurige bestanden uploaden.
Client-side validatie voegt een extra beveiligingslaag toe: omdat de XML in de browser van de gebruiker wordt geparsed, kan zelfs een kwaadaardig bestand geen toegang krijgen tot serverbronnen. Dit is een van de belangrijkste voordelen van de architectuur van ValidateFin — alle parsing vindt plaats in een geïsoleerde browsersandbox, waardoor server-side XXE-risico's volledig worden geëlimineerd.
Best practices voor validatieworkflows
Het opbouwen van een betrouwbare XML-validatieworkflow omvat verschillende best practices. Ten eerste: valideer vroeg — controleer XML-bestanden zo dicht mogelijk bij het generatiepunt, niet pas vlak voor indiening.
Ten tweede: gebruik de juiste schemaversie. SEPA pain.001 heeft meerdere versies (.003, .009, .011) en elke bank kan verschillende versies accepteren. UBL 2.1 is de standaard voor Peppol, maar sommige nationale netwerken gebruiken nog oudere versies.
Ten derde: implementeer een validatiepijplijn: (1) controle op welgevormdheid, (2) XSD-schemavalidatie, (3) validatie van bedrijfsregels, (4) inhoudsvalidatie. Elke stap vangt verschillende klassen fouten op.
Ten vierde: log en monitor validatieresultaten. Houd veelvoorkomende foutpatronen bij om uw generatieproces te verbeteren.
Automatiseer uw validatie
Integreer XML-validatie in uw bestandsgeneratieproces. ValidateFin laat u SEPA-, UBL- en camt.053-bestanden direct in de browser valideren — geen server-upload, geen API-sleutel nodig.
De validatietools uitproberenVeelgestelde vragen
Wat is XSD-schemavalidatie en waarom is het belangrijk?
XSD-validatie (XML Schema Definition) controleert of een XML-document voldoet aan het gedefinieerde schema — het verifieert elementnamen, gegevenstypen, verplichte velden en documentstructuur. Voor financiële XML-bestanden zoals SEPA en UBL is XSD-validatie de eerste verdedigingslinie tegen opmaakfouten die tot afwijzing zouden leiden.
Wat zijn de meest voorkomende XML-validatiefouten in financiële bestanden?
De meest voorkomende fouten zijn: ontbrekende verplichte elementen, onjuiste naamruimtedeclaraties, ongeldige datum- of bedragnotaties, elementen in verkeerde volgorde, overschrijding van maximale veldlengtes (bijv. MsgId beperkt tot 35 tekens in SEPA) en coderingsproblemen met speciale tekens.
Moet ik XML-bestanden client-side of server-side valideren?
Voor gevoelige financiële gegevens wordt client-side validatie sterk aanbevolen. Het garandeert dat geen vertrouwelijke betalingsgegevens of factuurdetails worden verzonden naar externe servers. ValidateFin verwerkt alle XML-validatie volledig in de browser, waardoor het veilig is voor echte productiebestanden.
Wat is het verschil tussen welgevormdheid en geldigheid in XML?
Een welgevormd XML-document volgt de basisregels van XML-syntaxis: correct geneste tags, aanhalingstekens rond attributen, één root-element en correcte codering. Een geldig XML-document gaat verder — het voldoet aan een specifiek schema (XSD of DTD) dat bepaalt welke elementen zijn toegestaan, hun gegevenstypen en hun structuur.
Wat is een XML-naamruimte en waarom veroorzaakt het validatiefouten?
Een XML-naamruimte (xmlns) is een URI die de schemaversie van een document uniek identificeert. Voor SEPA pain.001 bepaalt de naamruimte welke versie u gebruikt. Een naamruimtemismatch zorgt ervoor dat de validator tegen het verkeerde schema controleert.
Hoe valideer ik SEPA-bestanden aan de hand van EPC-bedrijfsregels?
EPC-bedrijfsregels gaan verder dan XSD: ze controleren of de CtrlSum overeenkomt met de som van alle bedragen, of de RequestedExecutionDate een geldige toekomstige werkdag is, en of IBAN's syntactisch correct zijn en binnen de SEPA-zone vallen. De SEPA-validator van ValidateFin implementeert deze EPC-regels automatisch.
Wat is de XXE-kwetsbaarheid en hoe verhoudt die zich tot XML-validatie?
XXE (XML External Entity) is een beveiligingskwetsbaarheid waarbij een XML-parser kwaadaardige DOCTYPE-declaraties verwerkt die verwijzen naar externe bronnen. Veilige XML-validators moeten de verwerking van externe entiteiten volledig uitschakelen. ValidateFin blokkeert alle DOCTYPE-declaraties en verwerkt bestanden in de browsersandbox.
Kan ik meerdere XML-bestanden tegelijk valideren?
ValidateFin ondersteunt validatie van één bestand tegelijk via de webinterface. Voor batchvalidatie kunt u bestanden achtereenvolgens verwerken. Elke validatie wordt volledig in uw browser uitgevoerd.
Welke bestandsgroottebeperkingen gelden voor XML-validatie?
ValidateFin beperkt de XML-bestandsgrootte tot 10 MB en de nestdiepte tot 64 niveaus. De meeste SEPA-betalingsbestanden zijn kleiner dan 1 MB en UBL-facturen zijn doorgaans kleiner dan 100 KB.
Hoe debug ik cryptische XML-validatiefouten?
Begin met controleren: (1) Is de XML welgevormd? (2) Is de naamruimte correct? (3) Staan de elementen in de juiste volgorde? (4) Zijn de gegevenstypen correct? ValidateFin biedt duidelijke foutmeldingen met elementpaden en regelnummers.