Geautomatiseerde btw-rapportage per land en VIES-validatie

Een praktijkgerichte gids voor developers die EU-btw-naleving integreren in marktplaatsen en platformen met behulp van een cloud accounting API.

De meeste btw-fouten in platformcode zijn terug te voeren op één enkele aanname: dat een geldig VIES-resultaat betekent dat je het tarief kunt verleggen of het nul tarief kunt toepassen. Dat is niet zo. Voortbouwen op die kortere weg leidt tot aangiften die er prima uitzien totdat een auditor vraagt waarom er een intracommunautaire vrijstelling is toegepast zonder bewijs van transport of een consistent dossier over de plaats van de dienst. Het gat tussen "btw-nummer is in orde" en "deze prestatie is correct verwerkt" is de plek waar de meeste integraties ongemerkt de mist ingaan.

Deze gids behandelt hoe je btw-rapportage per land en VIES-validatie automatiseert met een cloud accounting API, waarbij de accounting API van Nordlet als implementatiecontext wordt gebruikt. Het doel is een systeem dat het juiste bewijsmateriaal vastlegt op het moment van de verkoop, onveranderlijke (immutable) grootboekmutaties wegschrijft en gegevens oplevert die klaar zijn voor de aangifte, gegroepeerd naar regeling en lidstaat, zonder dat je achteraf totalen in een spreadsheet hoeft te herstructureren.

Wat VIES werkelijk vertelt, en wat niet

VIES is het EU VAT Information Exchange System. Wanneer je een landcode en btw-nummer indient, raadpleegt het systeem in realtime de relevante nationale database en wordt geretourneerd of die btw-informatie geldig of ongeldig is. Dat is de volledige reikwijdte. Het bevestigt dat een nummer is geregistreerd en, mits de lidstaat dit ondersteunt, is geactiveerd voor intracommunautaire handel.

Het geeft geen recht op vrijstelling van een intracommunautaire levering. De Europese Commissie is hier helder over. Een geldig VIES-antwoord is slechts één bewijsstuk naast andere. Je moet nog steeds bevestigen dat de afnemer de daadwerkelijke ontvanger is, dat de levering kwalificeert als intracommunautair, dat er bewijs van transport of verzending aanwezig is en dat de factuur de verplichte vermelding voor de verleggingsregeling bevat.

De eerste ontwerpbeslissing is dus structureel: houd de VIES-status en de btw-behandeling in afzonderlijke velden. Koppel viesStatus: valid nooit direct aan zeroRated: true. Zodra je die twee concepten samenvat, verlies je de mogelijkheid om een behandeling te verdedigen wanneer er twijfels ontstaan over het bewijsmateriaal.

Vereisten voordat je integratiecode schijft

Voordat er ook maar één endpoint wordt aangeroepen, moet je de reikwijdte van je rapportage schrijven. Dit deel is saai en het overslaan ervan is kostbaar.

In welke landen het bedrijf gevestigd is of vaste inrichtingen heeft
In welke landen het bedrijf een btw-registratie bezit
Of het goederen, diensten, digitale diensten of een mix daarvan verkoopt
Of transacties B2B, B2C of beide zijn
Of er gebruik wordt gemaakt van lokale registraties, OSS, IOSS, verleggingsregeling of regels voor de schijnleverancier (deemed supplier) op marktplaatsen
Welke outputs de API moet genereren: lokale aangiftegegevens, OSS/IOSS-gegevens, factuurregisters zoals de i.SAF in Litouwen, uitsluitend grootboekboekingen of payloads voor een externe aangiftepartner

Dit is cruciaal omdat OSS niet elke transactie dekt. Diensten die worden geleverd in een land waar het bedrijf een vaste inrichting heeft, horen doorgaans thuis in de lokale aangifte van dat land en niet in de OSS-aangifte. Modelleer vaste inrichtingen vanaf het begin afzonderlijk, anders worden deze leveringen tijdens de aggregatie verkeerd gerouteerd.

