Softwareentwicklungskosten: Wie Sie sie 2026 aktivieren oder als Aufwand erfassen

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Softwareentwicklungskosten sind die Ausgaben für Personal, Dienstleister, Werkzeuge und Infrastruktur, um Software zu konzipieren, zu entwickeln und zu testen – und 2026 lautet die schwierigere Frage nicht mehr nur, wie hoch sie sind, sondern wo sie im Jahresabschluss landen. Dieselben 500.000 $ können das operative Ergebnis eines Jahres belasten oder als Vermögenswert über drei bis fünf Jahre verteilt werden – je nachdem, wofür, wann und nach welchem Rechnungslegungsstandard das Geld ausgegeben wurde.

Die Bilanzierung von Softwareentwicklungskosten wird meist zu einem vorhersehbaren Zeitpunkt dringend: bei der ersten Abschlussprüfung, einer Finanzierungsrunde oder der ersten großen Rechnung eines externen Teams. Unternehmen, die Product-Engineering-Leistungen für Softwareunternehmen einkaufen, stoßen oft dann auf das Thema, wenn der Abschlussprüfer verlangt, die Monatsrechnungen des Dienstleisters in Forschung, neue Funktionalität und Wartung aufzuteilen – und bei Vertragsabschluss niemand diese Aufteilung eingeplant hat.

Zwei Änderungen machen 2026 zu einem guten Jahr, Ihre Bilanzierungsrichtlinie zu überprüfen. In den USA schreibt das ASU 2025-06 des FASB die Regeln für intern genutzte Software zum ersten Mal seit Jahrzehnten neu, und der One Big Beautiful Bill Act hat mit der neuen Section 174A den sofortigen Steuerabzug inländischer Forschungs- und Versuchsaufwendungen wiederhergestellt. Dieser Leitfaden erklärt beides sowie die IFRS-Regeln, nach denen viele europäische Unternehmen bilanzieren. Er dient der allgemeinen Information und ist keine Steuer- oder Prüfungsberatung: Stimmen Sie Ihre Richtlinie mit Ihrem Abschlussprüfer und Steuerberater ab.

Was sind Softwareentwicklungskosten?

Softwareentwicklungskosten sind alle Kosten, die der Erstellung von Software direkt zuzurechnen sind: eigenes Personal, Honorare von Dienstleistern und Agenturen, Lizenzen und Werkzeuge, Cloud-Umgebungen und Datenarbeit während der Entwicklung. Indirekte Kosten wie Büromiete oder allgemeine Verwaltung gehören zu den Kosten des laufenden Geschäfts, dürfen aber nach den Rechnungslegungsstandards selten in den Wert der Software einfließen.

Für die Bilanzierung hilft es, Kosten zuerst nach Art und dann nach Tätigkeit zu ordnen. Die Art zeigt, wofür bezahlt wurde; die Tätigkeit, die im nächsten Abschnitt behandelt wird, entscheidet über die Aktivierung. Die Tabelle fasst die üblichen Bestandteile und ihre typische Behandlung nach US GAAP für intern genutzte Software zusammen.

Dieser Artikel behandelt, wie diese Kosten erfasst werden, nicht, wie hoch sie sein sollten. Preisspannen nach Projektart, Teamgröße und Region finden Sie in unseren Benchmarks für Softwareentwicklungskosten 2026.

Sollten Softwareentwicklungskosten aktiviert oder als Aufwand erfasst werden?

Softwareentwicklungskosten werden aktiviert, wenn sie Software mit künftigem Nutzen schaffen oder um Funktionalität erweitern und die maßgebliche Bilanzierungsschwelle erreicht ist; alles andere ist sofort Aufwand. In der Praxis landen Forschung, Planung, Wartung, Schulung und Gemeinkosten in der Gewinn- und Verlustrechnung, während Design, Programmierung und Tests neuer Funktionalität zum Vermögenswert werden können.

