Overheid Nederland moet opnieuw besluiten over openbaren Belastingdienstbroncode

De Nederlandse overheid mag de broncode van bepaalde systemen van de Belastingdienst niet zomaar geheimhouden. De demissionaire staatssecretaris moet nog een keer uitleggen waarom hij de broncode niet wil openbaren, maar dan met een betere onderbouwing. Dat oordeelt de rechter na een klacht van een burger.

De rechtbank in Gelderland oordeelt dat in een beroepszaak die door een Nederlander werd gestart. Die vroeg in 2023 de broncode op van de systemen waarmee de Belastingdienst btw regelt. Hij wilde onder andere code van de back-end, van CI- en CD-configuraties en configuratiebestanden. De staatssecretaris weigerde die bestanden kort daarna openbaar te maken en herhaalde die beslissing nadat de klager daarover in beroep ging. Nu heeft de klager via de rechter afgedwongen dat de overheid daar alsnog over besluit.

De staatssecretaris haalde verschillende redenen aan om de broncode niet openbaar te hoeven maken. Zo vond hij dat 'het belang van openbaarmaking niet opweegt tegen het financiële en/of economische belang van de Belastingdienst', maar ook dat openbaarmaking 'de heffing en inning van omzetbelasting in gevaar kon brengen'. Dat zou zijn omdat het om oude code gaat waar zaken zoals de namen van servers, databases en tabellen hardcoded in de software staat.

De rechter gaat er deels in mee dat het openbaar maken mogelijk gevaarlijk kan zijn, maar de staatssecretaris moet dat wel beter motiveren. Nu maakt de staatssecretaris de keus om de gehele broncode geheim te houden. "De staatssecretaris moet wel inzichtelijk maken welke uitzonderingsgrond op welk deel van de BTW/OB-broncode van toepassing is", zegt de rechter. "Het is aan de staatssecretaris om een nieuw besluit te nemen waarbij inzichtelijk wordt gemaakt op welk deel van de verzochte informatie welke uitzonderingsgrond van toepassing is."

Door Tijs Hofmans

Nieuwscoördinator

10-08-2025 • 11:28

276

Reacties (276)

276
273
137
11
0
109
Wijzig sortering
Op zich is het inzien van de broncode niet zo interessant. Echter is het wel degelijk belangrijk dat de broncode openbaar is in een bepaalde vorm.

Alles wat de overheid doet zou in het algemeen belang moeten zijn en het wordt allemaal betaald door de belastingbetaler. Er moet een vorm van controle zijn en daar is de Wet Open Overheid (WOO) ook voor bedoeld. Het betekent trouwens niet dat de informatie volledig publiek beschikbaar komt, de aanvrager krijgt inzage en mogelijk met beperkingen of onder voorwaarden.

Er is al jaren lang veel gedoe rondom automatisering bij de overheid zonder enige vooruitgang. Daarom juich ik dit soort initiatieven toe. Het dwingt de overheid om transparant te worden zodat problemen zichtbaar worden. Pas als het zichtbaar en benoemd wordt kunnen problemen daadwerkelijk opgelost gaan worden. Er kan nu te veel onder het tapijt geschoven worden en dat zou je als burger niet moeten willen. Het feit dat de aanvraag zonder fatsoenlijke onderbouwing afgewezen is zegt al veel.
Het dwingt de overheid om transparant te worden zodat problemen zichtbaar worden. Pas als het zichtbaar en benoemd wordt kunnen problemen daadwerkelijk opgelost gaan worden.
Alle betrokken partijen zijn zich bewust van de problematiek die speelt en zullen het naar hun beste kunnen proberen aan te pakken. Het idee dat dit opgelost wordt als het maar openbaar wordt gemaakt is naief. Het zal eerder een extra laag complexiteit toevoegen en de voortgang verder beperken.
Aannemen dat alle betrokken partijen zich bewust zijn van de problematiek die speelt en dat ze het naar hun beste kunnen proberen aan te pakken is naief.

Vertrouwen is goed maar controle is beter.

[Reactie gewijzigd door Grimm op 11 augustus 2025 11:19]

De belastingdienst zelf en de betrokken ministeries weten beter wat er speelt dan wij, dat lijkt me nogal een inkoppertje.
[...]

Alle betrokken partijen zijn zich bewust van de problematiek die speelt en zullen het naar hun beste kunnen proberen aan te pakken. Het idee dat dit opgelost wordt als het maar openbaar wordt gemaakt is naief. Het zal eerder een extra laag complexiteit toevoegen en de voortgang verder beperken.
Dit is nou de BS waar de belastingdienst/overheid op vaart: "Openbaar maken van onze meest vastgeroestte faalprojecten in de ICT zorgt er alleen maar voor dat het nog problematischer wordt." Ja dààg. 8)7

Als je kijkt naar de nieuwsberichten als "we kunnen de lekkende ambtenaar niet opsporen omdat we geen deugdelijke logging hebben geimplementeerd", of het pas 10 jaar na de introductie van SS7-spoofing en SIM-swapping uitfaseren van SMS bij DigID, of het jaren lang in stand houden van identiteitsfraude bij ZZP'ers wegens het verplicht moeten lekken van persoonsgegevens die je privé dient te houden, of - wat waarschijnlijk aan dit WOB-verzoek ten grondslag lag - het niet kunnen verlagen van BTW op groente en fruit omdat het BTW-systeem slechts één wijziging per 10 jaar aankan. Dan denk je aan alles behalve maximale inzet.

Het is een bekend 40 jaar oud probleem. Individuele werknemers doen hun best. Ze kunnen bijna niet beter hun best doen. Maar je ziet vervolgens ant mills ontstaan.
"Echter is het wel degelijk belangrijk dat de broncode openbaar is in een bepaalde vorm."

Dat lijkt me helemaal niet belangrijk.

In de wet is keurig vastgelegd hoe de omzetbelasting moet worden berekend. Dat is niet extreem moeilijk. Als je zelf op iets anders uitkomt, dan de belastingdienst, dan stap je naar de rechter en dan leggen beide partijen hun berekening voor.
De broncode van systemen is daarvoor niet relevant, want de berekening kun je gewoon op papier doen.

De broncode wordt hooguit interessant - naar mijn mening - als de belastingdienst niet een berekening geeft, maar zich verschuilt achter een opmerking als 'dat komt uit onze systemen'.
Op dat moment is de broncode interessant, maar zou ik nog steeds de voorkeur hebben voor een berekening op papier.
Ter context, mocht de vraag zich voordoen: “Waarom zou iemand deze broncode überhaupt willen kennen of in bezit willen hebben?”

Rond dezelfde periode dat het verzoek tot openbaarmaking van de broncode van het huidige BTW‑systeem werd ingediend, startte de Belastingdienst met de verkenning en voorbereiding van het programma ‘Modernisering Omzetbelasting’. Dit programma heeft tot doel het bestaande systeem te vervangen. De realisatie van het nieuwe systeem wordt niet door de Belastingdienst zelf uitgevoerd, maar uitbesteed aan de markt via een openbare aanbesteding.

In aanbestedingen voor complexe en kritieke overheids­systemen, zoals dit oude BTW-systeem, wegen criteria als continuïteit, migratie en uitfasering vaak zwaar mee in de beoordeling. Een partij die beschikt over gedetailleerde technische kennis van het huidige systeem (zoals broncode, datamodellen, interfaces, configuratie en (technische) beperkingen) kan in theorie een aanzienlijk voordeel hebben bij het opstellen van bijvoorbeeld een realistisch plan van aanpak, het maken van een nauwkeurige risicoanalyse, continuïteitsborging, het inschatten van de kosten, etc, etc.

Het is natuurlijk mogelijk dat het Woo-verzoek en de start van het moderniseringsprogramma elkaar puur toevallig in de tijd gekruist hebben. Maar persoonlijk geloof ik zelden in dit soort toevalligheden.
De firma's die vandaag al ingehuurd worden om op zo'n systemen te werken, hebben vandaag een aanzienlijk voordeel.

Openbaarheid zal enkel voor een 'level playing field' zorgen. Meer competitie is in het belang van de aanbesteders.

Als er hard-gecodeerd wordt (Shell niet laten betalen!), dan kan je nog steeds openbaarheid realiseren door selectief uit te zwarten (mits motivatie).

Gewoon de ondernemingscode van het bedrijf (een bedrijf heeft m.i. niet de privacyrechten van een natuurlijk persoon, dit terzijde) schrappen en je kan alsnog de broncode weergeven. Dat lijkt mij echt maar een triviaal taakje te zijn.
Dat zou zijn omdat het om oude code gaat waar zaken zoals de namen van servers, databases en tabellen hardcoded in de software staat.
Wow. Dat is al een red flag van heb ik me jou daar, en een gevalletje erg bad practice dat men dat zo gebouwd heeft. Je zet dit soort zaken nooit hardcoded in een applicatie, dat doe je met configuratiebestanden, parameters in de software etc. Anders is het niet te beheren op termijn.

Dat is net zoiets als hardcoded usernames/passwords in een applicatie zetten, en dan nog unencrypted ook.

Wie dit ooit goed gekeurd heeft, en waarom dit nooit herschreven is... en hoe is dit door de code-review/audits gekomen?

Maar nog los daarvan: die informatie kan je toch weglakken? Dat gebeurt bij andere informatie, waar eventuele gevoeligheden in staan, toch ook gewoon (en terecht)? Dat lijkt me dus niet echt een valide argument om het niet vrij te geven?

[Reactie gewijzigd door wildhagen op 10 augustus 2025 11:37]

dat van bad practice moet je zien in de context van de tijd dat het systeem gebouwd werd. het OB systeem is meer dan 50 jaar oud en in die tijd (jaren 70) was het gewoon cobol tape verwerking. De grote mainframe systemen hadden geen databases van tig gig, en slechts geheugen van 100k en opslagdisks van megabytes. Met de beperking van al die resources ga je heel anders systemen bouwen dan nu met (nagenoeg) ongbeperkt geheugen en opslag.
"Met de beperking van al die resources ga je heel anders systemen bouwen dan nu met (nagenoeg) ongbeperkt geheugen en opslag."

Mooie uitspraak onder een artikel waarin staat dat we dus weldegelijk nog met dit systeem werken, haha.
Maar dat is het juist. Er draaien nog zoveel machines met COBOL... Toen ik nog actief was in de IT (5 jaar geleden) werd ik nog regelmatig benaderd om nog wat COBOL te krassen. Het blijft mij verbazen hoeveel er nog is. En idd er staan verschrikkelijke foute dingen in. Vooral in de headers en comments. En ja, je had maar zeer beperkt geheugen. Ooit heeft een toenmalige chef mijn programma afgekeurd omdat er 1(één) spatie te veel in stond. Ik heb het over halverwege de jaren 80 van de vorige eeuw 😀😃🙂
ik heb zelfs wel eens zitten overwegen toch maar eens COBOL te gaan leren.

je kan letterlijk de hoofdprijs vragen als je 't goed kan nu.
Als dit op IBM Z draait, dan is de kans aanwezig dat de huidige code (zeer) veel gemeen heeft met oudere iteraties. Vaak zijn er decennia lang incrementele wijzigingen aan toegebracht en om die code naar moderne maatstaven om te katten zonder downtime is ontzettend lastig. Misschien is er hier een mainframe engineer er meer inhoudelijk iets over roepen dan ik kan.
COBOL is een heel mooie taal voor relatief simpele maar massale administratieve toepassingen. Een goed geschreven COBOL programma leest, tenminste als de programmeur die moeite heeft genomen, als een boek en is dan prima overdraagbaar en door anderen te wijzigen.

Het gevaar is, als er werd uitgeweken naar ingelinkte subroutines die omwille van het geheugenbeslag destijds in Assembler werden geschreven. En dat is different koek.

Helemaal als er hardware afhankelijke dingen in zitten zoals toegang tot magneetbanden, Harde schijven, ponsbanden of kaarten, zijn dat programmeer ambachten die vrijwel zullen zijn uitgestorven...
Dit is wel een heel royale voorstelling van zaken, in werkelijkheid gaven ze gewoon zo extreem weinig om de kwaliteit van hun dienstverlening dat ze letterlijk nog op 60 jaar oude meuk werken.

Tech debt * 1000 dit.
Bron: heb een opdracht bij de belastingdienst gedaan en daar word spul pas vervangen als het letterlijk uit elkaar valt of er geen extended support meer bij de leverancier ingekocht kan worden (denk aan 10 jaar oude Java runtime versies). De technische externen waarschuwen regelmatig maar management is voornamelijk bezig met carriere maken en quick wins. Vast technisch personeel daar heeft het al lang opgegeven om er nog iets beters van te maken.
Dit klopt inderdaad helemaal. Al zou je een camera zetten op de werkzaamheden van een team zou je je rot schrikken over de dagelijkse gang van zaken. Het is ontzettend de-motiverend.
Vast personeel komt rond 10 binnen hobbelen. Stand-up, koffiepauze, half uurtje werken, lunchpauze, rondje wandelen, koffiepauze, nutteloze meeting, koffiepauze, oh het is al half 4, tijd om naar huis te gaan.

Als ze niet gewoon een hele week afwezig zijn om de avondvierdaagse onder werktijd te gaan lopen of te repeteren met het Douanesymfonieorkest.
Ik meen me te herinneren dat de Haagse politiek tien jaar geleden nog constateerde dat het BTW-systeem op de achterste benen liep. Als je daar vervolgens geen geld aan uitgeeft, dan komt er echt geen nieuw systeem.
Ja kijk het ding is zolang iets geen politiek probleem is dan gebeurt er niks in Den Haag. Het gewone volk begrijpt er geen drol van dus maken ze er ook geen issue van. En dan hoeft den haag het niet op te lossen want niemand heeft er last van. Tot het zo erg is dat alles volledig in de soep loopt.
Dan wordt je het lachertje als de politiek iets met BTW op fruit wil maar de Belastingdienst het niet meer kan op die oude systemen.
De politiek hoeft niet daadwerkelijk iets te doen, alleen maar hard te schreeuwen dat ze iets van plan zijn (zie huidige kabinet).
Als in, we zien wel weer als die systemen kapot gaan en we geen onderdelen meer kunnen verkrijgen?
Wat een onzin. Ik heb tussen de Cobolkrassers gezeten bij een grote bank. Ouderwets coderen met peer review en aftekenen voor iedere OTAP stap en soms tussenstappen.

De oorzaak zit in continue nieuwe wetgeving maar het altijd moeten kunnen narekenen over het jaar van aangifte. Kijk alleen al naar de bijtellingsregels, hoe vaak percentages of staffels en tegenwoordig ook fietsen, een bijtelling kennen.
Dat dit na 50 jaar allemaal nog draait en niet is vervangen of geüpdatet is precies de reden waarom de belastingdienst niet kan moderniseren.

We zien hier een schandaal in de maak want het kan niet lang meer duren voor de politiek stemt voor modernisering van het belastingstelsel en dat dit door de computersystemen van de dienst domweg niet kan.
Dat is niet een schandaal in de maak, dit is al heel lang bekend. Maar waar haal je zo snel en makkelijk een paar COBOL programmeurs vandaan? Daarnaast is COBOL erg goed in wat het doet, berekeningen maken. Dat is tot op hede nog niet zo goed gelukt met andere programmeertalen. Maar met de huidige techniek is het wel mogelijk inmiddels om daar omheen te werken. Echter, nu lopen we weer tegen het ding aan dat de huidige programmeurs geen COBOL kunnen lezen. Dus heb je toch weer die COBOL programmeurs nodig.