Hardcode ook geen enkel btw-tarief per land. De EU kent standaard-, verlaagde, superverlaagde, parkeer-, nultarieven en productspecifieke behandelingen, en deze veranderen regelmatig. De betrouwbare bron voor een specifiek product in een specifieke lidstaat is de belastingdienst van dat land, waarbij de TEDB van de Commissie een cross-country overzicht biedt. Leg de bron en versie vast achter elke tariefbeslissing, zodat een latere update van de tarieventabel niet stilletjes de weergave van een oude transactie wijzigt.

Het modelleren van de btw-beslissing, niet alleen het tarief

De kern van een robuuste integratie is een btw-categoriemethode die zich bevindt tussen producten en tarieven. Koppel producten aan categorieën, categorieën aan landspecifieke btw-codes en vervolgens aan tarieven met een ingangsdatum:

product/service
    → tax category
    → country-specific tax code
    → effective-dated rate and treatment

De onveilige variant die leidt tot afwijkingen in de rapportage is product SKU → 21% VAT. Hetzelfde product kent verschillende tarieven in verschillende landen, en een tarief kan midden in een periode wijzigen. De eigen btw-nalevingshandleiding van Nordlet raadt precies deze op categorieën gebaseerde koppeling aan in plaats van producten direct aan percentages te binden.

Je taxonomie voor btw-categorieën moet stabiel en intern zijn: goederen belast tegen het standaardtarief, goederen belast tegen het verlaagde tarief, elektronisch geleverde diensten, overige diensten, vrijgestelde prestaties, belaste leveringen tegen nultarief, intracommunautaire B2B-verleggingsregeling, intracommunautaire afstandsverkoop, IOSS-import, transacties via een schijnleverancier (deemed supplier). Alles stroomafwaarts stuurt op deze taxonomie.

VIES-validatie als asynchrone bewijsworkflow

De officiële VIES-service biedt een SOAP/WSDL-interface die een landcode van twee letters en een btw-nummer verwerkt. De gedocumenteerde fouten zijn van belang voor je foutafhandeling: ongeldige invoer, wereldwijde limieten en limieten per lidstaat voor gelijktijdige verzoeken, onbeschikbaarheid van de service, onbeschikbaarheid van de lidstaat en timeouts. Behandel deze als afzonderlijke uitkomsten en niet als één enkele categorie van "mislukt".

Een workflow die standhoudt onder belasting en audits ziet er als volgt uit:

Normaliseer het btw-nummer: maak het voorvoegsel hoofdlettergevoelig, verwijder toegestane spaties of leestekens en bewaar de oorspronkelijk door de gebruiker ingevoerde waarde afzonderlijk.
Valideer de landcode en de structuur van het nummer lokaal voordat je een netwerkaanroep doet.
Dien het genormaliseerde nummer in bij VIES.
Sla het genormaliseerde ID, de tijdstippen van aanvraag en antwoord, de status geldig/ongeldig/niet-verwerkt, de ruwe respons, eventuele servicefouten, de klant- en factuur-ID's en de beslissing van de applicatie op.
Cache succesvolle resultaten voor een gedefinieerde, gedocumenteerde periode.
Probeer tijdelijke technische storingen opnieuw met een uitstelmechanisme (backoff).
Routeer onopgeloste of tegenstrijdige gevallen naar een handmatige beoordeling.
Valideer opnieuw wanneer een gecachet resultaat verouderd is of voorafgaand aan een transactie waarin het bewijsmateriaal essentieel is.

Nordlet controleert een EU-btw-nummer wanneer een klant wordt toegevoegd en voert voorafgaand aan de facturering een hercontrole uit als het eerdere resultaat verouderd is. Dit is het gewenste gedrag, ongeacht of de controle plaatsvindt in het platform of in je eigen code.

De belangrijkste regel: maak het afrekenproces niet synchroon afhankelijk van VIES. Een storing in de service is geen ongeldig nummer. Als VIES een timeout geeft tijdens een verkoop, houd de transactie dan vast ter beoordeling of ken er een voorlopige status aan toe. Het blokkeren van een afrekenproces vanwege de uptime van de service van de Commissie leidt tot supporttickets, en het ten onrechte als ongeldig aanmerken van een goede klant is schadelijker.

Scheiden van validatiestatus en btw-behandeling

Zodra je een VIES-resultaat hebt, moet de beslissingsengine extra stappen uitvoeren. Sla deze op als afzonderlijke velden:

