Validatie van fiscale identificatienummers is de praktijk van het controleren van een fiscale identificatie voordat ze wordt opgeslagen, gefactureerd of gerapporteerd — en het is ook het veld waar verwachtingen het vaakst te hoog worden gesteld. Een goed ontworpen controle houdt verwisselde cijfers tegen voordat ze je database binnenkomen. Ze zal je niet vertellen of het bedrijf bestaat, of het nummer ooit is uitgegeven, of het bedrijf erachter ergens recht op heeft.
Dit artikel legt uit wat een fiscale identificatie is, waarom sommige formaten rekenkundig kunnen worden gecontroleerd en andere niet, hoe je validatie in lagen bouwt zodat elke laag een vraag beantwoordt die ze werkelijk kan beantwoorden, en waarom een mislukte controle nooit als een ontbrekend bedrijf mag worden gerapporteerd.
Wat is een fiscale identificatie?
Het is de identificatie die een belastingadministratie aan een belastingplichtige toekent. Dat is de hele definitie, en ze is met opzet breed, omdat landen fiscale registratie heel verschillend organiseren.
Het ene land kan één nationaal belastingnummer hebben dat voor alles wordt gebruikt. Een ander kan aparte nummers hebben voor verschillende belastingen, zodat een bedrijf één identificatie voor directe belastingen heeft en een andere voor de belasting over de toegevoegde waarde. Weer een ander kan een nummer gebruiken dat het belastingstelsel volledig voorafgaat, doordat het voor een ander administratief doel is ingevoerd en later voor belasting is overgenomen. Sommige rechtsgebieden gebruiken één identificatie die tevens het bedrijfsregistratienummer is; andere houden ze strikt gescheiden.
Er volgen onmiddellijk twee gevolgen. Ten eerste is “belastingnummer” in werkelijkheid geen enkel veld; het is een familie van velden waarvan het lidmaatschap van het land afhangt. Ten tweede is elke bewering van de vorm “een belastingnummer bevat altijd x” ergens onwaar, en daarom moet je validatie defensief worden geschreven.
Waarom dragen sommige belastingnummers een controlecijfer?
Omdat de uitgevende autoriteit ze zo heeft ontworpen. Een controlecijfer is een rekenkundige redundantie: het laatste teken, of een ingebed teken in het midden, wordt volgens een gepubliceerde regel uit de andere berekend, zodat één verkeerd getypt of verwisseld teken meestal een waarde oplevert die de regel niet doorstaat.
Waar een land zo’n regel publiceert, is het implementeren ervan echt nuttig. Het vangt de meest voorkomende invoerfouten op het moment van invoer, zonder netwerkaanroep, zonder externe afhankelijkheid en zonder privacyvraag. Het is goedkoop, snel en deterministisch — en het is de sterkste controle die je lokaal kunt uitvoeren.
Waar een land geen dergelijke regel publiceert, is de identificatie simpelweg een toewijzing: de autoriteit heeft ze toegewezen en vastgelegd, en geen enkele rekenkunde kan een echte van een verzonnen onderscheiden. Dit komt vaker voor dan ontwikkelaars verwachten. Sommige zeer grote rechtsgebieden geven gewone opeenvolgende nummers uit zonder enige redundantie.
De instructie die hieruit volgt is bot. Implementeer een controlecijferalgoritme alleen voor de specifieke landen waar je hebt geverifieerd dat het algoritme is gepubliceerd en nog actueel is. Raad geen algoritme uit de vorm van het nummer, en neem niet aan dat omdat het formaat van het ene land op dat van een ander lijkt, dezelfde regel geldt.
| Hoe het nummer eruitziet | Wat je eerlijk kunt controleren |
|---|---|
| Gepubliceerd algoritme met een controlecijfer | Tekenset, lengte en de rekenkundige regel |
| Gewone toewijzing, geen gepubliceerde regel | Alleen de tekenset en een royale lengtegrens |
| Formaat met een land- of autoriteitsvoorvoegsel | Dat het voorvoegsel overeenkomt met het opgegeven land |
| Formaat dat ook als registratienummer dient | Wat het register zelf kan bevestigen |
Betekent het doorstaan van validatie dat het nummer echt is?
Nee. Formaatgeldigheid en bestaan zijn verschillende eigenschappen, en ze door elkaar halen is de meest voorkomende ontwerpfout op dit gebied.
Een syntactisch perfect nummer kan aan niemand toebehoren. Iedereen die het patroon begrijpt, kan er een produceren dat aan elke lokale regel voldoet, inclusief het controlecijfer, omdat het controlecijfer is ontworpen om ongelukken te vangen in plaats van tegenstanders. Een nummer kan ook volledig echt zijn en je lokale regel niet doorstaan, als de regel tegen een oudere lay-out, een ander land, of een document dat het nummer ongewoon formatteerde is geschreven.
Het bestaan wordt alleen vastgesteld door de autoriteit die de identificatie heeft uitgegeven. Waar een belastingadministratie een officiële opzoekvoorziening publiceert, is die voorziening het antwoord op de bestaansvraag; waar ze dat niet doet, is het bestaan misschien alleen bevestigbaar uit documenten die het bedrijf aanlevert. Dat is een werkelijk zwakkere zekerheid, en dat moet als zodanig worden beschreven in plaats van als verificatie te worden opgedoft.
Er is ook een subtiliteit die teams verrast: zelfs een bevestigde registratie is een feit op één moment. Een nummer kan vandaag geldig zijn en volgende maand geannuleerd, dus een agressieve cache van “dit nummer is geldig” komt op den duur in conflict met de werkelijkheid. Cache doelbewust, en geef er de voorkeur aan het antwoord met een tijdstempel te cachen in plaats van voor altijd.
Hoe moet validatie worden gelaagd?
In drie passes, geordend op kosten, met de goedkoopste en meest zekere eerst.
De eerste pass is lokaal en structureel: is het veld niet leeg, valt het binnen een royale maximale lengte, bevat het alleen tekens die in een of ander formaat voorkomen, en komt het opgegeven land overeen met een eventueel voorvoegsel. Deze pass mag bijna nooit een plausibele invoer afwijzen; haar taak is lege en duidelijk beschadigde waarden vangen.
De tweede pass is landspecifiek: pas de gepubliceerde controlecijferregel toe waar je er een hebt, en alleen daar. Rapporteer de uitkomst als een typefoutwaarschuwing bij het veld, geformuleerd als “dit ziet er niet goed uit, controleer het”, want dat is wat een mislukking van het controlecijfer werkelijk betekent.
De derde pass is de gezaghebbende opzoeking, asynchroon en nooit blokkerend voor het formulier. Ze heeft drie uitkomsten die het onderscheiden waard zijn — bevestigd, niet gevonden, en niet beschikbaar — en ze moet kunnen zeggen welke zich voordeed. Een opzoeking die “geen zulk nummer” niet kan onderscheiden van “de service ligt eruit”, zal op een slechte netwerkdag uiteindelijk een legitieme klant afwijzen.
Voor ontwikkelaars: fouten, caching en auditsporen
Het ontwerpwerk gaat vooral over eerlijkheid in foutafhandeling. Elke laag moet een onderscheidbaar resultaat opleveren, en de melding die de gebruiker ziet moet de laag benoemen die faalde. “We konden de belastingdienst niet bereiken, je gegevens zijn opgeslagen en we controleren het opnieuw” is een bruikbare melding. “Ongeldig belastingnummer” bij een waarde die de gebruiker van een officieel certificaat heeft gekopieerd, is dat niet.
Overweeg een expliciet resultaattype in plaats van een boolean. Vier toestanden — niet geverifieerd, vorm geldig, opzoeking bevestigd, opzoeking niet gevonden — dekken de grond zonder een onderscheid af te dwingen dat het systeem niet kan maken. Een boolean vouwt ze samen en garandeert dat uiteindelijk een of andere legitieme waarde als onwaar wordt behandeld.
Caching moet asymmetrisch zijn. Een bevestigd resultaat is het waard om een redelijke periode vast te houden; een niet-gevonden-resultaat moet snel verlopen, omdat registraties veranderen en de afwezigheid van gisteren een slechte reden is om de klant van vandaag af te wijzen. Een niet-beschikbaar resultaat mag helemaal niet als negatief worden gecachet.
Auditeer wat je controleerde zonder de log in een kopie van de klantendatabase te veranderen. Leg het feit en het tijdstip van een controle vast, de toegepaste laag, en de uitkomst; vermijd het dupliceren van de ruwe identificatie naar systemen die die niet nodig hebben. Waar de identificatie moet worden bewaard, behandel die dan als bedrijfsgegevens met dezelfde zorg als elke andere — en houd gegenereerde waarden duidelijk gescheiden van echte, waarvoor de synthetische fiscale identificatievelden op deze site dienen. Het artikel over btw-nummerformaten behandelt het meest voorkomende lid van deze familie, en testbedrijfsgegevens laat zien hoe de rest van een synthetisch bedrijfsrecord eruitziet.
Volgende stappen
Inventariseer elke belastingnummercontrole in je product en label elke met de laag die ze implementeert. Elke controle die een waarde afwijst op basis van een geraden patroon moet worden teruggebracht tot een waarschuwing, en elke melding die “bestaat niet” zegt op grond van een rekenkundige test moet worden herschreven om te zeggen wat werkelijk is getest. Gebruik dan de generator voor bedrijfsgegevens om records voor verschillende landen te produceren en bevestig dat je formulier een land waar het niets van weet aankan zonder de invoer botweg te weigeren.