Je zou kunnen zeggen, begin je toch helemaal van de grond af aan. Maar moet je eens opletten hoe lang dat gaat duren. ING heeft bijvoorbeeld ook nog járen met de oude systemen van de Postbank gewerkt, omdat het zo goed werkte en omzetten niet zo simpel was als dat sommige mensen denken. Daarom duurde het bijvoorbeeld bij de Postbank lange tijd nog een dag voordat een overboeking werd gedaan, ipv instant payment.

[Reactie gewijzigd door William_H op 10 augustus 2025 22:39]

Dat moderne programmeertalen niet kunnen wat Cobol kan, is een bewering waar ik wel stevig bewijs van zou willen zien.

Zelfs als het iets inefficiënter (twijfelachtig) gaat, dan nog compenseer je dat eenvoudig door oneindig krachtiger hardware.

Verder kan een beetje programmeur Cobol leren. Zo complex waren die talen in de jaren -60 nu ook weer niet.

Verder eens hoor. Decennia aan legio aanpassingen in de code, het zal inmiddels wel ondoorgrondelijke spaghetti-code zijn.

Herschrijven (laat staan het testen) is een bijna onbegonnen zaak. Het zal ook niet 1 systeem zijn, maar een web van oude legacy meuk.
Cobol draait gewoon op moderne hardware. We hadden een complete automatische build en deployment straat voor cobol applicaties waar ik heb gezeten.
Ja, maar dat wil je dus niet. Want met cobol kan je niet moderne applicaties en technieken gebruiken. Webservices, geen toegang tot open source APIs, zeer verouderde taal op zich -zonder moderne inzichten- want het stamt uit de tijd voor C.

En er zijn nauwelijks programmeurs beschikbaar. Als je het future-proof wil maken, start dan niet met een taal die al zo goed als dood is.
en toch zijn de obstakels voor ombouwen naar iets nieuws zo groot, dat ze het niet doen.

niemand start iets nieuws met Cobol. Ze onderhouden iets ouds wat ooit al in Cobol is geschreven.

Dat het geen toegang tot API's heeft en geen webservices is ook geen onoverkomelijk probleem voor zoiets. Daar werken ze al lang en breed omheen. Nog maar los van dat de Cobol devs die er nog zijn, en daar zitten, waarschijnlijk gruwelijk allergisch zijn voor dergelijke nieuwerwetse fratsen. (ik heb ze meegemaakt ;) )
Het probleem van BD ligt in het niet/nauwelijks meer kunnen onderhouden van deze systemen. Dus, doorgaan op deze manier, is niet een oplossing. Want, de problemen worden alleen maar groter ipv kleiner.


Herschrijven (dat zal jaren duren) is de enige optie.
Herschrijven (dat zal jaren duren) is de enige optie.
Ook dat weten ze al jaren. En het komt niet van de grond. Waarom? Ze krijgen er geen budget voor. Of de politiek snapt de urgentie niet. (en worden wel boos als de wijziging die ze net voor het kerst-reces bedenken niet actief is op 1 januari).

Bij de BD intern werken genoeg knappe developers die deze klus in redelijk korte tijd (relatief, natuurlijk) kunnen klaren. Dat is het probleem echt niet.
Dat is een ander onderwerp. Het issue is niet hardware, het issue is het niet meer kunnen onderhouden van oude code op oude systemen, wat tientallen jaren op een houtje-touwtje-manier gemaakt is. In de politiek moet nu eenmaal vaak eerst een harde realitiet getoond worden, om te handelen. Ook al roept men van een naderende ramp.

Op een gegeven moment zijn vertalingen van wetten naar code, domweg niet meer uit te voeren. Dat zie je nu al. En kost het de staatskas uiteindelijk geld. En dan komt er (veel te laat), gewoon actie.
We hebben het over de jaren '70 en dat COBOL toen efficiënter was en qua rekenkracht destijds zelfs noodzakelijk, gelooft iedereen hier wel denk ik. Maar de bevolking in Nederland is niet zo snel gegroeid (van 13 naar 18,5M) als de rekenkracht (kiloflops voor mainframes naar tera- of zelfs peta-/exaflops voor supercomputers, als ik copilot moet geloven), dus je zou dit bij wijze van spreken op je sloffen moeten kunnen draaien met een inefficiënte programmeertaal op een mobiele telefoon 8)7

[Reactie gewijzigd door Grrrrrene op 11 augustus 2025 07:48]

Was het maar allemaal cobol... ze gebruiken ook cool:gen. Cobol is veel te gangbaar ;)
Je kunt ook gewoon mensen trainen / opleiden voor Cobol. Dat je niet weet dat je Cobol hebt als belastingdienst is flauwekul. Begin vandaag in plaats van over twee jaar te beweren dat je geen Cobol programmeurs kan vinden. Dit argument gaat op voor bedrijven met minder dan vijfhonderd medewerkers. Voor een grote organisatie als de belastingdienst is het geen sterk argument.
Waar zeg ik dat de Belastingdienst niet weet dat ze COBOL hebben?

En natuurlijk wordt dat gedaan wat jij zegt, opleiden, maar niet veel mensen willen dat meer omdat het geen nieuwe moderne taal is. Net zoals dat met talen als Latijn gebeurt.
Ja, dat is een probleem. Wellicht kan geld helpen en natuurlijk goed uitleggen wat het maatschappelijk belang is van COBOL (je hebt gelijk, hoofdletters!).
ik zit te overwegen Cobol te gaan leren. Leuk voor later. Beetje freelance consultancy doen om antieke meuk in de lucht te houden. (en ze naar - niet schiet jezelf in je voet - moderne oplossingen te brengen).

Pensioenklusjes.
Ze zouden heel graag willen moderniseren. Maar er zijn niet genoeg mensen om het op te kunnen pakken.

En de aankomende 5 a 10 jaar stromen heel veel medewerkers uit ivm het bereiken van de pensioengerechtede leeftijd. En ze mogen niet werven ivm bezuinigingen.

Dus als we iets willen dan moeten we vooral niet stemmen op een partij die het ambtebaren bestand wil laten krimpen. Want nu zijn ze al blij als ze de toko overeind kunnen houden.
Mensen zijn geen eens het probleem, het probleem is dat de overheid geen geld uitgeeft om het project aan te pakken
De overheid bestaat toch uit mensen? ;)
Meestal is het: project -> aanbesteding -> externe ontwikkelaars

Zelf mensen in dienst nemen doet men minder vaak. Veel liever werken ze met een flexibele schil; de ZZP-ers die ze nu eruit willen hebben.
Meestal is het: project -> aanbesteding -> externe ontwikkelaars

Zelf mensen in dienst nemen doet men minder vaak. Veel liever werken ze met een flexibele schil; de ZZP-ers die ze nu eruit willen hebben.
de overheid duwt juist HEEL hard om externen te verambtelijken heb ik gemerkt. En genoeg die er op happen. Ik heb hele hordes goed externe IT'ers ambtenaar zien worden.
Dit wordt al volop geprobeerd. Er worden al miljarden tegenaan gesmeten alleen rust er een beetje een vloek op het concept "overheid en IT"

Een combi die heel vaak heel erg verkeerd gaat waarna de boel geschrapt wordt.
Aan de overkant van de plas hebben ze nog wel een paar IT-ers met ervaring in het omzetten van oude software naar moderne, inclusief AI-toepassingen :Y)
Dit probleem bestaat niet, in NL kunnen we dit ook wel. Sterker, waarschijnlijk kan de belastingdienst het zelf ook nog wel als ze de prioriteit daaraan geven.
Hoofd van de belastingdienst heeft al een keer in een commissiedebat uitgelegd dat de regering alle wetgeving kan maken die ze willen maar dat daar de komende 5 jaar in ieder geval niks van verwerkt kan worden in de systemen wegens achterstallig onderhoud. Niks schandaal in de maak, we zijn er al.

Natuurlijk niet iets waar de regering graag de aandacht op vestigt.
Zoek en vervang is dan de grootste vriend.
Ik hoop heel erg dat je geen developer bent?

Dat is namelijk nogal een gevleugelde uitspraak ;) Als het echt zo simpel was dan zou het al lang gedaan zijn.

Bovendien zorgt technical debt er eigenlijk altijd voor dat je niet kan stoppen bij een taak die heel simpel lijkt. Er komen meestal nog wat extra taken uit. Waar ook weer taken uit komen. Die op hun beurt ook voor taken zorgen.

[Reactie gewijzigd door Stukfruit op 10 augustus 2025 22:20]

Ik heb zelf recentelijk aan een project gewerkt met een grote hoeveelheid technical debt. Uiteindelijk besloten om aan te raden om maar van scratch te beginnen omdat dit uiteindelijk sneller en goedkoper zou zijn dan de technical debt aanpakken.

Technical debt is echt geen grap, verkeerde keuzes maken in het begin van een project zijn echt de dood van een ICT project. En met een overheid die graag 'centen wilt besparen' en daarom vaak niet de juiste stappen wilt zetten om een goed ICT project op te zetten krijg je matige software met veel problemen die vervolgens lastig op te lossen zijn omdat alles op elkaar gebouwd wordt en afhankelijk is van elkaar.
Ik kan mij voorstellen dat de bestaande belastingwet- en regelgeving dat volledig in de weg staat. Het belastingstelsel is immers opgebouwd uit een wirwar van archaïsche wetten, beslisnota’s en jurisprudentie.

In plaats van enkel de IT te vernieuwen, lijkt het mij verstandiger om eerst de onderliggende wet- en regelgeving grondig te vereenvoudigen en moderniseren, zoals een aantal jaar geleden met de Omgevingswet is gedaan.
Zoek en vervang als belangrijke functie (dus zeker niet de enige) geeft aan dat je niet heel veel aan de code kunt veranderen. Een percentage vervangen is mogelijk, maar dan is het al verschrikkelijk oppassen dat je niet onbedoeld veranderingen op verkeerde plaatsen verandert.
Nou, je kan mij niet wijsmaken dat de Belastingdienst nog steeds 50 jaar oude code gebruikt. En 50 jaar terug (sorry, maar ik werkte toen al met harddisks) waren tape based systemen al echt uitgefaseerd. Ik weet dat o.a. de belasting toen met grote Philips systemen werkte, P1400 e.d., dat waren (voor die tijd) behoorlijk snelle systemen. 100 k? Praat over 1024 mb minimaal toen. Later is dat allemaal door veel modernere systemen vervangen, waarbij ook de broncode is vervangen en omgezet.
Ben daar ooit in Apeldoorn geweest en dat was groot, imposant en vooral ontoegankelijk voor buitenstaanders. Ja, ook Cobol werd gebruikt, heel normaal toen.
de grote systemen van de belastingdienst waren bull machines, eind jaren 70 kwamen de iBM machines. Philips systemen hebben voor de centrale verwerking nooit een grote rol gespeeld. tot begin jaren 80 was sequentiele tape verwerking de hoofdzaak. er lagen toen ca 50000 tape reels in de kluizen.

ik heb er vanaf 83 gewerkt

[Reactie gewijzigd door peter-rm op 10 augustus 2025 22:53]

Als "jonkie" vind ik dat toch wel machtig interessant om te lezen allemaal.

Wellicht iets voor Tweakers om eens in te duiken.
IT bij de belastingdienst is zeker video waardig.
Vergeet niet latere machtige tape silo's in het vroegere gebouw L. Allemaal iets van 1500 tapes per silo. Rijen vol met HPE 9000 systemen (welke overigens ook nog op de locaties stonden zoals Amsterdam, Amersfoort, Eindhoven, ...). Ontiegelijk veel Model 95 systemen met Novell, later vervangen door HP Netserver systemen. Heb er met mijn voormalige werkgever genoeg geleverd.

Maar die zelfs belastingdienst heeft ook aan de wieg gestaan om heel Nederland te verglazen met al hun glasverbindingen langs het Nederlands spoor.
Als iemand die recent een opdracht bij de belastingdienst heeft gedaan: Nog steeds mainframes en veel IBM systemen die erg achterlopen.
Ik kan me dat prima voorstellen, ik kom bedrijven tegen die 20 jaar bestaan en nog op 20 jaar oude software draait omdat het simpelweg nog gewoon werkt.

De belastingdienst is heel wat ouder, als er geen motivatie is om het te herschrijven gebeurt het simpelweg ook niet (vernieuwen om het vernieuwen is eigenlijk nooit een goed argument).


Ik verwacht zelf dat er nog wel software draait van 40 jaar oud, omdat het nog werkt.
Eigenlijk zou juist jij beter moeten weten. 50 jaar geleden (je was toen 20! volgens je profiel) waren er een handvol harddisks voor Cray en IBM systemen, maatje koelkast. Ik kan mij heel goed voorstellen dat de BD uit kosten overwegingen tape gebaseerde systemen draaiden. Maar evengoed, allerlei routines in zelfs recente libraries hebben onderliggend nog veel routines die ooit in b.v. Fortran zijn uitgedacht, en eventueel later vertaald naar C++, maar daarmee nog steeds dezelfde logica gebruikend.
Zoals in je quote staat: “het om oude code gaat”.

De practice van de jaren 1980/90 is anders de huidige. Oftewel appels met peren vergelijken. De omgeving was anders, de tools waren anders, de maatschappij was anders.
Mwah.
Toen ik midden '80 leerde programmeren werd dat al als slechte praktijk gezien, zelfs op een mainframe van die tijd (waar je maar 1 server had). Code, data en configuratie moest je scheiden. We hadden wel code waar dat niet zo was, maar die was (veel) ouder.
Het probleem is ook dat er verschillende leveranciers en developers aan hebben gewerkt.

De overheid heeft bijna al zijn kennis uit het raam gegooid (stem vooral VVD mensen), en alles hangt als een touwtje aan elkaar.

Ik snap bijvoorbeeld nog altijd niet dat de Toeslagen apart worden verrekend, want volgens mij kan dat prima allemaal worden voorberekend. Het voorkomt ook allemaal wazige fouten, zoals de Toeslagenaffaire.

Verder zijn er heel developers met o.a. een HBO diploma die dit wel normaal vinden om te doen. Ik heb vaak het gevoel dat ze daar minder kijken te kijken naar de praktische zaken (zoals beveiliging en sanitizing), en meer naar de bestuurlijke kant ervan.

Maar kennelijk vind ook onze overheid dat een MBO'er niet meer nodig zijn (zie recente uitspraken UWV), en dat AI die praktijk wel kan overnemen.
Een goede programmeur komt van het WO of HBO. Tenminste als die meer moet doen dan voorgekauwde specs uitwerken. Analytisch vermogen, abstract denken, kennis van de wereld, samenwerken zijn eigenschappen die echt van belang zijn.
Dat wil niet zeggen dat er niet een individuele MBO-er is die daartoe geschikt is. Maar de MBO IT opleidingen leveren niet het vereiste niveau voor een goede programmeur af. Mijn installateur voor de warmtepomp vindt overigens hetzelfde in zijn metier.
Dus, ben je goed op het MBO, ga vooral door op het HBO.
Ik weet dat het fashionable is om te doen alsof MBO en HBO, WO gelijk aan elkaar zouden zijn, maar laten we een kat een kat noemen. Het is niet zo.
Een goede programmeur voldoet aan de voorwaarden om kwalitatief goede code te schrijven. Dit kun je ook leren zonder daarvoor formeel een papiertje te halen. Er zijn overigens ook genoeg personen die zeer intelligent zijn en juist daardoor niet goed in het schoolsysteem passen. Dus iemand kan prima aan de vereisten voldoen zoals je ze schetste, zonder formele (afgeronde) opleiding. Ik heb genoeg voorbeelden gezien waarbij de formeel opgeleiden onder deden ten opzichte van bv. schoolverlaters. Dit gaat bv om autodidacten die gewend zijn veel zelf te onderzoeken en na te denken en niet slechts leren wat ze verteld wordt te leren. Ik zeg overigens niet dat je niks aan een opleiding hebt, maar je kunt bv. ook een goede muzikant of voetballer zijn zonder formele scholing.
Precies dit. :)