Entschieden wird je Tätigkeit, nicht je Rechnung. Ein einziger Sprint kann aktivierungsfähige Arbeit an einem neuen Modul, Fehlerbehebungen an einem alten Modul (Aufwand) und Forschungs-Spikes (Aufwand) enthalten. Die Tabelle zeigt das typische Ergebnis für intern genutzte Software nach US GAAP; IFRS kommt bei den meisten Zeilen zu ähnlichen Ergebnissen, aber über einen anderen Test, der weiter unten erklärt wird.

Der entscheidende Test für Arbeiten nach dem Start ist leicht formuliert und schwer anzuwenden: Erhält die Software eine Fähigkeit, die sie vorher nicht hatte? Ein neues Berichtsmodul besteht den Test; Refactoring für Performance oder Fehlerbehebung in der Regel nicht. Halten Sie die Regel schriftlich fest, ergänzen Sie Beispiele und wenden Sie sie jeden Monat gleich an.

Wie funktioniert ASC 350-40 heute für intern genutzte Software?

Nach dem geltenden ASC 350-40 folgt intern genutzte Software einem Dreiphasenmodell: Kosten der Vorprojektphase sind Aufwand, Kosten der Anwendungsentwicklungsphase werden aktiviert, und Kosten der Phase nach der Implementierung und des Betriebs sind wieder Aufwand. Bis ein Unternehmen ASU 2025-06 anwendet, bleibt dies die Regel für Bilanzierende nach US GAAP.

Intern genutzte Software ist Software, die ausschließlich für die internen Bedürfnisse des Unternehmens erworben, entwickelt oder angepasst wird, ohne substanziellen Plan zur externen Vermarktung. Dazu gehören ERP-Anpassungen, interne Werkzeuge, Kundenportale und – besonders wichtig – die meisten SaaS-Plattformen, wie weiter unten erläutert.

Die drei Phasen

• Vorprojektphase — konzeptionelle Ausarbeitung, Bewertung von Alternativen, Festlegung der benötigten Technologie und endgültige Auswahl. Alle Kosten sind Aufwand.
• Anwendungsentwicklungsphase — Design des gewählten Wegs, Programmierung, Installation von Hardware und Tests einschließlich Parallelbetrieb. Die Aktivierung beginnt, wenn die Vorprojektphase abgeschlossen ist, das Management das Projekt genehmigt und die Finanzierung zugesagt hat und die Fertigstellung sowie die bestimmungsgemäße Nutzung wahrscheinlich sind.
• Phase nach der Implementierung und Betrieb — Schulung und Wartung. Die Aktivierung endet, wenn die Software im Wesentlichen fertiggestellt und für den vorgesehenen Einsatz bereit ist, in der Regel nach Abschluss aller wesentlichen Tests.

Was Sie aktivieren dürfen und was nicht

Aktivierungsfähig sind externe direkte Kosten für Material und Dienstleistungen, die bei der Entwicklung verbraucht werden, Personal- und Personalnebenkosten der unmittelbar am Projekt beteiligten Mitarbeiter im Umfang ihrer Projektzeit sowie Fremdkapitalzinsen während der Entwicklung nach ASC 835-20. Allgemeine Verwaltungskosten, Gemeinkosten, Schulung und Datenkonvertierung sind Aufwand, selbst wenn sie in der Anwendungsentwicklungsphase anfallen.

Cloud-Computing-Vereinbarungen: Implementierungskosten eingekaufter SaaS

Ist Ihr Unternehmen Kunde eines gehosteten SaaS-Produkts, folgen die Implementierungskosten nach ASU 2018-15 denselben Phasenregeln des ASC 350-40, obwohl Sie die Software nie besitzen. Kosten für Konfiguration, Integration und Tests der gehosteten Lösung in der Anwendungsentwicklungsphase werden aktiviert, über die Laufzeit der Hosting-Vereinbarung einschließlich hinreichend sicherer Verlängerungen abgeschrieben und in derselben GuV-Position ausgewiesen wie die Abonnementgebühren. Die Abonnementgebühr selbst bleibt laufender Aufwand.

Für Unternehmen mit mehreren Systemen gelten diese Regeln für jedes Integrationsprojekt. Unsere Teams für individuelle Softwareentwicklung dokumentieren Konfigurations- und Integrationsarbeit genau aus diesem Grund getrennt vom Support.

Was ändert ASU 2025-06?

