Een btw-nummer is de identificatie die een bedrijf gebruikt voor de belasting over de toegevoegde waarde, en het is een van de weinige velden die op bijna elk grensoverschrijdend bedrijfsdocument voorkomen. Het is ook het veld waarop teams het vaakst twee volledig verschillende vragen door elkaar halen: ziet dit eruit als een geldig nummer, en is dit bedrijf werkelijk geregistreerd voor de btw. Die twee door elkaar halen levert formulieren op die echte klanten afwijzen en systemen die verzonnen nummers accepteren.
Dit artikel behandelt wat het nummer is, waarom de structuur bij elke grens verandert, hoe de openbare opzoekdiensten erin passen, en hoe je het veld ontwerpt zodat formaatcontrole en registratiecontrole in hun eigen baan blijven.
Wat is een btw-nummer?
Het is een fiscale registratie-identificatie. Een bedrijf dat btw-plichtig is, registreert zich bij de belastingdienst van het desbetreffende land en krijgt een nummer; dat nummer wordt vervolgens vermeld op facturen, in aangiften, en in de grensoverschrijdende rapportage die EU-achtige systemen vereisen.
Uit die definitie volgen twee eigenschappen. Ten eerste behoort het nummer toe aan een belastingadministratie, niet aan een bedrijvenregister, dus het wordt uitgegeven onder belastingwetgeving en kan bestaan voor een entiteit die heel ergens anders is geregistreerd. Ten tweede is het nummer door zijn opzet landspecifiek: het wordt uitgegeven door één autoriteit onder de regels van één rechtsgebied, en het betekent op zichzelf niets buiten dat rechtsgebied.
Het is ook geen bedrijfsregistratienummer, geen fiscaal identificatienummer in brede zin, en geen vergunning. Een bedrijf kan verschillende van deze identificaties tegelijk hebben, en een bedrijf dat puur binnenlands handelt, heeft misschien nooit een btw-nummer nodig.
Wanneer heeft een bedrijf er echt een nodig?
Vaker dan je zou raden op basis van de reputatie van het veld, en in een handvol terugkerende situaties.
- Goederen of diensten verkopen over een grens waar de koper een bedrijf is en de fiscale behandeling afhangt van de status van de koper.
- Factureren van een zakelijke klant die het nummer op het document nodig heeft om de belasting terug te vorderen of te verantwoorden.
- Rapporteren van intracommunautaire leveringen, waarbij het nummer van de tegenpartij deel uitmaakt van de aangifte.
- Registreren in een land waar het bedrijf de lokale drempel voor fiscale registratie heeft overschreden.
- Invoeren en uitvoeren, waarbij de belastingdienst de zending aan een geregistreerde handelaar moet kunnen koppelen.
Het patroon is dat het nummer het meest uitmaakt precies wanneer twee belastingstelsels elkaar ontmoeten. Daarom is het veld ook zo foutgevoelig: het wordt ingevuld door een mens die een document leest dat onder onbekende regels is opgesteld, en het wordt gecontroleerd door software die onder één bekend stel regels is geschreven.
Wat varieert van land tot land?
Bijna alles waarop een parser zou willen vertrouwen. De structuur wordt bepaald door de uitgevende belastingdienst, dus de enige veilige generalisatie is een zwakke: veel formaten beginnen met een tweeletterige landcode en gaan dan verder met cijfers, letters of een mengeling.
Voorbij die beginobservatie zijn de verschillen precies degene die strikte regels breken.
| Eigenschap | Waarom een vaste regel faalt |
|---|---|
| Of er een landvoorvoegsel is | Dezelfde autoriteit kan het in de ene context afdrukken en in de andere weglaten |
| Totale lengte | Formaten variëren van kort tot duidelijk lang, en geen enkele limiet dekt alles |
| Letters versus cijfers | Sommige formaten zijn numeriek, andere alfanumeriek, weer andere bevatten beide blokken |
| Interne scheidingstekens | Spatiëring en leestekens zijn presentatie, geen deel van de identificatie |
| Controlecijfers | Sommige formaten bevatten er een, andere zijn gewone toewijzingen zonder rekenkunde |
Merk op dat het voorvoegsel een gemak is, geen garantie. Wanneer het aanwezig is, vertelt het je welke autoriteit het nummer uitgaf — wat echt nuttig is voor het routeren van een opzoeking — maar het als verplicht behandelen wijst prima invoer af die is getypt van een document dat het heeft weggelaten.
Is een geldig formaat hetzelfde als een geregistreerd bedrijf?
Nee, en de kloof ertussen is het nuttigste dat er over dit veld te begrijpen valt.
Een nummer kan syntactisch perfect zijn en aan niemand toebehoren. Iemand die het patroon begrijpt, kan er een schrijven dat nooit door een autoriteit is uitgegeven, en een systeem dat alleen het patroon controleert, zal het accepteren. Omgekeerd kan een nummer geregistreerd zijn en toch een zelfgemaakte regel niet doorstaan, omdat de regel tegen een ander land of een oudere gedrukte lay-out is geschreven.
Daarom is de openbare btw-nummercontroleservice van de Europese Commissie zo belangrijk als voorbeeld: ze bestaat zodat een bedrijf kan bevestigen of een nummer werkelijk voor de btw is geregistreerd in een lidstaat, een vraag die geen enkel patroon kan beantwoorden. Het onderscheid generaliseert ruim voorbij die service — waar een belastingdienst een officiële opzoeking publiceert, is die opzoeking de autoriteit, en een reguliere expressie niet.
Er is een nuttig gevolg voor interfaceontwerp. Wanneer een controle faalt, moet de melding zeggen welke controle faalde. “Dit ziet er niet uit als een btw-nummer” en “we konden dit nummer niet bevestigen bij de belastingdienst” leiden de gebruiker naar verschillende acties, en ze door elkaar halen kost iedereen tijd.
Waarom zouden teams hun eigen regels vermijden?
Omdat de regels nationaal zijn, af en toe worden herzien, en talrijk zijn, en omdat een zelfgemaakte validator een onderhoudslast is die in de minst zichtbare richting faalt.
Overweeg wat een zelfgeschreven regel werkelijk doet. Ze codeert de lay-out van één land. Ze wordt getest tegen een handvol voorbeelden uit een of twee landen. Ze meldt één generieke fout. En wanneer een belastingdienst een lay-out wijzigt, kondigt niets dat aan — de regel begint simpelweg echte klanten af te wijzen, geleidelijk, in de landen waarmee niemand in het team handelt. Het falen is stil en de kosten worden gedragen door het verkoopteam.
Het alternatief is niet “geen validatie”. Het is gelaagde validatie, waarbij elke laag een vraag beantwoordt die ze werkelijk kan beantwoorden, en de gezaghebbende laag een aanroep naar de officiële service is in plaats van een gok. Die architectuur degradeert ook sierlijk: als de officiële service traag is, onbereikbaar, of een dubbelzinnig resultaat teruggeeft, kan het formulier de invoer nog steeds accepteren en de bevestiging als in behandeling markeren in plaats van een legitieme klant te blokkeren.
Voor ontwikkelaars: formaatcontroles en registercontroles zijn verschillende functies
Splits de verantwoordelijkheid in twee functies met twee verschillende retourtypes, en laat ze geen foutmelding delen.
De eerste is een lokale vormcontrole. Ze moet bewust toegeeflijk zijn: strip scheidingstekens, normaliseer hoofdletters, wijs lege waarden af en tekens die in geen enkel formaat kunnen voorkomen, en pas een maximale lengte toe die ruim boven het langste echte formaat ligt. Als je een landspecifiek patroon hebt en zeker bent van de herkomst, pas het dan toe als een hint die een waarschuwing kan verlagen, nooit als een harde afwijzing van een waarde die je niet kunt verifiëren. Waar een formaat werkelijk een controlecijfer draagt, implementeer het alleen voor de landen waar je het algoritme hebt geverifieerd, en behandel een fout als “mogelijke typefout” in plaats van “niet geregistreerd”.
De tweede is een registratieopzoeking tegen de officiële voorziening. Geef die een eigen time-out, een eigen herhaalbeleid, en een eigen vocabulaire van uitkomsten: bevestigd, niet gevonden, niet beschikbaar, en niet van toepassing voor dit land. Cache een positief resultaat voor een redelijke periode en een negatief veel korter, want een bedrijf dat vandaag registreert, mag niet een week worden afgewezen door een verouderd antwoord. Log welke nummers werden gecontroleerd en wanneer, maar behandel de log als bedrijfsgegevens en bescherm die dienovereenkomstig.
Nog twee gewoonten zijn de moeite waard. Houd de ruwe waarde die de gebruiker typte naast de genormaliseerde, zodat een weergave of een document exact kan reproduceren wat de bron toonde. En houd gegenereerde waarden onmiskenbaar synthetisch: de generator op deze site vult het btw-nummerveld met geformatteerde waarden die tot geen enkele belastingdienst behoren, en elke export ervan draagt een notitie die dat zegt. Het verwante artikel over fiscale identificaties doorloopt dezelfde gelaagdheid voor de bredere familie van fiscale nummers. Het testen van dit alles tegen het formulier van een echt product wordt behandeld in het artikel over testgevallen voor factuurformulieren.
Volgende stappen
Maak een lijst van elke plek in je product waar vandaag een btw-nummer wordt gevalideerd en label elke controle als vorm of registratie. Elke controle die beweert over het bestaan te gaan maar als patroon is geïmplementeerd, is een bug die wacht op een internationale klant. Laat dan je factuurformulier door de vier takken lopen — nummer aanwezig, nummer afwezig, grensoverschrijdend, en particulier — met gegenereerde gegevens uit de generator voor bedrijfsgegevens zodat niets waarmee je test voor een echt bedrijf kan worden aangezien.