Wanneer je een factuur instuurt bij eConnect, doorloopt het document een reeks verwerkingsstappen. Hoe die verwerking precies verloopt, hangt af van het bestandstype (XML of PDF) en de kwaliteit van het aangeleverde bestand. Dit artikel legt uit wat er achter de schermen gebeurt.

eConnect kent twee fundamenteel verschillende verwerkingsroutes:

XML-verwerking (directe route): als je een valide UBL-factuur (SI-UBL 2.0, Peppol BIS Billing 3.0 of een ander ondersteund XML-formaat) instuurt, wordt deze direct verwerkt. Het platform leest de gestructureerde data uit de XML, valideert deze en routeert het document naar de ontvanger. Dit is de snelste en meest betrouwbare route.

PDF-verwerking (conversie via IDR): als je een PDF-factuur instuurt, wordt deze verwerkt door de Intelligent Document Recogniser (IDR). De IDR extraheert de factuurgegevens via OCR en patroonherkenning, en produceert een UBL-factuur op basis van de herkende data. Dit proces is inherent minder betrouwbaar dan directe XML-verwerking, omdat het afhankelijk is van de kwaliteit van de PDF.

Tip: UBL-aanlevering heeft altijd de voorkeur boven PDF. Het is sneller, goedkoper en betrouwbaarder. Vraag je leverancier of softwarepakket of UBL-export beschikbaar is.

Bij het insturen van een XML-bestand doorloopt eConnect de volgende stappen:

Het platform herkent automatisch welk formaat het bestand volgt op basis van de CustomizationID en het XML-schema. Ondersteunde formaten zijn onder meer NLCIUS, BIS Billing V3, XRechnung, CII en Factur-X.

De factuur wordt gevalideerd tegen de regels van het herkende profiel. Dit omvat:

• Schema-validatie: voldoet de XML aan de UBL 2.1 of CII-schemastructuur?
• Business rules: kloppen de berekeningen? Zijn verplichte velden gevuld? Komen codelijstwaarden overeen?
• Landspecifieke regels: worden de juiste NL-R-, DK-R- of andere landregels nageleefd?

Tip: Krijg je de melding dat er "geen validatieregels" gevonden zijn? Dat betekent meestal dat het CustomizationID in je XML ontbreekt of niet wordt herkend. Zonder herkenbaar profiel kan de validator geen business rules toepassen. Controleer of je factuur een geldig CustomizationID bevat, zoals dat van NLCIUS of BIS Billing V3.

Een opvallend kenmerk van de eConnect-verwerking is de automatische reparatie van XML-bestanden. Via XSL-transformaties worden bekende fouten gecorrigeerd. Het platform accepteert in principe elke UBL; niet-essentiële ontbrekende velden worden gevuld met standaardwaarden. Deze reparatiefunctie wordt continu doorontwikkeld op basis van klantfeedback en is productierijp.

Voorbeelden van automatische reparaties:

• Ontbrekende optionele velden worden aangevuld met correcte standaardwaarden
• Bekende formatfouten in identifier-velden worden gecorrigeerd
• Onvolledige contactgegevens worden aangevuld (als het ElectronicMail-veld van de leverancier leeg is, vult eConnect automatisch [email protected] in, zodat afgewezen facturen toch bij de verzender terechtkomen)

Als de ontvanger een ander formaat ondersteunt dan het bronformaat, transformeert de PSB het document automatisch. Een NLCIUS-factuur kan bijvoorbeeld worden getransformeerd naar XRechnung als de ontvanger een Duitse overheidsinstantie is. Dit is mogelijk doordat alle ondersteunde formaten zijn gebaseerd op hetzelfde semantische model (EN 16931).

Technisch: Bij het downloaden van een factuur via de API kun je via de parameter targetDocumentTypeId het gewenste ontvangstformaat opgeven. De PSB transformeert het document dan naar dat formaat.

ZUGFeRD en Factur-X zijn hybride factuurformaten: een PDF/A-3 bestand met daarin een embedded CII XML-factuur. Bij deze documenten probeert het platform eerst de embedded XML uit de PDF te extraheren. Als de XML valide is, wordt deze direct verwerkt, net als een reguliere XML-factuur. Pas als de embedded XML niet valide blijkt, valt het systeem terug op OCR-verwerking via de IDR.

Een ZUGFeRD-factuur die in externe validators slaagt maar toch via OCR wordt verwerkt, wijst op een probleem met de embedded XML in het eConnect-validatieproces. In dat geval kun je contact opnemen met support.

Technisch: Het legacy platform kan uitsluitend valide UBL-facturen opslaan. Wanneer een ZUGFeRD-factuur via de IDR als PDF wordt verwerkt, moet de IDR-output eerst worden getransformeerd naar valide UBL (BIS Billing V3 of NLCIUS). Als die transformatie niet slaagt omdat de brondata onvoldoende velden bevat voor een valide UBL-factuur, kan het platform de factuur niet opslaan. In de PSB/Control speelt dit minder, doordat facturen daar in hun oorspronkelijke formaat worden opgeslagen en pas bij aflevering worden getransformeerd.

Als je een XML-bestand instuurt dat niet valide is, valt het systeem automatisch terug op de meegestuurde PDF. Dit werkt als volgt:

1. Het platform probeert eerst de XML-component te verwerken.
2. Als de UBL niet valide is, wordt de meegestuurde PDF opgepakt als fallback.
3. De PDF wordt verwerkt via de IDR-route (OCR en patroonherkenning).

Dit mechanisme zorgt ervoor dat de factuur altijd wordt verwerkt, zelfs als de XML fouten bevat. Het is echter wel een duurdere en langzamere route dan directe XML-verwerking.

SI-UBL 1.2 (Simplerinvoicing 1.2) is definitief uitgefaseerd per 1 januari 2024. Facturen in dit formaat worden afgewezen op het Peppol-netwerk. eConnect kan verouderde SI-bestanden die via e-mail binnenkomen soms nog wel transformeren naar valide NLCIUS, mits de essentiële data aanwezig is. Bij ontbrekende gegevens kan validatie falen.

Let op: Ontvang je foutmeldingen bij het verzenden van facturen? Controleer of je softwarepakket nog SI-UBL 1.2 genereert. Zo ja, vraag je leverancier om een upgrade naar NLCIUS/SI-UBL 2.0 of BIS Billing V3.

De verwerking verschilt licht tussen het legacy platform en de PSB/Control:

• Legacy platform: een factuur wordt altijd eerst getransformeerd naar valide UBL (BIS Billing V3 of NLCIUS) voordat deze wordt opgeslagen. Als die transformatie niet slaagt, kan de factuur niet worden opgeslagen.
• PSB/Control: een factuur wordt bij ontvangst gevalideerd en opgeslagen. Transformatie vindt pas later plaats wanneer dat nodig is, bijvoorbeeld bij aflevering aan een ERP-systeem. Dit betekent dat een factuur in de PSB wel kan worden opgeslagen, maar dat er later een transformatiefout kan optreden als het doelformaat niet kan worden gegenereerd.

Wil je controleren of je XML-bestand correct wordt verwerkt? Gebruik de gratis eConnect Validator om je factuur vooraf te testen.

• De opbouw van een UBL-factuur
• Wat is het verschil tussen XML, UBL, BIS Billing V3 en NLCIUS?
• Belangrijke verzendvelden in UBL
• SEEF: de Standaard Energie eFactuur
• XML-voorbeeldbestanden downloaden
• Van semantiek tot syntax