Zeven fouten die in vrijwel elk zelfgebouwd rekenmodel zitten

De zeven rekenfouten die telkens terugkeren in zelfgebouwde vastgoedmodellen, elk met de juiste formule ernaast en de schade die ze samen aanrichten.

1. Kort antwoord

Precies zeven rekenfouten duiken keer op keer op in zelfgebouwde vastgoedrekenmodellen. Rente op de verkeerde hoofdsom is er één van. Het verkeerde overdrachtsbelastingtarief is een tweede. Daarnaast: leegstand die niet in de huurstroom zit, geen piekmoment in de eigen inleg, ontbrekende rente tijdens de bouw, ROE op de verkeerde noemer, en een duizendtalnotatie die een spreadsheet verkeerd inleest.

Geen van deze fouten geeft ooit een foutmelding. Ze leveren gewoon een getal op: niet het juiste getal.

2. Waarom deze fouten zo vaak voorkomen

Een spreadsheet rekent precies wat je erin zet. Het waarschuwt je niet als een formule conceptueel fout is, zolang de syntax klopt. Een verkeerde grondslag, een vergeten post of een verkeerd geparst getal levert gewoon een uitkomst op. Die uitkomst ziet er plausibel uit, tot je hem tegen de werkelijkheid legt. Dit artikel laat bij elke fout zien wat er precies misgaat, en wat het je in euro's kost. Zeven concrete categorieën, elk met een compleet rekenvoorbeeld dat je zelf kunt naspelen in je eigen spreadsheet of rekentool.

BRIX Calc is tegen precies deze zeven fouten gebouwd. De rekenkern bevat expliciete guards: geklemde percentages, aparte parsers voor bedragen en tarieven, en een rekenvolgorde die niet afhangt van hoe een gebruiker een veld heeft ingevuld. Dat is geen verkooppraat. Het is de reden waarom dit artikel de formules kan tonen. Elke fout hieronder is een regel code die op een specifiek moment is toegevoegd om precies dit probleem op te lossen, met een eigen geschiedenis in de codebase.

3. De zeven fouten, met de juiste formule ernaast

1. Rente over de volledige hoofdsom in plaats van de dalende restschuld. Bij een lineaire of annuïtaire lening daalt de restschuld elke maand. Een model dat de rente steeds over de oorspronkelijke hoofdsom berekent, overschat de rentelast met het jaar dat verstrijkt.

Fout: rente = € 300.000 × 5% = € 15.000, elk jaar Juist: rente = restschuld × 5%, herberekend per jaar

Op een lening van € 300.000, lineair afgelost over 20 jaar, is de fout in jaar 1 nog beperkt. Het foute model rekent € 15.000, de juiste formule € 14.656: een verschil van € 344. In jaar 10 loopt de restschuld van € 165.000 aan het begin naar € 150.000 aan het eind. De juiste formule rekent dan € 7.906 rente, tegenover € 15.000 in het foute model. Dat is € 7.094 verschil, in dat ene jaar alleen al.

2. Overdrachtsbelasting op een verouderd of verkeerd tarief. Het tarief voor een beleggingswoning staat in 2026 op 8%, en voor een niet-woning op 10,4%. De volledige berekening staat in overdrachtsbelasting bij een beleggingspand berekenen. Een model dat nog met 10,4% rekent in plaats van het 8%-tarief van 2026 kost op € 400.000 koopsom € 9.600 te veel, direct uit het rendement van je project.

3. Leegstand als jaarpost vergeten in plaats van op de huurstroom.

Fout: NOI = € 30.000 huur − exploitatiekosten (leegstand genegeerd) Juist: NOI = (€ 30.000 × 95% bezetting) − exploitatiekosten

Bij 5% verwachte leegstand op € 30.000 jaarhuur is het verschil € 1.500 NOI per jaar. Dat lijkt beperkt, maar werkt door in élk jaar van de prognose én in de DSCR-toets van de bank.

4. Geen piekmoment in de eigen inleg. Een model dat alleen de startinleg toont, mist bij een aflossende lening de extra cash die je tussentijds bijlegt. In het rekenvoorbeeld hieronder is dat € 26.042, op een project met € 200.000 startinleg.

5. Rente tijdens de bouw ontbreekt. Rente die je tijdens een vergunningstraject niet betaalt maar bijschrijft, telt op bij de hoofdsom. Een model dat een vergunningstraject van acht maanden zonder rentepost doorrekent, mist € 16.283 aan bijgeschreven rente op een lening van € 400.000 tegen 6%.

6. ROE op de verkeerde noemer. Zie de aparte pagina over rendement op eigen vermogen. Wie winst deelt door de totale investering in plaats van de eigen inleg, noemt het resultaat ROE terwijl het eigenlijk ROI is. Op € 163.000 winst is dat het verschil tussen 26,1% en 81,5%: twee compleet andere getallen onder dezelfde naam.

7. Duizendtalnotatie die een spreadsheet verkeerd inleest. Dit is geen formulefout maar een parseerfout, en de meest destructieve van de zeven:

Fout: Number("450.000") in de meeste programmeertalen geeft 450 Juist: een NL-bedragparser leest de punt als duizendtalscheiding: 450.000

Typ je "450.000" (vierhonderdvijftigduizend euro) in een cel of een formulier dat de Engelse conventie verwacht. De kale parseFloat- of Number-functie leest de punt dan als decimaalteken. Het resultaat is een investering van € 450 in plaats van € 450.000. Dat is een factor 1.000 te laag. Elke verdere berekening erft die fout stil door, zonder waarschuwing.