ASU 2025-06, vom FASB am 18. September 2025 veröffentlicht, streicht die drei Projektphasen aus ASC 350-40 und ersetzt sie durch eine einzige Ansatzschwelle: Aktiviert wird, sobald das Management das Projekt genehmigt und die Finanzierung zugesagt hat und es wahrscheinlich ist, dass das Projekt fertiggestellt und die Software für ihre vorgesehene Funktion genutzt wird. Beratungsgesellschaften wie RSM bezeichnen dies als größte Überarbeitung der Bilanzierung intern genutzter Software seit 1998, maßgeblich angestoßen durch agile Entwicklung.

Das Phasenmodell ging von einem linearen Wasserfallprojekt aus, in dem die Planung endete, bevor die Programmierung begann. Agile Teams planen, entwerfen, entwickeln und testen in jedem Sprint, sodass sich die Phasen nie sauber auf ihre Arbeit abbilden ließen. Der neue Standard gibt diese Annahme auf und stellt eine praktischere Frage nach der Unsicherheit.

Die Schwelle der wahrscheinlichen Fertigstellung und erhebliche Entwicklungsunsicherheit

Bei der Beurteilung, ob die Fertigstellung wahrscheinlich ist, muss ein Unternehmen prüfen, ob erhebliche Entwicklungsunsicherheit besteht. Der Standard nennt zwei Indikatoren:

• Die Software hat neuartige, einzigartige oder unerprobte Funktionen oder Merkmale, und die Unsicherheit darüber ist noch nicht durch Programmierung und Tests ausgeräumt;
• die wesentlichen Leistungsanforderungen sind noch nicht festgelegt oder werden noch erheblich überarbeitet.

Solange einer der beiden Indikatoren vorliegt, ist die Schwelle nicht erreicht und die Kosten sind Aufwand. Das kann die Aktivierung bei experimentellen Produkten – etwa einer neuen Machine-Learning-Funktion – verzögern, während sie bei Routineprojekten wie einem Kundenportal auf bewährter Technologie früher und vorhersehbarer beginnt.

Altes Dreiphasenmodell im Vergleich zu ASU 2025-06

Erstanwendung und Übergangsmethoden

ASU 2025-06 gilt für Geschäftsjahre, die nach dem 15. Dezember 2027 beginnen, und für die Zwischenperioden darin – für Unternehmen mit kalendergleichem Geschäftsjahr also ab 2028. Eine vorzeitige Anwendung ist zu Beginn eines Geschäftsjahres zulässig. Unternehmen können auf drei Wegen umstellen:

• Prospektiv — die neuen Regeln gelten für Kosten, die nach der Umstellung anfallen;
• Modifizierter Übergang — Anwendung auf Projekte, die bei der Umstellung noch laufen, mit einer kumulierten Anpassung der Gewinnrücklagen zum Periodenbeginn;
• Retrospektiv — Anpassung der dargestellten Vorperioden.

Sollten Sie 2026 vorzeitig umstellen?

Eine vorzeitige Anwendung lohnt sich für Unternehmen, deren Entwicklung überwiegend agil und routiniert ist, und weniger für Unternehmen mit viel experimenteller Arbeit oder Investoren, die Perioden genau vergleichen. Wägen Sie diese Punkte mit Ihrem Abschlussprüfer ab:

• Dafür: weniger manuelle Zuordnung von Sprints zu Phasen und weniger Ermessensentscheidungen, die jedes Quartal zu dokumentieren sind.
• Dafür: eine Richtlinie, die der tatsächlichen Arbeitsweise agiler und Produktteams entspricht und sich neuen Prüfern und Investoren leichter erklären lässt.
• Dafür: Kosten der Website-Entwicklung wandern in dasselbe Modell, sodass eine Richtlinie Produkt und Marketingseite abdeckt.
• Dagegen: Richtlinien, Kontrollen und Systemkonfiguration müssen vor Beginn des Umstellungsjahres neu geschrieben werden.
• Dagegen: Projekte mit neuartigen Funktionen werden womöglich später aktiviert als heute, was Vermögen und operatives Ergebnis kurzfristig senkt.
• Dagegen: Bei prospektiver Umstellung leidet die Vergleichbarkeit mit Vorperioden, eine vollständige Anpassung kostet Aufwand.
• In jedem Fall: Die neuen Angaben nach dem Muster von ASC 360-10 brauchen Daten – Anlagenspiegel, Nutzungsdauern und Wertminderungen –, die viele Unternehmen heute nicht erheben.

