ASC 350-40: Aktivieren vs. Aufwenden von intern genutzter Software

ASC 350-40 — das Codification-Thema, das Suchende oft als 350/40 eingeben — ist die FASB-Regel für intern genutzte Software: wann Entwicklungskosten jetzt aufzuwenden sind versus als immaterieller Vermögensgegenstand zu aktivieren und später abzuschreiben. Im alten Drei-Phasen-Modell (das die meisten Anwender bis zum Pflichtdatum von ASU 2025-06 weiterhin anwenden) passt die Antwort in eine Tabelle:

ASU 2025-06 (herausgegeben am 18. September 2025; verpflichtend für Geschäftsjahre, die nach dem 15. Dezember 2027 beginnen) verabschiedet diese Phasenbezeichnungen zugunsten einer Wahrscheinlichkeits-Schwelle und signalisiert, dass mehr Kosten aufzuwenden sein werden. Die folgenden Abschnitte behandeln, was ASC 350-40 umfasst, die Phasendetails, das Update 2025, die Aktivieren/Aufwenden-Checkliste und wie die Entscheidung EBITDA und Bilanz beeinflusst.

Was ASC 350-40 abdeckt​

ASC 350-40 ist der FASB-Standard für intern genutzte Software — Software, die Ihr Unternehmen für den eigenen Betrieb entwickelt oder kauft, anstatt sie als Hauptprodukt an Kunden zu verkaufen. Beispiele:

• Interne CRM-, ERP-, HR- oder Buchhaltungssysteme
• Cloud-Infrastruktur-Tooling und DevOps-Plattformen
• Eine SaaS-Plattform, die Sie für Kunden betreiben (der Kunde nutzt sie als Dienstleistung, nicht als lizenzierte Software, die er installiert)
• Interne Datenpipelines, Dashboards und Analysetools
• Individuelle Workflow- oder Backoffice-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), das andere Regeln hat. Die meisten modernen SaaS-Unternehmen fallen unter ASC 350-40, weil Kunden die Software als gehosteten Dienst nutzen.

Die Kernfrage, die der Standard beantwortet: Wenn Sie Geld für die Softwareentwicklung ausgeben, soll dieser Aufwand sofort aufgewandt oder als immaterieller Vermögensgegenstand aktiviert und über zukünftige Perioden abgeschrieben werden?

Das alte Drei-Phasen-Modell (vor ASU 2025-06)​

Jahrzehntelang verwendete ASC 350-40 einen phasenbasierten Rahmen. Unter der alten Leitlinie, die für die meisten Anwender bis 2027 in Kraft bleibt, gliedert sich die Softwareentwicklung in drei getrennte Phasen.

Phase 1: Vorstudienphase​

Dies ist die Erkundungsphase — Definition der Anforderungen, Bewertung von Technologien, Einholen von Anbieter-Demos und die Entscheidung, ob gebaut, gekauft oder verzichtet wird. Alle Kosten in dieser Phase werden wie angefallen aufgewandt, ähnlich wie Forschungsausgaben. Die Begründung: Bis das Management sich verpflichtet hat, liegt noch kein wahrscheinlicher Vermögensgegenstand vor.

Aktivitäten hier umfassen:

• Konzeptformulierung und Designalternativen
• Anbieter-Demos und Technologiebewertungen
• Kosten-Nutzen-Analysen und Machbarkeitsstudien
• Endgültige Auswahl eines Ansatzes oder Anbieters

Phase 2: Anwendungsentwicklungsphase​

Die Aktivierung beginnt, wenn das Management das Projekt genehmigt, Mittel zusagt und die Fertigstellung wahrscheinlich ist. Diese Phase umfasst das eigentliche Bauen — Programmierung, Testen, Konfiguration, Integration und Installation.

Aktivierungsfähige Kosten in dieser Phase umfassen typischerweise:

• Gehälter und Sozialleistungen für Entwickler, QA-Ingenieure und Projektmanager (nur die Zeit, die direkt der Programmierung, dem Testen und der Konfiguration der Software zuzurechnen ist)
• Externe Beratungshonorare für Entwicklungsarbeiten
• Softwarelizenzen und Tools, die zum Bauen der Anwendung verwendet werden
• Direkte Material- und Dienstleistungskosten, die bei der Entwicklung verbraucht werden
• Zinskosten (in begrenzten Fällen)

Die Aktivierung endet, wenn die Software im Wesentlichen fertiggestellt und für den vorgesehenen Zweck bereit ist — in der Regel, wenn die Tests abgeschlossen sind und das System in Produktion geht, auch wenn die Einführung schrittweise erfolgt.

Phase 3: Nachbetreuungsphase​

