ASC 350-40 — het codificatieonderwerp dat zoekers vaak typen als 350/40 — is de FASB-regel voor interne gebruikssoftware: wanneer worden ontwikkelingskosten nu ten laste genomen versus geactiveerd als immaterieel actief en later afgeschreven. Onder het oude driefasenmodel (dat de meeste rapporteerders nog steeds toepassen tot de verplichte datum van ASU 2025-06) past het antwoord in één tabel:
| Fase | Wat er gebeurt | Activeren of ten laste nemen? |
|---|---|---|
| Voorbereidende projectfase | Vereisten, leveranciersdemo's, haalbaarheid, make-or-buy | Ten laste nemen naarmate deze worden gemaakt |
| Applicatieontwikkeling | Programmeren, configureren, testen, integratie nadat het management zich heeft gecommitteerd | Activeren van directe bouwkosten |
| Fase na implementatie | Training, onderhoud, bugfixes na de livegang | Ten laste nemen (nieuwe functionaliteit kan de kapitalisatie herstarten) |
ASU 2025-06 (uitgegeven op 18 september 2025; verplicht voor jaarperioden die beginnen na 15 december 2027) verwijdert deze faselabels en vervangt ze door een waarschijnlijk-om-te-voltooien-drempel, en geeft aan dat meer kosten ten laste zullen worden genomen. De onderstaande secties behandelen wat ASC 350-40 omvat, het detail van de fasen, de update van 2025, de activeren/ten-laste-nemen-checklist, en hoe de keuze EBITDA en de balans beïnvloedt.
Wat ASC 350-40 Behandelt
ASC 350-40 is de FASB-norm voor interne gebruikssoftware — software die uw bedrijf bouwt of koopt voor de eigen bedrijfsvoering, niet om als primair product aan klanten te verkopen. Voorbeelden zijn:
- Interne CRM-, ERP-, HR- of boekhoudsystemen
- Cloudinfrastructuur-tooling en DevOps-platforms
- Een SaaS-platform dat u voor klanten exploiteert (de klant heeft er toegang toe als dienst, niet als gelicentieerde software die ze installeren)
- Interne datapijplijnen, dashboards en analysetools
- Aangepaste workflow- of backoffice-automatisering
Als u gelicentieerde software verkoopt die klanten op hun eigen machines installeren, valt dat onder ASC 985-20 (software voor externe verkoop), waarvoor andere regels gelden. De meeste moderne SaaS-bedrijven vallen onder ASC 350-40 omdat klanten de software als gehoste dienst consumeren.
De kernvraag die de norm beantwoordt: wanneer u geld uitgeeft aan het bouwen van software, moet die kost dan onmiddellijk ten laste worden genomen of worden geactiveerd als immaterieel actief en over toekomstige perioden worden afgeschreven?
Het Oude Driefasenmodel (Vóór ASU 2025-06)
Decennialang gebruikte ASC 350-40 een fasengebaseerd kader. Onder de oude richtlijn die voor de meeste rapporteerders tot en met 2027 van kracht blijft, valt softwareontwikkeling uiteen in drie afzonderlijke fasen.
Fase 1: Voorbereidende Projectfase
Dit is de verkenningsfase — het definiëren van vereisten, het evalueren van technologieën, het krijgen van demo's van leveranciers, en het beslissen of u gaat bouwen, kopen of afzien. Alle kosten in deze fase worden ten laste genomen naarmate ze worden gemaakt, vergelijkbaar met onderzoekskosten. De reden: totdat het management zich committeert, heeft u nog geen waarschijnlijk actief.
Activiteiten hier omvatten:
- Conceptuele formulering en ontwerpalternatieven
- Leveranciersdemo's en technologie-evaluaties
- Kosten-batenanalyses en haalbaarheidsstudies
- Uiteindelijke selectie van een aanpak of leverancier
Fase 2: Applicatieontwikkelingsfase
De kapitalisatie begint wanneer het management het project goedkeurt, financiering toezegt en voltooiing waarschijnlijk is. Deze fase omvat het daadwerkelijke bouwen — programmeren, testen, configureren, integreren en installeren.
Activeerbare kosten in deze fase omvatten doorgaans:
- Salarissen en secundaire arbeidsvoorwaarden voor ontwikkelaars, QA-ingenieurs en projectmanagers (alleen de tijd die direct toerekenbaar is aan het programmeren, testen en configureren van de software)
- Externe consultancykosten voor ontwikkelwerkzaamheden
- Softwarelicenties en tools die worden gebruikt om de applicatie te bouwen
- Directe kosten van materialen en diensten die tijdens de ontwikkeling worden verbruikt
- Rentekosten (in beperkte gevallen)
De kapitalisatie stopt wanneer de software in wezen volledig is en gereed is voor het beoogde gebruik — doorgaans wanneer het testen is afgerond en het systeem in productie is genomen, zelfs als de uitrol geleidelijk verloopt.
Fase 3: Fase Na Implementatie
Na de livegang worden doorlopende kosten weer ten laste genomen. Training, onderhoud, bugfixes en routinematige ondersteuning worden allemaal ten laste genomen. De uitzondering: verbeteringen die nieuwe functionaliteit toevoegen (niet alleen bestaande functionaliteit repareren of onderhouden) kunnen worden geactiveerd met dezelfde criteria als in Fase 2.
De Belangrijke Update van 2025: ASU 2025-06
Op 18 september 2025 heeft de FASB ASU 2025-06 uitgegeven, die ASC 350-40 aanzienlijk moderniseert. De update is verplicht voor jaarperioden die beginnen na 15 december 2027, met vervroegde toepassing toegestaan.
De wijziging is structureel: het driefasenmodel is verdwenen. De FASB heeft expliciet alle verwijzingen naar projectfasen verwijderd omdat het oude kader niet paste bij moderne agile en iteratieve ontwikkelpraktijken, waarbij vereisten evolueren en "fasen" overlappen of parallel lopen.
De Nieuwe Principesgebaseerde Drempel
Onder de herziene norm activeert u softwarekosten alleen wanneer beide voorwaarden zijn vervuld:
- Goedkeuring van het management: Het management heeft het project goedgekeurd en zich gecommitteerd aan de financiering ervan.
- Waarschijnlijk-om-te-voltooien-drempel: Het is waarschijnlijk dat het project wordt voltooid en dat de software de beoogde functie zal vervullen.
Die tweede toets doet echt werk. De FASB heeft een concept geïntroduceerd dat significante ontwikkelingsonzekerheid wordt genoemd om te beoordelen of voltooiing waarschijnlijk is. U moet beoordelen:
- Of de software nieuwe of onbewezen functies bevat die niet zijn gevalideerd door middel van programmeren of testen
- Of de prestatiedoelstellingen nog niet zijn vastgesteld of onderhevig zijn aan ingrijpende herziening
Als er significante onzekerheid bestaat, moet de kapitalisatie worden uitgesteld totdat de onzekerheid is opgelost. De FASB heeft aangegeven dat zij verwacht dat de nieuwe regel ertoe zal leiden dat meer softwarekosten ten laste worden genomen, met name bij SaaS-bedrijven waar vereisten continu itereren.
Wat Dit in de Praktijk Betekent
Voor een startup die iets werkelijk nieuws bouwt — een AI-agentplatform, een nieuwe automatiseringsengine — kan de nieuwe regel ertoe leiden dat meer uitgaven eerder in de operationele kosten terechtkomen. Voor volwassen bedrijven die goed gedefinieerde systemen verbeteren, zal de praktische impact kleiner zijn. Hoe dan ook betekent de verschuiving van een mechanische fasecheck naar een op oordeel gebaseerde drempel dat bedrijven duidelijkere documentatie nodig hebben van managementbeslissingen, technische haalbaarheid en projectstatus.
Wat U Wel en Niet Kunt Activeren: Een Praktische Checklist
Of u nu het oude fasemodel of de nieuwe principesgebaseerde toets toepast, de grens tussen activeerbare en ten laste te nemen uitgaven is qua strekking vergelijkbaar. Hier is een werkbare checklist.
Over het Algemeen Activeerbaar
- Directe arbeidskosten voor ontwikkelaars, ontwerpers en QA tijdens de bouwfase
- Toegerekende loonheffingen en secundaire arbeidsvoorwaarden voor die werknemers
- Externe consultancy- en aannemersvergoedingen voor ontwikkelwerkzaamheden
- Software, tools en cloudinfrastructuurkosten die direct worden verbruikt in de ontwikkeling
- Kosten voor het ontwikkelen van nieuwe functionaliteit na de lancering (verbeteringen die de mogelijkheden materieel uitbreiden)
- Kosten voor het ontwikkelen van conversiesoftware (de software die oude data naar nieuw migreert), in tegenstelling tot de data-conversieactiviteit zelf
Over het Algemeen Ten laste te Nemen
- Voorbereidend onderzoek, leveranciersselectie en haalbaarheidsanalyse
- Training van medewerkers op het nieuwe systeem
- Datareiniging, reconciliatie en migratie van administraties
- Routinematig onderhoud, bugfixes en kleine refactoring
- Softwarekosten gemaakt tijdens perioden van significante ontwikkelingsonzekerheid
- Algemene administratieve overhead die niet direct aan ontwikkeling is gekoppeld
- Marketing-, ondersteunings- en klantsuccesactiviteiten na de lancering
Het Tijdregistratieprobleem
De grootste praktische uitdaging is het toerekenen van technische tijd. Een senior engineer die 40 uur per week werkt, zal waarschijnlijk niet 100% activeerbaar werk doen — ze debuggen ook productie, begeleiden teamgenoten, wonen stand-ups bij en beoordelen pull requests voor erfsoftwaresystemen. Zonder een verdedigbare tijdregistratiemethode (engineeringtickets gelabeld per project, tijdregistratiesoftware of formele allocatieonderzoeken) zullen kapitalisatieschattingen geen standhouden bij een accountantscontrole.
De Impact op de Financiële Overzichten
Het activeren versus het ten laste nemen van dezelfde dollar levert dramatisch verschillende financiële overzichten op.
Effect op de Resultatenrekening
Een geactiveerde kost raakt de resultatenrekening niet in de periode waarin deze wordt gemaakt. In plaats daarvan wordt deze afgeschreven — doorgaans lineair over drie tot vijf jaar voor interne gebruikssoftware. Dus €1M aan geactiveerde engineeringuitgaven in jaar 1 zou elk jaar slechts €200K tot €333K aan afschrijvingskosten kunnen creëren, waardoor het bedrijfsresultaat van jaar 1 materieel hoger uitvalt.
Dit is de reden waarom EBITDA een boost krijgt door kapitalisatie. Afschrijving wordt per definitie uitgesloten van EBITDA — dus het activeren van meer ontwikkelingskosten verschuift dollars van operationele kosten (die EBITDA verlagen) naar afschrijving (die dat niet doet). Beleggers die SaaS-metrics nauwkeurig bekijken, kijken vaak naar "EBITDA vóór geactiveerde R&D" of rule-of-40-berekeningen met cash R&D om door deze dynamiek heen te kijken.
Effect op de Balans
Geactiveerde software verschijnt als een langlopend immaterieel actief, vaak gelabeld als "Geactiveerde softwareontwikkelingskosten" of iets dergelijks. Dit:
- Verhoogt de totale activa en het eigen vermogen
- Verbetert het rendement op activa (ROA) alleen als de winst sneller stijgt dan de activabasis
- Creëert een actief dat moet worden getoetst op bijzondere waardevermindering als het project wordt gestaakt of de waarde ervan daalt
Als een project halverwege de ontwikkeling wordt gestaakt, moeten de eerder geactiveerde kosten worden afgeschreven — wat een plotseling, vaak materieel verlies oplevert. Dit is een van de redenen waarom de nieuwe ASU 2025-06 zo sterk de nadruk legt op de waarschijnlijk-om-te-voltooien-drempel.
Effect op het Kasstroomoverzicht
Geactiveerde ontwikkelingskosten worden doorgaans geclassificeerd als investeringsactiviteiten (niet operationeel), waardoor de operationele kasstroom er sterker uitziet. Geavanceerde beleggers corrigeren hiervoor bij het vergelijken van bedrijven — maar het kerncijfer profiteert nog steeds.
Veelvoorkomende Fouten Die Bedrijven in de Problemen Brengen
Accountants en overnemers zien dezelfde fouten steeds opnieuw.
Kapitaliseren van Kosten Vóór Goedkeuring
De klassieke fout is het activeren van technische tijd die is besteed voordat het management het project formeel goedkeurde. Zonder een gedocumenteerde goedkeuring en financieringstoezegging hadden die kosten ten laste moeten worden genomen. Zorg ervoor dat u notulen, bestuursgoedkeuringen of schriftelijke handtekeningen heeft die vastleggen wanneer het management zich heeft gecommitteerd.
Geen Documentatie op Projectniveau
Als een toezichthouder of accountant vraagt "laat me de projecten zien die u hebt geactiveerd", en u kunt alleen wijzen op algemene engineeringuitgaven, dan verliest u. U heeft project-voor-projectadministratie nodig: scope, goedkeuringsdatum, budget, status en toegerekende tijd.
Alle Technische Tijd als Activeerbaar Behandelen
Senior engineers repareren bugs, beoordelen code, wonen vergaderingen bij en reageren op incidenten. Niets daarvan is activeerbaar. Bedrijven die simpelweg de loonsom van het engineeringteam met een percentage vermenigvuldigen, overleven zelden een accountantscontrole.
Doorgaan met Kapitaliseren Na de Lancering
Op het moment dat de software gereed is voor het beoogde gebruik, stopt de kapitalisatie. Bugfixes, prestatieoptimalisatie en kleine verbeteringen daarna zijn operationele kosten. Nieuw, afzonderlijk afgebakend werk kan een nieuwe kapitalisatieperiode starten — maar routinematig werk na de lancering kan dat niet.
Het Vergeten van Toetsing op Bijzondere Waardevermindering
Geactiveerde software is een actief, en activa moeten worden afgewaardeerd als hun waarde daalt. Als u een product uit de vaart neemt, een functie beëindigt of het systeem fundamenteel herschrijft, moet u opnieuw beoordelen en waarschijnlijk het eerdere saldo afschrijven.
Hoe U een Verdedigbaar Proces Opzet
Als u besluit dat kapitalisatie juist is voor uw bedrijf, is het proces net zo belangrijk als het beleid.
-
Schrijf een softwarekapitalisatiebeleid. Definieer welke projecten in aanmerking komen, uw goedkeuringsproces, uw schatting van de gebruiksduur en hoe u tijd zult toerekenen. Laat het ondertekenen door uw CFO of auditcommissie.
-
Volg technische tijd op projectniveau. Dit is de fundamentele input. Of u nu Jira-labels, aangepaste tags in een projecttracker of formele tijdregistraties gebruikt, u moet kunnen verdedigen "engineer X heeft Y% van hun tijd besteed aan activeerbaar werk aan project Z."
-
Documenteer de goedkeuring van het management. Elk activeerbaar project heeft bewijs van goedkeuring nodig — gedateerde schriftelijke goedkeuring, bestuursnotulen of een projectcharter ondertekend door het leiderschap.
-
Beoordeel significante onzekerheid regelmatig opnieuw. Onder de nieuwe regel moet u monitoren of functies nog steeds nieuw of onbewezen zijn en of de vereisten stabiliseren. Kwartaalreviews met het engineeringleiderschap zijn redelijk.
-
Bouw afschrijvingsschema's per project. Elk geactiveerd project begint met afschrijven wanneer het gereed is voor gebruik, en u moet de kostprijs van dat actief, de cumulatieve afschrijving en de resterende levensduur bijhouden.
-
Toets op bijzondere waardevermindering wanneer projecten veranderen. Telkens wanneer u geactiveerd werk staakt, materieel herschrijft of beëindigt, voert u een bijzondere-waardeverminderingsanalyse uit en boekt u indien nodig afwaarderingen.
Waarom Dit Belangrijk Is voor de Boekhouding
Softwarekapitalisatie is een van die gebieden waar boekhoudkundige discipline op dag één jaren later zijn vruchten afwerpt. Beleggers tijdens een Serie B-financiering zullen uw proefbalans erbij pakken; overnemers in een verkoopproces zullen transacties terugleiden naar journaalposten; de Belastingdienst kan uw GAAP-behandeling vergelijken met uw fiscale behandeling van speur- en ontwikkelingswerk (S&O), die zijn eigen regels heeft. Als uw boeken geactiveerde projecten niet scheiden van operationele kosten, technische tijd niet aan specifieke projecten kunnen koppelen, of geen nette afschrijvingsschema's bijhouden, wordt elke accountantscontrole en due diligence-cyclus pijnlijk.
De oplossing is in concept eenvoudig: een schone rekeningstructuur onderhouden, tijd op projectniveau bijhouden en de beslissingen achter elke kapitalisatieboeking documenteren. Dit vanaf het begin doen, voorkomt dure opschoningsacties later.
Houd Uw Softwareboekhouding Auditklaar
Of u nu uw eerste interne platform activeert of afschrijvingsschema's over tientallen projecten beheert, schone financiële administraties vormen de basis. Beancount.io biedt boekhouding in platte tekst die u transparante, versiebeheerde boeken geeft — elke boeking herleidbaar, elke rekening controleerbaar, elk rapport reproduceerbaar. Voor softwarebedrijven die geactiveerde ontwikkeling over meerdere projecten bijhouden, is het hebben van boeken die als code lezen een serieus voordeel. Start gratis en ontdek waarom ontwikkelaars en financiële professionals overstappen op boekhouding in platte tekst.