Wie bilanzieren Sie Software, die Sie verkaufen oder lizenzieren (ASC 985-20)?

Software, die verkauft, vermietet oder anderweitig vermarktet wird, folgt ASC 985-20: Alle Kosten sind Forschungs- und Entwicklungsaufwand, bis die technologische Machbarkeit nachgewiesen ist, und nur Kosten danach und vor der allgemeinen Markteinführung werden aktiviert. Da die Machbarkeit oft spät im Projekt erreicht wird, aktivieren die meisten Unternehmen nach ASC 985-20 nur sehr wenig.

Die technologische Machbarkeit ist nachgewiesen, wenn das Unternehmen ein detailliertes Programmdesign oder, falls es keines gibt, ein funktionsfähiges Modell des Produkts fertiggestellt hat. Teams, die kein detailliertes Programmdesign vorab erstellen – der Normalfall in agiler Entwicklung –, erreichen ein funktionsfähiges Modell kurz vor Ende der Entwicklung, sodass sich das Aktivierungsfenster auf wenige Wochen abschließender Tests und die Erstellung der Produkt-Master beschränken kann.

Aktivierte Kosten werden produktweise abgeschrieben, und zwar mit dem höheren von zwei Beträgen: dem Verhältnis der aktuellen Bruttoerlöse zu den gesamten aktuellen und erwarteten künftigen Erlösen oder der linearen Abschreibung über die verbleibende geschätzte wirtschaftliche Nutzungsdauer. Zu jedem Bilanzstichtag wird der Restbuchwert mit dem Nettoveräußerungswert verglichen und bei Überschreitung abgeschrieben. ASU 2025-06 ändert daran nichts.

Wo stehen SaaS-Produkte?

Die meisten SaaS-Produkte fallen als intern genutzte Software unter ASC 350-40, nicht unter ASC 985-20. Wenn Kunden die Software nur über eine Hosting-Vereinbarung nutzen und kein vertragliches Recht haben, sie in Besitz zu nehmen und selbst zu betreiben, nutzt der Anbieter die Software intern, um eine Dienstleistung zu erbringen. Gründer gehen oft davon aus, dass „wir verkaufen Software“ ASC 985-20 bedeutet, und erfassen dadurch Entwicklung als Aufwand, die hätte aktiviert werden können – oder kommen zu uneinheitlichen Richtlinien, sobald eine On-Premise-Version hinzukommt. Wenn Sie eine SaaS-Plattform planen oder skalieren, behandelt unser Leitfaden zur SaaS-Softwareentwicklung die Produktseite derselben Entscheidungen.

Wie werden Softwareentwicklungskosten nach IFRS (IAS 38) behandelt?

Nach IFRS teilt IAS 38 Immaterielle Vermögenswerte jedes interne Projekt in eine Forschungsphase, die stets Aufwand ist, und eine Entwicklungsphase, die aktiviert werden muss, sobald das Unternehmen alle sechs Kriterien aus Paragraf 57 nachweisen kann. Anders als US GAAP verwendet IFRS dasselbe Modell, unabhängig davon, ob die Software intern genutzt oder verkauft wird.

Nach den sechs Kriterien in IAS 38 muss das Unternehmen nachweisen:

1. die technische Machbarkeit der Fertigstellung der Software, damit sie zur Nutzung oder zum Verkauf zur Verfügung steht;
2. die Absicht, die Software fertigzustellen und zu nutzen oder zu verkaufen;
3. die Fähigkeit, die Software zu nutzen oder zu verkaufen;
4. wie die Software voraussichtlich künftigen wirtschaftlichen Nutzen erzeugt, etwa durch einen Markt dafür oder ihren internen Nutzen;
5. die Verfügbarkeit angemessener technischer, finanzieller und sonstiger Ressourcen, um die Entwicklung abzuschließen und die Software zu nutzen oder zu verkaufen;
6. die Fähigkeit, die der Software während der Entwicklung zurechenbaren Ausgaben verlässlich zu bewerten.

