Aktivierung von Softwarekosten nach ASC 350-40: Ein praktischer Leitfaden zur Entscheidung zwischen Aktivierung und Aufwand

Eine Gartner-Umfrage aus dem Jahr 2024 ergab, dass 63 % der SaaS-Gründer in der Frühphase die Kosten für die Softwareentwicklung falsch klassifizieren. Dieser Fehler kostet sie an zwei Fronten: Investoren bewerten ihre Finanzdaten ab, wenn die Klassifizierungen unsorgfältig wirken, und Wirtschaftsprüfer beanstanden das Problem während der Due Diligence, was Finanzierungsrunden oder Verkaufsprozesse um Monate verzögern kann.

Die Softwarekapitalisierung ist nicht nur eine buchhalterische Formalität. Sie wirkt sich direkt auf das EBITDA, die Bilanz und die Außenwirkung Ihres Unternehmens gegenüber Kreditgebern, Investoren und Käufern aus. Die Regeln unter ASC 350-40 – und eine wichtige Aktualisierung für 2025 – bestimmen, welche Kosten sofort in die Gewinn- und Verlustrechnung einfließen und welche über Jahre verteilt werden.

Dieser Leitfaden erläutert die Anforderungen des Standards, die jüngste Überarbeitung durch ASU 2025-06, welche Kosten Sie aktivieren können, welche nicht und welche Auswirkungen die korrekte Umsetzung auf den Jahresabschluss hat.

Was ASC 350-40 abdeckt

ASC 350-40 ist der FASB-Standard für Software zur internen Nutzung – Software, die Ihr Unternehmen für den eigenen Betrieb erstellt oder kauft, anstatt sie als Primärprodukt an Kunden zu verkaufen. Beispiele hierfür sind:

• Interne CRM-, ERP-, HR- oder Buchhaltungssysteme
• Cloud-Infrastruktur-Tools und DevOps-Plattformen
• Eine SaaS-Plattform, die Sie für Kunden betreiben (der Kunde greift darauf als Dienstleistung zu, nicht als lizenzierte Software, die er installiert)
• Interne Daten-Pipelines, Dashboards und Analysetools
• Individuelle Workflow- oder Back-Office-Automatisierung

Wenn Sie lizenzierte Software verkaufen, die Kunden auf ihren eigenen Rechnern installieren, fällt dies unter ASC 985-20 (Software für den externen Verkauf), wofür andere Regeln gelten. Die meisten modernen SaaS-Unternehmen fallen unter ASC 350-40, da die Kunden die Software als gehosteten Service nutzen.

Die Kernfrage, die der Standard beantwortet: Wenn Sie Geld für die Erstellung von Software ausgeben, sollten diese Kosten sofort als Aufwand verbucht oder als immaterieller Vermögenswert aktiviert und über künftige Perioden abgeschrieben werden?

Das alte Drei-Stufen-Modell (vor ASU 2025-06)

Über Jahrzehnte hinweg verwendete ASC 350-40 ein stufenbasiertes Rahmenwerk. Nach den bisherigen Leitlinien, die für die meisten Berichterstatter bis 2027 in Kraft bleiben, unterliegt die Softwareentwicklung drei diskreten Phasen.

Phase 1: Vorläufige Projektphase (Preliminary Project Stage)

Dies ist die explorative Phase – Anforderungen definieren, Technologien bewerten, Demos von Anbietern einholen und entscheiden, ob man bauen, kaufen oder darauf verzichten möchte. Alle Kosten in dieser Phase werden als Aufwand erfasst, wenn sie anfallen, ähnlich wie Forschungsausgaben. Die Begründung: Bis sich das Management festlegt, verfügen Sie noch nicht über einen wahrscheinlichen Vermögenswert.

Zu den Aktivitäten hier gehören:

• Konzeptionelle Formulierung und Design-Alternativen
• Anbieter-Demos und Technologiebewertungen
• Kosten-Nutzen-Analysen und Machbarkeitsstudien
• Endgültige Auswahl eines Ansatzes oder Anbieters

Phase 2: Anwendungsentwicklungsphase (Application Development Stage)