{
  "viesStatus": "valid",
  "vatTreatment": "intra_eu_b2b_reverse_charge",
  "evidenceStatus": "reviewed",
  "placeOfSupply": "DE"
}

Voordat een verleggingsregeling of vrijstelling wordt toegepast, moet de engine controleren of de klant daadwerkelijk de ontvanger is, of het land van de klant en het btw-voorvoegsel consistent zijn, of de prestatie kwalificeert als intracommunautair, of er speciale regels voor de plaats van de dienst gelden, of er transportbewijs aanwezig is, of de verkoper optreedt als schijnleverancier en of de factuur de verplichte bewoordingen bevat. Een geldige VIES-status die aan geen van deze andere tests voldoet, is geen groen licht.

Het creëren van een onveranderlijke btw-beslissing op factuurmoment

Wanneer de factuur wordt aangemaakt, leg je de volledige beslissing daarbij vast, en dus niet alleen het uiteindelijke tarief:

invoice
  ├─ line tax category
  ├─ place of supply
  ├─ VAT scheme
  ├─ country-specific rate
  ├─ rate-table version
  ├─ VIES evidence reference
  ├─ location-evidence references
  ├─ legal-basis reference
  └─ marketplace-role flags

EU-factuurregels vereisen gegevens van leverancier en afnemer, factuurnummer, omschrijving, maatstaf van heffing (belastbaar bedrag), btw-tarief, btw-bedrag en eventuele informatie over de verleggingsregeling of vrijstelling. Creditnotas en wijzigingen vereisen een ondubbelzinnige verwijzing naar de oorspronkelijke factuur.

Het grootboek van Nordlet is onveranderlijk (immutable), waardoor correcties plaatsvinden via nieuwe boekingen zoals creditnotas of correctieboekingen in plaats van het bewerken van afgesloten administraties. Bouw je consument op rondom dat model, zelfs als je opslagtechnologie het zou toestaan om gegevens te overschrijven. Het bewerken van een afgesloten factuur vernietigt de keten tussen de oorspronkelijke aangifte en de correctie, en dat is precies de traceerbaarheid die een auditor volgt.

Boekingen, webhooks en idempotentie

Een verkoop genereert dubbel boekhoudkundige mutaties die zowel de commerciële transactie als de btw-schuld per land en regeling bewaren. Een binnenlandse verkoop kan er als volgt uitzien:

Dr Accounts receivable / payment clearing
    Cr Revenue
    Cr VAT payable - DE - domestic

Een intracommunautaire B2B-verkoop met verleggingsregeling boekt omzet zonder verschuldigde btw en met een verwijzing naar het bewijs van de verleggingsregeling. Het exacte grootboekschema is aan jou; wat telt is dat de rapportagedimensies gekoppeld blijven aan elke boeking: lidstaat, regeling, btw-categorie, tarief, periode, bronfactuur en correctieketen.

Stuur statuswijzigingen aan via webhooks in plaats van te pollen. Nordlet verstuurt events zoals sale_invoice.paid, ondertekent leveringen en voert mislukte pogingen opnieuw uit met een uitstelmechanisme. Geef elke schrijfoperatie een deterministische idempotency key:

sale:{platform_order_id}:invoice:{invoice_version}

Jouw consumer moet eveneens idempotent zijn. Een webhook kan tweemaal binnenkomen, te laat arriveren of pas vuren nadat het oorspronkelijke verzoek al is geslaagd. Verifieer handtekeningen, leg event-ID's vast, plaats misvormde events in quarantaine, verwerk ze via een duurzame wachtrij en reconcileer de webhook-status op gezette tijden met de API. Als je niet eerder hebt gewerkt met ondertekende webhooks en idempotency keys, is dit de plek waar de meest subtiele dubbele boekingsfouten zich voordoen.

Groeperen voor OSS en opleveren van aangiftekare data

Voor in aanmerking komende OSS-transacties groepeer je de grootboekgegevens per regeling, lidstaat van verbruik, type levering, tariefcategorie, tarief, belastbaar bedrag, btw-bedrag, lidstaat van vertrek of vaste inrichting, valuta en correctieperiode.