Sind alle sechs erfüllt, ist die Aktivierung Pflicht, kein Wahlrecht. Kann ein Unternehmen Forschungs- und Entwicklungsphase nicht unterscheiden, behandelt IAS 38 das gesamte Projekt als Forschung und erfasst es als Aufwand. Aktivierte Software wird über ihre Nutzungsdauer abgeschrieben und nach IAS 36 auf Wertminderung geprüft; noch nicht nutzungsbereite Software ist mindestens jährlich zu testen. Das Neubewertungsmodell ist nur bei einem aktiven Markt zulässig, den es für individuelle Software praktisch nie gibt.

Bei SaaS, die ein Unternehmen einkauft statt selbst zu entwickeln, weicht IFRS von ASU 2018-15 ab. Nach den Agenda-Entscheidungen des IFRS Interpretations Committee von 2019 und 2021 sind Konfigurations- und Anpassungskosten eines Cloud-Dienstes, den der Kunde nicht beherrscht, in der Regel Aufwand, sofern sie keinen separaten, vom Kunden beherrschten Vermögenswert wie individuellen Code schaffen.

US GAAP und IFRS im Überblick

Konzerne, die nach beiden Rahmenwerken berichten – etwa eine europäische Muttergesellschaft mit einer US-Tochter –, sollten Kosten so detailliert erfassen, wie es das strengere Rahmenwerk verlangt, und beide Ergebnisse aus denselben Daten ableiten.

Wie sollten Sie aktivierte Software abschreiben?

Die Abschreibung intern genutzter Software beginnt mit ihrer Einsatzbereitschaft und folgt meist der linearen Methode über die geschätzte Nutzungsdauer. Viele Unternehmen setzen drei bis fünf Jahre an, doch das ist gängige Praxis und keine Vorschrift: Der Zeitraum sollte widerspiegeln, wie lange die Software realistisch Nutzen stiftet, bevor sie ersetzt oder neu entwickelt wird.

• Beginn — wenn die Software oder ein separat nutzbares Modul im Wesentlichen fertig und einsatzbereit ist, auch wenn sie noch nicht für alle Nutzer ausgerollt wurde.
• Methode — linear, sofern kein anderes Muster den Nutzenverbrauch besser abbildet; Software nach ASC 985-20 verwendet den höheren Betrag aus umsatzbasierter und linearer Abschreibung.
• Nutzungsdauer — berücksichtigen Sie Ihre Release-Historie, das Tempo des technologischen Wandels und etwaige Pläne zur Ablösung der Plattform.
• Überprüfung — überprüfen Sie Nutzungsdauern mindestens jährlich und passen Sie sie bei geänderten Erwartungen prospektiv an.
• Auslöser für Wertminderung — Projektabbruch, eine wesentliche Änderung der Nutzung, Kostenüberschreitungen weit über Plan oder die Entscheidung, die Software vorzeitig zu ersetzen.
• Abgebrochene Projekte — ist die Fertigstellung nicht mehr wahrscheinlich, beenden Sie die Aktivierung und schreiben Sie den Vermögenswert ab, statt ihn weiterzuführen.

Wie werden Softwareentwicklungskosten 2026 steuerlich behandelt (Section 174A)?

Für die US-Bundessteuer hat der One Big Beautiful Bill Act vom Juli 2025 die Section 174A eingeführt. Sie erlaubt Unternehmen, inländische Forschungs- und Versuchsaufwendungen – ausdrücklich einschließlich Softwareentwicklung – für Steuerjahre, die nach dem 31. Dezember 2024 beginnen, im Jahr ihres Anfalls abzuziehen. Forschung außerhalb der USA muss nach Section 174 weiterhin aktiviert und über 15 Jahre abgeschrieben werden.