Die Kapitalisierung beginnt, wenn das Management das Projekt genehmigt, Mittel zusagt und der Abschluss wahrscheinlich ist. Diese Phase umfasst den eigentlichen Aufbau – Kodierung, Testen, Konfigurieren, Integrieren und Installieren.

Zu den aktivierungsfähigen Kosten in dieser Phase gehören in der Regel:

• Gehälter und Sozialleistungen für Entwickler, QA-Ingenieure und Projektmanager (nur die Zeit, die direkt der Kodierung, dem Testen und der Konfiguration der Software zuzuordnen ist)
• Externe Beratungsgebühren für Entwicklungsarbeiten
• Softwarelizenzen und Tools, die zur Erstellung der Anwendung verwendet werden
• Direkte Kosten für Materialien und Dienstleistungen, die bei der Entwicklung verbraucht werden
• Zinskosten (in begrenzten Fällen)

Die Kapitalisierung endet, wenn die Software im Wesentlichen fertiggestellt und für den beabsichtigten Gebrauch bereit ist – im Allgemeinen, wenn die Tests abgeschlossen sind und das System in die Produktion überführt wird, auch wenn der Rollout schrittweise erfolgt.

Phase 3: Phase nach der Implementierung (Post-Implementation Stage)

Nach dem Go-live kehren die laufenden Kosten zur Aufwandsbehandlung zurück. Schulungen, Wartung, Fehlerbehebungen und routinemäßiger Support werden als Aufwand verbucht. Die Ausnahme: Erweiterungen, die neue Funktionalitäten hinzufügen (nicht nur bestehende Funktionen reparieren oder warten), können nach denselben Kriterien wie in Phase 2 aktiviert werden.

Das große Update 2025: ASU 2025-06

Am 18. September 2025 veröffentlichte das FASB die ASU 2025-06, die ASC 350-40 erheblich modernisiert. Die Aktualisierung ist für Geschäftsjahre, die nach dem 15. Dezember 2027 beginnen, verpflichtend, wobei eine vorzeitige Anwendung zulässig ist.

Die Änderung ist strukturell: Das Drei-Stufen-Modell ist hinfällig. Das FASB hat explizit alle Verweise auf Projektphasen entfernt, da das alte Rahmenwerk nicht zu modernen agilen und iterativen Entwicklungspraktiken passte, bei denen sich Anforderungen weiterentwickeln und „Phasen“ sich überschneiden oder parallel laufen.

Die neue prinzipienbasierte Schwelle

Nach dem überarbeiteten Standard aktivieren Sie Softwarekosten nur dann, wenn beide der folgenden Bedingungen erfüllt sind:

1. Genehmigung durch die Geschäftsführung: Die Geschäftsführung hat das Projekt genehmigt und sich zur Finanzierung verpflichtet.
2. Wahrscheinlichkeit des Abschlusses (Probable-to-complete threshold): Es ist wahrscheinlich, dass das Projekt abgeschlossen wird und die Software ihre beabsichtigte Funktion erfüllen wird.

Diese zweite Prüfung ist entscheidend. Das FASB hat das Konzept der erheblichen Entwicklungsunsicherheit eingeführt, um zu beurteilen, ob der Abschluss wahrscheinlich ist. Sie müssen bewerten:

• Ob die Software neuartige oder unbewiesene Funktionen enthält, die noch nicht durch Kodierung oder Tests validiert wurden
• Ob Leistungsanforderungen noch unbestimmt sind oder einer wesentlichen Überarbeitung unterliegen

Besteht eine erhebliche Unsicherheit, muss die Kapitalisierung aufgeschoben werden, bis die Unsicherheit geklärt ist. Das FASB hat signalisiert, dass es erwartet, dass die neue Regel dazu führen wird, dass mehr Softwarekosten als Aufwand verbucht werden, insbesondere bei SaaS-Unternehmen, deren Anforderungen kontinuierlich iteriert werden.

Was das in der Praxis bedeutet

