Fragt man eine Engineering-Managerin oder einen Engineering-Manager, wann ein Projekt „begonnen" hat, bekommt man eine Sprint-Nummer als Antwort. Fragt man den Controller dasselbe, sollte die Antwort nach den Rechnungslegungsregeln, die seit 1998 für intern genutzte Software gelten, eigentlich aus einer starren dreistufigen Checkliste stammen – einer Checkliste, die davon ausgeht, dass niemand Code schreibt, bevor die Anforderungen feststehen. Wer in den letzten zehn Jahren Software ausgeliefert hat, weiß, dass das längst nicht mehr der Realität entspricht – und im September 2025 hat auch das FASB das eingeräumt.
Das 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, wirft den alten, phasenbasierten Test vollständig über Bord und ersetzt ihn durch eine einzige, ermessensbasierte Frage: Ist es wahrscheinlich, dass diese Software tatsächlich fertiggestellt wird und das tut, was sie tun soll? Für jedes Unternehmen, das Software selbst entwickelt – und besonders für die agilen Teams, für die die alte Regel nie gemacht war – ändert das, wann Entwicklungskosten von der Gewinn- und Verlustrechnung in die Bilanz wandern, und in welchem Umfang.
Das Problem: Ein Regelwerk aus dem Jahr 1998 für die Wasserfallentwicklung
Die Vorgängerregelung, die ASU 2025-06 ersetzt, ASC 350-40 (ursprünglich SOP 98-1), wurde geschrieben, als „Softwareentwicklung" noch einen linearen Wasserfallprozess bedeutete. Sie teilte jedes Projekt für intern genutzte Software in drei aufeinanderfolgende Phasen:
- Vorbereitungsphase (Preliminary Project Stage) – konzeptionelle Ausarbeitung, Bewertung von Alternativen, Anbieterauswahl. Alles in dieser Phase wird sofort als Aufwand erfasst.
- Anwendungsentwicklungsphase (Application Development Stage) – eigentliche Programmierung, Konfiguration und Tests. Kosten in dieser Phase werden aktiviert.
- Phase nach der Implementierung (Post-Implementation Stage) – Schulung und Wartung. Wieder als Aufwand erfasst.
Dieses Modell funktioniert gut, wenn ein Team drei Monate lang ein Lastenheft schreibt, sich das absegnen lässt und dann mit dem Bau beginnt. Es bricht in dem Moment zusammen, in dem ein Team zweiwöchige Sprints fährt, inkrementelle Releases ausliefert und den Scope in jeder Retro anpasst. In einer agilen Umgebung sind „Vorbereitung" und „Anwendungsentwicklung" keine aufeinanderfolgenden Phasen mehr – sie sind ineinander verwoben, manchmal innerhalb desselben Sprints. Unternehmen und ihre Wirtschaftsprüfer haben jahrelang darüber gestritten, zu welcher Phase ein bestimmter zweiwöchiger Sprint eigentlich gehört, und die ehrliche Antwort lautete oft: „ein bisschen von beidem, wir raten." FASBs eigene Konsultationen ergaben, dass Stakeholder dies immer wieder als einen der operativ schmerzhaftesten Aspekte bei der konsistenten Anwendung von GAAP nannten.
Die Lösung: Ein Test statt drei Phasen
ASU 2025-06 streicht jeden Verweis auf die alten Projektphasen. An ihre Stelle tritt eine einzige Ansatzschwelle der „wahrscheinlichen Fertigstellung". Nach der neuen Regelung aktiviert ein Unternehmen Kosten für intern genutzte Software, sobald beide der folgenden Bedingungen gleichzeitig erfüllt sind:
- Das Management hat das Projekt genehmigt und sich zur Finanzierung verpflichtet. Das ist kein neues Konzept – es existierte auch schon in der alten Regelung –, aber es leistet jetzt mehr Arbeit, da es eine von nur zwei Torbedingungen ist, statt in einer Phasenanalyse verborgen zu sein.
- Es ist wahrscheinlich, dass das Projekt abgeschlossen wird und die Software für ihren vorgesehenen Zweck genutzt wird. Das ist das eigentlich neue Element, und hier liegt der Ermessensspielraum.
Das zweite Kriterium erfordert die Beurteilung, ob noch erhebliche Entwicklungsunsicherheit besteht. Das FASB nennt zwei Hauptquellen dieser Unsicherheit:
- Unerprobte Technologie oder neuartige Funktionalität, deren Machbarkeit noch nicht durch tatsächliches Programmieren und Testen nachgewiesen wurde – kein Design-Dokument, kein Lastenheft, sondern ein funktionierender Nachweis.
- Undefinierte oder noch im Fluss befindliche Leistungsanforderungen – der Standard definiert diese als das, „was ein Unternehmen von der Software erwartet, z. B. Funktionen oder Merkmale." Solange das Team noch substanziell darüber diskutiert, was das Produkt leisten soll, ist diese Unsicherheit nicht ausgeräumt.
In der Praxis bedeutet das: Der Zeitpunkt der Aktivierung richtet sich jetzt nach dem Nachweis der Machbarkeit und nicht nach einer Kalenderphase. Ein Team, das ein technisch neuartiges Feature zwei Sprints lang in einem Spike untersucht, bevor es sich zum eigentlichen Bau verpflichtet, würde diese Spike-Sprints als Aufwand erfassen – die Unsicherheit, ob das Feature überhaupt gebaut werden kann, ist noch nicht ausgeräumt. Sobald der Spike den Nachweis erbringt und das Management das Budget für den vollständigen Bau freigibt, ist die Schwelle der „wahrscheinlichen Fertigstellung" erreicht, und die nachfolgenden Entwicklungskosten werden aktiviert – unabhängig davon, welche agilen Zeremonien dazwischenliegen.
Warum sich laut FASB die Aktivierung kaum ändern wird – außer bei SaaS
Das FASB selbst erwartet, dass sich für die meisten On-Premises- oder lizenzbasierten, intern genutzten Softwareprojekte die Aktivierungsergebnisse durch die Änderungen nicht dramatisch verschieben werden – Unternehmen aktivierten bereits bisher, sobald die eigentliche Programmierung begann, und der neue Test kommt ungefähr am selben Punkt an, nur ohne die Übung, Phasen zu etikettieren.
Bei Software, die für die Bereitstellung über ein SaaS- oder Cloud-Modell entwickelt wird, sieht die Sache anders aus. Das FASB erwartet hier ausdrücklich einen Rückgang der Aktivierung. Die Begründung: SaaS-Produkte werden ihrer Natur nach fortlaufend gebaut und umgebaut, wobei erhebliche technische und produktbezogene Unsicherheit bis tief in den Entwicklungszeitraum hinein bestehen bleibt – manchmal bis kurz vor der Veröffentlichung eines Features. Nach dem Test der „wahrscheinlichen Fertigstellung" bedeutet diese anhaltende Unsicherheit, dass viele SaaS-Entwicklungskosten die Aktivierungsschwelle erst deutlich später im Bauprozess überschreiten, als es das alte Phasenmodell nahegelegt hätte. Der Nettoeffekt: Ein größerer Teil der Entwicklergehälter eines SaaS-Produkts landet als laufender F&E-Aufwand in der Periode statt als über mehrere Jahre abzuschreibender Vermögenswert. Das ist eine spürbare Verschiebung für das ausgewiesene EBITDA und die Bilanzsumme jedes SaaS-Unternehmens – noch bevor sich auch nur eine Zeile des tatsächlichen Codes ändert.
Ein konkretes Beispiel: Zwei Teams, zwei Ergebnisse
Angenommen, ein SaaS-Unternehmen mit 40 Mitarbeitenden beschließt, ein KI-gestütztes Prognosemodul für sein Produkt zu bauen. So würden die alten und neuen Regeln denselben achtmonatigen Entwicklungsprozess unterschiedlich behandeln.
Nach dem alten Phasenmodell würde das Finance-Team versuchen, eine Trennlinie zu ziehen: Die ersten sechs Wochen mit Anforderungserhebung und Anbieterbewertung galten als „Vorbereitung" (Aufwand), und alles nach dem Kickoff-Meeting galt als „Anwendungsentwicklung" (Aktivierung) – obwohl das Engineering-Team die nächsten zwei Monate mit explorativen Spikes verbrachte, um herauszufinden, ob der gewählte Prognoseansatz bei produktionsnahen Datenmengen eine akzeptable Genauigkeit erreichen könnte. Nach dem Wortlaut der alten Regel wurden diese Spike-Sprints, sobald die „Phase" gewechselt hatte, oft ebenfalls aktiviert, weil sie formal nach dem Kickoff-Meeting stattfanden.
Nach ASU 2025-06 stellt sich das Finance-Team stattdessen die Frage: Ab wann wurde es wahrscheinlich, dass dieses Feature fertiggestellt wird und wie vorgesehen funktioniert? War der Genauigkeitsansatz in den ersten zwei Monaten noch unerprobt – das Team testete drei verschiedene Modellierungsansätze und wusste nicht, ob einer davon die Anforderungen erfüllen würde –, wird die gesamte Explorationsphase als Aufwand erfasst, unabhängig davon, in welche „Phase" sie kalendarisch fiel. Die Aktivierung beginnt erst, sobald das Team einen validierten Ansatz auswählt und das Management das Budget für den Bau freigibt, was in diesem Beispiel Monat drei sein könnte, nicht Monat zwei. Das Ergebnis: ein kleinerer aktivierter Vermögenswert, ein höherer laufender F&E-Aufwand in der Periode und – entscheidend – eine Zahl, die der CFO in einer Prüfung tatsächlich verteidigen kann, weil sie an einen konkreten, dokumentierten Entscheidungspunkt geknüpft ist und nicht an eine nachträglich vergebene Phasenbezeichnung.
Genau das ist die Verschiebung, die das FASB im gesamten SaaS-Sektor erwartet: weniger „wir haben es Anwendungsentwicklung genannt, weil es nach dem Kickoff-Call kam" und mehr „wir können auf den Sprint zeigen, in dem das technische Risiko ausgeräumt wurde".
Inkrafttreten und Übergang
ASU 2025-06 gilt für alle Unternehmen – börsennotiert und nicht börsennotiert – für Geschäftsjahre, die nach dem 15. Dezember 2027 beginnen, sowie für die Zwischenperioden innerhalb dieser Jahre. Eine vorzeitige Anwendung ist für jedes Unternehmen in jeder Zwischen- oder Jahresperiode zulässig, sobald der Standard veröffentlicht ist.
Unternehmen können die Änderungen nach einem von drei Übergangsansätzen anwenden: prospektiv nur auf neue Softwarekosten, die nach dem Inkrafttreten anfallen, prospektiv auf Kosten, die ab Beginn des Jahres der Erstanwendung anfallen, oder retrospektiv auf alle dargestellten Perioden. Diese Flexibilität ist wichtig – ein Unternehmen, das mitten in einem großen Plattform-Rewrite steckt, wenn die Regel in Kraft tritt, muss jahrelange aktivierte Kostenhistorie nicht zurückrollen, sofern es sich nicht für die retrospektive Option entscheidet.
Was kleine und mittelgroße Softwareunternehmen jetzt tun sollten
Dezember 2027 klingt weit weg, aber die praktische Vorbereitung ist keine Aufgabe fürs letzte Quartal – besonders nicht für Unternehmen mit schlanken Finance-Teams ohne eigene Fachabteilung für technische Rechnungslegung.
Dokumentieren Sie die Ermessensentscheidung zur „wahrscheinlichen Fertigstellung" in Echtzeit, nicht im Nachhinein. Das alte Phasenmodell war mechanisch – man konnte Monate später anhand von Sprint-Daten rekonstruieren, in welcher Phase sich ein Projekt befand. Der neue Test fragt wann haben wir aufgehört, technisch unsicher zu sein, und das ist eine Ermessensentscheidung, die sich im Nachhinein deutlich schwerer rekonstruieren lässt. Etablieren Sie jetzt eine leichtgewichtige Routine: Wenn Engineering-Leitung und Finance sich einig sind, dass ein Feature seinen technischen Spike überstanden hat und für den Bau freigegeben ist, halten Sie dieses Datum fest. Dieses Protokoll wird zu Ihrem Aktivierungsstartdatum und zu Ihrem Prüfungsnachweis.
Trennen Sie „Explorations"-Arbeit von „verpflichteter Bau"-Arbeit in Ihrer Zeiterfassung oder Ihren Projektcodes, falls Sie das nicht bereits tun. Ob das ein Jira-Epic-Flag, ein separater Kostenstellencode oder einfach ein Tag in Ihrem Zeiterfassungstool ist – eine saubere Datenspur dafür, wann ein Feature von Spike/Prototyp zu verpflichteter Entwicklung wechselte, macht die Anwendung des neuen Standards deutlich weniger schmerzhaft, als sie während einer Prüfung aus dem Gedächtnis zu rekonstruieren.
Modellieren Sie beide Übergangsoptionen, bevor Sie sich entscheiden. Wenn Ihr Unternehmen unter dem alten Phasenmodell SaaS-Entwicklungskosten aggressiv aktiviert hat, könnte die retrospektive Anwendung zu einer einmaligen Abschreibung bereits aktivierter Vermögenswerte führen, da diese Kosten so umklassifiziert werden, als wären sie von Anfang an als Aufwand erfasst worden. Ein prospektiver Ansatz vermeidet diese Neudarstellung, bedeutet aber, dass Ihre Gewinn- und Verlustrechnung die neue Methodik erst widerspiegelt, wenn nach der Erstanwendung neue Projekte starten. Rechnen Sie beide Varianten durch, bevor Ihr Prüfungsausschuss es tun muss.
Sprechen Sie frühzeitig mit Ihrem Wirtschaftsprüfer, besonders wenn Sie ein SaaS-Unternehmen sind. Angesichts der eigenen Erwartung des FASB, dass die Aktivierung bei SaaS-Entwicklung sinken wird, werden Prüfer die Ermessensentscheidungen zur „wahrscheinlichen Fertigstellung" wahrscheinlich genauer unter die Lupe nehmen, als sie es bei den Phaseneinordnungen unter der alten Regel taten – gerade weil sie subjektiver sind. Ein Unternehmen, das mit einem dokumentierten, zeitnah geführten Rahmenwerk für diese Entscheidung in die Prüfung für 2028 geht, wird ein deutlich einfacheres Gespräch führen als eines, das alles im Nachhinein rekonstruiert.
Saubere Buchführung macht Ermessensentscheidungen leichter verteidigbar
Jede buchhalterische Ermessensentscheidung – und „wahrscheinliche Fertigstellung" ist eindeutig eine solche – ist nur so gut zu verteidigen wie die Unterlagen dahinter. Wenn Ihr Kontenplan F&E-Ausgaben bereits nach Projekt trennt und Ihre Buchungen versioniert und prüfbar sind, statt in verstreuten Spreadsheets zu leben, wird die Anwendung eines Standards wie ASU 2025-06 zu einer Frage des Taggens bestehender Daten, statt die Historie aus Slack-Threads rekonstruieren zu müssen. Die Klartext-Buchhaltung von Beancount.io bietet Ihnen standardmäßig genau dieses transparente, git-versionierte Ledger – jede Buchung nachvollziehbar, jede Änderung überprüfbar, ohne Anbieterbindung. Jetzt kostenlos starten und Bücher führen, die sowohl vor einem Prüfer als auch vor einem Erwerber oder dem nächsten FASB-Update Bestand haben.