Die Auslandsregel betrifft alle, die Software mit einem Offshore- oder Nearshore-Team entwickeln. In den USA erbrachte Entwicklung ist jetzt sofort abzugsfähig, dieselbe Arbeit im Ausland wird über 15 Jahre verteilt. Dieser Unterschied gehört in jeden Gesamtkostenvergleich zwischen Inhouse-, Onshore- und Offshore-Entwicklung.

• Kleine Unternehmen mit durchschnittlichen jährlichen Bruttoeinnahmen von höchstens 31 Mio. $ können den inländischen Sofortabzug rückwirkend für Steuerjahre ab dem 31. Dezember 2021 anwenden, indem sie ihre Erklärungen für 2022–2024 berichtigen.
• Andere Steuerpflichtige können den verbleibenden, noch nicht abgeschriebenen inländischen Section-174-Betrag aus 2022–2024 vollständig 2025 abziehen oder gleichmäßig auf 2025 und 2026 verteilen.
• Verfahren — der IRS hat die Wahlrechte und Methodenwechsel in Rev. Proc. 2025-28 geregelt.
• Handels- und Steuerbilanz — Steuer und Rechnungslegung laufen nicht mehr parallel: Ein aktivierter Vermögenswert in den Büchern bei sofortigem Steuerabzug erzeugt eine passive latente Steuer, die verfolgt werden muss.

Section 174A regelt den Abzug; die Forschungszulage nach Section 41 ist ein separater Vorteil mit eigenem vierteiligen Test. Unser Leitfaden zur F&E-Steuergutschrift für Softwareentwicklung erklärt Voraussetzungen und Dokumentation im Detail.

Wie erfassen Sie aktivierungsfähige Kosten in einem agilen Team?

Um aktivierungsfähige Kosten in einem agilen Team zu erfassen, kennzeichnen Sie Arbeit auf Epic- und Ticketebene als neue Funktionalität, Wartung oder Forschung, erfassen Zeit je Person und Epic und verlangen von externen Dienstleistern Rechnungen in derselben Struktur. So wird die Aktivierung zu einem Monatsbericht statt zu einer Rekonstruktion zum Quartalsende.

1. Schreiben Sie eine Aktivierungsrichtlinie. Legen Sie fest, welche Tätigkeiten aktiviert werden, welche Schwelle Sie anwenden (phasenbasiert oder ASU 2025-06), eine Mindestprojektgröße, Standard-Nutzungsdauern und wer Ausnahmen genehmigt.
2. Kennzeichnen Sie Epics und Tickets. Jedes Epic erhält eine Kategorie – neue Funktionalität, Erweiterung, Wartung, Forschung oder Infrastruktur –, und Tickets übernehmen sie. Product Owner setzen die Kennzeichnung, das Finanzteam prüft sie.
3. Erfassen Sie Zeit je Person und Epic. Eine schlanke wöchentliche Zeitaufteilung je Epic genügt; minutengenaue Stundenzettel sind nicht nötig, die Schätzungen müssen aber plausibel und konsistent sein.
4. Legen Sie Regeln für Dienstleister fest. Bitten Sie Entwicklungsdienstleister, nach Epic oder Feature mit Stunden je Rolle abzurechnen, damit externe Kosten wie Personalkosten klassifiziert werden können.
5. Schließen Sie monatlich ab. Grenzen Sie zum Monatsende ab, berechnen Sie aktivierungsfähige Personal- und Dienstleisterkosten, buchen Sie die Einträge und nehmen Sie fertige Module in Betrieb, damit die Abschreibung pünktlich beginnt.
6. Bewahren Sie Nachweise auf. Archivieren Sie Finanzierungsgenehmigungen, Roadmaps, Release Notes und die Begründung der Einschätzung zur wahrscheinlichen Fertigstellung; der Abschlussprüfer wird danach fragen.
7. Prüfen Sie vierteljährlich. Kontrollieren Sie die Qualität der Kennzeichnung, überprüfen Sie Nutzungsdauern und suchen Sie nach abgebrochenen oder stockenden Projekten, die wertzumindern sind.

Was sind die häufigsten Fehler bei der Bilanzierung von Softwareentwicklung?