Für ein Startup, das etwas wirklich Neues entwickelt – eine KI-Agenten-Plattform, eine neuartige Automatisierungs-Engine –, könnte die neue Regel dazu führen, dass mehr Ausgaben früher in die Betriebskosten (OpEx) fließen. Für etablierte Unternehmen, die wohldefinierte Systeme verbessern, wird der praktische Effekt geringer sein. So oder so: Der Übergang von einer mechanischen Phasenprüfung hin zu einem ermessensbasierten Schwellenwert bedeutet, dass Unternehmen Managemententscheidungen, technische Machbarkeit und Projektstatus klarer dokumentieren müssen.

Was Sie aktivieren können und was nicht: Eine praktische Checkliste

Unabhängig davon, ob Sie das herkömmliche Phasenmodell oder die neue prinzipienbasierte Prüfung anwenden, ist die Grenze zwischen aktivierungsfähigen und als Aufwand zu erfassenden Ausgaben vom Grundsatz her ähnlich. Hier ist eine Arbeitscheckliste.

In der Regel aktivierungsfähig

• Direkte Personalkosten für Entwickler, Designer und QA während der Build-Phase
• Zugeordnete Lohnnebenkosten und Sozialleistungen für diese Mitarbeiter
• Externe Beratungs- und Honorarkosten für Entwicklungsarbeiten
• Software-, Tool- und Cloud-Infrastrukturkosten, die direkt in der Entwicklung verbraucht werden
• Kosten für die Entwicklung neuer Funktionen nach dem Launch (Erweiterungen, die die Fähigkeiten wesentlich ausbauen)
• Kosten für die Entwicklung von Konvertierungssoftware (Software, die alte Daten in neue migriert), im Gegensatz zur eigentlichen Datenkonvertierung

In der Regel als Aufwand zu erfassen

• Vorläufige Forschung, Anbieterauswahl und Machbarkeitsanalyse
• Schulung von Mitarbeitern für das neue System
• Datenbereinigung, Abstimmung und Migration von Datensätzen
• Routinemäßige Wartung, Fehlerbehebungen und geringfügiges Refactoring
• Softwarekosten, die in Zeiten erheblicher Entwicklungsunsicherheit anfallen
• Allgemeine Verwaltungsgemeinkosten, die nicht direkt mit der Entwicklung zusammenhängen
• Marketing, Support und Customer-Success-Aktivitäten nach dem Launch

Das Problem der Zeiterfassung

Die größte praktische Herausforderung ist die Zuweisung der Entwicklungszeit. Ein Senior Engineer, der 40 Stunden pro Woche arbeitet, wird kaum zu 100 % aktivierungsfähige Arbeit leisten – er debuggt auch die Produktion, mentort Teamkollegen, nimmt an Standups teil und prüft Pull-Requests für Altsysteme. Ohne eine belastbare Zeiterfassungsmethode (nach Projekt getaggte Tickets, Zeiterfassungssoftware oder formelle Zuweisungsumfragen) werden Aktivierungsschätzungen einer Prüfung durch Wirtschaftsprüfer nicht standhalten.

Die Auswirkungen auf den Jahresabschluss

Derselbe Dollar führt zu dramatisch unterschiedlichen Jahresabschlüssen, je nachdem, ob er aktiviert oder als Aufwand erfasst wird.

Auswirkungen auf die Gewinn- und Verlustrechnung (GuV)

Ein aktivierter Betrag wirkt sich in der Periode, in der er ausgegeben wurde, nicht auf die GuV aus. Stattdessen wird er abgeschrieben – bei Software für den Eigenbedarf in der Regel linear über drei bis fünf Jahre. So könnten 1 Mio. $an aktivierten Entwicklungskosten im Jahr 1 nur 200.000 bis 333.000$ Abschreibungsaufwand pro Jahr verursachen, wodurch das Betriebsergebnis im Jahr 1 deutlich höher ausfällt.

Deshalb wird das EBITDA durch die Aktivierung begünstigt. Abschreibungen sind per Definition vom EBITDA ausgeschlossen – die Aktivierung von mehr Entwicklungskosten verschiebt also Beträge vom Betriebsaufwand (der das EBITDA mindert) zur Abschreibung (die dies nicht tut). Investoren, die SaaS-Metriken genau unter die Lupe nehmen, schauen oft auf das „EBITDA vor aktivierter F&E“ oder Rule-of-40-Berechnungen auf Basis der Cash-F&E-Kosten, um diese Dynamik zu durchschauen.

