Je financeverantwoordelijke heeft de btw-codes gecontroleerd, de factuurstromen gestandaardiseerd en de maandafsluiting eindelijk onder controle. Toch verschijnt al een volgend dossier op de radar: e-reporting België. Daarbij gaat het niet om een nieuw factuurformaat, maar om het sneller rapporteren van een afgebakende set transactionele gegevens aan de belastingadministratie. Voor ondernemingen die met Odoo werken, roept dat meteen praktische vragen op. Welke data worden belangrijk? Is Odoo al klaar? En welke voorbereiding heeft vandaag zin zonder vooruit te lopen op regels die nog niet definitief zijn? Deze gids maakt e-reporting in Odoo concreet zonder de Belgische plannen als definitieve wet voor te stellen.
Laatst bijgewerkt op 23-06-2026. De Belgische wetgeving en technische specificaties zijn nog in ontwikkeling. Daarom maken we in deze gids telkens onderscheid tussen officieel bevestigde informatie, actuele werkhypothesen uit het overleg en onderdelen die nog niet vastliggen. Deze inhoud vervangt geen individueel fiscaal of juridisch advies.
Wat is e-reporting in België?
E-reporting België is de geplande elektronische rapportering van een gestructureerde subset van transactionele en fiscale gegevens aan de overheid. Die gegevens zouden dichter bij het moment van de transactie worden doorgestuurd dan bij de huidige periodieke btw-aangiften en jaarlijkse listings. Near-real-time btw-rapportering betekent daarbij niet automatisch dat elke factuur binnen enkele seconden moet worden gemeld. De uiteindelijke Belgische termijn, dataset, uitzonderingen en foutprocedures moeten nog definitief worden vastgelegd in wetgeving en uitvoeringsregels.
De officiële Belgische FAQ bevestigt dat sinds 01-01-2026 nog geen factuurgegevens automatisch aan de administratie worden bezorgd als onderdeel van e-reporting België. De maatregel staat wel in het federale regeerakkoord, met 2028 als politieke timing, maar was op 18-06-2026 nog niet omgezet in Belgische wetgeving. Volgens dezelfde bron zou near-real-time btw-rapportering de jaarlijkse klantenlisting op termijn vervangen en betrekking hebben op transacties tussen twee Belgische btw-plichtige ondernemingen.
Voor e-reporting in Odoo is dit onderscheid essentieel. Een factuur verwerken in een ERP, een btw-aangifte voorbereiden en transactionele gegevens rapporteren zijn drie verwante maar afzonderlijke processen. De huidige richting is dat een e-report een beperkte set gegevens uit de factuur bevat en geen kopie vormt van de volledige boekhouding. E-reporting België geeft de fiscus dus niet automatisch toegang tot je complete Odoo-database, bijlagen, interne notities of andere bedrijfsinformatie die buiten de vastgelegde dataset valt.
E-reporting is niet hetzelfde als elektronische facturatie
Elektronische facturatie regelt hoe een gestructureerde factuur tussen leverancier en klant wordt uitgewisseld. E-reporting België gaat over de fiscale gegevens die uit zo'n transactie aan de overheid worden gemeld. We beperken ons hier bewust tot die rapporteringslaag. Voor de bestaande factuuruitwisseling en technische aansluiting heeft Odive al een afzonderlijke uitleg over de Peppol-integratie in Odoo. Een succesvol verzonden factuur bewijst immers nog niet dat alle vereiste e-reportingdata correct, volledig en tijdig werden verwerkt.
Het factuurformaat zelf vormt nog een afzonderlijke laag. Wil je begrijpen hoe de gegevens in zo’n gestructureerde elektronische factuur technisch zijn opgebouwd, lees dan ook onze uitleg over UBL, XML en gestructureerde e-facturen. Daar leggen we onder meer uit hoe een UBL-factuur is opgebouwd, hoe UBL verschilt van gewone XML en welke rol het formaat speelt binnen elektronische facturatie.
E-reporting België 2028: wat staat al vast en wat nog niet?
Rond e-reporting België circuleren veel stellige uitspraken, terwijl niet alle onderdelen dezelfde juridische status hebben. De veilige aanpak is daarom werken met vier categorieën: bevestigd, politiek aangekondigd, technisch voorbereid en nog onbekend. Die nuance is belangrijk voor ondernemers, accountants en softwareleveranciers. E-reporting in Odoo kan pas definitief worden ontworpen zodra de nationale dataset, termijnen, uitzonderingen, ontvangstbevestigingen en correctieprocedures voldoende nauwkeurig zijn gepubliceerd.
Volgens een ITAA-update van 29-05-2026 bevond het wetsontwerp zich in de slotfase van het pre-parlementaire traject. De werkplanning ging uit van publicatie van de wet in het najaar van 2026 en een uitvoeringsbesluit begin 2027. Dat is relevante planningsinformatie, maar nog geen geldende regel. Voor e-reporting België moeten toekomstige besluiten, circulaires en FAQ's uiteindelijk bepalen hoe ondernemingen de verplichting concreet uitvoeren.
Een goede roadmap maakt daarom onderscheid tussen inventariseren, voorbereiden, ontwerpen, testen en formeel valideren. De eerste twee stappen kunnen nu al beginnen. E-reporting in Odoo vraagt bijvoorbeeld inzicht in factuurbronnen, btw-configuraties, maatwerk en integraties. Het is daarentegen te vroeg om een specifieke connector of module als volledig conform met e-reporting België 2028 te bestempelen zolang de Belgische specificaties nog niet definitief zijn.
Wie moet rapporteren en binnen welke termijn?
De actuele werkhypothese is dat zowel de uitreiker als de ontvanger van een factuur rapporteert. Volgens ITAA zou de ontvangende zijde niet manueel hoeven te bevestigen dat een factuur inhoudelijk werd aanvaard of geboekt. De technische ontvangst van de factuur zou de trigger vormen. Voor near-real-time btw-rapportering wordt in het overleg een termijn van vijf dagen genoemd, afgestemd op ViDA. Deze elementen zijn belangrijk, maar moeten nog in de definitieve Belgische regels worden bevestigd.
Voor e-reporting in Odoo betekent dubbele rapportering niet noodzakelijk dubbel administratief werk. Wanneer de verwerking correct in de bestaande softwareflow wordt geïntegreerd, kan de rapportering grotendeels automatisch verlopen. Het systeem moet dan wel onderscheid kunnen maken tussen een technisch ontvangen bericht, een inhoudelijk goedgekeurde factuur en een geboekte leveranciersfactuur. Die statussen zijn niet hetzelfde en mogen in Odoo of een gekoppelde toepassing niet met elkaar worden verward.
De beoogde termijn van vijf dagen verklaart waarom e-reporting België vaak near-real-time wordt genoemd. Het is sneller dan maandelijkse of kwartaalgebonden rapportering, maar niet noodzakelijk onmiddellijk. Ondernemingen moeten daarom niet alleen gegevens versturen, maar ook opvolgen of de rapportering tijdig werd ontvangen, geweigerd of opnieuw verzonden. Near-real-time btw-rapportering verschuift de controle van een periodieke piek naar een doorlopend proces.
Welke ondernemingen en transacties kunnen worden geraakt?
De officiële Belgische communicatie richt zich op binnenlandse transacties tussen Belgische btw-plichtige ondernemingen. Daardoor raakt e-reporting België in de eerste plaats aan Belgische B2B-verkoop- en aankoopstromen. In Odoo kunnen die transacties ontstaan in Accounting, Sales, Purchase, Point of Sale, eCommerce of een extern systeem. Niet elke onderneming, factuurlijn of bijzondere regeling zal noodzakelijk op dezelfde manier worden behandeld. Definitieve uitzonderingen moeten nog in de wet en uitvoeringsregels worden afgebakend.
Bij een klassieke Belgische B2B-verkoop is de gegevensstroom relatief overzichtelijk: de onderneming levert goederen of diensten, maakt een factuur op en verwerkt de btw. E-reporting in Odoo wordt complexer zodra facturen buiten de standaardstroom ontstaan. Denk aan self-billing, facturatie door een derde partij, voorschotten, creditnota's, periodieke afrekeningen, kassaverkopen of facturen die eerst in een webshop worden gemaakt en pas later in Odoo terechtkomen.
Volgens ITAA zouden handelingen die onder artikel 44 van het Belgische btw-wetboek zijn vrijgesteld buiten de voorgestelde scope blijven. Bij gemengde facturen zouden alleen de belastbare lijnen worden gerapporteerd. Dat is nog een werkmodel, maar het toont waarom near-real-time btw-rapportering meer is dan een technische verbinding. De fiscale betekenis van iedere relevante factuurlijn moet correct uit de brondata kunnen worden afgeleid.
Grensoverschrijdende B2B-transacties volgen daarnaast het Europese ViDA-traject. Die afbakening voorkomt dat e-reporting België 2028 wordt vermengd met alle Europese verplichtingen. Vanaf 01-07-2030 worden Europese Digital Reporting Requirements van toepassing op grensoverschrijdende B2B-transacties. De Belgische binnenlandse roadmap en de Europese roadmap hangen samen, maar kennen verschillende deadlines en toepassingsgebieden.
Welke gegevens krijgt de fiscus via e-reporting België?
De vraag of de fiscus straks de volledige factuur of complete Odoo-database kan bekijken, wordt vaak te stellig beantwoord. De huidige richting voor e-reporting België is een gestructureerde subset van bestaande factuurdata. Volgens ITAA blijft de Belgische dataset zo dicht mogelijk bij het ViDA Tax Data Document. De exacte nationale selectie moet echter nog in het uitvoeringsbesluit worden vastgelegd. Daarom kunnen we vandaag gegevenscategorieën aanduiden, maar geen definitieve veldmapping beloven.
E-reporting in Odoo staat of valt daardoor met betrouwbare brondata. Een connector kan geen verkeerd btw-nummer, foutieve fiscale positie of onjuiste belastingcode inhoudelijk herstellen zonder bijkomende regels en risico's. De data die vandaag de Belgische boekhouding in Odoo ondersteunen, worden waarschijnlijk ook bepalend voor de toekomstige rapporteringskwaliteit.
Near-real-time btw-rapportering verhoogt bovendien het belang van tijdige correcties. Wanneer een fout pas tijdens de maandafsluiting wordt ontdekt, kan de oorspronkelijke transactie al eerder zijn gemeld. De uiteindelijke Belgische regels moeten bepalen hoe correcties, annuleringen, creditnota's en herverzendingen worden gekoppeld. De audittrail moet in elk geval duidelijk aantonen wat oorspronkelijk werd gerapporteerd en welke wijziging daarna volgde.
Krijgt de fiscus toegang tot je volledige Odoo-database?
Op basis van de huidige officiële informatie is daar geen aanwijzing voor. E-reporting België wordt beschreven als de elektronische verzending van een afgebakende dataset, niet als rechtstreekse toegang tot het volledige ERP. De fiscus krijgt dus niet automatisch toegang tot alle klantenhistoriek, interne communicatie, documenten, prijsafspraken, marges of gebruikersnotities in Odoo. Welke concrete factuurvelden worden gerapporteerd, moet nog officieel worden vastgelegd.
Dit onderscheid is ook belangrijk voor beveiliging en gegevensbescherming. E-reporting in Odoo vereist een gecontroleerde gegevensstroom vanuit de bron naar de rapporteringsdienst. Ondernemingen moeten kunnen aantonen welke gegevens worden geselecteerd, wie de configuratie mag wijzigen en hoe technische logs worden beschermd. Een gerichte aanpak voor gegevens afschermen in Odoo blijft daarom relevant, ook wanneer de fiscale rapportering grotendeels automatisch verloopt.
Near-real-time btw-rapportering mag evenmin worden verward met voorafgaande goedkeuring van iedere factuur door de overheid. De huidige Belgische informatie spreekt over rapportering en gerichte risicoanalyse. Een definitief clearance- of goedkeuringsmodel is op 18-06-2026 niet vastgelegd. Formuleringen als “de fiscus keurt elke factuur eerst goed” gaan daarom verder dan wat officieel kan worden bevestigd.
Wat verandert e-reporting in Odoo in je ERP-landschap?
E-reporting in Odoo raakt niet alleen Accounting. De benodigde gegevens kunnen ontstaan in verkooporders, aankopen, webshops, kassasystemen, externe facturatietools of integratieplatformen. De centrale vraag is welke toepassing de juridische factuur creëert, waar de fiscale classificatie wordt bepaald en waar de rapporteringsstatus wordt bewaard. E-reporting België maakt het noodzakelijk om die verantwoordelijkheden expliciet vast te leggen in plaats van ze impliciet over verschillende systemen te verdelen.
In een eenvoudige omgeving wordt de verkoopfactuur volledig in Odoo opgesteld, geboekt en gecorrigeerd. Dan bevinden de meeste brongegevens zich in één systeem. In een complex landschap kan een Odoo-webshopkoppeling orders aanleveren, een koppeling tussen Odoo en een e-facturatieplatform de juridische factuur verwerken en een integratie alleen boekingsregels naar Odoo sturen. Near-real-time btw-rapportering maakt zulke verschillen zichtbaar, omdat een rapport niet mag ontbreken of dubbel worden verstuurd.
Hetzelfde geldt voor verkoop via een kassasysteem in Odoo. Wanneer kassatransacties worden samengevoegd, gecorrigeerd of achteraf aan een zakelijke klant worden gekoppeld, moet duidelijk zijn welke gebeurtenis relevant is voor e-reporting België. De definitieve regels zullen bepalen welke stromen onder de B2B-verplichting vallen, maar de onderneming kan nu al documenteren hoe gegevens door haar landschap bewegen.
E-reporting in Odoo vraagt ook duidelijke technische eigenaarschap. Een Odoo API-integratie kan gegevens transporteren, maar mag niet ongemerkt de fiscale betekenis van een factuur wijzigen. Mappings, unieke referenties, herverzendmechanismen en foutcodes moeten controleerbaar zijn. Wie alleen controleert of een bericht technisch werd verzonden, mist mogelijk inhoudelijke fouten in de brondata.
Is Odoo vandaag al klaar voor e-reporting België?
Odoo bevat vandaag veel gegevens en fiscale logica waarop e-reporting België kan voortbouwen. De Belgische lokalisatie ondersteunt onder meer btw-rapporten, de Partner VAT Listing, de EC Sales List en Intrastat. Odoo 19 documenteert ook tax grids, belastingconfiguratie, fiscale posities, validatiecontroles en lock dates. Die functies bewijzen dat het ERP over relevante bouwstenen beschikt, maar vormen nog geen officiële Belgische e-reportingoplossing.
Op 18-06-2026 bevat de officiële Odoo 19-documentatie geen afzonderlijk gedocumenteerde workflow voor e-reporting in Odoo volgens de toekomstige Belgische regels. Er is nog geen definitieve nationale dataset, officiële foutcodetabel of beschreven rapporteringsprocedure waarmee volledige conformiteit kan worden getest. Daarom is de correcte conclusie niet dat Odoo ongeschikt is, maar dat een finale complianceclaim vandaag voorbarig blijft.
De uiteindelijke ondersteuning kan bovendien verschillen volgens Odoo-versie, hostingmodel, Enterprise- of Community-editie, lokalisatiemodules en maatwerk. Ondernemingen die met een oudere release werken, moeten hun Odoo-upgradestrategie tijdig bespreken. Near-real-time btw-rapportering zal waarschijnlijk sneller evolueren dan een zwaar aangepaste omgeving zonder regelmatig upgradepad kan volgen.
Voor e-reporting in Odoo is het daarom verstandiger om nu de basis te versterken dan een definitieve technische oplossing te kopen. Controleer of de Belgische lokalisatie correct is ingericht, breng afwijkende factuurstromen in kaart en documenteer maatwerk. Zodra de officiële specificaties verschijnen, kan de onderneming gericht beoordelen welke standaardfunctionaliteit, update of integratie werkelijk nodig is.
Welke Odoo-data moeten nu al op orde zijn?
E-reporting België vergroot het belang van gegevens die vandaag soms pas tijdens de btw-controle worden gecorrigeerd. Btw-nummers, landen, juridische entiteiten, belastingen en fiscale posities bepalen hoe een transactie wordt geclassificeerd. Wanneer die brongegevens fout zijn, kan e-reporting in Odoo een technisch geldig maar fiscaal onjuist bericht produceren. Dat maakt datakwaliteit een procesverantwoordelijkheid en niet alleen een eenmalig opschoningsproject. Die kwaliteit moet bovendien doorlopend worden bewaakt, omdat klanten, leveranciers en fiscale regels blijven veranderen.
Een formeel beleid voor Odoo-data governance helpt bepalen wie stamgegevens mag aanmaken, wijzigen en goedkeuren. Leg minimaal eigenaarschap vast voor bedrijfsgegevens, contactfiches, btw-nummers, fiscale posities, belastingen, tax grids en uitzonderingscodes. Near-real-time btw-rapportering verkleint immers de tijd tussen invoer en extern gebruik van de gegevens.
Bij ondernemingen met meerdere vennootschappen in Odoo moet iedere juridische entiteit correct worden geïdentificeerd. Een gedeeld contact of product kan praktisch zijn, maar de rapporterende onderneming, toegepaste belasting en factuurreeks moeten ondubbelzinnig blijven. E-reporting België mag niet leiden tot een rapport onder het verkeerde btw-nummer of vanuit de verkeerde onderneming.
Controleer daarnaast creditnota's, terugbetalingen en correcties. Een aanpassing mag niet alleen het saldo herstellen; ze moet ook traceerbaar blijven naar de oorspronkelijke factuur. E-reporting in Odoo zal waarschijnlijk nood hebben aan een betrouwbare referentie tussen beide documenten. Hetzelfde geldt voor manuele journaalposten die btw beïnvloeden zonder klassieke factuurflow.
Waar zitten de grootste risico's?
De grootste risico's voor e-reporting België ontstaan niet noodzakelijk in de standaardfactuur. Ze zitten vaak in uitzonderingen, koppelingen en historisch maatwerk. Een organisatie kan duizenden gewone facturen correct verwerken en toch problemen krijgen bij self-billing, gemengde facturen, correcties of externe verkoopkanalen. Near-real-time btw-rapportering vereist daarom scenario-gebaseerde tests en niet alleen een technische connectiviteitstest. Ook kleine afwijkingen kunnen zich bij doorlopende rapportering snel over een groot aantal transacties verspreiden.
Een eerste risico is onvolledige bronregistratie. Wanneer een extern systeem alleen totalen naar Odoo doorstuurt, ontbreken mogelijk lijngegevens die voor e-reporting België relevant worden. Een tweede risico is dubbele rapportering wanneer zowel het externe facturatiesysteem als Odoo dezelfde transactie meldt. Een derde risico is dat een integratie een bericht opnieuw verstuurt zonder betrouwbare unieke sleutel, waardoor dezelfde factuur meer dan één keer wordt geregistreerd.
Maatwerk vormt een apart aandachtspunt. Custom modules kunnen belastingcodes, factuurnummers, boekingsdatums of correctieflows wijzigen. E-reporting in Odoo moet daarom deel worden van de regressietests bij toekomstige upgrades. Een Odoo-securityaudit kan daarnaast nagaan welke gebruikers of integratieaccounts gevoelige configuratie mogen aanpassen en of wijzigingen voldoende worden gelogd.
Ook operationele opvolging is een risico. Een groen technisch verzendbericht is niet altijd hetzelfde als een fiscaal aanvaard rapport. De definitieve procedures zullen bepalen welke statussen bestaan, maar ondernemingen kunnen nu al een incidentproces voorbereiden. Near-real-time btw-rapportering vraagt iemand die waarschuwingen opvolgt, fouten onderzoekt en tijdig beslist of een rapport moet worden gecorrigeerd of opnieuw verstuurd.
Wie is verantwoordelijk voor e-reporting in Odoo?
E-reporting in Odoo is geen verantwoordelijkheid die volledig bij één partij kan worden neergelegd. De onderneming blijft verantwoordelijk voor haar transacties en brongegevens. De accountant beoordeelt de fiscale verwerking en uitzonderingen. De Odoo-partner beheert configuratie, maatwerk en technische tests binnen de afgesproken scope. De rapporterings- of netwerkdienst zorgt voor transport en technische terugmeldingen. E-reporting België vereist daarom duidelijke afspraken over wie controleert, wie corrigeert en wie escaleert.
Maak deze verantwoordelijkheden concreet in een RACI-matrix en leg ook vervanging vast bij afwezigheid. Near-real-time btw-rapportering stopt niet tijdens vakantie of ziekte. Voor e-reporting België moet bovendien duidelijk zijn wie contact opneemt met de accountant, Odoo-partner of dienstverlener wanneer een afwijking niet binnen de eigen organisatie kan worden opgelost.
Contracten verdienen eveneens aandacht. Controleer of supportovereenkomsten incidenten rond fiscale rapportering afdekken, welke responstijden gelden en wie verantwoordelijk is voor updates. E-reporting in Odoo kan alleen betrouwbaar functioneren wanneer operationele afspraken aansluiten op de technische architectuur. Een onduidelijke grens tussen software, maatwerk en dienstverlening leidt anders tot vertraging tijdens een incident.
Wat gebeurt er bij fouten, correcties en technische storingen?
E-reporting België moet ook werken wanneer de standaardflow mislukt. ITAA meldt dat uitzonderingsscenario's zoals geweigerde facturen, gemengde facturen, self-billing, facturatie door derden en btw-eenheden nog verder worden uitgewerkt. Voor near-real-time btw-rapportering is vooral belangrijk dat een technische storing niet automatisch dezelfde gevolgen heeft als een inhoudelijk foutieve transactie. De uiteindelijke Belgische regels moeten beide situaties duidelijk onderscheiden. Een goed incidentproces voorkomt dat technische en fiscale oorzaken door elkaar worden gehaald.
Volgens de ITAA-update blijft de bestaande bescherming bij bepaalde technische ontvangstproblemen behouden. Wanneer de ontvanger om louter technische redenen geen gestructureerde factuur kan ontvangen, kan een alternatief kanaal worden gebruikt en blijft het recht op aftrek volgens die toelichting behouden. De nadelige gevolgen voor e-reporting zouden bij de partij liggen die de technische tekortkoming veroorzaakt. Dit moet in de uiteindelijke operationele richtlijnen verder worden geconcretiseerd.
Voor e-reporting in Odoo moet iedere fout daarom een herkenbare status en eigenaar krijgen. Een technisch geweigerd bericht, een ontbrekende verplichte waarde, een onjuist btw-nummer en een dubbele rapportering vragen elk een andere oplossing. Bewaar originele berichten, foutmeldingen, correcties en herverzendingen in een controleerbare audittrail. Near-real-time btw-rapportering wordt anders een ondoorzichtige stroom waarin alleen de eindstatus zichtbaar blijft.
Test ook idempotentie: hetzelfde bericht mag bij een herstart niet als nieuwe transactie worden beschouwd. E-reporting België vraagt stabiele unieke referenties over de volledige keten. Wanneer een externe toepassing, middleware en Odoo elk een eigen nummer gebruiken, moet de koppeling tussen die referenties aantoonbaar blijven.
Hoe bereid je Odoo vandaag voor op e-reporting België?
Een verstandige voorbereiding op e-reporting België begint niet met een moduleaankoop, maar met inzicht. Ondernemingen kunnen vandaag al de kwaliteit van hun brondata, processen en integraties verbeteren zonder te speculeren over de definitieve technische specificatie. E-reporting in Odoo wordt daardoor later geen los complianceproject, maar een gecontroleerde uitbreiding van een reeds beheersbaar financieel landschap. Zo ontstaat een basis waarop near-real-time btw-rapportering later gecontroleerd kan worden aangesloten.
- Breng alle systemen in kaart die verkoopfacturen, leveranciersfacturen, creditnota's of relevante correcties creëren.
- Bepaal per stroom welk systeem de juridische bron vormt en waar de fiscale classificatie wordt vastgesteld.
- Controleer actieve klanten, leveranciers, btw-nummers, landen, belastingen, fiscale posities en tax grids.
- Documenteer maatwerk, API-mappings, unieke sleutels, herverzendlogica en foutafhandeling.
- Wijs eigenaars toe voor data, configuratie, fiscale beoordeling, incidenten en leverancierscontact.
- Beoordeel of je Odoo-versie en hostingmodel voldoende updatebaar zijn richting e-reporting België 2028.
- Plan tests zodra de Belgische dataset, scenario's en officiële Odoo-ondersteuning beschikbaar zijn.
De eerste vijf stappen verbeteren ook je huidige boekhouding en btw-controle. Near-real-time btw-rapportering maakt bestaande zwakke plekken alleen sneller zichtbaar. Houd de inventaris levend en koppel elke controle aan een eigenaar. E-reporting in Odoo vraagt geen paniek, maar wel aantoonbare beheersing van de processen die fiscale gegevens creëren en wijzigen.
Vermijd intussen drie overhaaste beslissingen. Laat geen zwaar maatwerk bouwen op basis van onbevestigde velden. Koop geen oplossing die volledige Belgische compliance claimt zonder officiële testspecificatie. En neem niet aan dat een accountant, Odoo-partner of netwerkprovider automatisch alle verantwoordelijkheden overneemt. E-reporting België blijft een gedeelde keten waarin iedere partij haar eigen controles moet uitvoeren.
Wat betekent ViDA voor Odoo en buitenlandse transacties?
ViDA, voluit VAT in the Digital Age, vormt de Europese context voor digitale btw-rapportering. Vanaf 01-07-2030 gelden Digital Reporting Requirements voor grensoverschrijdende B2B-transacties binnen de Europese Unie. Lidstaten met een binnenlands digitaal rapporteringssysteem moeten dat systeem uiterlijk tegen 01-01-2035 afstemmen op de Europese standaarden. E-reporting België kan daarom niet volledig los van ViDA worden ontwikkeld. Internationale Odoo-omgevingen moeten daarom nationale en Europese deadlines afzonderlijk kunnen beheren.
Voor e-reporting in Odoo betekent dit dat internationale ondernemingen twee roadmaps nodig hebben. De Belgische roadmap behandelt binnenlandse B2B-transacties richting 2028. De Europese roadmap behandelt grensoverschrijdende transacties richting 2030 en verdere harmonisatie. Near-real-time btw-rapportering krijgt daardoor verschillende regels volgens land, transactietype en datum. Een modulaire architectuur is veiliger dan één hard gecodeerde oplossing die alle situaties probeert te behandelen.
Odoo-omgevingen met meerdere landen of vennootschappen moeten landgebonden fiscale logica gescheiden houden van gedeelde stamdata en integratiecomponenten. E-reporting België mag een toekomstige ViDA-aanpassing niet blokkeren, maar ViDA hoeft vandaag evenmin volledig te worden nagebouwd. De beste voorbereiding bestaat uit duidelijke brondata, gedocumenteerde mappings en koppelpunten die kunnen evolueren zodra officiële specificaties verschijnen.
E-reporting België voorbereiden zonder voorbarige complianceclaim
E-reporting België verdient vandaag al aandacht, maar nog geen overhaaste technische oplossing. De politieke richting is duidelijk en de actuele werkhypothesen geven een steeds concreter beeld. Toch moeten wet, dataset, termijnen en foutprocedures nog officieel worden bevestigd. Ondernemingen gebruiken 2026 en 2027 daarom het best om hun factuurbronnen, fiscale data, maatwerk, koppelingen en verantwoordelijkheden aantoonbaar beheersbaar te maken. E-reporting België vraagt daarom een gefaseerde aanpak met duidelijke beslismomenten.
De organisaties die later het snelst kunnen testen, zijn niet noodzakelijk degene met de meeste modules. Succesvolle e-reporting in Odoo begint bij betrouwbare brondata, een duidelijke audittrail en een eigenaar voor iedere kritieke stap. Near-real-time btw-rapportering maakt fouten sneller zichtbaar, maar lost ze niet automatisch op. Een onderneming die weet waar haar gegevens ontstaan en hoe uitzonderingen worden verwerkt, kan nieuwe specificaties veel gecontroleerder invoeren. Dat is de kern van een beheerste invoering van e-reporting in Odoo.
Odive helpt ondernemingen om hun Odoo-landschap onafhankelijk te beoordelen op datakwaliteit, procesrisico's, maatwerk en integraties. Zo kun je gerichte vragen stellen aan je accountant, Odoo-partner en technische dienstverlener zodra e-reporting België verder wettelijk en technisch wordt ingevuld.
Veelgestelde vragen
Is e-reporting vanaf 2028 al definitief wettelijk verplicht in België?
Nee. E-reporting België staat in het federale regeerakkoord met 2028 als politieke timing, maar was op 18-06-2026 nog niet omgezet in Belgische wetgeving. ITAA meldde dat het wetsontwerp zich in de slotfase van het pre-parlementaire traject bevond en dat publicatie van de wet in het najaar van 2026 werd nagestreefd. De definitieve dataset, termijnen, uitzonderingen en procedures moeten vervolgens verder worden ingevuld. Ondernemingen kunnen dus al voorbereiden, maar mogen een ontwerp of werkhypothese nog niet als geldende verplichting behandelen. Near-real-time btw-rapportering krijgt pas juridische zekerheid na publicatie van de relevante teksten.
Welke factuurgegevens zal de fiscus via e-reporting ontvangen?
De huidige richting voor e-reporting België is een gestructureerde subset van bestaande factuurdata. Denk aan identificatie van leverancier en klant, factuurreferenties, datums, bedragen, valuta, btw-behandeling en correcties. Volgens ITAA wordt de Belgische dataset geïnspireerd op het ViDA Tax Data Document en zo dicht mogelijk bij die Europese basis gehouden. De definitieve veldlijst moet nog via het uitvoeringsbesluit worden vastgelegd. E-reporting in Odoo betekent dus niet dat de fiscus automatisch toegang krijgt tot de volledige Odoo-database. Near-real-time btw-rapportering selecteert specifieke fiscale gegevens uit de transactieflow. Een definitieve technische mapping kan pas worden gemaakt zodra die nationale specificatie officieel is gepubliceerd.
Moeten zowel leverancier als klant een e-report versturen?
Volgens de actuele werkhypothese die ITAA beschrijft, rapporteren zowel de uitreiker als de ontvanger. Aan de ontvangende zijde zou de technische ontvangst van de factuur de trigger vormen, zonder dat de factuur eerst inhoudelijk moet worden goedgekeurd of geboekt. Dat model is bedoeld om beide zijden van dezelfde transactie te bevestigen en inconsistenties sneller zichtbaar te maken. De praktische uitwerking moet nog officieel worden vastgelegd. Voor e-reporting in Odoo is vooral belangrijk dat ontvangst, aanvaarding en boeking afzonderlijke statussen blijven. Near-real-time btw-rapportering mag geen onbedoelde goedkeuring van een leveranciersfactuur suggereren. De onderneming moet die technische statussen daarom afzonderlijk kunnen opvolgen en auditeren.
Is Odoo vandaag al klaar voor Belgische e-reporting?
Odoo bevat relevante bouwstenen, zoals Belgische fiscale lokalisatie, belastingen, fiscale posities, tax grids, btw-rapporten en controlefuncties. Toch documenteert Odoo 19 op 18-06-2026 nog geen afzonderlijke Belgische workflow waarmee volledige e-reportingcompliance voor 2028 kan worden bevestigd. De nationale wet, dataset, foutcodes en technische procedures zijn nog niet definitief. E-reporting in Odoo kan daarom wel organisatorisch en technisch worden voorbereid, maar een finale complianceclaim is voorbarig. Controleer vooral brondata, factuurstromen, maatwerk, integraties en upgradebaarheid. Near-real-time btw-rapportering kan pas formeel worden getest zodra officiële specificaties beschikbaar zijn. De uiteindelijke beoordeling moet per database, versie, hostingmodel, lokalisatie en maatwerk worden uitgevoerd.
Vervangt e-reporting de klantenlisting en de btw-aangifte?
De officiële Belgische FAQ stelt dat near-real-time btw-rapportering de jaarlijkse klantenlisting zal vervangen. ITAA nuanceert dat dit voor het gros van de ondernemingen geldt en dat voor kleine ondernemingen en landbouwers nog een alternatieve omzetrapportering wordt onderzocht. E-reporting België wordt niet voorgesteld als vervanging van de volledige boekhouding of van alle periodieke btw-verplichtingen. De gewone btw-aangifte en fiscale verwerking blijven afzonderlijke processen zolang de wet niets anders bepaalt. E-reporting in Odoo moet daarom naast de bestaande rapportering worden ontworpen en mag niet automatisch worden gelijkgesteld aan het huidige btw-rapport in Odoo.