De Unieregeling-aangifte scheidt leveringen per lidstaat van verbruik en onderscheidt diensten uit de lidstaat van identificatie, diensten uit andere vaste inrichtingen en goederen verzonden vanuit verschillende lidstaten. Het rapporteert belastbare bedragen en btw-bedragen apart voor het standaardtarief en verlaagde tarieven. Vrijgestelde leveringen en leveringen tegen nultarief blijven volledig buiten de OSS-aangifte.

Een aantal operationele details waar velen tegenaan lopen:

De periodes voor de Unieregeling en de niet-Unieregeling zijn per kwartaal; IOSS is maandelijks. Aangiften en betalingen moeten voldaan zijn voor het einde van de daaropvolgende maand.
Een nihilaangifte is verplicht voor elke periode, zelfs wanneer er geen relevante leveringen hebben plaatsgevonden. Genereer een periodieke checklist en maak automatisch een nul-aangifte aan.
OSS-aangiften worden opgesteld in euro's, waarbij gebruik wordt gemaakt van de ECB-referentiekoers op de laatste dag van de belastingperiode indien conversie nodig is. Sla de bronvaluta, de wisselkoers, de koersdatum, het geconverteerde bedrag en de methode op.

Exports moeten afkomstig zijn uit het vergrendelde grootboek, en nooit uit een losse spreadsheet. Totalen in spreadsheets verliezen correcties, verzendlanden, tarieven en bewijsmateriaal. Een export bevat de aangifteperiode, de regeling, de lidstaat van verbruik, het verzendland, de leveringscategorie, het tarief, de belastbare bedragen en btw-bedragen, de valuta en de toegepaste wisselkoers, correctiebedragen voor de lopende periode en eerdere periodes, bronfactuur-ID's, verwijzingen naar creditnotas en reconciliatietotalen.

Wees nauwkeurig over wat de API hier oplevert. Nordlet berekent OSS- en IOSS-aangiften op basis van facturen en het grootboek, inclusief correcties uit eerdere periodes, levert lokale aangiftepakketten voor Litouwen (FR0600), Duitsland (UStVA) en Polen (JPK_V7M), en genereert VMI-gereedstaande i.SAF-registers voor Litouwen. Dat zijn gegevens die klaar zijn voor de aangifte. Eén API-aanroep dient niet de btw-aangifte van elk land in via elke nationale portal, en er wordt geen aangifte namens jou ingediend bij een autoriteit. Houd administratie, aangiftegeneratie, export, indiening bij de portal en betalingsbevestiging gescheiden in je systeem. De handleiding voor de EU-btw-engine documenteert welke gevallen de engine oplost en waar de waarschuwingen worden geactiveerd.

Het vergrendelen van de periode

Na controle en goedkeuring reconcileer je facturen met grootboekmutaties, reconcileer je de btw-saldi in het grootboek met de aangifteset, exporteer je de aangifte, leg je de referentiegegevens van de indiening en betaling vast en vergrendel je vervolgens de periode. Nordlet blokkeert boekingen naar een vergrendelde maand, ook via de API. Correcties na het vergrendelen komen in een latere periode terecht met expliciete koppelingen naar het oorspronkelijke document en de getroffen aangifteperiode.

Veelvoorkomende fouten en hoe je ze voorkomt

Fout	Oorzaak	Oplossing
Een geldig VIES-resultaat beschouwen als voldoende voor het nultarief	VIES schept geen vrijstellingsrechten	Bewaar bewijs van klant, levering, transport en factuur samen met het resultaat
Een ongeldig resultaat beschouwen als bewijs van het ontbreken van een registratie	Het nummer is mogelijk niet geactiveerd voor intracommunautaire handel, of de database loopt achter	Maak onderscheid tussen ongeldig, niet-verwerkt en technische storing; stuur geschillen door voor beoordeling
Het afrekenproces synchroon afhankelijk maken van VIES	Gelijktijdigheidslimieten, timeouts, storingen	Asynchrone validatie, kortstondige caching, backoff, voorlopige statussen
Resultaten voor onbepaalde tijd cachen	Registratie- en activatiestatus veranderen	Sla tijdstippen en vervaltijden op; hercontroleer vóór facturering indien verouderd
Producten direct koppelen aan btw-percentages	Tarieven en vrijstellingen zijn afhankelijk van land en datum	Van product naar categorie, naar landcode, naar tarief met ingangsdatum
OSS reconstrueren vanuit spreadsheets	Totalen missen correcties, verzendlanden, bewijsmateriaal	Bereken op basis van het onveranderlijke grootboek met dimensies op elke boeking
Diensten van een lokale vaste inrichting opnemen in OSS	Bepaalde diensten behoren tot de lokale aangifte	Modelleer vaste inrichtingen afzonderlijk, routeer op basis van regeling vóór aggregatie
Nihilaangiften weglaten	OSS vereist elke periode een aangifte	Genereer een checklist en maak automatisch nul-aangiften aan
Het bewerken van gesloten facturen voor correcties	Vernietigt de koppeling tussen aangifte en correctie	Gebruik creditnotas en correctieboekingen in een latere periode