Auswirkungen auf die Bilanz

Aktivierte Software erscheint als langfristiger immaterieller Vermögenswert, oft als „Aktivierte Softwareentwicklungskosten“ oder ähnlich bezeichnet. Dies:

• Erhöht die Bilanzsumme und das Eigenkapital
• Verbessert die Gesamtkapitalrentabilität (ROA) nur dann, wenn die Gewinne schneller steigen als die Vermögensbasis
• Schafft einen Vermögenswert, der auf Wertminderung (Impairment) geprüft werden muss, wenn das Projekt aufgegeben wird oder sein Wert sinkt

Wird ein Projekt während der Entwicklung abgebrochen, müssen die zuvor aktivierten Kosten abgeschrieben werden – was zu einem plötzlichen, oft erheblichen Verlust führt. Dies ist ein Grund, warum der neue ASU 2025-06 den Schwellenwert für die „Wahrscheinlichkeit des Abschlusses“ so stark betont.

Auswirkungen auf die Kapitalflussrechnung

Aktivierte Entwicklungskosten werden in der Regel als Investitionstätigkeit (nicht als laufende Geschäftstätigkeit) eingestuft, wodurch der operative Cashflow stärker aussieht. Erfahrene Investoren korrigieren dies beim Vergleich von Unternehmen – die Schlagzeilenzahl profitiert jedoch dennoch.

Häufige Fehler, die Unternehmen in Schwierigkeiten bringen

Wirtschaftsprüfer und Käufer sehen immer wieder dieselben Fehler.

Aktivierung von Kosten vor der Projektgenehmigung

Der klassische Fehler besteht darin, Entwicklungszeit zu aktivieren, die aufgewendet wurde, bevor das Management das Projekt formell genehmigt hat. Ohne eine dokumentierte Genehmigung und Finanzierungszusage hätten diese Kosten als Aufwand verbucht werden müssen. Stellen Sie sicher, dass Sie Sitzungsprotokolle, Vorstandsbeschlüsse oder schriftliche Freigaben haben, die belegen, wann das Management die Verpflichtung eingegangen ist.

Keine Dokumentation auf Projektebene

Wenn eine Aufsichtsbehörde oder ein Wirtschaftsprüfer fragt: „Zeigen Sie mir die Projekte, die Sie aktiviert haben“, und Sie können nur auf allgemeine Entwicklungsausgaben verweisen, werden Sie verlieren. Sie benötigen projektbezogene Aufzeichnungen: Umfang, Genehmigungsdatum, Budget, Status und abgerechnete Zeit.

Behandlung der gesamten Entwicklungszeit als aktivierungsfähig

Senior Engineers beheben Fehler, prüfen Code, nehmen an Meetings teil und reagieren auf Vorfälle. Nichts davon ist aktivierungsfähig. Unternehmen, die das Gehalt des Entwicklerteams einfach mit einem Prozentsatz multiplizieren, überstehen selten eine Prüfung.

Weiterführung der Aktivierung nach dem Launch

Sobald die Software für ihren beabsichtigten Einsatz bereit ist, endet die Aktivierung. Fehlerbehebungen, Leistungsoptimierungen und geringfügige Verbesserungen nach diesem Zeitpunkt gelten als Betriebsausgaben. Neue, separat abgegrenzte Funktionen können eine neue Aktivierungsperiode einleiten – routinemäßige Arbeiten nach dem Launch hingegen nicht.

Vernachlässigung von Werthaltigkeitsprüfungen

Aktivierte Software ist ein Vermögenswert, und Vermögenswerte müssen wertgemindert werden, wenn ihr Wert sinkt. Wenn Sie ein Produkt stilllegen, eine Funktion einstellen oder das System grundlegend umschreiben, müssen Sie den Buchwert neu bewerten und den bisherigen Saldo wahrscheinlich abschreiben.

So richten Sie einen belastbaren Prozess ein

Wenn Sie entscheiden, dass die Aktivierung für Ihr Unternehmen der richtige Weg ist, ist der Prozess ebenso wichtig wie die Richtlinie selbst.