Ik heb programmeurs gezien die hun HBO/VWO niet hebben afgemaakt (ik o.a. ook), maar toch kunnen programmeren en kritisch denken. Ik sta juist open voor feedback/dingen beter doen, en heel veel MBOers die precies hetzelfde willen, maar enkel verwacht worden te programmeren om te ontwikkelen. Tijd om even stil te staan, is dan vaak niet.

Dit zijn vaak de HBOers aan de top, die enkel besturen en implementeren, maar niet zelf begrijpen dat je ruimte nodig hebt om dingen op te zoeken of analyses op te doen.

Dus ontopic zie ik dit ook bij de overheid. Er zijn veel HBO'ers die niet perse willen programmeren, maar in aansturing en procedures denken. Daardoor missen ze wat 'hip' is in de huidige wereld.

*Niet allemaal, maar dit is mijn gevoel bij de overheid.

[Reactie gewijzigd door HollowGamer op 10 augustus 2025 21:14]

Met je eens. Ook ik was een programmeur uit de praktijk. Letten op wat echt nodig is, de juiste vragen stellen en net zo lang doorgaan tot het goed is. Goede ontwikkelaars zijn helaas zeldzaam, vooral; de 'strebers', waar ik altijd een bloedhekel aan had. Ik ben er al een paar jaar uit (leeftijd 70 nu), maar de missers die ik soms zie... Ook het denken dat AI alles kan.... Nee dus, alleen gezond verstaan en die grijze cellen gebruiken.
‘Van Gogh was een gek, maar niet iedere gek is Van Gogh’

Een hoge intelligentie is echt geen belemmering om op een universiteit in een onderwijssysteem te passen. Het kan wel een belemmering zijn op een andere plek in het schoolsysteem. Dan zit je niet op de juiste plek. Helaas komt dat voor.
Mijn indruk is dat MBO instellingen soms willen shinen met succesvolle studenten die ze eigenlijk gewoon snel hadden moeten wegsturen naar een hoger niveau en die hun succes niet zozeer te danken hebben aan hun opleiding. Die gevallen moeten niet maatgevend zijn om het niveau van een opleiding te benoemen.

Je begint met een zin die een cirkelredenering is. Je ‘dus’ lijkt me geen geldige conclusie. Dat is problematisch.
Een (zeer) hoge intelligentie kan belemmerend werken omdat sommige autodidacten niet altijd in een bureaucratisch systeem passen, dat vooropgesteld. Daarnaast kunnen sommigen uitstekend leren op precies de onderwerpen die ze zelf interessant vinden, maar zich daarbuiten bijvoorbeeld snel vervelen en zich er niet op kunnen concentreren. Dit gaat dan om een sterke intrinsieke motivatie voor zeer specifieke onderwerpen. Ook zegt intelligentie (ligt er ook een beetje aan hoe je intelligentie precies definieert) niet altijd iets over sociale vaardigheden of emotionele veerkracht, wat zeker ook impact heeft op je leervermogen binnen een bepaalde context. Dit zijn enkele voorbeelden.

Als we stellen dat alleen mensen met een HBO- of WO-opleiding “goed” zijn, dan lopen we tegen een paradox aan: de allereerste programmeurs hadden geen formele opleiding in informatica, want die bestond nog niet. Net zoals de eerste universiteit niet door een academicus kon zijn opgericht, omdat er nog geen academici waren. Wanneer in de tijd werden programmeurs en academici dan “goed”?

Ik begrijp je punt over dat MBO scholen hun studenten misschien willen behouden voor de cijfers. Dat zou kunnen. Ik ken geen getallen, maar je kunt altijd doorstromen naar het volgende niveau. Overigens, naar mijn idee wordt de waarde van bijvoorbeeld een hoge performale/praktische intelligentie onderschat en misschien soms zelfs op neergekeken. Als je een beroep wilt uitoefenen waarbij dat van belang is, wat heb je dan aan een ‘hogere’ opleiding? Laat ik het anders stellen, ik denk dat een hoog IQ (of HBO denkniveau) niet de enige voorwaarde is voor een goede programmeur. En ik zeg nadrukkelijk denkniveau, want dat kun je ook hebben (of ontwikkelen) zonder formele opleiding.

Ik heb je argument over de cirkelredenatie opnieuw en opnieuw bekeken, maar ik zie hem niet. Mijn “dus” was een inductieve.
Er zijn genoeg ex-MBO'ers met niveau, sommige leren door en geven zelfs les aan universiteiten.

Het is misschien leuk om neer te kijken op mensen, of trots te zijn op wat je zelf hebt bereikt in je vormende jaren (of welke gedachte dan ook). Dat MBO'ers minder gestudeerd hebben en daarom op veel/alle theorie een achterstand hebben, hoeft niet te betekenen dat een ex-MBO-er op dat niveau moet zijn blijven hangen.

Je redenatie is wellicht in algemene zin te volgen (zeker in je voorbeeld dat gaat over mensen die starten op de arbeidsmarkt!), maar er worden kansen gemist zo. Dat een UWV zo werkt is te begrijpen i.v.m. efficientie. Laten we buiten de context van een UWV of een rekenmodel, zoveel mogelijk proberen mensen te beoordelen als individu.

N.B. gaf vroeger bijles aan MBO-ers elektrotechniek voor wiskunde en programmeren.
Verder zijn er heel developers met o.a. een HBO diploma die dit wel normaal vinden om te doen. Ik heb vaak het gevoel dat ze daar minder kijken te kijken naar de praktische zaken (zoals beveiliging en sanitizing), en meer naar de bestuurlijke kant ervan.

Maar kennelijk vind ook onze overheid dat een MBO'er niet meer nodig zijn (zie recente uitspraken UWV), en dat AI die praktijk wel kan overnemen.
Huh? Ik ben een paar jaar geleden afgestudeerd van het HBO maar dit is echt niet iets waar je daar mee weg kwam, laat staan dat het normaal was :? . Hier waren het juist de MBO'ers die op school niet het gehele plaatje leerde (hoewel genoeg uit intresse zelf wel breeder leerde). Wellicht dat je mensen bent tegengekomen met opleidingen als "Business IT" en dergelijke? De bestuurlijk gefocusde opleidingen zeg maar, ipv de technische...

Overigens vind ik beveiliging in vrijwel elke opleiding die ik zie ondermaats gerepresenteerd :'), maar zelfs dan niet zo laag dat dit normaal is. Ik kom zo eens in het half jaar kijken wat studenten van mijn oude opleiding doen en zie het het afgelopen jaar gelukkig wel groeien, dus hopelijk zet die trend voort.

Neemt niet weg dat ik genoeg MBO'ers ken die beter werk leveren dan veel HBO'ers, en genoeg HBO'ers die nogal mattig werk leveren. Maar meer op een "allebij zijn prima, allebij kan slecht zijn, ligt meer aan de persoon dan de opleiding" manier dan een "HBO'ers missen wat" manier. Helaas vinden er genoeg mensen het prima zolang de code "werkt" (met een reden tussen "), maar dat staat los van opleidingsniveau.

[Reactie gewijzigd door Cambionn op 10 augustus 2025 13:43]

Je hebt zeker gelijk. Er zijn mensen met een HBO niveau, die niet naar security kijken, maar die heb je ook zeker op MBO niveau.

Mijn punt is dat we wel heel veel denkers hebben tegenwoordig. Ook bij de overheid zie je vaak zaken terugkomen, zoals de recente broncode van iets dat ik mij al niet meer kan herinneren, waarbij je juist dat stukje gevoel voor praktijk miste.

Beide zijn ondermaats, ik zie genoeg mensen een browser addon installeren die data steelt en productie data voor lokaal testing gebruiken. Prima als je dat doet voor je eigen dingen, niet voor de overheid.
Het punt is dat het niets met het soort opleiding te maken heeft. Ik heb ze allemaal van dichtbij gezien als student en nu in het werkveld. Vrijwel niemand doet het goed vanuit de opleiding. Of ze nu een MBO, HBO of WO(-master) opleiding achter de rug hebben.

En dat is niet erg. Je kan niet verwachten dat iemand met 3-5 jaar opleiding alles goed doet. Daar hebben ze nog 20+ jaar voor en tot die tijd zullen er (hopelijk) genoeg collega's zijn die ze erop wijzen.
Ja, helaas werkt dat dus niet meer. Juniors komen momenteel nog nauwelijks aan banen omdat er overal afgeslankt word. Geef de senior een AI assistent ipv een Junior lijkt het devies te zijn. Veel goedkoper en net zo productief denkt men.
Voor zover ik de systemen begrijp is het wel degelijk mogelijk om in ieder geval een "waarschuwing" te geven wanneer iemand recht heeft op iets als een toeslag. Uitgaande van de dan bekende gegevens uiteraard.


Er is namelijk ook een uitwisseling van gegevens met bijvoorbeeld het UWV die vervolgens op bepaalde momenten "in kan grijpen" indien er iets niet lijkt te kloppen. Dat is ook iets waar meer gebruik van gemaakt zou moeten worden in plaats van "een aanpassing in je uitkering" doorgeven terwijl er ergens een kleine wijziging plaatsvind. Dat is erg verwarrend voor veel mensen.
Heeft veel te maken met hoe er gewerkt wordt, het is niet per definitie onveilig. Zolang de code niet op straat ligt. Wel lijkt me dit weer lastig als je verschillende omgevingen hebt. Tja tijden veranderen. Maar zolang ze het 'geheim' houden is het niet per definitie onveilig.
1980 is iets te modern voor deze software, denk ik. Vermoedelijk komt deze uit 1960.
Grote kans dat het hier om 40~50 jaar oude cobol applicaties gaat.

En politieke wil zal er niet zijn om deze applicaties te moderniseren. Nieuwe functionaliteit heeft immers altijd prioriteit over herbouw en verbeteringen. Zeker met een enorm wispelturig politiek aan het roer.

Vervangen van dergelijke applicaties vereisen meer visie dan de gemiddelde politicus vandaag de dag heeft.

Ik heb bij een partij gewerkt waar ze een dergelijke oude cobol applicatie in hun core gebruikte. Gigantisch lastig om uit te faseren.

[Reactie gewijzigd door Caayn op 10 augustus 2025 11:56]

Het probleem bij de belastingdienst en UWV is dat veel zaken ooit aan elkaar zijn geknutseld, maar niemand het durft op te ruimen: niemand wil de idioot zijn die het systeem heeft uitgezet dat achteraf alle andere systemen in de lucht hield. In theorie een makkelijk probleem, maar de realiteit is dat het krankjorum moeilijk is dat te bepalen (dingen als een jaarrekening komen maar eens per jaar voorbij).
Nou weet ik niets over systemen bij de belastingdienst, maar ...

Gebruik kan je monitoren en dan kan je zo'n systeem toch na een jaar uitzetten? Bij onvoorspelbare incidentele koppelingen werkt dat weer niet.

Je hebt een ander probleem als een systeem custom-made is voor wetgeving in een bepaalde periode, of zelfs per belastingjaar is ingericht. Dan moet je dat systeem operationeel houden tot de bezwaartermijn is verstreken of misschien langer.

Als er systemen zijn die wel intern verschillende periodes van wetgeving overspannen, dan zijn ze weer veel moeilijker te herschrijven en is er een groot risico bij een big-bang overgang. Als je zo'n monoliet in delen wil herschrijven, dan zit je weer met de (on)mogelijkheden om oude en nieuwe talen of andere onderdelen met elkaar te linken.

Je wil ook niet degene zijn die fouten introduceert vanwege het missen van uitzonderingen in complexe code gerelateerd aan regelgeving of anderszins.

Nou ben je er niet met wetgeving per belastingjaar, want ook binnen een belastingjaar wordt er nieuwe regelgeving geïntroduceerd, zoals vaak op 1 juli. Het lijkt me lastig te bepalen of je uiteindelijk beter af bent met een kopie van een systeem per belastingjaar of een systeem met intern tijdsgebonden uitzonderingen.

Gooi er een paar spreadsheets bij en de chaos is compleet.

Op het eerste gezicht zou ik neigen naar parallel draaien van backend systemen tijdens het jaar van introductie, of zonodig nog langer, en het oude laten doodbloeden. Als de technologie of implementatie inderdaad verouderd is natuurlijk.

Maar zoals ik al schreef, sta ik aan de wal.

Ik zou de code of architectuur weleens willen zien.
Gebruik kan je monitoren en dan kan je zo'n systeem toch na een jaar uitzetten? Bij onvoorspelbare incidentele koppelingen werkt dat weer niet.
...
Op het eerste gezicht zou ik neigen naar parallel draaien van backend systemen tijdens het jaar van introductie, of zonodig nog langer, en het oude laten doodbloeden. Als de technologie of implementatie inderdaad verouderd is natuurlijk.
Dat is de theorie. En dat is hoog over dus makkelijk. En dus bouwt men een nieuw systeem dat het oude moet vervangen. Maar dan komt het moment waarop het oude systeem echt uit moet. En dan blijken systemen ook via filesystemen te communiceren, of zelfs in-memory (wat erg lastig traceerbaar is). Die oude meuk is vaak echt een black box waar je soms geen flauw idee hebt hoe dingen aan elkaar hangen. En leveranciers voelen zich vaak genoodzaakt om geen enkele verantwoordleijkheid voor gevolgen te willen nemen en dat vaak formeel heel erg duidelijk te communiceren naar hoger management (vaak ingegeven door hun juristen). En dan durft geen enkele manager de eindverantwoordleijkheid te nemen om het systeem daadwerkelijk uit te zetten. Het vereist enorm veel bestuurlijke moed om de boel daadwerkelijk plat te branden en overnieuw te beginnen.

[Reactie gewijzigd door J_van_Ekris op 10 augustus 2025 17:34]

Of wat dacht je van Cool:Gen. Dit wordt ook gebruikt door de Belastingdienst, maar daar hebben nog minder mensen van gehoord dan van COBOL. Ik vermoed zomaar dat alles geschreven in Cool:Gen niet is gedaan volgens de best practices zoals we in 2025 kennen
Ik heb het geluk dat ik zakelijk Cool:Gen enkel van naam ken.
Voor overheidssoftware is er nog een bijkomend probleem dat ze geen 'baas' zijn over hun processen en use cases.
Het parlement beslist elk jaar over nieuwe regeltjes en uitzonderingen, die er telkens aan toegevoegd moeten worden. Dat creëert ongelooflijk complexe processen, en navenant lastige software.

Die dan migreren...

Idealiter stemmen ze zich af op een wetgevende hervorming (vereenvoudiging). Maar politiek gezien wil iedereen zijn eigen uitzonderingetjes en voordelen natuurlijk behouden.
Best practices zijn ontstaan nadat er een heleboel bad practicus zijn geweest. In de tijd dat deze oude software is geschreven waren de best practices schijnbaar nog niet zo’n gemeengoed.
Ook zijn de toegangscontroles ‘hardcoded’ opgenomen in de broncode.
Uit bovenstaande zin uit de uitspraak vermoed ik dat niet alleen server namen en database namen zijn opgenomen in de code maar ook wachtwoorden. “IF Gebruikersnaam == “Administrator” AND Wachtwoord == “Administrator” THEN …
Het probleem is niet dat dat is gebeurd (vermoedelijk niet), maar dat je het niet uit kan sluiten. En daarom geef je iemand niet zomaar de codebase.

Dit roept bij mij de vraag wel op: waarom wil iemand die nu echt?