Die häufigsten Fehler bei der Bilanzierung von Softwareentwicklung sind die Aktivierung von Arbeit, die noch Forschung ist, die Aktivierung von Wartung, die Wahl des falschen Standards für SaaS und fehlende Dokumentation von Ermessensentscheidungen. Jeder dieser Fehler fällt meist bei der ersten gründlichen Prüfung auf, wenn die Korrektur am teuersten ist.

• Aktivierung von Forschung und Prototypen — Proof-of-Concept-Spikes und Experimente vor der Finanzierungsgenehmigung sind Aufwand.
• Aktivierung von Wartung — Fehlerbehebung, Refactoring und kleine UI-Anpassungen schaffen keine neue Funktionalität, selbst wenn sie einen ganzen Sprint dauern.
• SaaS als ASC 985-20 behandeln — gehostete Produkte ohne Besitzrecht des Kunden sind intern genutzte Software.
• Gemeinkosten im Vermögenswert — Miete, HR und allgemeine Geschäftsführung sind bei intern genutzter Software Aufwand.
• Kein Nachweis der wahrscheinlichen Fertigstellung — ohne Finanzierungsgenehmigungen und Roadmaps kann der Prüfer den Aktivierungsbeginn nach hinten verschieben.
• Vergessene Wertminderung — ein abgebrochenes Modul, das weiter in der Bilanz steht, überzeichnet das Vermögen.
• Ausländische Entwicklung steuerlich als inländisch behandeln — außerhalb der USA erbrachte Arbeit wird über 15 Jahre abgeschrieben und nicht nach Section 174A abgezogen.

Rechenbeispiel: ein Projekt über 600.000 $, zwei Bilanzierungsergebnisse

Dasselbe Projekt über 600.000 $ kann einen Vermögenswert von 480.000 $ oder von 40.000 $ ergeben – je nachdem, welches US-GAAP-Modell gilt. Das folgende Beispiel ist hypothetisch, verwendet runde Zahlen und unterstellt, dass das Projekt nach der Discovery die Bedingungen für Finanzierung und wahrscheinliche Fertigstellung erfüllt; es veranschaulicht die Mechanik und bezieht sich auf kein reales Unternehmen.

Ergebnis A behandelt das Produkt als intern genutzte Software oder SaaS-Plattform nach ASC 350-40. Ergebnis B behandelt es als lizenzierte Software, die Kunden nach ASC 985-20 selbst installieren, wobei die technologische Machbarkeit durch ein funktionsfähiges Modell spät in der Testphase nachgewiesen wird.

Bei Ergebnis A ergibt die lineare Abschreibung von 480.000 $ über vier Jahre 120.000 $ pro Jahr. Geht die Software zu Jahresbeginn live, beträgt die GuV-Belastung im ersten Jahr 240.000 $ (120.000 $ Aufwand plus 120.000 $ Abschreibung) statt 600.000 $. Bei Ergebnis B mindert fast das gesamte Projekt das operative Ergebnis im Jahr der Ausgabe.

ASU 2025-06 fügt Ergebnis A eine dritte Variante hinzu. Betreffen 150.000 $ der Programmierung eine neuartige Funktion, deren Unsicherheit erst spät in der Entwicklung ausgeräumt wurde, ist dieser Betrag nach den neuen Regeln Aufwand. Der aktivierte Vermögenswert sinkt auf 330.000 $, die jährliche Abschreibung über vier Jahre auf 82.500 $. Die Rechnung ist einfach; dokumentiert werden muss die Einschätzung der Unsicherheit.

Häufig gestellte Fragen

Veröffentlicht am 26. Oktober 2026. Quellen: Volltext von FASB ASU 2025-06 über PwC Viewpoint; Deloitte DART Heads Up (2025); Kommentare von AICPA & CIMA, RSM US und Grant Thornton zu ASU 2025-06; IFRS Foundation, IAS 38 Immaterielle Vermögenswerte; Baker Newman Noyes und Kaufman Rossin zu Section 174A und Rev. Proc. 2025-28; The Tax Adviser (AICPA) zur Definition von Softwareentwicklungskosten. Dieser Artikel dient der allgemeinen Information und ist keine Bilanzierungs-, Prüfungs- oder Steuerberatung.