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 support@econnect.eu 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.

eConnect herkent een verkooporder (order-document) nooit als een factuur en converteert deze niet automatisch naar een factuur. Als je een verkooporder instuurt op een plek waar een factuur wordt verwacht, wordt het document afgewezen.

De leverancier moet zelf een correct factuurdocument aanleveren: een UBL Invoice met de juiste InvoiceTypeCode. eConnect past het brondocument niet aan en verzorgt deze conversie niet.

Uitzondering — orderflip: via de orderflip-functie kunnen ordergegevens als basis dienen om een conceptfactuur (draft) klaar te zetten. Dit is een aparte gebruikershandeling, geen automatische omzetting van verkooporder naar definitieve factuur. De leverancier moet die conceptfactuur zelf completeren en als definitief factuurdocument (UBL Invoice + InvoiceTypeCode) indienen.

Let op: Verwar documenttype-herkenning niet met referentieherkenning. Een verkoopordernummer dat op een factuur moet worden herkend (als OrderReference of order_reference) is een referentieveld, niet het documenttype zelf. eConnect leest dat ordernummer uit de factuur en koppelt het als referentie, maar het verandert daarmee niet het type van het document.

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.

Wordt een UBL afgewezen (omdat deze niet geldig is), dan verwerkt eConnect wél de overige bijlagen die in dezelfde e-mail zitten, zoals een PDF. De inzender ontvangt dan een e-mail met:

• de melding dat de UBL-factuur niet wordt verwerkt, inclusief de foutmelding;
• de mededeling dat eventuele andere bijlagen in de e-mail wel worden geprobeerd te verwerken.

Let op: deze foutmelding op de XML-factuur kan niet worden onderdrukt zolang er andere bijlagen in de e-mail zitten die wel worden verwerkt.

Voorbeeld -- BR-AE-10 (Reverse Charge): een UBL met BTW-categorie AE (Reverse Charge) zonder BT-121 (VAT exemption reason code) of BT-120 (VAT exemption reason text) triggert validatieregel BR-AE-10. Bij categorie AE moet minimaal een van beide velden aanwezig zijn. De UBL wordt afgewezen, een meegestuurde PDF wordt via de IDR-fallback verwerkt, en de foutmelding over de UBL blijft zichtbaar in de e-mail aan de inzender.

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.

eConnect verwerkt UBL-velden bij ontvangst zoals aangeleverd in de bron-UBL en past deze niet inhoudelijk aan. Er is geen klant-instelbare veldmapping aan de ontvangerkant om aangeleverde waarden te herschrijven. Ontbrekende of onjuiste waarden moeten door de verzender in de bron-UBL worden gecorrigeerd. eConnect corrigeert alleen bekende technische formatfouten en vult niet-essentiële optionele velden met standaardwaarden (zie automatische XML-reparatie hierboven).

Een concreet voorbeeld bij een inkomende intracommunautaire creditnota (leveringsvelden):

Beide velden worden door eConnect bij ontvangst verwerkt zoals aangeleverd. BT-80 is alleen verplicht wanneer een Deliver-to-address (BG-15) is opgenomen in de factuur. eConnect biedt geen ontvangerkant-mapping om BT-72 of BT-80 te herschrijven. Correctie van ontbrekende of onjuiste waarden gebeurt door de verzender in de bron-UBL.

Maatwerk-correctie via consultancy (geen self-service): eConnect kán op basis van consultancy de RBE (rule/business engine) inrichten voor automatische correcties op de flow. Dit is maatwerk via eConnect-consultancy, niet iets dat de klant zelf configureert. Er is geen klant-instelbare self-service herschrijving van aangeleverde UBL-velden aan de ontvangerkant.

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