Zelf zou ik die codebase ook wel willen zien, zodat ik een betere versie kan maken en kan aanbieden.
Zelf zou ik die codebase ook wel willen zien, zodat ik een betere versie kan maken en kan aanbieden.
https://werken.belastingdienst.nl/vacatures/ict?distance=Afstand&order_by=publication_date ;)
Licht offtopic maar: Als je dat ziet wil je daar toch acuut niet meer werken....senior technische functies die evenveel of zelfs minder betaald krijgen dan scrum rollen.

Wat ontzettend kansloos.
Volgens mij staat er bij elke functie een salaris range van ruim 2.000 euro.

Dus voordat je het kansloos gaat noemen, gewoon even iets verder kijken dan 1 getal.
Ik weet prima hoe salarissen werken bij dit soort organisaties. Dat er een range staat i.p.v. 1 getal verandert de situatie niet. Het gaat om de waarderingssystematiek (welke functie hoort bij welke schaal) en de keuze voor werkwijze (scrum functies) die gewoon niet deugt.
ik heb er al gewerkt maar, eh, dan wordt ik heel wat beter betaald :)

Aangezien ik ze meer dan 10 miljoen euro heb bespaard, vonden we dat beide een win-win. Maar een gewone baan aannemen bij de BD... nope.
Dit roept bij mij de vraag wel op: waarom wil iemand die nu echt?
Je wilt bijvoorbeeld bewijzen dat de code en dus de daarop rustende algarytmes onveilig zijn of bias bevatten zodat je de staat aansprakelijk kunt stellen

Om maar ėėn scenario te noemen

Voordat je ook maar iets kunt vinden zul je eerst heel veel moeten speuren
Ja, alsof ze in een stuk code hebben staan "if ouders niet NL dan risico := risico + 50%"

Zo dom zijn ze nu ook weer niet. Dat zouden ze zelf allang hebben aangepast. Dus dit lijkt mij echt heel lastig.

Het kan wel zijn dat er code instaat voor steekproeven. Die is natuurlijk tegelijkertijd gevoelig en geheim.
Je hebt principes en de echte wereld. En in de echte wereld worden vanwege omstandigheden bepaalde principes vloeibaar.


Daar kun je wat van vinden, maar dat gebeurt in iedere organisatie waar onder tijdsdruk of budget limieten iets moet worden opgeleverd. En zonder deze omstandigheden worden prioriteiten verkeerd gesteld en je product nooit af.
[...]

Wow. Dat is al een red flag van heb ik me jou daar, en een gevalletje erg bad practice dat men dat zo gebouwd heeft. Je zet dit soort zaken nooit hardcoded in een applicatie, dat doe je met configuratiebestanden, parameters in de software etc. Anders is het niet te beheren op termijn.
Code reviews? Audits? Dat klinkt modern. Hadden ze die dingen al toen die software werd ontwikkeld?
Maar nog los daarvan: die informatie kan je toch weglakken? Dat gebeurt bij andere informatie, waar eventuele gevoeligheden in staan, toch ook gewoon (en terecht)? Dat lijkt me dus niet echt een valide argument om het niet vrij te geven?
Dat is gewoon veel werk. En als ze het 1 keer toestaan is er een precedent en gaan meer mensen om die code vragen. En een club als de belastingdienst heeft honderden, misschien wel duizenden, applicaties.
Maar nog los daarvan: die informatie kan je toch weglakken?
Dat kan inderdaad, de complete codebase moet dan uitgekamd worden om er zeker van te zijn dat er geen zaken openbaar gemaakt worden die gebruikt kunnen worden om de complete belastingdienst plat te leggen. Dit kan je niet overlaten aan een stagiere die even niks te doen heeft aangezien dit zo'n enorm risico met zich meebrengt en vereist dat hier geen enkele fout in gemaakt wordt. Dus dit kan alleen uitgevoerd worden door mensen met een hoog niveau van kennis. Met andere woorden, het zoveelste dure team van consultants van Deloitte die hier lekker lang over gaat doen.
De kans dat de privacy van particulieren geschaad wordt, lijkt mij eerder klein.
De meeste informatie zal toch betrekking hebben op ondernemingen. Dit hebben slechts een beperkt recht op privacy.

Het kan natuurlijk ook dat de Nederlandse staat illegale staatssteun verleent door middel van gunstige belastingsconstructies. Dat kan wel tot rechtzaken leiden, en schadevergoedingen aan benadeelde partijen.
en hoe is dit door de code-review/audits gekomen?
Die waren niet de norm in 1972 he? Ik denk dat je niet snapt dat dit zeer deels zeer ouder software is die, als ik me niet vergis, deels nog in Kobol is. Daarnaast is het natuurlijk amper een risico bij software die voor een zeer specifiek doel en een zeer specifieke klant is. Je moet echt de software (of zelfs de broncode) stelen om er iets aan te hebben.

Je maakt je erg druk over niets.
Wow. Dat is al een red flag van heb ik me jou daar, en een gevalletje erg bad practice dat men dat zo gebouwd heeft. Je zet dit soort zaken nooit hardcoded in een applicatie, dat doe je met configuratiebestanden, parameters in de software etc. Anders is het niet te beheren op termijn.
Dat is met de kennis van nu zo. Net zoals je tegenwoordig een datum altijd ook de eeuw-aanduiding meegeeft. 50 to 60 jaar geleden dacht men daar echt anders over omdat men al blij was dat het werkte, en memory en storage onbetaalbaar waren. Het milleniumprobleem was niet voor niets een enorm ding destijds, terwijl we nu (hopenlijk) niet die fout meer maken. Dit is net zo.
Dat is net zoiets als hardcoded usernames/passwords in een applicatie zetten, en dan nog unencrypted ook.

Wie dit ooit goed gekeurd heeft, en waarom dit nooit herschreven is... en hoe is dit door de code-review/audits gekomen?
Omdat decennia geleden toen het gebouwd werd testen en reviewen geen gemeengoed waren, en nu het wel gemeengoed is men er niet meer aan durft te komen. Tel daar decennia aan roofbouw en onderhoud met angst om het systeem echt aan te passen bij op en je eindigt met wat de belastingdienst nu heeft

In dit soort antieke legacy systemen staat een heel groot onzichtbaar hek: het punt waarop men nog weet hoe het werkt. Het lijkt een beetje op jaarringen van een boom. Alleen hier: hoe dieper van de buitenkant je komt, hoe minder mensen het nog snappen. Met de leeftijd van dit soort systemen zijn er delen die niemand meer kent omdat de kennisdragers op zijn minst met pensioen zijn, maar waarschijnlijk al overleden. Ik heb vrij veel reverse engineering van complexe bedrijfskritische systemen gedaan, en als kennisdragers afwezig zijn om je te helpen is het een extreem moeizaam traject omdat je ziet dat zaken onlogisch zijn, maar je niet weet waarom. Soms is het roofbouw, soms is het iets oplossen zonder het kernsysteem te willen aanraken, maar soms is het krankzinnig subtiele bedrijfslogica. En commentaar is vaak afwezig of te summier om behulpzaam te zijn.
Maar nog los daarvan: die informatie kan je toch weglakken? Dat gebeurt bij andere informatie, waar eventuele gevoeligheden in staan, toch ook gewoon (en terecht)? Dat lijkt me dus niet echt een valide argument om het niet vrij te geven?
Als je dat soort dingen weet te vinden. Het probleem is dat het bergen aan code is waar niemand echt meer weet wat nu wat doet en of het nog gebruikt wordt. Echt een speld in een hooiberg.

[Reactie gewijzigd door J_van_Ekris op 10 augustus 2025 15:15]

Heb hun COBOL code wel eens ingezien. Ze geven zelf ook toe dat het een grote spaghetti is… ze durven allerlei code ook niet aan te raken hoewel er hele stukken dode code stukken zijn die nooit bereikt worden, maar stel dat iets de printstraat onterecht aan het werk zet hebben we er weer een schandaal bij in NL zeg maar…
Nooit hardcoded, waarom niet ik gok dat je telefoon overloopt met hardcoded waarden voor vergelijkbare zaken. Veel enterprise software die PakketX heet eist gewoon 1 op 1 een database met de naam PakketX niks configureerbaar aan alleen de database server waar het op draait.

Ik snap dat je inzage wilt in de broncode maar de ci/cd snap ik al een stuk minder, en inzage betekend niet geef mij de broncode, kom een middag op bezoek lijkt me ook prima.
Je kijkt te beperkt vanuit een huidig paradigma. Deze systemen komen uit een andere periode waarin zaken op een andere manier werden aangepakt en opgelost. Wat tot een prima oplossing kon leiden.

Als een systeem draait in een geïsoleerde omgeving, het systeem omvat data, proces en configuratie dan is het volledig veilig. In batch mode krijgt het alleen cijfermatige of basale alfanumerieke bestanden aangeleverd, en de uitvoer is van dezelfde soort. Heb je dit in COBOL gebouwd, dan heb je op byte niveau nagedacht. Die oude wereld is in sommige opzichten sterk te prefereren boven de hedendaagse puinhoop.

Deze systemen bestaan zolang omdat ze heel erg goed zijn gebleken. En omdat ze gebouwd werden door programmeurs die geselecteerd werden op een IQ van 135+. Wat ook enorm helpt.
het klinkt alsof je veel vertrouwen hebt in dit soort systemen. Het tegendeel blijkt keer op keer waar.
herinneren we ons ze docu "De Spaghetticode" nog van Zembla? Waarin een 200 Miljoen kostend project vd Sociale Verzekeringsbank een grote flater bleek ? https://www.bnnvara.nl/zembla/artikelen/de-spaghetticode
Er wordt gezegd dat het oude systeem prima was binnen de tijdsgeest/context/aanpak. Je verwijzing naar de Zembla docu gaat juist over de bar slechte vervanging daarvan met nieuwe technieken.
Je kan het belachelijk maken, maar een goed ontworpen mainframe applicatie voor landelijk of zelfs globaal gebruik voor miljoenen mensen en gevormd in een steeds veranderd IT en politiek landschap maar beperkt door techniek en kennis van 40-50 jaar oud is vaak te preferen boven een rotzooi zoals ze bij de SVB ervan hebben gemaakt om dat met iets nieuws om het nieuwe uit te faseren. En is ook zeker niet te vergelijken met keuzes om “kritische apps” op Windows 7 te draaien.
daarom heb ik ook even die Zembla docu vermeld en er zijn natuurlijk VELE andere voorbeelden waarin het vrij lachwekkend is om de overheid serieus te nemen in deze. En "een goed ontworpen mainframs applicatie" kan zeker goed werken maar da's een hele grote aanname van jou kant dat het systeem bij de belastingdienst goed ontworpen is. Dat ene SVB voorbeeld was een foutje van zo'n 300 miljoen. Als je zo'n overheid serieus neemt in het onderhouden van systemen , tja daar heb ik geen woorden voor.

[Reactie gewijzigd door AnonAapje op 11 augustus 2025 17:08]

Het wordt wel steeds meer, 200 mio, 300 mio.... Het was zo'n 43 mio voor het MRS als ik het goed lees dat de mist in ging, als onderdeel van SVB Tien wat op andere punten blijkbaar wel geld oplevert. Groot deel wordt nu bij Cap via rechtzaken terugggehaald. Maar dat terzijde. Nee overheid heeft geen goede trackrecord qua IT, maar er gaan ook veel projecten gewoon goed. IIn het bedrijfsleven wordt ook een hoop geprutst maar daar hoor je gewoon niet vaak iets van. Enig idee hoeveel projecten de overheid totaal draait? Mijn punt was ook niet dat het oude systeem van de BD nou per se zo goed was/is, maar uit eigen ervaring werd er destijds juist door de beperkingen meer dan nu goed over sommige dingen juist wel goed nagedacht, i.p.v. zoals nu te smijten met populaire termen, een frameworkje er tegenaan gooien dat over 2 jaar niet meer bestaat, en performance is er toch wel genoeg door gewoon een beetje groter te sizen in je cloud dus waarom zou je goed normaliseren, optimaliseren, etc. Dat soort werk. Als de aanpak slecht is faalt alles. En blijkbaar heeft het systeem van BD het toch uitgehouden ondanks tientallen jaren van allerlei invloeden - dan moet er wel iets goed zijn.
"maar er gaan ook veel projecten gewoon goed" het 'Parlementair onderzoek ICT-projecten' uit 2015 liet een succespercentage van 29% zien en lijkt me niet dat dat in de laatste 10 jaar is verbeterd.
Hij wilde anders ook de configuratiebestanden zien, dus dat lijkt mij gewoon een beveiligingsrisico...
Uit de uitspraak:
Eiser heeft op 16 januari 2023 verzocht om openbaarmaking van de sourcecode van het BTW-systeem (broncode). Daarbij verzoekt eiser om in ieder geval de volgende informatie:
  • [...]
  • configuratiebestanden voor zover deze geen geheimen bevatten (keys, wachtwoorden etc.);
  • [...]
Ik denk niet dat het handig is om de verzoeker woorden in de mond te leggen. Het probleem is niet dat de verzoeker persé alles wil hebben ongeacht het risico. Het probleem is dat de Belastingdienst geen onderscheid heeft gemaakt tussen de delen die risico opleveren en de delen waar dat niet zo is.
Dit is wat er gebeurt in een organisatie waar vrijwel constant bezuinigd en gereorganiseerd wordt, wanneer er snel in de paar weken tussen de goedkeuring van de belastingwetten na Prinsjesdag en het begin van het nieuwe belastingjaar wijzigingen in prgramma's aangebracht moeten worden waar die programma's oorspronkeljk nooit voor bedoeld zijn geweest.
Ik begreep eerst eerlijk gezegd niet waarom je de broncode van het btw-systeem zou willen zien. Bij inkomstenbelasting snap ik het nog wel, daar zitten complexe berekeningen in die echt per persoon verschillen.

Maar goed, btw blijkt dus veel ingewikkelder te zijn dan ik dacht. Het is niet gewoon “reken 21% uit”, maar er zitten allerlei uitzonderingen in: internationale regels, verleggingsregelingen, margeregels, fraudedetectie, gekke aangiftes en historische rotzooi van toen de regels nog anders waren. Logisch dat je wilt controleren of dat systeem wel eerlijk werkt.

Alleen vraag ik me af of je er wat mee kunt. Want dit spul draait waarschijnlijk nog steeds op CA Gen / COOL:Gen en COBOL. Dat is geen wilde gok, staat gewoon op het Rijks ICT-dashboard dat de Belastingdienst dat gebruikt.


En dan heb je een probleem: code die door zulke systemen wordt gegenereerd is echt complete onzin voor normale mensen zoals ik. Ik gok dat zelfs ervaren programmeurs er gek van worden zonder de originele modellen of documentatie, de juiste tools en een mainframe om het op te draaien. Je krijgt dan miljoenen regels rommel waar je geen touw aan vast kunt knopen. En levert dat dan iets op? Behalve dat je dan weet dat het niet zo is.

Al eerder genoemd door anderen, het enige echte risico lijkt mij niet te zitten in de logica, maar in gevoelige informatie zoals servernamen of wachtwoorden, dat soort dingen zit vaak hardcoded (nu not done maar vroeger de normaalste zaak van de wereld) in oude CA Gen-systemen. Maar dat kun je gewoon aflakken voordat je het publiceert.

Al is de code waarschijnlijk verouderd, onleesbaar en praktisch nutteloos, ik zou het gewoon openbaar maken. Laat ze die gevoelige data er eventueel met hulp van ai tools, er eerst uithalen, en dan publiceren. Transparantie is goed, ook al begrijpt niemand de code.

En misschien komt er dan ook een breder besef dat we misschien niet zo verder moeten.

[Reactie gewijzigd door aeon_flux op 10 augustus 2025 14:27]