4. Rekenvoorbeeld: de gecombineerde schade

Transformatieproject van € 625.000. Een zelfgebouwd model maakt hier drie van de zeven fouten tegelijk: het oude OVB-tarief, geen piekmoment in de eigen inleg, en geen rentepost tijdens de bouw.

Totale onderschatting = € 9.600 + € 16.283 + € 26.042 = € 51.925

Gevoeligheid: voeg de duizendtalfout (fout 7) toe aan dit plaatje. Het verschil is dan niet meer procentueel, maar een factor duizend. Geen kleine onderschatting meer, maar een compleet onbruikbaar getal.

5. Hoe herken je een betrouwbaar rekenmodel?

Test je eigen model met een extreem scenario: vul een rente van 0% in, of een looptijd van 1 maand. Een model met verborgen fouten geeft dan vaak een absurd getal, maar een gezond model blijft logisch, ook aan de randen.

Een tweede, even simpele test: verander één invoerveld en kijk of alleen de kengetallen veranderen die logischerwijs zouden moeten veranderen. Pas je de rente aan, dan hoort de overdrachtsbelasting gelijk te blijven. Verandert die toch mee, dan zit er ergens een formule die naar het verkeerde veld verwijst: een fout die in een kleine spreadsheet makkelijk binnensluipt zodra cellen worden gekopieerd en geplakt in plaats van herberekend.

6. De twee fouten die het meeste schade doen

De duizendtalfout (7), omdat ze alles erna besmet. Een verkeerd geparste koopsom maakt niet alleen die ene cel fout. Elke formule die ernaar verwijst rekent mee: kosten koper, lening, rendement. Alles rekent verder op een getal dat al duizend keer te laag is.

Rente op de verkeerde hoofdsom (1), omdat ze het langst onopgemerkt blijft. Bij een kort project is het verschil klein genoeg om niet op te vallen. Bij een lening van tien jaar of langer stapelt de fout zich op tot duizenden euro's. Dat gebeurt precies op het moment dat bijsturen niet meer mogelijk is.

7. Zelf doorrekenen

Vul je project in bij BRIX Calc en vergelijk de uitkomst met je eigen spreadsheet. Elk verschil is een aanwijzing welke van deze zeven fouten zich in je eigen model heeft genesteld. Reken hetzelfde project door in beide tools en loop de zeven categorieën hierboven één voor één af, in plaats van te gokken welke van de twee uitkomsten klopt.

Begin je liever met een model dat deze zeven fouten niet maakt, dan staat die opzet in gratis Excel-template voor je huurwoning. Welke kengetallen er allemaal uit een project komen en wat ze meten, staat in de complete gids financiële indicatoren.

8. Veelgestelde vragen

Zijn deze fouten alleen relevant voor Excel-gebruikers?

Nee. Ze duiken op in elk model dat handmatig formules combineert, of dat nu Excel, Google Sheets of een eigen webformulier is. De kwetsbaarheid zit niet in het programma, maar in het ontbreken van ingebouwde controles die een specifieke rekentool wél kan afdwingen.

Welke van deze fouten komt het vaakst voor?

Rente over de volledige hoofdsom (fout 1) zien we het meest, simpelweg omdat een vaste jaarlijkse rentepost de eenvoudigste formule is om te bouwen. De juiste, dalende berekening vraagt een aparte regel per jaar of per maand, wat meer werk kost dan één statische formule.

Waarom komt de duizendtalfout vooral bij webformulieren voor?

Excel herkent de systeeminstelling van je computer meestal correct, en verwerkt een Nederlandse notatie dus goed. Een los webformulier of een gedeeld sjabloon van een Engelstalige bron doet dat niet automatisch. De notatie hangt daar af van hoe de bouwer van het formulier het bedragveld destijds heeft geprogrammeerd, niet van jouw eigen taalinstelling of browser.

Kan ik deze fouten controleren zonder een nieuwe tool te gebruiken?

Deels. Reken een extreem scenario door (een looptijd van één maand, of een rente van 0%) en kijk of de uitkomst logisch blijft. Voor de duizendtalfout (7) helpt het om een testbedrag als "1.234.567" in te voeren. Check daarna of de uitkomst exact dat bedrag laat zien, zonder afronding of een verschoven komma ergens in de rekenketen.

Waarom noemt dit artikel geen achtste of negende fout?

Niet omdat er geen andere fouten bestaan, maar omdat deze zeven het vaakst voorkomen en het meest rekenkundig aantoonbaar zijn. Andere risico's, zoals een te optimistische huurgroei-aanname, zijn geen rekenfout maar een inschattingsfout. Dat is een ander soort probleem: geen verkeerde formule, maar een verkeerde aanname die de formule zelf niet kan corrigeren.

Maakt een dure rekentool deze fouten automatisch niet?

Niet automatisch, maar wel minder snel. Een tool die specifiek voor vastgoedberekeningen is gebouwd, heeft doorgaans expliciete tests op deze zeven categorieën, opnieuw uitgevoerd bij elke wijziging aan de rekenkern. Een generiek spreadsheetprogramma heeft die controle niet ingebouwd: daar blijft de zorgvuldigheid van de bouwer bepalend voor of de fouten binnensluipen, project na project opnieuw.