Nach dem Go-live fallen laufende Kosten wieder unter die Aufwandsbehandlung. Schulung, Wartung, Fehlerbehebungen und routinemäßiger Support werden aufgewandt. Die Ausnahme: Erweiterungen, die neue Funktionalität hinzufügen (nicht nur bestehende Funktionalität 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 gab das FASB ASU 2025-06 heraus, das ASC 350-40 erheblich modernisiert. Das Update ist für Geschäftsjahre, die nach dem 15. Dezember 2027 beginnen, verpflichtend; eine vorzeitige Anwendung ist erlaubt.

Die Änderung ist strukturell: Das Drei-Phasen-Modell ist weg. Das FASB hat ausdrücklich alle Verweise auf Projektphasen entfernt, weil der alte Rahmen nicht zu modernen agilen und iterativen Entwicklungsmethoden passte, bei denen sich Anforderungen entwickeln und „Phasen" überlappen oder parallel laufen.

Die neue prinzipienbasierte Schwelle​

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

1. Management-Freigabe: Das Management hat das Projekt genehmigt und die Finanzierung zugesagt.
2. Wahrscheinliche Fertigstellung: Es ist wahrscheinlich, dass das Projekt abgeschlossen wird und die Software ihre vorgesehene Funktion erfüllt.

Der zweite Test leistet echte Arbeit. Das FASB hat ein Konzept namens erhebliche Entwicklungsunsicherheit eingeführt, um zu bewerten, ob die Fertigstellung wahrscheinlich ist. Sie müssen bewerten:

• Ob die Software neuartige oder unerprobte Funktionen enthält, die nicht durch Programmierung oder Tests validiert wurden
• Ob Leistungsanforderungen noch unbestimmt oder wesentlichen Überarbeitungen unterworfen sind

Wenn erhebliche Unsicherheit besteht, muss die Aktivierung aufgeschoben werden, bis die Unsicherheit aufgelöst ist. Das FASB hat signalisiert, dass die neue Regel voraussichtlich dazu führt, dass mehr Softwarekosten aufgewandt werden, insbesondere bei SaaS-Unternehmen, bei denen sich Anforderungen kontinuierlich weiterentwickeln.

Was das in der Praxis bedeutet​

Für ein Startup, das etwas wirklich Neues baut — eine KI-Agenten-Plattform, eine neuartige Automatisierungsmaschine — kann die neue Regel mehr Ausgaben früher in die Betriebsausgaben verschieben. Für reife Unternehmen, die klar definierte Systeme erweitern, wird die praktische Auswirkung geringer sein. In jedem Fall bedeutet der Wechsel von einer mechanischen Phasenprüfung zu einer beurteilungsbasierten Schwelle, dass Unternehmen eine klarere Dokumentation von Managemententscheidungen, technischer Machbarkeit und Projektstatus benötigen.

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

Ob Sie das alte Phasenmodell oder den neuen prinzipienbasierten Test anwenden — die Grenze zwischen aktivierbaren und aufzuwendenden Ausgaben ist vom Grundsatz her ähnlich. Hier ist eine Arbeitscheckliste.

Im Allgemeinen aktivierungsfähig​

• Direkte Arbeitskosten für Entwickler, Designer und QA während der Bauphase
• Zugeordnete Lohnnebenkosten und Sozialleistungen für diese Mitarbeiter
• Externe Beratungs- und Auftragnehmerhonorare für Entwicklungsarbeiten
• Software, Tools und Cloud-Infrastrukturkosten, die direkt in der Entwicklung verbraucht werden
• Kosten für die Entwicklung neuer Funktionalität nach dem Launch (Erweiterungen, die die Fähigkeiten wesentlich ausweiten)
• Kosten für die Entwicklung von Konvertierungssoftware (die Software, die Altdaten in das neue System migriert), im Gegensatz zur Datenkonvertierungsaktivität selbst

Im Allgemeinen aufzuwenden​

• Vorstudienforschung, Anbieterauswahl und Machbarkeitsanalyse
• Schulung von Mitarbeitern im neuen System
• Datenbereinigung, Abgleich und Migration von Datensätzen
• Routinemäßige Wartung, Fehlerbehebungen und kleinere Refaktorierungen
• Softwarekosten, die in Zeiten erheblicher Entwicklungsunsicherheit anfallen
• Allgemeine Verwaltungsgemeinkosten, die nicht direkt mit der Entwicklung verbunden sind
• Marketing-, Support- und Post-Launch-Kundenerfolgsaktivitäten

Das Problem der Zeiterfassung​

Die größte praktische Herausforderung ist die Zuordnung der Entwicklungszeit. Ein leitender Ingenieur mit 40 Wochenstunden wird wahrscheinlich nicht zu 100 % aktivierungsfähige Arbeit leisten — er debuggt auch die Produktion, betreut Teammitglieder, nimmt an Stand-ups teil und prüft Pull Requests für Altsysteme. Ohne eine vertretbare Zeiterfassungsmethode (nach Projekt getaggte Engineering-Tickets, Zeiterfassungssoftware oder formelle Zuordnungserhebungen) werden Aktivierungsschätzungen einer Prüfung nicht standhalten.

Die Auswirkung auf den Jahresabschluss​

Denselben Dollar zu aktivieren versus aufzuwenden erzeugt dramatisch unterschiedliche Jahresabschlüsse.

Auswirkung auf die Gewinn- und Verlustrechnung​

Ein aktivierter Aufwand belastet die Gewinn- und Verlustrechnung nicht in der Periode, in der er anfällt. Stattdessen wird er abgeschrieben — typischerweise linear über drei bis fünf Jahre für intern genutzte Software. So könnten 1 Million USD aktivierter Entwicklungsausgaben im Jahr 1 nur 200.000 bis 333.000 USD Abschreibungsaufwand pro Jahr erzeugen und das Betriebsergebnis im Jahr 1 materiell erhöhen.

Deshalb erhält das EBITDA durch Aktivierung einen Schub. Abschreibungen sind per Definition vom EBITDA ausgeschlossen — mehr Entwicklungskosten zu aktivieren verschiebt also Dollars von Betriebsausgaben (die das EBITDA senken) zu Abschreibungen (die das nicht tun). Investoren, die SaaS-Kennzahlen genau prüfen, betrachten oft „EBITDA vor aktivierter F&E" oder Rule-of-40-Berechnungen mit Cash-F&E, um diese Dynamik zu durchschauen.

Auswirkung auf die Bilanz​

Aktivierte Software erscheint als langfristiger immaterieller Vermögensgegenstand, oft als „Aktivierte Softwareentwicklungskosten" oder ähnlich bezeichnet. Das:

• Erhöht das Gesamtvermögen und das Eigenkapital
• Verbessert die Gesamtkapitalrendite (ROA) nur, wenn die Gewinne schneller steigen als die Vermögensbasis
• Schafft einen Vermögensgegenstand, der auf Wertminderung getestet werden muss, wenn das Projekt abgebrochen wird oder sein Wert sinkt

Wenn ein Projekt mitten in der Entwicklung abgebrochen wird, müssen die zuvor aktivierten Kosten abgeschrieben werden — was einen plötzlichen, oft materiellen Verlust erzeugt. Dies ist einer der Gründe, warum die neue ASU 2025-06 so stark auf die Schwelle der wahrscheinlichen Fertigstellung abhebt.

Auswirkung auf die Kapitalflussrechnung​

Aktivierte Entwicklungskosten werden typischerweise als Investitionstätigkeit klassifiziert (nicht als Betriebstätigkeit), was den operativen Cashflow stärker erscheinen lässt. Anspruchsvolle Investoren korrigieren dies beim Vergleich von Unternehmen — aber die Schlagzeilenzahl profitiert trotzdem.

Häufige Fehler, die Unternehmen in Schwierigkeiten bringen​

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

Aktivierung von Kosten vor der Freigabe​

Der klassische Fehler ist die Aktivierung von Entwicklungszeit, die vor der formellen Genehmigung durch das Management anfiel. Ohne eine dokumentierte Freigabe und Mittelzusage hätten diese Kosten aufgewandt werden müssen. Stellen Sie sicher, dass Sie Sitzungsprotokolle, Vorstandsbeschlüsse oder schriftliche Genehmigungen haben, die festlegen, wann sich das Management verpflichtet hat.

Keine projektbezogene Dokumentation​

Wenn ein Regulator oder Prüfer fragt: „Zeigen Sie mir die Projekte, die Sie aktiviert haben", und Sie nur auf allgemeine Entwicklungsausgaben verweisen können, verlieren Sie. Sie benötigen projektbezogene Aufzeichnungen: Umfang, Freigabedatum, Budget, Status und berechnete Zeit.

Behandlung aller Entwicklungszeit als aktivierungsfähig​

Seniorentwickler beheben Fehler, prüfen Code, nehmen an Besprechungen teil und reagieren auf Vorfälle. Nichts davon ist aktivierungsfähig. Unternehmen, die einfach die Lohnsumme des Entwicklungsteams mit einem Prozentsatz multiplizieren, überleben eine Prüfung selten.

Fortsetzung der Aktivierung nach dem Launch​

In dem Moment, in dem die Software für den vorgesehenen Zweck bereit ist, endet die Aktivierung. Fehlerbehebungen, Leistungsoptimierung und kleinere Verbesserungen danach sind Betriebsausgaben. Neu abgegrenzte Funktionen können einen neuen Aktivierungszeitraum beginnen — aber routinemäßige Arbeit nach dem Launch nicht.

Vergessen des Wertminderungstests​

Aktivierte Software ist ein Vermögensgegenstand, und Vermögensgegenstände müssen abgewertet werden, wenn ihr Wert sinkt. Wenn Sie ein Produkt einmotten, eine Funktion einstellen oder das System grundlegend neu schreiben, müssen Sie neu bewerten und den bisherigen Saldo wahrscheinlich abschreiben.

So richten Sie einen vertretbaren Prozess ein​

Wenn Sie entscheiden, dass Aktivierung für Ihr Unternehmen richtig ist, ist der Prozess genauso wichtig wie die Richtlinie.

1. Schreiben Sie eine Software-Aktivierungsrichtlinie. Definieren Sie, welche Projekte qualifizieren, Ihren Freigabeprozess, Ihre Nutzungsdauerschätzung und wie Sie Zeit zuordnen. Holen Sie die Unterschrift Ihres CFO oder Prüfungsausschusses ein.

2. Erfassen Sie Entwicklungszeit auf Projektebene. Dies ist die grundlegende Eingabe. Ob Sie Jira-Labels, benutzerdefinierte Tags in einem Projekt-Tracker oder formelle Zeiterfassungsbögen verwenden — Sie müssen verteidigen können: „Ingenieur X hat Y % seiner Zeit für aktivierungsfähige Arbeit an Projekt Z aufgewendet."

3. Dokumentieren Sie die Management-Freigabe. Jedes aktivierungsfähige Projekt benötigt einen Nachweis der Genehmigung — datierte schriftliche Genehmigung, Vorstandsprotokolle oder eine von der Führung unterzeichnete Projektscharta.

4. Bewerten Sie erhebliche Unsicherheit regelmäßig neu. Nach der neuen Regel müssen Sie überwachen, ob Funktionen noch neuartig oder unerprobt sind und ob sich Anforderungen stabilisieren. Vierteljährliche Überprüfungen mit der Entwicklungsleitung sind angemessen.

5. Erstellen Sie Abschreibungspläne pro Projekt. Jedes aktivierte Projekt beginnt mit der Abschreibung, wenn es zur Nutzung bereit ist, und Sie müssen die Kostenbasis des Vermögensgegenstands, die kumulierten Abschreibungen und die Restlaufzeit verfolgen.

6. Testen Sie auf Wertminderung, wenn sich Projekte ändern. Wann immer Sie aktivierte Arbeit abbrechen, materiell neu schreiben oder einstellen, führen Sie eine Wertminderungsanalyse durch und buchen Sie Abschreibungen nach Bedarf.

Warum das für die Buchhaltung wichtig ist​

Software-Aktivierung ist einer dieser Bereiche, in denen sich Disziplin am Tag eins Jahre später auszahlt. Investoren während einer Series-B-Runde ziehen Ihre Saldenbilanz; Käufer in einem Verkaufsprozess verfolgen Transaktionen bis zu Journaleinträgen zurück; das IRS kann Ihre GAAP-Behandlung mit Ihrer Sektion-174-F&E-Steuerbehandlung vergleichen, die eigene Regeln hat. Wenn Ihre Bücher aktivierte Projekte nicht von Betriebsausgaben trennen, Entwicklungszeiterfassung nicht bestimmten Projekten zuordnen können oder keine sauberen Abschreibungspläne führen, wird jeder Prüfungs- und Due-Diligence-Zyklus schmerzhaft.

Die Lösung ist konzeptionell einfach: Führen Sie eine saubere Kontenstruktur, erfassen Sie Zeit auf Projektebene und dokumentieren Sie die Entscheidungen hinter jedem Aktivierungseintrag. Das von Anfang an zu tun, vermeidet kostspielige Aufräumarbeiten später.

Halten Sie Ihre Software-Buchhaltung prüfungsbereit​

Ob Sie Ihre erste interne Plattform aktivieren oder Abschreibungspläne über Dutzende von Projekten führen — saubere Finanzunterlagen sind die Grundlage. Beancount.io bietet Textbuchhaltung, die Ihnen transparente, versionskontrollierte Bücher gibt — jeder Eintrag nachvollziehbar, jedes Konto prüfbar, jeder Bericht reproduzierbar. Für Softwareunternehmen, die aktivierte Entwicklung über mehrere Projekte verfolgen, ist ein Vorteil, Bücher zu haben, die sich wie Code lesen. Jetzt kostenlos starten und sehen Sie, warum Entwickler und Finanzprofis auf Textbuchhaltung umsteigen.