Vraag een software engineering manager wanneer een project 'is gestart' en je krijgt een sprintnummer als antwoord. Stel dezelfde vraag aan hun controller, en volgens de boekhoudregels die sinds 1998 gelden voor intern gebruikte software, hoorde het antwoord te komen uit een starre checklist met drie fasen die ervan uitgaat dat niemand code schrijft voordat de vereisten zijn vastgelegd. Iedereen die het afgelopen decennium software heeft uitgeleverd, weet dat het zo niet meer werkt — en in september 2025 gaf FASB dat eindelijk ook toe.
Accounting Standards Update (ASU) 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software, schrapt de oude, op fasen gebaseerde toets volledig en vervangt deze door één simpele, op oordeel gebaseerde vraag: is het waarschijnlijk dat deze software daadwerkelijk wordt afgerond en doet wat ze moet doen? Voor elk bedrijf dat software in eigen beheer ontwikkelt — en zeker voor de agile teams waarvoor de oude regel nooit was bedoeld — verandert dit wanneer ontwikkelingskosten van de winst-en-verliesrekening naar de balans verhuizen, en met hoeveel.
Het probleem: een regelboek uit 1998 voor watervalontwikkeling
De richtlijn die ASU 2025-06 vervangt, ASC 350-40 (oorspronkelijk SOP 98-1), werd geschreven in een tijd waarin 'softwareontwikkeling' een lineair watervalproces betekende. Deze verdeelde elk project voor intern gebruikte software in drie opeenvolgende fasen:
- Voorbereidende projectfase — conceptuele formulering, evaluatie van alternatieven, leverancierskeuze. Alles hier wordt direct als kosten geboekt.
- Ontwikkelingsfase van de toepassing — daadwerkelijk coderen, configureren en testen. Kosten hier worden geactiveerd.
- Fase na implementatie — training en onderhoud. Wordt weer direct als kosten geboekt.
Dat kader werkt prima als een team drie maanden besteedt aan het schrijven van een functioneel ontwerp, akkoord krijgt en dan pas begint te bouwen. Het houdt geen stand zodra een team sprints van twee weken draait, incrementele releases uitlevert en de scope bij elke retro bijstelt. In een agile omgeving zijn 'voorbereidend' en 'ontwikkeling van de toepassing' geen opeenvolgende fasen — ze lopen door elkaar, soms binnen dezelfde sprint. Bedrijven en hun accountants hebben jaren gediscussieerd over tot welke fase een gegeven sprint van twee weken nu eigenlijk behoorde, en het eerlijke antwoord was vaak 'een beetje van beide, we gokken maar wat.' Uit eigen onderzoek van FASB bleek dat belanghebbenden dit consequent aanmerkten als een van de operationeel meest lastige onderdelen van GAAP om consistent toe te passen.
De oplossing: één toets, geen drie fasen
ASU 2025-06 schrapt elke verwijzing naar de oude projectfasen. In de plaats daarvan stelt de standaard één enkele erkenningsdrempel voor 'waarschijnlijke voltooiing' in. Onder de nieuwe richtlijn activeert een bedrijf kosten voor intern gebruikte software zodra beide van de volgende voorwaarden tegelijk waar zijn:
- Het management heeft het project goedgekeurd en zich verbonden tot de financiering ervan. Dit is geen nieuw concept — het bestond ook al in de oude richtlijn — maar het speelt nu een grotere rol als een van slechts twee toegangsvoorwaarden, in plaats van verstopt te zitten in een fase-analyse.
- Het is waarschijnlijk dat het project wordt voltooid en dat de software wordt gebruikt voor de beoogde functie. Dit is het werkelijk nieuwe onderdeel, en hier zit de kern van het oordeel.
Dat tweede criterium vereist een beoordeling of er nog aanzienlijke ontwikkelingsonzekerheid bestaat. FASB wijst op twee belangrijke bronnen van die onzekerheid:
- Onbewezen technologie of nieuwe functionaliteit waarvan de haalbaarheid nog niet is aangetoond door daadwerkelijk coderen en testen — geen ontwerpdocument, geen specificatie, maar werkend bewijs.
- Ongedefinieerde of nog verschuivende prestatievereisten — de standaard omschrijft deze als 'wat een entiteit van de software verlangt, bijvoorbeeld functies of kenmerken.' Als het team nog wezenlijk discussieert over wat het product moet doen, is die onzekerheid nog niet weggenomen.
In de praktijk betekent dit dat het moment van activering nu bewijs van haalbaarheid volgt, niet een kalenderfase. Een team dat gedurende twee sprints een technisch nieuwe functie uitprobeert ('spiket') voordat het zich vastlegt om die serieus te bouwen, zou die verkennende sprints als kosten boeken — de onzekerheid of het überhaupt gebouwd kan worden, is nog niet weggenomen. Zodra de verkenning uitwijst dat het werkt en het management budget toezegt voor de volledige bouw, is de drempel van 'waarschijnlijke voltooiing' bereikt en worden de daaropvolgende ontwikkelingskosten geactiveerd, ongeacht de agile ceremonies eromheen.
Waarom FASB zegt dat kapitalisatie nauwelijks zal veranderen — behalve voor SaaS
FASB verwacht zelf dat de wijzigingen voor de meeste on-premises of licentiegebaseerde intern gebruikte software niet ingrijpend zullen veranderen wat er wordt geactiveerd — bedrijven activeerden al zodra het echte coderen begon, en de nieuwe toets komt ongeveer op hetzelfde punt uit, alleen zonder de exercitie van het labelen van fasen.
Software die wordt ontwikkeld voor levering via een SaaS- of cloudregeling is een ander verhaal. FASB verwacht expliciet dat de kapitalisatie voor deze projecten zal afnemen. De redenering: SaaS-producten worden van nature voortdurend gebouwd en herbouwd, met aanzienlijke technische en productonzekerheid die tot diep in de ontwikkelingstijdlijn blijft bestaan — soms tot vlak voor een functie wordt uitgebracht. Onder de toets van waarschijnlijke voltooiing betekent die aanhoudende onzekerheid dat veel SaaS-ontwikkelingskosten pas veel later in het bouwproces de kapitalisatiedrempel halen dan het oude fasenmodel zou hebben gesuggereerd. Het netto-effect: een groter deel van de loonkosten van engineers bij een SaaS-product komt terecht als R&D-kosten in de lopende periode, in plaats van als een over meerdere jaren af te schrijven actief. Dat is een betekenisvolle verschuiving voor de gerapporteerde EBITDA en activabasis van elk SaaS-bedrijf, nog voordat er ook maar één regel echte code verandert.
Een concreet voorbeeld: twee teams, twee uitkomsten
Stel dat een SaaS-bedrijf met 40 medewerkers besluit een AI-gestuurde forecastingmodule voor zijn product te bouwen. Zo zouden de oude en de nieuwe regels dezelfde bouw van acht maanden verschillend behandelen.
Onder het oude fasemodel probeerde het finance team een grens te trekken: de eerste zes weken van requirements verzamelen en leveranciersevaluatie waren 'voorbereidend' (kosten), en alles na de kick-offmeeting was 'ontwikkeling van de toepassing' (geactiveerd) — ook al besteedde het engineeringteam de volgende twee maanden aan verkennende spikes om uit te zoeken of hun gekozen forecastingaanpak een acceptabele nauwkeurigheid kon halen bij productie-datavolumes. Naar de letter van de oude regel werden die verkennende sprints, zodra de 'fase' omsloeg, vaak ook geactiveerd, omdat ze technisch gezien na de kick-offmeeting plaatsvonden.
Onder ASU 2025-06 stelt het finance team in plaats daarvan de vraag: wanneer werd het waarschijnlijk dat deze functie zou worden voltooid en zou werken zoals bedoeld? Als de nauwkeurigheidsaanpak de eerste twee maanden nog onbewezen was — het team testte drie verschillende modelleringsbenaderingen en wist niet of er één de lat zou halen — worden de kosten van die hele verkenningsperiode geboekt, ongeacht in welke 'fase' die op de kalender viel. Kapitalisatie begint pas zodra het team een gevalideerde aanpak kiest en het management budget toezegt om die uit te bouwen, wat in dit voorbeeld maand drie kan zijn in plaats van maand twee. Het resultaat: een kleiner geactiveerd actief, hogere R&D-kosten in de lopende periode en — belangrijker nog — een cijfer dat de CFO daadwerkelijk kan verdedigen bij een audit, omdat het is gekoppeld aan een specifiek, gedocumenteerd beslismoment in plaats van een achteraf toegepast faselabel.
Dit is precies de verschuiving die FASB in de hele SaaS-sector verwacht: minder 'we noemden het ontwikkeling van de toepassing omdat dat kwam na de kick-offcall' en meer 'we kunnen aanwijzen in welke sprint het technische risico werd weggenomen.'
Ingangsdata en overgang
ASU 2025-06 treedt in werking voor alle entiteiten — beursgenoteerd en privaat — voor jaarlijkse verslagperiodes die beginnen na 15 december 2027, en voor tussentijdse periodes binnen die jaren. Vervroegde toepassing is toegestaan voor elke entiteit, in elke tussentijdse of jaarlijkse periode, zodra de standaard is uitgevaardigd.
Entiteiten kunnen de wijzigingen toepassen via een van drie overgangsbenaderingen: prospectief, alleen voor nieuwe softwarekosten die na de ingangsdatum worden gemaakt; prospectief voor kosten die worden gemaakt op of na het begin van het jaar van invoering; of retrospectief voor alle gepresenteerde periodes. Die flexibiliteit is belangrijk — een bedrijf dat middenin een grote platform-herbouw zit wanneer de regel ingaat, hoeft jaren aan geactiveerde kostenhistorie niet terug te draaien, tenzij het kiest voor de retrospectieve optie.
Wat kleine en middelgrote softwarebedrijven nu moeten doen
December 2027 klinkt ver weg, maar het praktische voorbereidingswerk is geen taak voor het laatste kwartaal, vooral niet voor bedrijven met een krap bemenst finance team zonder toegewijde technische accountingfunctie.
Begin nu met het in real time documenteren van de 'waarschijnlijke voltooiing'-beoordeling, niet achteraf. Het oude fasemodel was mechanisch — je kon maanden later aan de hand van sprintdata reconstrueren in welke fase een project zat. De nieuwe toets vraagt wanneer hielden we op technisch onzeker te zijn, en dat is een oordeel dat achteraf veel moeilijker te reconstrueren is. Bouw nu een lichte gewoonte op: wanneer engineering-leiding en finance het erover eens zijn dat een functie haar technische verkenning heeft doorstaan en is vrijgegeven voor bouw, leg die datum vast. Dat logboek wordt je startdatum voor kapitalisatie en je auditonderbouwing.
Scheid 'verkennend' werk van 'toegezegd bouw'-werk in je urenregistratie of projectcodes, als je dat nog niet doet. Of dat nu een Jira-epicvlag is, een aparte kostenplaatscode, of gewoon een label in je urenregistratietool — een duidelijk gegevensspoor voor wanneer een functie overging van spike/prototype naar toegezegde ontwikkeling maakt het toepassen van de nieuwe standaard aanzienlijk minder pijnlijk dan proberen het uit het geheugen te reconstrueren tijdens een audit.
Modelleer beide overgangsopties voordat je er één kiest. Als je bedrijf onder het oude fasemodel agressief SaaS-ontwikkelingskosten heeft geactiveerd, kan retrospectieve toepassing leiden tot een eenmalige afwaardering van eerder geactiveerde activa, doordat die kosten worden geherclassificeerd alsof ze steeds al als kosten waren geboekt. Een prospectieve aanpak voorkomt die herziening, maar betekent dat je winst-en-verliesrekening de nieuwe methodiek pas weerspiegelt zodra nieuwe projecten na invoering starten. Reken beide scenario's door voordat je auditcommissie dat moet doen.
Praat vroeg met je accountant, zeker als je een SaaS-bedrijf bent. Gezien de eigen verwachting van FASB dat de kapitalisatie voor SaaS-ontwikkeling zal afnemen, zullen accountants beoordelingen van 'waarschijnlijke voltooiing' waarschijnlijk kritischer bekijken dan ze de faseclassificaties onder de oude regel bekeken — juist omdat het subjectiever is. Een bedrijf dat zijn audit van 2028 ingaat met een gedocumenteerd, actueel vastgelegd kader voor die beoordeling, heeft een veel eenvoudiger gesprek dan een bedrijf dat dit achteraf probeert te reconstrueren.
Schone boeken maken oordelen makkelijker te verdedigen
Elk boekhoudkundig oordeel — en 'waarschijnlijke voltooiing' is bij uitstek een oordeel — is slechts zo verdedigbaar als de administratie erachter. Als je rekeningschema R&D-uitgaven al per project scheidt, en je grootboekboekingen geversioneerd en controleerbaar zijn in plaats van verspreid over losse spreadsheets, wordt het toepassen van een standaard als ASU 2025-06 een kwestie van het taggen van bestaande gegevens in plaats van het reconstrueren van geschiedenis uit Slack-threads. De plain-text accounting van Beancount.io geeft je standaard zo'n transparant, met git geversioneerd grootboek — elke boeking herleidbaar, elke wijziging controleerbaar, zonder vendor lock-in. Gratis aan de slag en bouw een administratie die overeind blijft, of de vraag nu komt van een accountant, een overnamekandidaat of de volgende FASB-update.