Ik begreep eerst eerlijk gezegd niet waarom je de broncode van het btw-systeem zou willen zien. Bij inkomstenbelasting snap ik het nog wel, daar zitten complexe berekeningen in die echt per persoon verschillen.

Maar goed, btw blijkt dus veel ingewikkelder te zijn dan ik dacht. Het is niet gewoon “reken 21% uit”, maar er zitten allerlei uitzonderingen in: internationale regels, verleggingsregelingen, margeregels, fraudedetectie, gekke aangiftes en historische rotzooi van toen de regels nog anders waren. Logisch dat je wilt controleren of dat systeem wel eerlijk werkt.
Om te controleren of een systeem alle regels wel eerlijk verwerkt hoef je niet naar de prgrammacode te kijken.
Het systeem moet de wettelijke regels volgen. Je hoeft dus alleen maar te kijken of de uitkomst volges het systeem klopt met de uitkomst volgens de wet. En dat gebeurt dageijks ontelbare keren. Elk bedrijf gebruikt administratiesoftware dat zelf ook de berekening maakt wat de uitkomst volgens de wettelijke regels zou moeten zijn. Veel bedrijven zullen blind de Belastingdient geloven wanneer er een verschil tussen de twee uitkomsten zit, maar veel bedrijven ook niet. Wanneer de systemen van de Belastingdienst de regels uit de wet niet goed zouden volgen dan wordt er vroeg of laat (maar waarschijnlijk al zeer vroeg) aan de bel getrokken.
Het klopt dat je in theorie alleen maar hoeft te kijken of de uitkomst van het systeem overeenkomt met de wettelijke regels. In de praktijk is dat echter te beperkt.


-edit- verkeerde link en herinnering aan incident -edit-


De Belastingdienst wekt niet alleen met simpele tarieven van 9% en 21%, maar met een groot stelsel van uitzonderingen, verleggingsregelingen, margeregelingen, internationale handelsregels en historische overgangsbepalingen. Die complexiteit maakt dat er veel meer kan misgaan dan alleen een verkeerd percentage. Het gaat ook om de manier waarop het systeem uitzonderingen verwerkt, controles uitvoert, en of er geen verborgen aannames of automatische correcties plaatsvinden die de wet nét anders interpreteren. Zulke dingen zie je vaak niet terug in alleen de einduitkomst.

code-inzicht kan een waardevolle manier zijn om het systeem te controleren op eerlijkheid en correctheid, maar dat je de veiligheidsrisico’s niet mag negeren.

Wie kwaad wil, kan proberen in de logica een zwakke plek of “loophole” te vinden, ik kan geen concreet voorbeeld verzinnen voor de btw maar wel een vergelijking trekken naar box 3. Om de belasting in box 3 te verlagen kun je vanuit je eigen bv naar privé een direct opeisbare lening lenen, waardoor het belastbare vermogen in box 3 afneemt én geen rente hoeft te betalen. Een uitkomst die eigenlijk niet gewenst is maar wel binnen het wettelijk kader past.

[Reactie gewijzigd door aeon_flux op 12 augustus 2025 21:26]

Al die uitzonderingen en regelingen resulteren uiteindelijk toch in een bepaald af te dragen of te ontvangen bedrag. Elke afwijking met wat de eigen boekhoudsoftware van een bedrijf aangeeft moet verklaard kunnen worden met het wetboek, verdraen en beleidsregels in de hand. En hoe ingewikkeld dat ook klinkt, het is vele malen makkelijker dan -tig maal gewijzigde en aangevulde spaghettie-code in een broncode na te lopen.

Wanneer een belastingadviseur aan kan tonen dat de berekening van het BTW-systeem van de Belastingdienst niet klopt, terwijl alle input corect is, dan moet die code alsnog nagelpen worden, door een programmeur bij de Belastingdienst die veel beter weet waar hij/ ij naar kijkt en zoekt dan iemand van buiten.
Ik ben opzich voor een open overheid. Maar kan iemand mij uitleggen wat de meerwaarde is om de broncode te weten van dit soort systemen?
Inderdaad. Prima dat de overheid beter moet beargumenteren waarom ze de broncode niet willen openbaren, maar kunnen we dan ajb ook toe naar een systeem waarin de aanvrager ook duidelijk moet beargumenteren waarom ze de broncode wel moeten openbaren?
Prima dat de overheid beter moet beargumenteren waarom ze de broncode niet willen openbaren, maar kunnen we dan ajb ook toe naar een systeem waarin de aanvrager ook duidelijk moet beargumenteren waarom ze de broncode wel moeten openbaren?
Wat een rare opmerking. De burger doet een beroep op de wet. Dat geeft hem het recht om die broncode te bekijken. Wat voor andere argumenten heeft ie nodig?
Nou, een goed argument waarom we met zijn allen miljoenen gaan uitgeven voor iemands nieuwsgierigheid lijkt me wel prettig.

Ik snap de WOO wel, en bij motivatie mag je natuurlijk niet gaan toetsen anders werkt die wet niet, maar er zijn zat mensen die de BD gewoon op kosten willen jagen uit wraak voor een boete o.i.d. Dat zou je mogen afstoppen.
Dat spreek ik ook niet tegen. Misbruik van dit soort regels is ook een probleem. Al was het maar omdat het ambtenaren afhoudt van werk waar de rest van Nederland meer aan heeft.

Wat ik bedoel: Als de wet zegt dat die informatie inzichtelijk moet zijn, en geen voorwaarden stelt, dan moet de rechter niet naar argumenten vragen. De wet is het argument. Het zou een rare boel worden als we onze rechten alleen maar met goede argumenten mogen uitoefenen.
da's de eeuwenoude smoes vd overheid en de bewijslast omdraaien. Meteen met quasi oordelen komen als "'t zal wel wraak zijn of 'ambtenaren bezighouden' ".
WOO is simpel, de overheid dient binnen 4 weken te antwoorden en 6 weken voor "complexe antwoorden". Zoals Brenno de Winter ook al vele malen heeft uitgelegd: de overheids-info moet per default worden openbaart tenzij er gegronde redenen voor zijn en niet andersom.
De overheid gebruikt deze weigeringen steeds vaker om haar eigen fouten te verbergen:
- Toeslagenaffaire WOO 2021
- WHO regels WOO 2025
- Microsoft Datacenter Project in Middenmeer – 2024
- Spoorwegovergang Incident Rapport – Achmea, 2025
en deze lijst is nog maar het topje vd ijsberg
Komt bij dat het klassieke argument ‘fouten in de beveiliging vinden en verhelpen’ voor een groot deel niet op gaat. Deze systemen hangen om te beginnen in principe niet aan internet, zegt de Belastingdienst zelf en dat is ook logisch. Het open source argument werkt in de praktijk ook vaak niet of juist averechts, want degene die daar normaliter tijd in steken cq nuttige bijdragen aan leveren, zijn vooral de bedrijven en personen die zelf zo’n systeem draaien. In dit geval is dat alleen de Belastingdienst zelf. Blijft over: Degenen die zoeken naar een manier hoe ze deze software kunnen traineren.
Deze systemen hangen om te beginnen in principe niet aan internet, zegt de Belastingdienst zelf en dat is ook logisch.
Laatste keer dat ik BTW aangifte deed gebeurde dat gewoon via het Internet. En je maakt mij niet wijs dat ze die aangifte uitprinten en met de hand in het berekeningssysteem intypen, vervolgens de uitkomst daarvan ook weer met de hand op de website zetten....

Deze systemen hangen gewoon aan het internet, daar kan geen seconde twijfel over bestaan. Ware dat niet zo dan zou niemand zijn aangifte digitaal kunnen doen.

Daarnaast gaat dit niet over open source. Niemand zal pull requests kunnen doen naar de codebase van de belastingdienst. Het gaat hier over openbaarheid van informatie.
Laatste keer dat ik BTW aangifte deed gebeurde dat gewoon via het Internet. En je maakt mij niet wijs dat ze die aangifte uitprinten en met de hand in het berekeningssysteem intypen, vervolgens de uitkomst daarvan ook weer met de hand op de website zetten....
Dit is natuurlijk een karikatuur, je kan prima aangiftes ontvangen op een systeem wat wel aan het internet hangt om die vervolgens door te sluizen naar een systeem wat niet aan het internet hangt zonder uitprinten en met de hand intypen.
Defacto kun je dat niet. Als Systeem A documenten ontvangt via het internet en electronisch doorstuurt naar Systeem B dan hangt Systeem B defacto óók aan het internet.

Het is wellicht iets minder eenvoudig om binnen te komen omdat er geen directe verbinding is. Maar stellen dat het systeem niet met het internet verbonden is, is naïef én fout.
Volgens die redenatie zou zelfs wanneer de data wordt uitgeprint en met de hand ingevoerd en systeem nog aan internet hangen.

Wat hier bedoeld wordt is of het systeem via internet benaderbaar is. Wanneer het aangifte--invoer systeem de gegevens in een database zet en een ander systeem vanuit die database de gegevens haalt om de aangifte te berekenen, dan is dat andere systeem niet via internet benaderbaar.
Volgens die redenatie zou zelfs wanneer de data wordt uitgeprint en met de hand ingevoerd en systeem nog aan internet hangen.
Zo werkt het niet. Als je het met de hand invoert is er geen netwerk verbinding tussen het invoerende en verwerkende systeem.
Wat hier bedoeld wordt is of het systeem via internet benaderbaar is. Wanneer het aangifte--invoer systeem de gegevens in een database zet en een ander systeem vanuit die database de gegevens haalt om de aangifte te berekenen, dan is dat andere systeem niet via internet benaderbaar.
Of het nu via een database, een API, een servicebus of wat dan ook gaat, het verwerkende systeem is via een netwerk verbonden met het internet. Het doet er niet toe of dat rechtstreeks of via een bergje hops gaat. Zolang er geen menselijke interventie nodig is tussen invoerende en verwerkende systeem is het verwerkende systeem defacto op het internet aangesloten.

Als een kwaadwillende toegang krijgt tot het invoerende systeem kan hij daar code uitvoeren die toegang geeft tot de database server waar hij code kan uitvoeren die toegang geeft tot het uitvoerende systeem.
True. Maar er zijn ook bv usb sticks die we voor dataoverdracht kunnen gebruiken. ;)
Dat is helemaal niet raar. Dat is het gelijkheidsbeginsel.
Gelijkheid tussen wie? Burgers en de overheid? Die zijn niet gelijk.
?? Het gelijkheidsbeginsel betekent niet dat iedere burger gelijk behandelt wordt. Niet dat de overheid hetzelfde behandeld wordt als een willekeurige burger. Dat zou ook raar zijn want er is per definitie een machtsdisbalans tussen een burger en een overheid.

In de wet is duidelijk opgenomen dat het recht op informatie niet gemotiveerd hoeft te worden. Dat is ook niet wenselijk, want dat betekent dat de overheid voortaan alles geheim kan houden als het belang van de vrager niet in het belang van de overheid is. Een journalist (of onafhankelijk burger) zal dan waarschijnlijk nooit meer een misstand kunnen vinden of aantonen omdat de overheid dat altijd zal weigeren.
Hij moet summier aan kunnen geven welk doel hij persoonlijk heeft met het opvragen/ vrijgeven van de gegevens (in dit geval de brocode).

Er zijn mensen die puur om te treiteren overheden overspoelen met WOO-verzoeken. Dat gaat ten koste van de verwerking van valide verzoeken en van de overige werkzaamheden van die overheidsorganisaties. (Zie het als een fysieke DOS-aanvaf.)
De aanvrager kan controleren of de code iedereen gelijk behandeld wordt, zoals het in de wet beschreven is.
De wet openbaarheid overheid geeft niet aan dat de aanvrager een reden moet geven en dat is ook terecht. Het is natuurlijk raar dat het geen automatisme is. Dat kan ook een financieel voordeel zijn voor de overheid (lees: wij) als er fouten uitgehaald worden.
Dat hoef je toch niet uit de code te halen. Gewoon kijken of je aangifte volgens regelgeving overeenkomt met wat eruit het programma rolt en je bent gucci
Ja want jij kan de aangifte van iedere Nederlander zien...
Dit gaat om BTW aangifte, niet jou inkomsten belasting. Doorgaans geeft jou boekhoud software aan om hoeveel het zo gaan, dus je ziet meteen als het niet klopt en gaat er dus ook niet zo maar van uit dat het wel goed zal zijn.
Oké, alle ondernemers dan die btw-plichtig zijn, kun je die allemaal inzien?
Je doet nogal een aanname.

Maar het doet er totaal niet toe of jij denkt dat het goed is. We hebben als burger gewoon het recht.
Maar daar krijgen ze natuurlijk ook gewoon audits voor, net als andere grote bedrijven,
Want een audit is ook 100% dekkend gelukkig 🥲
Controle is natuurlijk prima, maar anderzijds voelt dit wel een beetje als een gelegenheidsargument, want miljoenen bedrijven en bedrijfjes laten hun omzetbelastingaangifte doen, door specialisten of rekenen dit zelf tot ver achter de komma uit. We zouden er snel genoeg achter komen, dat er ook maar iets niet klopt.

Daarnaast is er allerlei software die de regels van de Belastingdienst toepast op jouw boekhouding, wat het eenvoudig maakt verschillen op te sporen. Ook komt de Belastingdienst zelf met een berekening. Je aanslag komt dus niet zomaar uit de lucht vallen.
Als een bepaalde groep niet goed berekend wordt dan is de kans niet zo heel erg groot dat deze dat zullen melden.
Hoezo niet? Dit betekend dat jou boekhoud software telkens met verkeerde cijfers komt, en ik kan je garanderen dat er bij de belastingdienst vragen gesteld worden. Je moet immers zelf aangifte doen van BTW
Jij gaat uit van 'boekhoudsoftware' die dat goed zou moeten doen, maar zo werkt het maar deels. Kleine bedrijven meestal wel, hoewel bij hele kleine het vaak gewoon in een Excel gedaan wordt.

Maar bij grotere bedrijven met veel internationale transacties, daar wordt het alweer een stuk complexer.

Maar goed, ook hier negeer je weer vrolijk dat we gewoon recht hebben als burger om dat in te zien en dat recht wordt teniet gedaan als daar vragen over het nut worden gesteld.
Nee zo'n systeem is niet nodig.
Artikel 1, lid 1, van de woo zegt het vrij duidelijk:
Eenieder heeft recht op toegang tot publieke informatie zonder daartoe een belang te hoeven stellen [...]
Artikel 4.1, lid 3:
De verzoeker behoeft bij zijn verzoek geen belang te stellen.
Als je dan toch graag wil dat mensen een goede reden moeten hebben, dan moeten we dus de wet veranderen. Maar dan moeten we dus ook ELK verzoek gaan beoordelen. Dat gaat heel veel werk en dus belastinggeld kosten. En dan krijg je de situatie dat persoon a, na een dure beoordeling, geen goede reden blijkt te hebben, en dus de info niet krijgt. En vlak daarna persoon b, na wéér een dure beoordeling over dezelfde info, die wél een goede reden blijkt te hebben, waardoor de info alsnog openbaar wordt. Tsjah, daar betaal ik liever geen belasting voor...

Veel makkelijker om gewoon per definitie te zeggen dat alle info openbaar moet (kunnen) worden, zonder gedoe met beargumentaties en beoordelingen daarvan.

[Reactie gewijzigd door fruitbakje op 10 augustus 2025 12:07]

Ik vind niet dat je de reden moet gaan toetsen, maar je mag er best om vragen. Dat levert vaak ook een beter antwoord op.


