Je ontvangt van een leverancier een bestand dat eindigt op .xml. Je boekhouder noemt het een UBL-factuur, terwijl je ERP-systeem hetzelfde document als elektronische leveranciersfactuur verwerkt. Is dat gewoon een PDF in een andere verpakking? Nee. Een UBL-factuur bevat gestructureerde gegevens die software rechtstreeks kan lezen, zonder eerst de visuele opmaak te interpreteren. Dat maakt het formaat bijzonder belangrijk voor Belgische ondernemingen die facturen sneller, consistenter en met minder manuele invoer willen verwerken.
Toch worden XML, UBL, Peppol en PDF vaak door elkaar gebruikt. In deze gids ontdek je wat een UBL-factuur precies is, hoe een UBL-bestand eruitziet, welke gegevens het bevat, hoe je het opent en valideert en hoe UBL zich verhoudt tot EN 16931 en Peppol BIS Billing 3.0. Je ziet ook hoe Odoo verkoop- en leveranciersfacturen binnen een gestructureerde e-facturatieflow verwerkt en welke controles nodig blijven voordat een factuur wordt geboekt of betaald.
Een UBL-factuur is een gestructureerd XML-document waarin factuurgegevens volgens vaste zakelijke afspraken zijn opgeslagen. Daardoor kan boekhoud- of ERP-software onder meer leverancier, klant, factuurregels, btw, totalen, betaalgegevens en referenties automatisch herkennen. Een PDF is vooral bedoeld om door mensen te worden bekeken; UBL is in de eerste plaats bedoeld om gegevens betrouwbaar tussen systemen uit te wisselen.
Wat is een UBL-factuur?
UBL staat voor Universal Business Language. Het is een open internationale standaard van OASIS voor elektronische zakelijke documenten, opgebouwd in XML. UBL beperkt zich niet tot facturen: ook creditnota’s, bestellingen, leveringsinformatie en andere bedrijfsdocumenten kunnen volgens dezelfde systematiek worden gestructureerd. Bij een UBL-factuur krijgt elk belangrijk gegeven een vaste technische betekenis. Software hoeft daardoor niet te raden waar het factuurnummer, de datum, de leverancier of het totaalbedrag staat, maar kan die velden rechtstreeks uit het document lezen.
Dat vaste gegevensmodel is de echte meerwaarde. Twee bedrijven hoeven niet hetzelfde ERP- of boekhoudpakket te gebruiken om een factuur automatisch te verwerken. Zolang beide systemen hetzelfde afgesproken profiel begrijpen, kunnen ze de gegevens eenduidig interpreteren. Een UBL-factuur is dus niet simpelweg “een XML met factuurgegevens”, maar een XML-document waarvan de zakelijke structuur en betekenis volgens een standaard zijn vastgelegd.
De opbouw van een UBL-bestand
Wanneer je een UBL-factuur opent in een teksteditor, zie je geen klassieke factuur met logo, kolommen en betaalstrook. Je ziet XML-tags die aangeven wat een waarde betekent en hoe die zich tot andere gegevens verhoudt. Voor een medewerker oogt dat technisch; voor software is het net veel duidelijker dan een visuele PDF. Elementen zoals cbc:ID, cbc:IssueDate en cbc:DocumentCurrencyCode hebben een voorspelbare functie, terwijl geneste blokken partijen, adressen, belastingen, betalingen en factuurregels groeperen.
<cbc:ID>INV-2026-0042</cbc:ID>
<cbc:IssueDate>2026-08-05</cbc:IssueDate>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>PO-2026-118</cbc:BuyerReference>
Dit vereenvoudigde fragment betekent dat de factuur nummer INV-2026-0042 draagt, op 05-08-2026 werd uitgereikt, euro als valuta gebruikt en naar aankoopreferentie PO-2026-118 verwijst. Een volledig UBL-bestand bevat veel meer informatie. Denk aan identificatie van verkoper en koper, factuurregels, hoeveelheden, prijzen, kortingen, toeslagen, btw-categorieën, betaalvoorwaarden, rekeninggegevens en het uiteindelijk verschuldigde bedrag.
Deze gegevens bevat een UBL-factuur
De precieze inhoud hangt af van het gebruikte factuurprofiel en van de transactie, maar een UBL-factuur bevat doorgaans alle gegevens die nodig zijn om de factuur te identificeren, te controleren en te verwerken. Het grote verschil met een gewone PDF is niet noodzakelijk dat UBL méér gegevens bevat, maar dat die informatie technisch een vaste betekenis krijgt. Daardoor kan software een factuurnummer als factuurnummer herkennen, een btw-bedrag als belasting behandelen en een bestelreferentie rechtstreeks aan een aankoopdocument koppelen.
Niet elk veld is in elke situatie verplicht. Een gewone dienstenfactuur vraagt andere gegevens dan een creditnota, factuur met bestelreferentie of complexe factuur met meerdere btw-categorieën. Daarom moet je niet alleen controleren of het document technisch UBL is, maar ook of het juiste profiel wordt toegepast en of de inhoud overeenstemt met de zakelijke werkelijkheid.
UBL-factuur voorbeeld: zo leest software dezelfde factuur
Een goed UBL-factuur voorbeeld toont niet alleen XML-code, maar maakt duidelijk hoe de technische velden overeenkomen met de leesbare factuur. Stel dat een leverancier tien onderdelen aan 25 euro factureert. In een PDF ziet een medewerker een tabel met artikel, aantal en prijs. In UBL worden hoeveelheid, eenheid, prijs, nettobedrag, btw-categorie en totaal afzonderlijk vastgelegd. Het ontvangende systeem kan die waarden daardoor rechtstreeks verwerken zonder eerst een tabel uit een afbeelding of PDF te reconstrueren.
Die directe veldmapping is fundamenteel anders dan OCR. Bij een PDF probeert documentherkenning te bepalen waar naam, datum, bedragen en btw staan. Bij een correcte UBL-factuur wordt die betekenis al vanuit de bronsoftware meegegeven. OCR voor boekhoudautomatisering in Odoo blijft nuttig voor scans en ongestructureerde documenten, maar voor een geldige gestructureerde factuur is die visuele interpretatiestap niet de primaire gegevensbron.
PDF, XML en UBL: de verschillen in één overzicht
PDF, XML en UBL zijn geen drie varianten van hetzelfde factuurformaat. Een PDF beschrijft vooral hoe een document visueel wordt weergegeven. XML is een algemene taal om gegevens met tags en hiërarchieën te structureren. UBL gebruikt XML, maar voegt daar een gestandaardiseerde zakelijke woordenschat en documentstructuur aan toe. Daardoor weet ontvangende software niet alleen dát een waarde aanwezig is, maar ook of het bijvoorbeeld om een factuurdatum, koper, btw-categorie, betaalrekening of totaalbedrag gaat.
Een PDF kan naast een UBL-factuur nuttig blijven als leesbare voorstelling. Sommige systemen bewaren beide documenten samen of genereren vanuit de gestructureerde data een visuele factuur. De twee bestanden hebben echter een andere functie: de PDF helpt een medewerker om snel te lezen, terwijl de UBL-data de betrouwbare machineleesbare bron vormt voor automatische verwerking.
XML versus UBL: waarom structuur het verschil maakt
Iedere UBL-factuur is XML, maar niet ieder XML-bestand is een UBL-factuur. XML bepaalt hoe gegevens in tags kunnen worden opgeslagen, maar zegt niet welke zakelijke betekenis die tags hebben. Een ontwikkelaar kan bijvoorbeeld zelf <datum>, <invoiceDate> of <factuurdatum> gebruiken. Zonder aanvullende afspraken weet een ander systeem niet automatisch dat die velden hetzelfde betekenen. UBL legt die afspraken wel vast via gestandaardiseerde componenten, elementnamen, datatypes en XML-schema’s.
Een factuur omzetten naar UBL: van bronbestand naar geldige data
Een factuur omzetten naar UBL is daarom geen bestandsconversie zoals Word naar PDF. De brongegevens moeten eerst worden herkend of rechtstreeks uit het facturatiesysteem worden gelezen, vervolgens naar gestandaardiseerde UBL-velden worden gemapt en daarna volgens het vereiste profiel worden opgebouwd en gevalideerd. Een XML-factuur met zelfgekozen tags is dus niet automatisch een UBL-factuur. Werk je vanuit een PDF, dan kan OCR gegevens helpen extraheren, maar bedragen, btw, partijen, referenties en totalen moeten nog steeds correct worden geïnterpreteerd. Rechtstreekse UBL-generatie vanuit de bronsoftware vermijdt die extra interpretatiestap.
Een UBL-factuur openen en lezen
Een UBL-factuur kun je technisch openen met iedere teksteditor die XML kan weergeven. Je ziet dan de ruwe tags en waarden. Voor dagelijkse controle is een betrouwbare UBL-viewer praktischer, omdat die het bestand omzet naar een herkenbare factuurweergave. Het belangrijkste is dat je weet wat de tool doet: een viewer maakt de gegevens leesbaar, maar bewijst niet automatisch dat alle velden, berekeningen en profielregels correct zijn. Bewaar daarom altijd het oorspronkelijke bestand naast eventuele visuele weergaven.
- Bewaar een ongewijzigde kopie van de oorspronkelijke UBL-factuur.
- Open het document in je ERP, boekhoudsoftware of een vertrouwde viewer.
- Controleer leverancier, klant, factuurnummer, datum en valuta.
- Vergelijk factuurregels, btw-totalen en het te betalen bedrag.
- Controleer bestelreferenties, rekeninggegevens en vervaldatum.
- Gebruik voor formele technische controle een validator die het relevante profiel ondersteunt.
- Upload vertrouwelijke documenten niet zonder beoordeling naar onbekende online tools.
Wie facturen centraal wil bewaren, kan UBL, leesbare weergave en bijlagen koppelen aan een breder proces voor documentenbeheer in Odoo. Zo blijven bronbestand, rechten, status en boekhoudkundige verwerking beter bij elkaar.
UBL-viewer versus validator: twee verschillende controles
Een viewer en een validator beantwoorden twee verschillende vragen. De viewer vraagt: “Wat staat er in dit bestand?” Een validator vraagt: “Voldoet dit bestand aan de technische en zakelijke regels die voor het gekozen profiel gelden?” Daarbovenop blijft een financiële of operationele controle nodig. Geen XML-validator kan bevestigen dat de goederen werkelijk zijn geleverd, een aankoop correct is goedgekeurd of een gewijzigd bankrekeningnummer betrouwbaar is. Een goede factuurflow combineert daarom leesbaarheid, technische validatie en zakelijke controle.
UBL-factuur valideren: structuur, regels en inhoud
Een UBL-factuur valideer je best in lagen. Eerst controleer je of het document geldige XML is: tags moeten correct openen en sluiten en de structuur moet technisch leesbaar zijn. Daarna volgt controle tegen het relevante UBL-schema. Vervolgens komen de profiel- en business rules, bijvoorbeeld verplichte referenties, identificaties, valuta, btw-logica en rekenkundige aansluiting van bedragen. Een UBL-factuur kan technisch perfect XML zijn en toch inhoudelijk ongeldig zijn omdat een verplicht veld ontbreekt of totalen niet overeenstemmen.
Voor Peppol BIS Billing 3.0 bestaan daarom aanvullende validatieregels boven op de UBL-structuur en EN 16931. Zo kan een profiel voorschrijven dat een koperreferentie of aankooporderreferentie aanwezig moet zijn, of dat bepaalde identificaties een specifiek formaat volgen. Controleer ten slotte ook de zakelijke werkelijkheid: klopt de leverancier, hoort de factuur bij de bestelling, zijn goederen ontvangen en mag de betaling worden vrijgegeven? Technische geldigheid is noodzakelijk, maar niet voldoende voor een betrouwbare boeking.
Veelvoorkomende fouten in een UBL-bestand
Een UBL-factuur vermindert interpretatiefouten en handmatig overtypen, maar elimineert verkeerde brondata niet. Wanneer een leveranciersfiche een fout btw-nummer bevat, een product verkeerd is geconfigureerd of een betaalrekening ongecontroleerd werd aangepast, kan een perfect gestructureerd UBL-bestand die fout juist zeer efficiënt doorgeven. Ook mappings, afrondingen, btw-codes en referenties kunnen verkeerd staan. Daarom horen UBL-fouten zowel in implementatietests als in dagelijkse uitzonderingscontroles thuis.
- ontbrekend of ongeldig ondernemings- of btw-nummer;
- verkeerde valuta-, btw- of eenheidscode;
- ontbrekende koper-, klant- of bestelreferentie;
- factuurtotalen die niet aansluiten op regels, kortingen, toeslagen en belastingen;
- fout rekeningnummer of onvolledige betaalinstructie;
- verkeerde leverancier of klant door gebrekkige masterdata;
- dubbele factuur met een licht afwijkende referentie;
- technisch geldige UBL-factuur die niet aan het vereiste profiel voldoet.
Wie de voordelen van automatisering wil behouden, moet daarom ook data governance organiseren. Leg vast wie bedrijfs- en contactgegevens beheert, welke velden verplicht zijn, wie bankgegevens mag wijzigen en hoe uitzonderingen worden opgevolgd. De standaard maakt verwerking sneller; ze maakt foutieve masterdata niet automatisch correct.
Is een UBL-factuur verplicht in België sinds 2026?
Sinds 01-01-2026 is voor quasi alle B2B-handelingen tussen Belgische btw-plichtige ondernemingen een gestructureerde elektronische factuur verplicht. Een gewone PDF via e-mail volstaat voor die transacties niet meer. De officiële Belgische informatie over gestructureerde elektronische facturen legt echter niet simpelweg op dat “ieder bedrijf altijd UBL moet gebruiken”. De gestructureerde factuur moet voldoen aan EN 16931 en praktisch kunnen worden uitgewisseld in Peppol BIS-formaat; onder voorwaarden kan een alternatief formaat worden gebruikt wanneer beide partijen akkoord gaan en dezelfde Europese norm wordt gerespecteerd.
Voor Belgische ondernemingen betekent dit dat software zowel verzending als ontvangst van gestructureerde facturen moet ondersteunen wanneer de organisatie binnen het toepassingsgebied valt. B2C- en bepaalde internationale situaties vallen anders. Wie Odoo gebruikt en specifiek wil weten hoe registratie, verzending en ontvangst via het netwerk werken, vindt dat afzonderlijk uitgewerkt in de gids over Peppol-integratie in Odoo. Zo blijft deze pagina gericht op UBL zelf en vermijden we inhoudelijke cannibalisatie met de Peppol-pagina.
UBL, EN 16931, Peppol BIS 3.0 en Peppol uitgelegd
Deze vier begrippen worden vaak in één zin gebruikt, maar ze beschrijven verschillende lagen. UBL is de technische syntax waarmee factuurgegevens in XML worden uitgedrukt. EN 16931 is de Europese semantische norm die bepaalt welke kernelementen een elektronische factuur heeft en welke betekenis en regels daarbij horen. Peppol BIS Billing 3.0 is een concreet interoperabiliteitsprofiel dat EN 16931 aan UBL koppelt en aanvullende regels toepast. Peppol zelf is het netwerk waarmee documenten tussen verzender en ontvanger worden uitgewisseld.
Dat onderscheid voorkomt een veelvoorkomende misvatting: een UBL-factuur is niet automatisch een geldige Belgische Peppol-factuur. Het document moet ook voldoen aan de relevante semantische en profielregels. Omgekeerd gebruikt Peppol BIS Billing 3.0 UBL als syntax voor facturen en creditnota’s. De begrippen horen dus bij dezelfde keten, maar zijn niet onderling uitwisselbaar.
De rol van UBL 2.1 binnen Peppol-facturatie
UBL 2.1 is een versie van de Universal Business Language-standaard die OASIS als definitieve standaard publiceerde. Voor facturen binnen Peppol BIS Billing 3.0 blijft die versie technisch relevant: de actuele Peppol-regels geven aan dat UBLVersionID, wanneer het element aanwezig is, de waarde 2.1 hoort te hebben. Dat betekent niet dat elke willekeurige UBL 2.1-factuur automatisch aan Peppol BIS voldoet. De gebruikte CustomizationID, profielregels, verplichte velden, codes en rekenregels moeten eveneens correct zijn.
Voor softwareselectie is “ondersteunt UBL 2.1” daarom slechts een eerste vraag. Vraag ook welk profiel de software genereert, welke validatieregels worden toegepast en of ontvangen documenten tegen dezelfde eisen worden gecontroleerd. In België is voor Peppol in Odoo 19 bijvoorbeeld BIS Billing 3.0 de relevante formaatkeuze bij de verificatie van een klant als Peppol-deelnemer.
UBL-facturen maken, versturen en ontvangen in Odoo
Volgens de officiële Odoo 19-documentatie over elektronische facturatie ondersteunt Odoo elektronische facturatie vanuit de boekhoud- en facturatieflow. Bij een bevestigde verkoopfactuur kan het relevante e-facturatieformaat in het verzendvenster worden gebruikt, waarna Odoo het overeenkomstige XML-document genereert. Voor Belgische Peppol-facturatie moet de klant correct zijn ingericht en wordt BIS Billing 3.0 als formaat gebruikt. De kwaliteit van de UBL-data begint dus vóór het verzenden: bedrijfsgegevens, ondernemingsnummer, klantfiche, btw-instellingen, betalingsvoorwaarden en productbelastingen bepalen mee welke gegevens in het document terechtkomen.
Wie de volledige financiële context wil begrijpen, kan dit combineren met de gids over Odoo Boekhouding voor Belgische kmo’s. UBL is daarbij geen los exportformaat, maar een onderdeel van de factuurketen van brondata tot boeking, verzending, ontvangst, controle en betaling.
UBL-verkoopfacturen maken en versturen in Odoo
Voor een uitgaande e-factuur vertrek je in Odoo van een correcte, bevestigde klantfactuur. Vanuit Verzenden kies je het relevante elektronische facturatieformaat. Odoo genereert vervolgens het overeenkomstige XML-bestand en kan het document via Peppol verzenden wanneer de configuratie en deelnemer correct zijn ingesteld. Controleer vóór verzending vooral de klantidentificatie, btw-behandeling, factuurregels, betalingsgegevens en eventuele koper- of bestelreferenties. Een fout in de brondata wordt anders netjes in een technisch correct document overgenomen.
Een praktisch testscenario omvat minstens een gewone factuur, creditnota, korting, meerdere btw-categorieën en een factuur met aankoopreferentie. Test daarnaast wat er gebeurt wanneer een klant niet correct als Peppol-deelnemer is geverifieerd of wanneer een verplicht veld ontbreekt. Zo weet je vóór livegang of gebruikers duidelijke foutmeldingen krijgen en of de correctie op de juiste plaats in de masterdata gebeurt.
UBL-leveranciersfacturen ontvangen en verwerken in Odoo
Aan de inkomende kant kan Odoo Peppol-documenten ontvangen en naar een gekozen inkoopdagboek of documentenmap sturen. De gestructureerde gegevens worden gebruikt om de leveranciersfactuur voor verdere verwerking voor te bereiden. Daardoor hoeft software leverancier, datum, regels, belastingen en totalen niet eerst uit een PDF af te leiden. Toch blijft gebruikerscontrole nodig: is de juiste leverancier gekoppeld, bestaat het factuurnummer al, past de btw-behandeling en klopt de betaling met de onderliggende aankoop?
Richt daarnaast duidelijke rechten en uitzonderingsflows in. Een medewerker die een leveranciersrekening kan wijzigen, facturen kan goedkeuren én betalingen kan vrijgeven, creëert een ander risico dan een technisch foutieve UBL-factuur. De winst van automatisering ontstaat wanneer correcte gestructureerde data wordt gecombineerd met functiescheiding, logging en gerichte controle op afwijkingen.
UBL-facturen koppelen aan aankoopcontrole en 3-way matching
Een inkomende UBL-factuur wordt pas echt interessant wanneer de gestructureerde gegevens kunnen worden vergeleken met wat de organisatie verwachtte te ontvangen. Daar komt aankoopcontrole in Odoo in beeld. De leveranciersfactuur kan worden beoordeeld tegenover bestelling, ontvangst, prijsafspraken en goedkeuringen. Een bestelreferentie in de UBL-data maakt zo’n koppeling makkelijker, maar de uiteindelijke proceslogica moet in het ERP blijvend correct zijn ingericht.
Bij een klassiek 3-way matching-proces in Odoo vergelijk je aankooporder, goederenontvangst en leveranciersfactuur. UBL kan de factuurzijde van die controle betrouwbaarder aanleveren, maar bepaalt niet automatisch of een afwijking aanvaardbaar is. Stel toleranties, verantwoordelijkheden en uitzonderingen daarom expliciet in. Een verschil van één cent door afronding vraagt een andere behandeling dan een dubbele levering of onverwachte prijsstijging.
UBL-facturatie implementeren in complexe bedrijfsworkflows
UBL-facturatie implementeren wordt belangrijker naarmate een organisatie meer entiteiten, leveranciers, goedkeuringsniveaus en uitzonderingen heeft. Bij grotere bedrijven en corporate omgevingen gaat het niet alleen om UBL-facturen genereren, maar om complexe workflows rond masterdata, validatie, routing, aankooporders, ontvangsten, functiescheiding en foutafhandeling. Leg daarom vast welke systemen bronhouder zijn, welke profielen worden ondersteund, waar uitzonderingen terechtkomen en wie ze mag oplossen. Ook groeiende KMO’s profiteren zo van automatische controles en een reproduceerbare end-to-end factuurflow.
Checklist: 10 controles voor betrouwbare UBL-software
Een softwareleverancier die zegt dat zijn pakket “UBL ondersteunt”, kan daarmee verschillende dingen bedoelen. Sommige systemen exporteren alleen een XML-bestand. Andere kunnen UBL genereren, valideren, ontvangen, visualiseren en koppelen aan boekhoudkundige of aankoopprocessen. Beoordeel daarom niet het vinkje op de featurelijst, maar de volledige keten. Deze praktische checklist helpt om technische ondersteuning, gebruiksgemak, compliance en procescontrole heel concreet afzonderlijk te beoordelen.
- De software genereert een UBL-factuur volgens het profiel dat voor jouw transacties nodig is.
- Bedrijfs-, klant-, btw- en betaalgegevens worden correct in de XML geplaatst.
- Verkoopfacturen en creditnota’s worden vóór verzending gevalideerd.
- Inkomende gestructureerde facturen kunnen automatisch worden ontvangen en verwerkt.
- Gebruikers kunnen de originele XML én een leesbare voorstelling raadplegen.
- Foutmeldingen verwijzen naar concrete velden of regels in plaats van een generieke importfout.
- Dubbele facturen, onlogische bedragen en afwijkende totalen worden zichtbaar gemaakt.
- Aankooporders, ontvangsten en goedkeuringen kunnen aan de factuur worden gekoppeld.
- Rollen, rechten, logging en archivering zijn ingericht.
- Testscenario’s omvatten creditnota’s, kortingen, meerdere btw-codes, uitzonderingen en foutieve masterdata.
Wie deze tien punten alleen als technische checklist behandelt, mist een deel van de waarde. Een goede implementatie kijkt ook naar eigenaarschap van stamgegevens, uitzonderingsbeheer, training en rapportering. De vraag is niet alleen “kan de software UBL lezen?”, maar “kan onze organisatie er betrouwbaar mee werken zonder dat fouten onzichtbaar versnellen?”
Van UBL-bestand naar betrouwbaar facturatieproces
Een UBL-factuur maakt gegevensuitwisseling consistenter, maar bedrijfswaarde ontstaat pas wanneer de volledige verwerking goed is ingericht. Leg vast wie stamgegevens beheert, welke controles vóór verzending gelden, wie afgekeurde documenten onderzoekt en wanneer een inkomende factuur mag worden geboekt of betaald. Meet daarna doorlooptijd, foutpercentages, automatische verwerking en uitzonderingen. Zo wordt zichtbaar of UBL werkelijk manueel werk vermindert of alleen een technische laag boven op een onduidelijk proces legt.
De verkeerde doelstelling is: “we kunnen een UBL-bestand exporteren”. De betere doelstelling is: “een correcte factuur beweegt aantoonbaar van brongegevens naar verzending, ontvangst, controle, boeking en betaling”. Dat vraagt samenwerking tussen finance, aankoop, masterdatabeheer, IT en de implementatiepartner. Wanneer die rollen duidelijk zijn, wordt de UBL-factuur niet alleen een antwoord op e-facturatieregels, maar ook een praktische bouwsteen voor financiële automatisering.
Conclusie: een UBL-factuur is meer dan een XML-bijlage
Een UBL-factuur is een gestructureerd zakelijk document dat XML gebruikt om factuurgegevens een vaste betekenis te geven. Daardoor kunnen verschillende systemen dezelfde leverancier, klant, regels, belastingen, totalen, referenties en betaalgegevens herkennen. Iedere UBL-factuur is XML, maar niet ieder XML-bestand volgt UBL. Voor Belgische B2B-e-facturatie moet je bovendien kijken naar EN 16931, Peppol BIS Billing 3.0 en de manier waarop het document wordt uitgewisseld.
In Odoo kan die gestructureerde gegevensstroom worden verbonden met verkoop, aankoop, boekhouding, documenten en factuurcontrole. De grootste winst komt echter niet van het bestandsformaat op zich, maar van betrouwbare brondata en een goed ingericht proces. Controleer daarom niet alleen of software “UBL kan”, maar ook welk profiel ze ondersteunt, hoe ze valideert, hoe inkomende documenten worden gekoppeld en welke controles blijven bestaan voordat een factuur wordt betaald.
Veel gestelde vragen
Hieronder beantwoorden we de vragen die bij een UBL-implementatie meestal pas na de technische uitleg opduiken. De aandacht verschuift dan van het bestandsformaat naar de praktijk: wettelijke verplichtingen, implementatieduur, integraties, migratie en interne controle. Die beslissingen bepalen of UBL-facturatie alleen technisch werkt of ook betrouwbaar in je dagelijkse Odoo-processen past. Gebruik de antwoorden daarom als startpunt voor je eigen proces- en configuratiecheck.
Is een UBL-factuur verplicht in België sinds 2026?
Voor quasi alle B2B-handelingen tussen Belgische btw-plichtige ondernemingen is sinds 01-01-2026 een gestructureerde elektronische UBL-factuur of gelijkwaardige conforme e-factuur verplicht. Een gewone PDF via e-mail volstaat voor die transacties niet meer. Dat betekent niet dat de wet uitsluitend het woord UBL voorschrijft. De factuur moet voldoen aan de Europese norm EN 16931 en praktisch in Peppol BIS-formaat kunnen worden uitgewisseld. Onder voorwaarden kan een alternatief formaat worden gebruikt als beide partijen daarmee akkoord gaan en dezelfde Europese norm wordt gerespecteerd. Controleer uitzonderingen daarom altijd zorgvuldig met je boekhouder of fiscaal adviseur op basis van je concrete btw- en transactiesituatie.
Hoe lang duurt UBL-facturatie implementeren in Odoo?
De doorlooptijd hangt vooral af van de kwaliteit van je masterdata, de huidige facturatieflow en het aantal uitzonderingen. Bij een eenvoudige Belgische Odoo-omgeving kan de technische Peppol-configuratie relatief beperkt zijn, maar een betrouwbare UBL-factuurimplementatie vraagt meer dan alleen activeren. Controleer ondernemingsgegevens, klantidentificatie, btw-codes, betalingsvoorwaarden, referenties, creditnota’s en de verwerking van inkomende leveranciersfacturen. Test ook foutscenario’s en bepaal wie uitzonderingen opvolgt. In een complexere organisatie met meerdere vennootschappen, goedkeuringsflows of koppelingen kan de voorbereiding aanzienlijk meer tijd vragen. Plan daarom eerst een proces- en datacheck voordat je een concrete implementatieduur vastlegt.
Welke integraties zijn nodig voor UBL en Peppol in Odoo?
Voor een Belgische UBL-factuur via Peppol kan Odoo zelf als toegangspunt en Service Metadata Publisher functioneren, waardoor niet automatisch een afzonderlijk extern e-facturatieplatform nodig is. De relevante integraties hangen vooral af van je bredere proces. Denk aan koppelingen met webshop, aankoopplatform, externe boekhouding, documentbeheer, banken of gespecialiseerde goedkeuringssoftware. Bepaal per koppeling welke gegevens de bron zijn, wie eigenaar is van klant- en leveranciersdata en hoe fouten worden teruggekoppeld. Vermijd dubbele conversies tussen PDF, XML en UBL wanneer systemen rechtstreeks gestructureerde gegevens kunnen uitwisselen. Test bovendien zowel uitgaande als inkomende facturen end-to-end, inclusief creditnota’s, referenties, btw en uitzonderingen.
Kan je bestaande PDF- of XML-facturen naar UBL omzetten bij een migratie?
Ja, maar een migratie of conversie is meer dan een bestandsextensie wijzigen. Bij een PDF die je naar een UBL-factuur wilt omzetten, moeten factuurgegevens eerst worden herkend, bijvoorbeeld via OCR, vervolgens naar de juiste zakelijke velden worden gemapt en daarna volgens het vereiste UBL-profiel worden opgebouwd en gevalideerd. Een willekeurig XML-bestand is evenmin automatisch UBL: de elementnamen, structuur en business rules moeten overeenstemmen met het afgesproken profiel. Voor historische facturen is conversie alleen zinvol wanneer er een concrete proces- of archiveringsbehoefte bestaat. Voor nieuwe transacties is het meestal robuuster om UBL rechtstreeks vanuit de bronsoftware te genereren, zodat interpretatie- en mappingfouten worden vermeden.
Welke controles en beveiliging blijven nodig nadat Odoo een UBL-factuur ontvangt?
Controleer eerst of Odoo de juiste leverancier heeft gekoppeld, of het factuurnummer niet dubbel voorkomt en of btw, valuta, vervaldatum en totalen logisch zijn. Vergelijk de factuur waar mogelijk met aankooporder, goederenontvangst of uitgevoerde prestatie. Kijk ook naar rekeningnummer, kortingen, toeslagen en afwijkende referenties. Richt functiescheiding zo in dat één gebruiker niet onbeperkt leveranciersgegevens, boeking, goedkeuring én betaling kan wijzigen. Log wijzigingen aan kritieke masterdata en maak uitzonderingen zichtbaar in een gecontroleerde workflow. UBL vermindert vooral interpretatie en overtypen; de onderneming blijft verantwoordelijk voor correcte boeking, goedkeuring, beveiliging en betaling.
Odoo updates 1×/maand (Gratis, geen spam)
Odive Digest
Odoo updates voor KMO’s
Elke maand één compacte mail met de belangrijkste Odoo inzichten.
Geen verkooppraat, wél praktisch toepasbare tips.