1. Erstellen Sie eine Richtlinie zur Softwareaktivierung. Definieren Sie, welche Projekte qualifiziert sind, wie Ihr Genehmigungsprozess aussieht, wie hoch die geschätzte Nutzungsdauer ist und wie Sie Zeitressourcen zuweisen. Lassen Sie diese von Ihrem CFO oder dem Prüfungsausschuss absegnen.

2. Erfassen Sie die Entwicklungszeit auf Projektebene. Dies ist die grundlegende Datenbasis. Unabhängig davon, ob Sie Jira-Labels, benutzerdefinierte Tags in einem Projekt-Tracker oder formale Zeiterfassungsbögen verwenden: Sie müssen belegen können, dass „Entwickler X einen Anteil von Y % seiner Zeit für aktivierungsfähige Arbeiten an Projekt Z aufgewendet hat“.

3. Dokumentieren Sie die Genehmigung durch das Management. Für jedes zu aktivierende Projekt ist ein Nachweis der Autorisierung erforderlich – ein datiertes schriftliches Einverständnis, Protokolle von Vorstandssitzungen oder eine von der Führungsebene unterzeichnete Projektcharta.

4. Bewerten Sie wesentliche Unsicherheiten regelmäßig neu. Nach der neuen Regelung müssen Sie überwachen, ob Funktionen noch neuartig oder unbewiesen sind und ob sich die Anforderungen stabilisieren. Quartalsweise Überprüfungen mit der technischen Leitung sind hierbei angemessen.

5. Erstellen Sie Abschreibungspläne pro Projekt. Jedes aktivierte Projekt beginnt mit der Abschreibung, sobald es einsatzbereit ist. Sie müssen die Anschaffungskosten des Vermögenswerts, die kumulierten Abschreibungen und die Restnutzungsdauer genau verfolgen.

6. Führen Sie Werthaltigkeitsprüfungen bei Projektänderungen durch. Wann immer Sie aktivierte Arbeiten einstellen, wesentlich umschreiben oder auslaufen lassen, müssen Sie eine Werthaltigkeitsprüfung (Impairment-Test) durchführen und bei Bedarf Abschreibungen buchen.

Warum dies für die Buchhaltung wichtig ist

Die Aktivierung von Software ist einer dieser Bereiche, in denen sich Disziplin in der Buchhaltung vom ersten Tag an Jahre später auszahlt. Investoren während einer Series-B-Finanzierungsrunde werden Ihre Summen- und Saldenliste prüfen; Käufer in einem Verkaufsprozess werden Transaktionen bis zu den Journalbuchungen zurückverfolgen; die Steuerbehörden vergleichen möglicherweise Ihre GAAP-Behandlung mit Ihrer R&D-Steuerbehandlung nach Section 174, für die eigene Regeln gelten. Wenn Ihre Bücher aktivierte Projekte nicht von Betriebsausgaben trennen, die Zeitanteile der Entwickler nicht bestimmten Projekten zuordnen können oder keine sauberen Abschreibungspläne führen, wird jeder Audit- und Due-Diligence-Zyklus schmerzhaft.

Die Lösung ist konzeptionell einfach: Pflegen Sie eine saubere Kontenstruktur, erfassen Sie die Zeit auf Projektebene und dokumentieren Sie die Entscheidungen hinter jeder Aktivierungsbuchung. Wer dies von Anfang an tut, vermeidet später kostspielige Bereinigungen.

Halten Sie Ihre Software-Buchhaltung prüfungssicher

Ganz gleich, ob Sie Ihre erste interne Plattform aktivieren oder Abschreibungspläne für Dutzende von Projekten verwalten – saubere Finanzdaten sind das Fundament. Beancount.io bietet Plain-Text-Buchhaltung, die Ihnen transparente, versionskontrollierte Bücher ermöglicht – jede Buchung rückverfolgbar, jedes Konto prüfbar, jeder Bericht reproduzierbar. Für Softwareunternehmen, die aktivierte Entwicklungskosten über mehrere Projekte hinweg verfolgen, ist eine Buchführung, die sich wie Code liest, ein entscheidender Vorteil. Starten Sie kostenlos und erfahren Sie, warum Entwickler und Finanzexperten auf Plain-Text-Buchhaltung umsteigen.