Bij de SVB vroeg een tv-programma ooit in feite het hele archief op. Na een goed gesprek werd duidelijk wat ze nu echt wilden hebben en kon veel gerichter en sneller een antwoord worden gegeven. Maar dat werkt alleen als er van beide zijden enig vertrouwen is in de goede wil van de ander.
Ik vind niet dat je de reden moet gaan toetsen, maar je mag er best om vragen. Dat levert vaak ook een beter antwoord op.
Wat jij vindt is irrelevant. Wat we hebben afgesproken in een wet is wel belangrijk.
Je mag misschien vragen of iemand het wil specificeren om te voorkomen dat je teveel moet leveren, maar uiteindelijk moet je gewoon alles ophoesten wat de burger vraagt.
Als de aanvrager dan toch gewoon alles wil zien, dan moet je niet zeuren en gewoon zorgen dat het er is.

In Nederland wordt heel erg moeilijk gedaan over de WOO, in andere Europese landen is dat gewoon een standaard optie. De burger heeft dan vaak gewoon standaard toegang. Het zijn tot nu toe vooral de rechtse partijen die alle openheid tegenhouden. Het lijkt wel of ze iets te verbergen hebben.
Goede wil? Mijn broertje heeft ooit het UWV gevraagd hoe ze zijn WAO uitkering berekenden. Door omstandigheden was hij invalide geraakt en hadden zijn uitkering berekend a.d.v zijn laatste loon. Prima en klopte ook.

Toen het in zijn ogen wat beter ging wilde hij zijn soort werk weer hervatten en kon bij een bedrijf beginnen die 60% meer betaalde dan zijn oude loon. Echter na ruim een jaar ging het niet meer, bedrijf betaalde volgens de wet nog een jaar uit. Daarna vroeg hij weer de uitkering aan, kreeg hij direct, maar wel met de oude uitkering. Volgens de regels klopt dat niet; na een jaar werken moet het nieuwe loon gebruikt worden van afgelopen jaar en de UWV zei 'is geautomatiseerd'. Na zijn brieven over correctie verzoeken, inzage van waar de berekening nu vandaan kwam, elke keer afgewezen en later werd er niet eens meer op gereageerd. Via advocaat inzage gevraagd. Niets dus, de reden was volgens hen niet dringend. De wet schrijft veel, maar de instanties zelf werken het meest tegen. Denk dat er honderden zo zijn die gekort zijn op hun uitkering.

Ben toch ook benieuwd hoe ze het automatisch berekenen of dat er nog een persoon die het handmatig nivelleert en dan accordeert.
Maar dat is ook de totaal verkeerde manier.

Wanneer jij denkt dat het UWV een verkeerde beslissing heeft genomen en je kan dat met de regels in de hand aantonen, dan moet je niet vragen hoe zij aan hun antwoord komen. Dan moet je in bezwaar gaan en met jouw gegevens komen. Dan moet het UWV opieuw naar je gegevens kijke en een nieuwe beslissing nemen. Daarbij moeten ze op z'n minst beargumenteren waarom de oorspronkelijke beslissing volgens hen juist was en kunnen ze niet verwijzen naar de automatisering.
Ben je niet tevreden het het antwoord, dan kan je bij de rechter in beroep gaan. De rechter is niet geïnteresseerd in wat de automatisering zegt, enkel in hoe het volgens de regels moet. Kan het UWV dat niet uitleggen, dan doet hij het zelf.

De belangrijkste hobbel is alleen dat je wel in bezwaar moet gaan binnen zes weken nadat je de beslissing hebt gekregen.
Verkeerde manier? Je begint bij de normale communicatie protocollen. Daarna ga je verdere stappen ondernemen. Denk je dat dat niet gedaan is.
Helaas is mijn broer overleden en is de zaak gestopt.

[Reactie gewijzigd door Lord Anubis op 11 augustus 2025 12:37]

Inderdaad. Prima dat de overheid beter moet beargumenteren waarom ze de broncode niet willen openbaren, maar kunnen we dan ajb ook toe naar een systeem waarin de aanvrager ook duidelijk moet beargumenteren waarom ze de broncode wel moeten openbaren?
Nee.
De wet gaat uit van "openbaarheid, tenzij" en dat is niet voor niets.
Dat is een beetje omgekeerde wereld of niet? Dit is met openbaar geld gemaakt dus is van ons allemaal en de code zou dus sowieso standaard al voor iedereen toegankelijk moeten zijn.
Mogelijk om te valideren of de regels die de belastingdienst zegt te hanteren ook daadwerkelijk word ondersteund door de software?
Je geeft zelf je btw aangifte door, dus je kunt m ook gewoon zelf narekenen....
En als het dan dus niet klopt is het prettig dat je uit kunt zoeken waar het preciesis gaat. In plaats van dat iemand aan de telefoon zegt "computer says no"
Want iedere ondernemer gaat is de broncode van belastingen nalopen.

Je vult letterlijk je omzet in, hoeveel je al betaald hebt en dan rekent belastingdienst je resterende btw uit.... Die kun je zelf prima ba rekenen en dan ga je op hetzelfde getal uitkomen
Ook niet iedere gebruiker gat de broncode van open source software nalopen. Dat wil niet zeggen dat dat dus maar niet mogelijk hoeft te zijn.

Uiteindelijk is ook de software die geschreven is voor de belastingdienst publiek bezit dus moet het publiek dat gewoon in kunnen zien.
Tsja ook volkel is publiek bezit hebben we allemaal aan mee betaalt net als leeuwarden, Eindhoven, Oirschot enzo. Ook daarvan moet je niet alle ins en outs maar op straat gooien.


Er kunnen gewoon hard coded identificerende gegevens in die broncode staan zoals database logins etc die dus eerst eventjes weg gehaald moeten worden ipv het zo rechtstreeks te openbaren
Niemand heeft het over het publiceren van hard coded identificeerbare gegevens., daar kom jij nu mee. Net zoals alle ins en outs van militaire complexen.

Die gegevens kunnen inderdaad waar nodug verwijderd worden maar dat is ook niet wat er geweigerd is. De minister weigert gewoon alles te verstrekken en dat is vrij opmerkelijk want als ze niks te verbergen hebben en de software zit legitiem in elkaar wat is dan het probleem?

[Reactie gewijzigd door jbhc op 10 augustus 2025 22:12]

Dat het een precedent schept en mogelijk de deur opent naar veel meer mensen die vervolgens allerlei code op gaan vragen. Dan ben je als overheid druk met dingen verstrekken en uitpluizen om te voorkomen dat je per ongeluk informatie er in laat staan die wel gevoelig is. En als je iets vergeet is het weer een schandaal.

Daarnaast is "als je niks te verbergen hebt" geen goed argument. Ik heb niks te verbergen, maar gooi ook niet m'n persoonlijke informatie op straat. Wat nu prima is, kan onder een minder leuke overheid trouwens ineens strafbaar zijn. Joden hadden niks te verbergen voor de intrede van de Nazi's en ongewenst zwangere vrouwen hadden niks te verbergen voor abortus verboden werd in Republikeinse staten.

En hoewel de broncode waarschijnlijk niks interessants bevat, zal iemand vast wel creatief genoeg zijn om iets te vinden of er misbruik van te maken.

Als we dan toch zo gefocused zijn op transparantie, vraag dan wat voor dealtjes multinationals hebben. Kunnen we zien hoe weinig belasting ze betalen.
Toch is het bijzonder. Als er een wet is dienen burgers en bedrijven zich daar gewoon aan te houden, denk bijvoorbeeld aan de wet financieel toezicht die voor iedereen ontzettend veel kosten met zich meebrengt.

Als er vervolgens een wet is waarin de overheid dingen moet doen voor burgers en bedrijven dan is dat opeens een probleem want het kan kosten met zich meebrengen.
Vliegbasis Volkel is Amerikaans grondgebied. Geen publiek bezit dus.
Volkel is gewoon Nederlands, een klein stuk is Amerikaans grond gebied, dat is een gebied binnen volkel.


(Oud collega in dienst op volkel gezeten)
Met een fractie van de moeite die het kost om de broncode na te lopen kan je in de wet uitzoeken hoe het zou moeten. (Dat moet je sowiso al doen voordat je kan beplen of het in de systemen wel goed gaat.)

Dan is het simpl: "Law says yes!" Dan kan je eerst in bezwaar gaan bij de Belastingdienst zelf en wanneer die er anders over blijven denken kan je in beroep gaan bij de rechter. En wanneer de wet inderdaad een andere uitkomst geeft dan de sytemen van de Belastingdienst, dan zegt ook de rechter: "Law says yes. Fix it!"
Zo zou het inderdaad moeten zijn ja maar om een of andere reden is dat toch vaak niet zo.
Wat is vaak niet zo?

Dat de Belastingdienst A zegt en de wet B en dat de rechter toch de kant van de Belastingdienst kiest? Zelden tot nooit. (En dan kan je nog in hoger beroep gaan.)

Wat je wel vaak hebt is dat er een interpretatieverschil is in wat de wet eigenlijk zegt of eigenlijk bedoelt. Dat is het voor de belastingplichtge klip en klaar dat er A bedoelt wordt, terwijl de Belastingdient zegt dat er B bedoelt wordt. Dan kijkt de rechter er naar en die komt tot de conclusie dat uit de vergelijking met vergelijkbare wetgeving, jurispriudentie, een uitspraak van de Hoge Raad of wetsgeschiedenis toch echt blijkt dat er B bedoelt wordt.
Dan blijft de belastingplichtige nog steeds A lezen. Wanneer het wel een plausibele uitleg is om de wet te lezen, zal de rechter meestal wel de boete schrappen, die de belastingdienst soms wat erg gul uitdeelt.
Ah, net zoals met de toeslag affaire of de verzakte huizen in Groningen?

Probeer eens echt een gevecht met de overheid aan te gaan als je gelijk hebt en kijk hoe makkelijk je wint.
De btw aangifte zelf is echt een van de meest eenvoudige aangiftes, voor de meeste ondernemingen zijn het een veldje of 4,5 die je moet invullen. De echte complexiteit zit hoe je tot de cijfers in de aangifte komt. De omzetbelastingwetgeving is ontzettend complex. Het gaat er dan om of je wel of niet onder vrijstellingen valt, zaken als gemengde verhuur van OG, omzetbelastingen in groepen of samenwerkingsverbanden, internationaal etc etc. Maar dat wordt niet vastgelegd in de aangifte.
Probleem is dat de belastingdienst een omgekeerde bewijslast heeft. Dus als computer says no het antwoord is, moet jij maar aantonen dat het niet klopt. Nadat je wel eerst even afgetikt hebt.

En gezien een nogal groot recent schandaal is het natuurlijk niet vreemd dat mensen de belastingdienst niet op hun blauwe ogen vertrouwen dat het allemaal wel snor zit.
Een reden kan zijn dat iemand een bug ontdekt waardoor alle belastingbetalers een bedrag teveel of teweinig hebben betaald sinds die applicatie.

Daarnaast kunnen sommige mensen voor de lol gaan grasduinen, als hobby.

Andere kunnen staatsactoren zijn die herrie in eenand willen schoppen.

En weer anderen willen nalezen of de belastingen ècht eerlijk geheven worden.

Maakt het uit?


Overigens ben ik geen voorstander van het openbaren. Het valt wat mij betreft onder het staatsgeheim. Er zijn zòveel mogelijke misbruikers in de wereld dat obscurity gewoon een nuttige veiligheidsmaatregel is. Hackers kringen hiermee teveel insider gegevens.
Ieder beetje administratief programma voert alle berekeningen ook zelf uit. Een systematische fout waardoor iedereen te veel of te weinig zou hebben betaald was daardoor al lang ontdekt. De meeste incidentele fouten zouden op deze manier ook al wel gevonden zijn.

