Hoe we voorkomen dat onze belasting- en loonberekenaars stilletjes verouderen

Elke calculator op deze site die met belastingen, sociale verzekeringen of minimumloon te maken heeft, kent dezelfde faalwijze: hij is correct op de dag dat we hem bouwen, en dan past een overheid zes maanden later een tarief aan, en begint de tool stilletjes verkeerde antwoorden te geven. Niemand krijgt een foutmelding. De pagina blijft precies zo werken als eerst — hij is alleen fout, en dat met veel zelfvertrouwen.

Dat is een slechtere uitkomst dan de tool helemaal niet hebben. Dus bouwden we een systeem dat dit specifiek opspoort.

Het probleem met “we denken er wel aan om te controleren”

De voor de hand liggende oplossing — “controleer de cijfers gewoon af en toe” — schaalt niet. We onderhouden nettoloon-, sociale-verzekerings- en loonberekenaars voor een half dozijn landen, elk met eigen belastingschijven, premiepercentages en jaarlijks bijgestelde drempels. Vermenigvuldig dat met het aantal maanden dat voorbijgaat voordat iemand eraan denkt om te controleren, en het eerlijke antwoord is: uiteindelijk veroudert er iets en merkt niemand het totdat een gebruiker dat doet.

Wat we in plaats daarvan bouwden

Een registerbestand somt elk hardgecodeerd officieel cijfer in elke calculator op: in welk bestand het staat, wat het cijfer voorstelt, waar de officiële bron is, en hoe vaak het realistisch gezien verandert (sommige waarden schuiven elke januari op bij een nieuw fiscaal jaar; andere veranderen alleen bij een wetswijziging, wat onvoorspelbaar maar zeldzaam is).

Een geplande job draait wekelijks, checkt welke items volgens dat schema aan controle toe zijn, en doet voor elk daarvan:

1. Zoekt de actuele waarde op bij de officiële overheidsbron
2. Vraagt een taalmodel het specifieke cijfer uit de zoekresultaten te halen — niets anders, alleen het cijfer en een betrouwbaarheidsniveau
3. Is het model zeker van zijn zaak en is het cijfer veranderd, dan wordt het toegepast als een letterlijke, geverifieerde tekstvervanging in de code (nooit een vrije herschrijving — het model mag de omliggende logica niet improviseren)
4. Draait een volledige build om te bevestigen dat er niets brak, voordat er iets wordt gecommit
5. Faalt de build, dan wordt de wijziging automatisch teruggedraaid en gemarkeerd voor menselijke controle

Het geheel is ontworpen rond een simpel principe: de automatisering mag een cijfer bijwerken, maar mag nooit gokken. Vindt hij geen betrouwbaar antwoord bij een officiële bron, dan doet hij niets en meldt dat duidelijk, in plaats van een plausibel ogend fout cijfer te laten staan.

Onafhankelijk van welke tool dan ook

De job zelf draait op infrastructuur die onafhankelijk is van één leverancier of account — valt een deel van de pipeline uit, dan stopt het hele systeem niet, maar valt het terug op een andere route om het cijfer te achterhalen. Die redundantie is hier belangrijker dan bij de meeste automatisering: een belastingcalculator die fout zit is actief schadelijk op een manier waarop, zeg, een kapotte meme-generator dat simpelweg niet is.

Wat dit voor jou betekent

Elke calculator die onder dit systeem valt, toont direct op de pagina een datum “officiële data geverifieerd”, los van de “laatst bijgewerkt”-datum die je op een normale contentpagina ziet. Ziet die datum er ooit verdacht oud uit, dan is het de moeite waard om dat direct bij ons te melden — het betekent meestal dat de automatische controle op een bron stuitte die hij niet kon parsen, niet dat we het vergeten zijn.

Probeer het

Dit zijn tools in één taal, elk specifiek gebouwd voor de regels van het eigen land, dus de links hieronder openen in die taal:

• Tsjechische nettoloon-calculator (Čeština)
• Hongaarse salariscalculator (Magyar)
• Roemeense nettoloon-calculator (Română)
• Poolse ZUS-calculator (Polski)