Wat wij als eerste zouden doen

Als we morgen met deze integratie zouden beginnen, dan bouwden we eerst de laag voor de btw-categoriemethode en het btw-beslissingsrecord voordat we ook maar één rapportage-endpoint aanraakten. Zorg dat de taxonomie stabiel is, koppel producten aan categorieën en zorg ervoor dat het beslissingsrecord de ruwe landsignalen vastlegt plus de reden waarom er voor een bepaalde plaats van de dienst is gekozen. Al het andere - VIES, boeken, OSS-groepering, export - is afhankelijk van het correct functioneren van dat model.

Vervolgens zouden we VIES inrichten als een asynchrone bewijsstap met vier afzonderlijke statussen, en dit testen tegen een sandbox-bedrijf met testgegevens voor de lastige scenario's (timeouts, niet-verwerkte resultaten, afwijkende voorvoegsels) voordat we het in de buurt van productie brengen. De bovengenoemde fouten zijn vrijwel volledig te vermijden als het datamodel bewijsmateriaal en rapportagedimensies meedraagt vanaf de eerste boeking.

FAQ

Betekent een geldige VIES-respons dat ik een intracommunautaire B2B-levering mag belasten met het nultarief?

Nee. VIES bevestigt dat een btw-nummer is geregistreerd en, indien ondersteund, is geactiveerd voor intracommunautaire handel. Het recht om een intracommunautaire levering vrij te stellen is afhankelijk van aanvullend bewijsmateriaal: de afnemer die de daadwerkelijke ontvanger is, transport- of verzendbewijs, de juiste plaats van de dienst en de vereiste bewoordingen op de factuur. Sla het VIES-resultaat op als één enkele input, niet als de definitieve beslissing.

Moet VIES-validatie het afrekenproces blokkeren?

Dat moet niet. VIES kan een timeout geven of de limieten voor gelijktijdige verzoeken bereiken, en een storing is niet hetzelfde als een ongeldig nummer. Valideer asynchroon, cache succesvolle resultaten voor een gedocumenteerde periode, probeer tijdelijke storingen opnieuw en houd ambigue gevallen vast voor beoordeling met een voorlopige status in plaats van de verkoop te laten mislukken.

Kan een cloud accounting API automatisch mijn btw-aangiften indienen?

Het kan gegevens opleveren die klaar zijn voor de aangifte, gegroepeerd naar regeling en lidstaat, berekend op basis van het onveranderlijke grootboek inclusief correcties. Of het ook indient via elke nationale aangifteportal is afhankelijk van het product en het land. Nordlet berekent OSS- en IOSS-aangiften, levert lokale aangiftepakketten voor Litouwen, Duitsland en Polen, en genereert VMI-gereedstaande i.SAF-registers voor Litouwen, maar het dient niets namens jou in bij een belastingdienst. Behandel administratie, aangiftegeneratie, export, indiening bij de portal en betaling als afzonderlijke statussen in plaats van aan te nemen dat één aanroep overal indient.

Hoe ga ik om met correcties nadat een periode is vergrendeld?

Boek deze in een volgende periode met een expliciete koppeling naar het oorspronkelijke document en de getroffen aangifteperiode. Nordlet blokkeert nieuwe boekingen naar een vergrendelde maand, ook via de API, zodat correcties via creditnotas of correctieboekingen lopen in plaats van via bewerkingen. Dit behoudt de keten tussen de oorspronkelijke aangifte en de aanpassing.