Maar geen enkele software is foutloos. En niet iedereen die een fout in de software vindt zal deze rapporteren.
Stel dat er ergens in de spaghetti van programmaregels (de meeste programma's bij de Belastigdienst bevatten aanpassing op aanpassing op aanpassing op... en zijn na vele jaren niet allemaal meer even duidelijk en gestructureerd) een fout zit waardoor na de invoer van € 99999,99 alle later ingevoerde bedragen in dezelfde aangifte genegeerd worden. Als incidentele fout zal het vrijwel geen impact hebben.
Als ontdekte en stilgehouden fout is he voor diegenen die er van afweten een vrijbrief voor fraude. Natuurlijk kan een andere onderzoeker over dezelfde fout struikelen en deze wél melden, maar dat is lang niet zeker. Dan moet je je afvragen wie er het meeste werk, tijd en geld in steekt om dergelijke fouten te ontdekken. Degenen die de fouten willen corrigeren staan daarbij altijd op een achterstand vergeleken met degenen die de fouten willen uitbuiten.
Er is eerder gebleken dat de Belastingdienst systemen heeft die etnisch profileren. En dat ze zich niet altijd aan de AVG houden.

Broncode van IT systemen kan helpen om te zien of er nog meer plekken zijn waar ze zich niet aan de wet houden. Ook is IT voor de Belastingdienst een belemmerende factor (bijvoorbeeld bij het aanpassen van de heffing in box 3), dus dan kan wat transparantie geen kwaad.
Het voordeel is dat de overheid gepushed kan worden naar een betere en wellicht open standaard.

We recent weer een lek gezien van het OM (waar heel weinig over wordt geschreven, want IT en minder belangrijk schijnbaar), en wellicht wordt dan eens duidelijk welke kennis er niet (meer) is bij deze overheidsinstanties.
Die lek stond gewoon in alle Nederlandse kranten. Ook NOS, BNR etc deden er verslag van. Algemeen Dagblad deed vervolgartikelen, etc. Dus daar lag het niet aan.

De overheid zit al (vele) jaren met een groot probleem qua software van de Belastingdienst, namelijk dat het allemaal losse programma’s zijn, met hele oude broncode, op ouderwetse basis, die daardoor niet makkelijk aan te passen is.

De wet aanpassen gaat daardoor vaak niet, omdat er dan een nieuwe parameter moet worden ingebouwd in die bestaande, oude software, wat inclusief testen zoveel tijd kost dat het jaren zou duren. Eigenlijk moet het gewoon een keer helemaal opnieuw gedaan worden, maar dan op zo’n manier dat er wél makkelijk wijzigingen doorgevoerd kunnen worden.

Dat is ook al eerder geprobeerd maar mislukt, zie ook tweakers artikelen hierover. Dat is ook alweer jaren geleden.
Dan lees ik waarschijnlijk de verkeerde kranten, want ik zie maar èèn ding dat alles domineert.

Het OM lek is gewoon echt ontzettend gevaarlijk voor onze veiligheid en het vertrouwen in het systeem (dat al heel laag was).

Ga je echt nog getuigen, als zij zo met je data omgaan? Ik weet het niet.
Het OM hack is gerapporteerd in het AD, de NOS, de RTL, nu.nl, het Parool, RTV Drenthe, De Telegraaf, De Volkskrant, RTV Oost, het NRC, het Noordhollands Dagblad, De Limburger, Het Nederlands Dagblad, het Financieele Dagblad, Hart van Nederland en meer (dit is de eerste paar pagina's op Google die ik hier beschrijf). Het zal niet bij iedere krant elke dag op de voorpagina gestaan hebben, maar het was wijdverspreid gerapporteerd. Maar goed, tussen de Russische invasie, de genocide in Gaza, de mafketelerij van Trump, en het politieke gestuntel in eigen land kan ik begrijpen dat je dit gemist of niet onthouden kan hebben; er is genoeg nieuws dat het oog meer trekt.

Het OM is onder andere gehackt omdat hun leverancier incomplete informatie gaf over het mitigeren en patchen van het probleem. Tokens konden worden geheractiveerd na het herinitialiseren van de daemons zoals Cisco eerst in hun advies zetten. Hoewel het OM maar kort kwetsbaar was, zijn de gestolen sessietokens later nog misbruikt zonder dat men dat doorhad. Verder werd andere CVE werd als DoS aangemerkt door de leverancier terwijl het een RCE was, wat ook pas achteraf naar voren is gekomen. Het OM heeft netjes en snel de boel gepatcht en gemitigeerd zoals omschreven, maar zij hebben de broncode en expertise niet om software van derden zelf te decompileren om te bepalen of de leverancier wel of niet liegt in hun patch notes en beveiligingsadvies.

Er gaat genoeg mis qua digitalisering bij de overheid (en overigens net zo hard bij het bedrijfsleven, ook al komt een mislukt IT-project van een bedrijf niet in de krant), maar bij de recente hack zaten ze bovenop het probleem. Zoiets voorkom je alleen door de hele IT-infra om te bouwen en edge-VPN's van een andere partij in te kopen/zelf te ontwikkelen, maar daar gaan jaren en miljoenen overheen.

Bij het OM zou ik eerder bang zijn om gewoon als getuige te verschijnen. Ze lekken nogal wat gegevens (adressen, foto's) van kroongetuigen door menselijke slordigheden en fouten bij zaken tegen criminelen die een moord meer of minder niet schuwen. Mensen in gevaar brengen kunnen ze prima zonder hulp van de Russen.
Er zijn (op het vermoeide af) dominante onderwerpen maar gelukkig komen er nog steeds ook veel andere zaken aan bod.

Iedereen denkt gelijk aan moord en doodslag maar dat is maar een fractie van wat het OM doet zoals verkeersboetes, economische delicten, zoals rond Deliveroo, of werknemers zelfstandig waren of werknemer etc. Arbeidsconflicten, belastingfraude, illegaal verblijf etc. etc.
In principe is de broncode de implementatie van de wet, en zou daarom publiek moeten zijn.

Door dit open source te maken, kunnen ook andere mensen de implementatie controleren.
Die implementatie is ook heel eenvoudig te controleren door naar de uitkomst te kijken.
Wanneer i in een rekenmachine '1+1' invoer en als uitkomst '3' krijg, weet ik dat de rekenmachine de wiskunde niet goed implementeert zonder ook maar één blik op de broncode te werpen.

Nu is het bij Belastingen niet zo heel eenvoudig om direct een fout te ontdekken. Maar de meeste bedrijven hebben eigen boekhoudprogramma's die zelf vanuit dezelfde wettelijke regels, maar op basis van een broncode die voor elke softwareleverancier anders is, berekent wat de uitkomst zou moeten zijn. Wanneer de boncode van de Belastingdienst fouten bevat waardoor de software met de vrkeerde uitkomst komt, wordt dat snel genoeg bekend.
Ik redeneer vanuit een breder perspectief. Dit zou ook voor de handhavingsapplicaties en boete applicaties van de politie moeten gelden, uitvoeringsinstanties en andere publieke instellingen die volgens wetgeving dingen automatiseren. Het dwingt mensen beter te (gaan) programmeren en het maakt het mogelijk om software te controleren. Het wordt namelijk ook publieke betaald en is dus ook publiek bezit.

Ik snap ook dat er jaren history inzit, en dat niemand op Cobol-applicaties zit te wachten met een basis in de late jaren 70, maar dan nog....

Volgende stap is het mogen inchecken van aangepast code... We accepteren het ook voor Linux, wat helemaal de basis is voor heel veel spullen die de overheid nu al draait. En dit betekent echt een mindsetverandering, maar we stellen het alleen maar uit....
Recht op openbaarmaking hoeft niet gemotiveerd te worden.

Je kan de gekste informatie opvragen, zonder dat je belang of meerwaarde hoeft aan te tonen.
Wat houdt het in om de broncode te publiceren? Krijgt het publiek dan ook inzicht in bepaalde grenswaarden? Ik werk regelmatig met ondernemers rondom wat accountancy kwesties en ik kan je garanderen dat er een groep gaat zijn die precies op de grenswaarden gaat ‘inkopen’ als dit bekend wordt.

Misschien heel raar, maar in dit soort gevallen lijkt mij een onafhankelijke partij die de bron code controleert en de belangrijkste conclusies deelt met het publiek (soort van audit) beter dan een hele code publiceren.

Zeker als er dingen hardcoded zijn in de code, dan is het een paar maanden afwachten of we hebben weer een box-3 geval of misschien wel een toeslagen light. Kritische mensen gaan altijd wat vinden. En natuurlijk moet een systeem eerlijk zijn, maar ik ben zelf wel klaar met alle problemen uit het verleden waar we in NL het alleen nog maar over hebben. Toeslagen affaire, box-3, UWV, etc….
Wat is het probleem met inkopen op een grenswaarde? Volgens mij zijn alle berekeningen die de belastingdienst uitvoert over te verwachten inkomsten ook berekend op die grenswaarden, niet op de kans dat zoveel procent precies op die grenswaarde gaat inkopen. En dan nog: het is een grens, als je niet wilt dat die grens benaderd wordt moet je de grenswaarde verlagen.
Ik snap niet helemaal wat je bedoelt. Ik kijk meer vanuit de ondernemer, hoe bedoel jij het?
Wat ik bedoel is dat het toch helemaal geen probleem is als die grenswaarden bekend worden. Het zijn grenzen, blijkbaar mag je tot die grenzen gaan, dus waarom zou het een probleem zijn als die grenswaarden bejkend worden? Ik sta er eerder van te kijken dat ze blijkbaar niet bekend zijn.
Vaak zijn die grenzen niet zo vastgelegd en is het meer vanuit risicobeleid dat je bij bepaalde waarden (grenzen) vragen moet gaan stellen. Ik zeg maar wat, wat is de grens dat je vragen gaat stellen over de omzet bij een ondernemer. Als de ondernemer in zijn IB / VPB 5% afwijkt, of 10% of is het een absolute grens. Of zijn er uitzonderingen voor specifieke sectoren etc.

Oftewel: stel ik weet een grens als ondernemer, dan kan ik de ‘marge’ gebruiken om minder IB / BTW te betalen. Of als ik weet dat een x% op representatie een trigger is dan voer ik lekker al mijn etentjes op ook al waren ze niet zakelijk.
Het gaat hier om de grenzen waarbij bv. gecontroleerd gaat worden of een aangifte wel of niet correct is.

Er is misschien ooit vestgesteld dat er pas om bonnetjes gevraagd wordt wanneer je meer dan € 1.000 aan giften af wilt trekken. Wanneer dat bekend wordt, zullen veel mensen daar misbruik van maken door op te geven dat ze € 999 aan giften hebben geschonken, omdat ze weten dat er nooit naar d (niet bestaande) bonnetjes gevraagd zal worden.
Die grens van € 1.000 betekent hierbij niet dat je tot die grens 'legaal' mag frauderen, maar dat er te weinig mensen bij de Belastingdienst werken om alle giften onder € 1.000 te controleren. En zo zijn er heel veel grensbedragen waaronder net wordt gecontroleerd.

Een volledig legale grens, die ook in de wet genoemd wordt, is bijvoorbeeld de grens voor het privégebruik van een terbeschikkinggestelde bedrijfsauto. In principe krijg je een bijtelling van een bepaald percentage van de nieuwwaarde van die auto wanneer je deze ook privé gebruikt. Maar de wet geeft je een grens van 500 km per jaar. Wanneer je daar onder blijft (en dat ook aan kan tonen) geldt er alsnog geen bijtelling. Maar die grens is wel keihard: bij 501 km ben je alsnog de sjaak.
Wat is het probleem met inkopen op een grenswaarde? Volgens mij zijn alle berekeningen die de belastingdienst uitvoert over te verwachten inkomsten ook berekend op die grenswaarden, niet op de kans dat zoveel procent precies op die grenswaarde gaat inkopen. En dan nog: het is een grens, als je niet wilt dat die grens benaderd wordt moet je de grenswaarde verlagen.
Niets, het is menseigen om de grenzen op te zoeken. Waar kom je nog mee weg. Echter heb ik sterk het idee dat de mensen die de grens opzoeken ook het hardste schreeuwen als ze er overheen gaan en betrapt worden.

Denk aan de mensen die 84 gaan rijden in een 80 omdat er toch correctie is. Maar dan klagen dat ze met 85 geflitst worden want ze reden niet te hard (alsof je snelheidsmeter beter geeikt is dan de camera's van de overheid)
En natuurlijk moet een systeem eerlijk zijn, maar ik ben zelf wel klaar met alle problemen uit het verleden waar we in NL het alleen nog maar over hebben. Toeslagen affaire, box-3, UWV, etc….
... ware het niet dat deze problemen niet afgehandeld zijn. Deze problemen zijn er nog steeds, dus het lijkt mij een terechte vraag van "waarom?". Waarom kan een belastingdienst niet dynamischer omgaan met een belastingtarief? Waarom duurt het zo lang om het systeem te veranderen? Is het kennis/kunde? Een leverancier die de overheid in de greep houdt? incompetente managers? onwil? te weinig mensen?

Toeslagenaffaire => Waarom zijn nog niet alle gedupeerden geholpen?
UWV => Waarom gaat het ons 1 miljard kosten om te "moderniseren"? En welke garanties hebben we op verbetering?
etc..

Als men nu die broncode openbaart, dan kun je als stuurlui aan de wal tenminste gerichter roepen op wat de overheid moet doen.
Ik snap je vragen en ik ben het met je eens dat ik erg graag zou willen weten waar het ‘probleem’ ligt. Wel denk ik dat de BD ook te maken heeft met wetgeving wat tegenwerkt. Dus wetgeving is te vaag en te complex om dat makkelijk in je systemen te krijgen.

En ik zou inderdaad graag zeggen wat de BD moet doen. Maar uiteindelijk de aanpassingen qua systemen, etc. Ik denk wel dat je op detail niveau daarin moet zitten om iets goeds te kunnen roepen. Dus van een afstand roepen zonder enige kennis / context / beslissingsonderbouwing ik denk niet dat dat heel veel gaat helpen.

Om toch e.e.a. Bij te zetten wat jij zegt: veel is denk ik de top bij de BD. Volgens mij zijn er weinig top mensen gesneuveld en als ik het nieuws, maar vooral als ik semi interne mensen hoor: klassiek voorbeeld van incapable mensen die in de top zijn gekomen door goed politiek te bedrijven.
Het duurt zo lang om de systemen te veranderen omdat de meeste van deze systemen in een ver verleden zijn gebouwd en er door vrijwel constante bezuinigingen en reorganisaties nauwelijks geld was om deze systemen goed te onderhouden. Elk jaar moeten er ook nog eens nieuwe wetgeving 'ingeprakt' worden, wat door het budget enkel op een houtje-touwtje manier kan, waardoor systemen dingen moeten doen waar ze oorspronkelijk nooit voor bedoeld zijn.

Dat is ook meteen het antwoord op je vraag over de modernisering van het UWV. Tientallen of honderden systemen die met elkaar samen meten werken en die door moeten blijven draaien terwijl je de systemen stuk voor stuk wilt moderniseren.

Het antwoordt op je vraag over de toeslagaffaire duidt meer op een maatschappelijk dan institutioneel probleem.
Nadat de problemen bij Toeslagen bekend werden, was er een schatting van Toeslagen zelf dat er bij ongeveer 5.000 gezinnen iets goed mis was gegaan. Je zal in eerste instantie misschien denken dat Toeslagen de laatste is die je hiervoor kunt vertrouwen, omdat ze het probleem zouden willen baggetaliseren. Maar het is juist Toeslagen geweest die jarenlang bij de leiding van de Belastingdienst en de politiek heeft aangegeven dat het star volgen van wetten en beleidsregels onaanvaardbare problemen oplevert. Toelagen was daardoor eerder geneigd om de problemen te overdrijven. Zeker in de beginfase van het bekend worden van de Toeslagenaffaire, toen ze nog niet alle drek van de publieke opinie over zich heen hadden gekregen.
Door alle commotie en het door de politiek aangekondigde ruimhartige compensatiebeleid heeft vrijwel iedereen die ooit iets terug heeft moeten betalen aangegeven ook slachtoffer te zijn. Daardoor zijn er in eerste instantie zo'n 70.000, later opgelopen tot ongeveer 125.000, dossiers die allemaal handmatig doorgekeken moeten worden om te bepalen of er iets fout gegaan is. Met het overgrote deel van de dossiers is niets aan de hand (al hebben vele daarvan al wel € 30.000 compensatie gekregen), maar ze houden wel de hele procedure verstopt voor diegenen waar het wél fout gegaan is en die wél geholpen moeten worden.
Wat houdt het in om de broncode te publiceren? Krijgt het publiek dan ook inzicht in bepaalde grenswaarden? Ik werk regelmatig met ondernemers rondom wat accountancy kwesties en ik kan je garanderen dat er een groep gaat zijn die precies op de grenswaarden gaat ‘inkopen’ als dit bekend wordt.
De broncode is een deel van een code dat laat zien hoe een systeem functioneert. Waardes die gebruikt worden, bijvoorbeeld bedragen en percentages zullen uiteraard niet in de code zitten, maar in een database.


Wat welke grenswaarde is zal je dus niet terugvinden. Wat je wel terug zou kunnen vinden is hoe je om grenswaardes heen werkt door fouten in de code. Maar de kans dat je die vind is vrij klein, en anders vrij snel gepatcht.
Snap ik, zeker in moderne systemen is dat zo. Maar ik lees ook dingen over ‘hard coded’, hoe weet je of daarin geen grenswaardes worden benoemd? En daarmee dat je dus de grenswaarden kunt opzoeken en misbruiken.

Overigens, referenties naar databases zoals ‘outliers OB MKBgroot’ zijn natuurlijk ook al indirecte signalen die je uit zo’n code kan halen.

Dus het kan zijn dat er niks te vinden is, maar ik acht de kans toch groter dat je veel minder ongewenste informatie publiceert dan je denkt/ wilt.
Wat je wel terug zou kunnen vinden is hoe je om grenswaardes heen werkt door fouten in de code.
En dat is belasting fraude, en argumenteren dat de software iets anders gezegd had word door de belastingrechter van tafel geveegd.
Maar aangezien de software niet aanslaat op het verschil komt het niet voor de rechter.

Iets als: "ik kan de omzet op papier 12% verlagen en dan komt er geen controle van de papieren". En zo frauderen.
Maar wanneer die fout ergens in een berg spaghetti-code zit en niet meteen opgemerkt wordt, maar wel later opgemerkt wordt door iemand die het gebruikt om te frauderen, heb je een probleem. Het systeem denkt immer dat het goed is en zal geen alarm geven.
En wie zal meer motivatie hebben om tijd en geld te investeren om dat soort fouten in de code te ontdekken?
Die groep zoekt zonder meer uit waar de grenswaarden liggen.
Zo gek is dat niet.
Is ook bekend waarom de klager het wil hebben/wat voorgevallen is en wat er te “winnen” valt met de broncode? Staat los van de vraag óf de belastingdienst het zou moeten openbaren.
Testen c.q. zien of de wet ook wel wordt uitgevoerd door de software, discriminatie en willekeur tegengaan. Maar inderdaad, misschien is er ook wel wrok richting de overheid wegens contact met de belastingdienst in het verleden.

Sowieso ben ik het wel eens dat er gecontroleerd moet worden door een ander orgaan dan de overheid of de software doet wat de wet zegt dat er gedaan moet worden.
Sowieso ben ik het wel eens dat er gecontroleerd moet worden door een ander orgaan dan de overheid of de software doet wat de wet zegt dat er gedaan moet worden.
bij ons in Belgie kan je op voorhand met allerlei software berekenen hoeveel je moet bijbetalen of terugkrijgen na je aangifte. Het document dat je terugkrijgt van de overheid met de berekening is ook gedetailleerd en geeft duidelijk aan hoe het bedrag berekend is. Is dit in Nederland dan anders met een black box berekening?

De vrijgave zou vermoedelijk bijzonder veel tijd en geld kosten zonder aanwijsbare meerwaarde. Lijkt mij meer een gevalletje “omdat het kan”.
Dat is in Nederland in principe niet anders.
Mijn boekhouder berekent vooraf hoeveel er afgedragen moet worden, en de Belastingdienst is het daar altijd mee eens. (De details wil ik niet weten, daar heb je een boekhouder voor)
Ik heb decennia geleden wel eens een klus voor de belastingdienst gedaan voor het systeem Sagitta, de zakelijke invoerbelasting. Daar zag je dat ook: de partij die inklaart heeft dat sommetje allang gemaakt voordat de spullen de grens overkomen. Erger nog: het was toen (eind jaren 90) daar vrij gewoon dat bedrijven gericht opvroegen wat de onderbouwing was als de belastingdienst afweek van het door hen berekende bedrag, wat opsporing van fouten aan beide kanten vereenvoudigde. Als beide kanten de regels kennen, kun je dat makkelijk doen.
Het is natuurlijk z’n beetje basisschool optellen en aftrekken.

Uiteindelijk gaat het alleen om de uitkomsten van totale inkoop en verkoop en de BTW die daar in rekening is gebracht.

Verleg je de btw dan hou je dat natuurlijk ook gewoon bij.
En dat soort vergeljkingen kan je dus prma doen zonder de broncode te kennen.

En ik denk dat vrijwel alle fouten voortkwamen uit een verkeerd ingevoerde productcode of bedrag.
Het lijkt mij ook te gaan om de code van de extra systemen. Zoals de code van het systeem die mogelijke fraudeurs detecteert.
De code die op fraudeurs controleert zal wel werken met parameters. Daarom ook de vraag om de configuratie.

Het lijkt me niet dat de Belastingdienst de fraude-parameters meegeeft in een woo, dat speelt misbruik in de hand want dan is ineens het "speelveld" bekend.

Ook de ci/cd configuratie is veelal ondersteunend in de Quality Assurance, wat me ook niet relevant lijkt (tenminste, op mijn afdeling).


Een woo om de code van de Belastingdienst te bekijken, snap ik volledig. Wees lekker nieuwsgierig naar hoe dat allemaal werkt, want het resulteert in een rekening op jouw deurmat. Maar om het hele landschap op te vragen, is misschien wat enthousiast en als het alleen om de fraudedetectie gaat, ietwat verdacht.

Dit is allemaal maar mijn mening, en ik werk niet voor de Omzetbelasting, dus kan en mag niet inhoudelijk reageren.

[Reactie gewijzigd door SirQuack op 10 augustus 2025 13:43]

Vraag me ook af wie de tijd ervoor heeft om het allemaal te doorzoeken, als je de gehele belastingdienst openbaar maakt heb je iets van 5 verschillende talen met miljoenen als niet miljarden lines code. Ik vraag me ook af of de documentatie er ook gelijk bij wordt gegooid want dan ben je nog verder into the rabbit hole.
Als je uit de boekhouding/industrie de juiste sleutelwoorden kent, zou het niet zo'n drama moeten zijn om de code waar je naar op zoek bent te vinden. Denoods gooi je er een of ander AI-model overheen, kost wat centen maar dan weet je wel waar je moet beginnen met zoeken. Je hoeft niet per se meteen te vinden wat je zoekt, als je maar een aangrijppunt hebt.

Als je op zoek bent naar bijvoorbeeld illegaal etnisch profileren, discriminatie op basis van geslacht, of andere ongure dingen, zou je dat moeten kunnen vinden met een redelijk snelle zoekopdracht. Ik denk niet dat iemand denkt "laat ik voor de lol eens de hele belastingdienst optuigen" (al zou het wellicht grappig zijn voor de hobbyist om de software uit de jaren '70 in een virtuele supercomputer te draaien).

Natuurlijk zou je specifiek kunnen vragen om de code of documentatie waarin het illegale gedrag gebeurt en proberen de belastingdienst het zoekwerk voor je te laten doen, maar de belastingdienst gaat natuurlijk niet zomaar toegeven dat ze illegaal bezig zijn, dus dan moet je maar alles vragen.
Tja, ik hoop dat we zaken zoals de Toeslagenaffaire juist willen voorkomen en er geen doofpot van maken, ik kan dus juist heel goed begrijpen dat er velen zijn (ook niet-slachtoffers) die mede hierdoor erg wantrouwend zijn.
Het is niet dat een bedrijf als de overheid weg komt zonder audits van een gespecialiseerd bedrijf. Al is het lastig natuurlijk om beslisregels te controleren met een audit. Echter als je de uitkomsten wil controleren, kan je dat toch ook gewoon zelf narekenen, daar heb je toch geen code voor nodig?
Misschien om het systeem te controleren op kwetsbaarheden en het zo te kunnen hacken.

Misschien is de klager wel een Russische handlanger. In Oekraïne startte met de fysieke aanval ook direct de digitale aanval.
Het zou kunnen, maar ik neem aan dat onze AIVD de aanvrager al lang een keertje heeft nagetrokken als daar enig vermoeden voor bestaat.

Ik denk dat de kans groter is dat iemand vermoedt dat de belastingdienst verkeerde bedragen heeft gerekend en veel geld terug zou moeten krijgen, maar dat nog niet goed kan onderbouwen. Of misschien zoekt iemand de thresholds op waardoor iemand verdacht wordt en aan een audit wordt onderworpen zodat er met geld gesjoemeld kan worden.

Als hier criminele gedachten achter zitten, zou ik uit gaan van witteboordencriminaliteit, niet een aanval van Rusland. De Russen hacken ons toch al (en wij zijn ook niet gek en hacken ze net zo hard terug).
Mijn broertje is wel het type om zoiets te doen. Niet omdat hij iets om de broncode geeft, maar gewoon uit principe. De overheid is een publieke zaak, dus het hoort openbaar te zijn, en dan gaat hij lastig doen omdat het dat niet is. Want we moeten als burgers kunnen weten wat de overheid allemaal doet. En zodra de broncode publiek wordt, kijkt hij er niet meer naar om.

Zeker na de toeslagenaffaire is dit wel een begrijpelijk standpunt. We willen niet allerlei vage algoritmes die mensen oneerlijk benadelen.

[Reactie gewijzigd door Amanoo op 10 augustus 2025 14:20]

Misschien wil de klager zichzelf positief in het zonnetje wilt zetten.

Zeg dat je de broncode na wilt kijken op mogelijke etnische profilering en discriminatie. Dan kan je bij weigering zeggen dat de overheid die etnische profilering en discriminatie geheim wilt houden.

Misschien heeft de Belastingdienst bij een controle ontdekt dat de klager te weinig BTW aangegeven heeft en zegt de klager dat hij alleen maar geconroleerd is omdat hij van buitenlandse afkomst is (pure speculatie van mijn kant) en wil hij de broncode van de systemen inzien om dat te kunnen bewijzen. Ondertussen blijven alle procedures op pauze staan totdat hij de broncode defintitef wél of niet krijgt. En wanneer hij de broncode niet krijgt wat waarschijnlijk is) kan hij dat feit in de publieke opinie gebuiken als 'bewijs' dat het allemal niet zuiver is. En misschien krijgt hij daar ook wel een recher in mee, zodat hij uiteindelijk de te weinig aangegeven BTW niet hoeft te betalen.

Er komen de laatste tijd zoveel belastingzaken voor de rechter waarbij de argumenten niet meer gaan over de te betalen belasting zelf, maar of er wel gecontroleerd had mogen worden en of er tijdens de controle geen fouten zijn gemaakt.
Jammer dat de code sowieso niet openbaar mag zijn, je zou verwachten dat een overheid openheid van zaken naar de burger kan geven zodat (ook) de burger de overheid kan controleren indien gewenst.
Het lijkt mij vanuit een pragmatisch staatsrechtkundig perspectief ook gewoon - dat de wil van het volk, gedragen moet worden door het hele volk - en dat daarmee 'de gedachtegang' (programmering) van de overheid volledig open en toegankelijk moet zijn. Als de eigen inwoners vervolgens al rottigheid kunnen met die informatie, is het nog niet veilig genoeg. Simpel toch ?
Er zitten wel haken en ogen aan. Ja, de burger heeft baat bij transparantie: om discriminatie tegen te gaan en om de mogelijkheid te bieden de betrouwbaarheid en berekeningen van de Belastingdienst te controleren. Maar als drempelwaardes en algoritmes worden geopenbaard, weten criminelen en belastingontduikers precies hoe ver ze kunnen gaan.
Volgens mij werken criminelen al sinds jaar en dag met de pakkans in het systeem inderdaad. Maar dat is hun niet zelden erg nadelig uitpakkende 'gok' dan ook. De factoren moeten systeembreed dan ook uitbalanceren. De meesten moeten een goede incentive hebben om 'het winkelwagentje terug te brengen'. Degenen bij wie die basis ontbreekt kun je meteen gerichter faciliteren in meer overtuigende factoren om alsnog te gaan gehoorzamen. Hetzij door straf, hetzij door belonen en tot slot ook nog door begrip. Enfin, TLDR;
Hebben we daar niet een gespecialiseerde tak voor, genaamd de rekenkamer? Die controleert hoe dingen uitgevoerd worden, net zoals de Auditddienst Rijk. Als burgers bepalen we de spelregels, de overheid moet zich daaraan houden en haar toezichthouders controleren hierop. Dat is geen burgertaak.

Als elke idioot zomaar de broncode van de gehele belastingdienst en/of UWV kan opvragen en daar lukraak vragen over kan stellen dan kom je al snel ambtenaren tekort. Laat dat door vakinhoudelijk deskundigen beoordelen die dit dagelijks doen, niet door iemand waarvoor het installeren van een printer al een opgave is.
Nou van mij mogen ze het lekker allemaal closed houden. Ik denk dat er meer hackers dan weldoeners op de code duiken. Jaja, "security through obscurity" maar liever dat, dan het openzetten van de deur voor iedereen met slechte bedoelingen.
"Public money, public code".

De Belastingdienst kan ook slechte bedoelingen in de broncode hebben. Verder kan publiceren juist helpen met verbeteren (vinden kwetsbaarheden, moderniseren).

[Reactie gewijzigd door The Zep Man op 10 augustus 2025 12:12]

Er is iets te zeggen voor regelgeving rondom het publiek maken van repos van overheids oplossingen, bijv voor nieuwe componenten of tools. Zeker bij ontwikkeling van een systeem zo ingrijpend als dat van de Belastingdienst, zou ik als burger wel graag willen kunnen nazien of het allemaal correct en voldoende veilig is geïmplementeerd. Mijn handmatige berekening van de belastingaangifte komt nooit overeen met van die de Belastingdienst. Ligt ws aan mij, maar ik adv de broncode kunnen uitzoeken waar de berekening spaak loopt.

Aan de andere kant wil ik er (vooralsnog) ook gewoon vanuit kunnen gaan dat de Belastingdienst zijn verantwoordelijkheid hier begrijpt en zorgdraagt voor correcte implementatie en de kwaliteit van de processen en software.

Daarnaast is de vraag hier de broncode inzichtelijk maken van ws een van de meer complexe brownfield omgevingen die er landelijk te vinden zijn. Onderhevig aan nieuwe coderings technieken en best practices gedurende de jarenlange ontwikkeling en uitbreidingen (door verschillende contractors?). Grote kans dat daar 'gevoelige' informatie hardcoded in verwerkt is, zoals de staatssecretaris zich al heeft laten influisteren.

De code handmatig screenen voor het openbaar maken gaat ongetwijfeld miljoenen kosten. Met kans dat er zaken over het hoofd worden gezien. En ws ten koste van implementatie van nieuwe features en/of verbeteringen. Je moet je afvragen of dát het allemaal waard is.
Het zou mij niets verbazen, dat o.a. het aangehaalde argument ( dat server namen hardcoded zijn ), meer een smoes is om het slechte programmeer werk te verbloemen.

Al jaren is die software een reden tot discussie en al jaren wordt er gesproken over het vernieuwen van die software. Maar er gebeurt nog steeds niets, terwijl er steeds meer regels/wetgeving aangebouwd wordt. Waardoor er.e.a. misschien wel m.b.v. houtje-touwtje aan elkaar hangt en ( wel/niet ) met elkaar communiceert.

Tevens zou het mij niets verbazen dat in die software enkele zaken/percentage hardcoded zijn ( i.p.v. via berekeningen ) om zo te ingewikkelde berekeningen te ontwijken.

M.i. zal geen enkel bedrijf nieuwe software willen schrijven, aangezien de huidige regels dusdanig ingewikkeld zijn en met elkaar conflicteren, waardoor er geen 'dekkend' programma van/voor te maken is.

Dat het Nederlandse belasting systeem op de schop moet en veel simpeler moet, is duidelijk. Maar wie durft dat aan ?

Want dan zal men ( de politiek ) moeten beslissen dat de inning ook eerlijker moet zijn/worden en de sterkste schouders het meeste betalen.

Helaas hebben de sterkste schouders ook de meeste invloed en zie daar : de reden waarom er niets veranderd.

[Reactie gewijzigd door PsiTweaker op 10 augustus 2025 12:17]

Al jaren is die software een reden tot discussie en al jaren wordt er gesproken over het vernieuwen van die software. Maar er gebeurt nog steeds niets, terwijl er steeds meer regels/wetgeving aangebouwd wordt.
Dit is dus ook precies het probleem. De belastingdienst heeft al jaren terug aangegeven, politiek, stop met constant nieuwe regels en uitzonderingen bedenken. Dan hebben wij tijd om fatsoenlijke software te bouwen, die vervolgens ook veel flexibeler kan omgaan met nieuwe wetgeving.

Maarja, die 150 mensen in den haag luisteren niet naar de praktijk en gaan gewoon door met uitzondering op uitzondering stapelen.
Dat er niets gebeurd, klopt niet. Uit een brief van de Staatssecretaris van vorig jaar:
Sinds 2018 is meer dan de helft (52 procent) van die achterstand weggewerkt, waardoor de zogenaamde technische schuld is gedaald tot 19 procent van het aantal ICT-systemen.
Dus ze hebben de afgelopen jaren fors geinvesteerd in het uitfaseren en vernieuwen van systemen. Er moet echter nog steeds een hoop gebeuren.
Ze zijn nog steeds bezig, en dat gaat ook nog wel even door:
Voor de systemen voor de inkomensheffing, vennootschapsbelasting en
loonheffingen wordt nu nog de verouderde software Cool:Gen gebruikt. Het doel
is om de uitfasering van Cool:Gen voor het einde van 2026 te realiseren en
daarmee de continuïteit van de ICT-systemen en de belastinginkomsten voor de
toekomst te garanderen.
Eerder heeft de politiek ook al vriendelijk de boodschap of vraag ontvangen om geen nieuwe belastingwetgeving te introduceren. dat krijgen ze simpelweg niet voor elkaar.
Nu ben ik geïntrigeerd. Hoe komen ze op die kwantificatie van technical debt? Is daar enige informatie over beschikbaar?
Pure speculatie van mijn kant, maar het kan ook dat de overheid bepaalde fiscale gunstregimes heeft die eigenlijk illegale staatssteun zijn. Dat kunnen ze natuurlijk niet luidop zeggen. Dan komen er smoezen zoals servernamen of tabelnamen die in de code staan. Dit laatste lijkt mij trouwens niet abnormaal.


Om te kunnen reageren moet je ingelogd zijn