Ihr ML-Team hat gerade fünf Entwicklermonate damit verbracht, einen Open-Source-Feature-Store aufzusetzen. Ihr Controller sieht sich den Gehaltslauf an und stellt eine Frage, mit der niemand im Team gerechnet hat: Sind diese 180.000 $ Entwicklerzeit eine Ausgabe, die dieses Quartal belastet, oder ein Vermögenswert, der in der Bilanz steht? Die Antwort verändert Ihren Burn Multiple, Ihre Runway-Rechnung und — wenn Sie Kapital einsammeln — die Geschichte, die Ihre Finanzzahlen erzählen. Und sie ändert sich vollständig, je nachdem, ob Sie auf Feast aufgebaut oder Tecton gekauft haben.
Ein Feature-Store ist die Infrastrukturschicht, die Machine-Learning-Features sowohl für das Training als auch für die Echtzeit-Inferenz verwaltet, speichert und bereitstellt. Seine Kernaufgabe ist die Vermeidung von Training-Serving-Skew: sicherzustellen, dass das Modell in der Produktion exakt dieselben Features sieht, mit denen es trainiert wurde. Die Architektur besteht aus fünf beweglichen Teilen — einem Offline-Store für Trainingsdaten, einem Online-Store für Bereitstellung mit geringer Latenz, Feature-Pipelines, die Werte berechnen, einer zentralen Feature-Registry und Serving-APIs. Wenn Teams zwischen Feast und Tecton wählen, entscheiden sie sich zwischen zwei sehr unterschiedlichen Eigentumsmodellen, und jedes Modell führt zu einer ganz anderen bilanziellen Behandlung.
Feast vs. Tecton: die Build-vs-Buy-Abwägung
Feast ist der führende Open-Source-Feature-Store: kostenlos nutzbar, selbst gehostet und flexibel. Sie betreiben den Online-Store selbst (typischerweise Redis oder DynamoDB), den Offline-Store selbst (S3, BigQuery oder Snowflake), und Sie verantworten jedes Upgrade, jeden Bereitschaftsdienst bei Ausfällen und jede Skalierungsentscheidung. Tecton ist die vollständig verwaltete kommerzielle Alternative, entwickelt von Mitgliedern des Teams hinter Ubers Michelangelo-Plattform. Es übernimmt Online- und Offline-Serving, Streaming-Feature-Berechnung und integriertes Feature-Monitoring hinter einem Enterprise-SaaS-Vertrag.
Der übliche Vergleich sieht so aus:
| Faktor | Feast | Tecton |
|---|---|---|
| Lizenzkosten | Kostenlos (nur Infrastrukturkosten) | Enterprise-SaaS-Preismodell |
| Online-Serving | Redis, DynamoDB — Sie betreiben es | Vollständig verwaltet |
| Offline-Store | Parquet, BigQuery, Snowflake — Sie verdrahten es | Verwaltet |
| Streaming-Features | Push-basiert, Sie bauen die Pipelines | Native Echtzeit-Berechnung |
| Feature-Monitoring | Externe Tools, die Sie zusammenstellen | Integriert |
| Betriebsaufwand | Hoch — Ihr Team betreibt alles | Gering — Vendor-SLAs |
Die bilanzierungsrelevante Version dieser Tabelle hat eine Zeile mehr: wo das Geld auftaucht. Bei Tecton kommt praktisch der gesamte Aufwand als Lieferantenrechnung — eine Abonnementausgabe. Bei Feast ist die Lizenzzeile null, und die tatsächlichen Kosten verstecken sich in den Entwicklergehältern: die Wochen, die Ihre Data Engineers mit dem Deployment der Registry, dem Schreiben von Feature-Pipelines, dem Tuning des Online-Stores und dem Aufbau des Monitorings verbringen, das Feast nicht mitliefert. Open-Source-Infrastruktur mit „Null-Lizenzkosten" braucht trotzdem eine GuV-Zeile für Entwicklerstunden, und genau diese Zeile regelt ASC 350-40.
Die Bilanzierungsfrage: Was ASC 350-40 tatsächlich sagt
Nach US-GAAP fallen Kosten für Software für internen Gebrauch unter ASC 350-40, das jeden Dollar eines Softwareprojekts einer von drei Phasen zuordnet (siehe unseren praktischen Leitfaden zur Entscheidung zwischen Aktivieren und Aufwandserfassung für den allgemeinen Rahmen):
- Vorprojektphase — Aufwand bei Entstehung. Bewertung von Anbietern, Proof-of-Concept-Spikes, Vergleich von Feast mit Tecton, Machbarkeitsstudien und die Build-vs-Buy-Analyse selbst. All das belastet sofort die GuV.
- Anwendungsentwicklungsphase — aktivierungsfähige Kosten aktivieren. Sobald das Management das Projekt genehmigt und sich dazu verpflichtet hat, werden die Kosten für Design, Programmierung, Konfiguration, Tests und Integration der Software als Vermögenswert aktiviert und über ihre Nutzungsdauer abgeschrieben. Dies ist die einzige Phase, die einen Vermögenswert aufbaut.
- Phase nach der Implementierung und Betriebsphase — Aufwand bei Entstehung. Schulung, Wartung, Fehlerbehebung und laufender Betrieb nach dem Go-live. Später hinzugefügte neue Funktionalität kann die Aktivierung neu starten, aber der reine Betrieb niemals.
Um in die Anwendungsentwicklungsphase einzutreten, müssen zwei Bedingungen erfüllt sein: Das Management mit der relevanten Befugnis hat das Projekt genehmigt (implizit oder explizit), und es ist wahrscheinlich, dass das Projekt abgeschlossen und die Software für ihre vorgesehene Funktion genutzt wird. Bis beides zutrifft, ist jeder Dollar weiterhin Aufwand der Vorprojektphase — einschließlich eines „Prototyps", der später zur Produktion wird.
Die Aktivierung hat außerdem eine enge Definition aktivierungsfähiger Kosten. Direkte Gehälter für Entwickler, die am Build arbeiten, lohnbezogene Kosten wie Sozialleistungen und an externe Entwickler gezahlte Fremdleistungsentgelte, die am Projekt arbeiten, qualifizieren sich in der Regel. Datenkonvertierung aus einem Altsystem, Schulung, Wartung, allgemeine Gemeinkosten und Verwaltungskosten hingegen nicht — selbst wenn sie innerhalb des Fensters der Anwendungsentwicklungsphase anfallen.
Zuordnung der Feature-Store-Arbeit zu den drei Phasen
So ordnet sich ein typischer Feast-Build in ASC 350-40 ein:
Aufwand: die Bewertung. Ihr Team verbringt drei Wochen damit, Feast gegen Tecton zu benchmarken, einen Beispiel-Pipeline-Spike durchzuführen und Anbieterdokumentation zu lesen. Vorprojektphase — Aufwand. Das gilt selbst dann, wenn der Spike-Code später in der Produktion wiederverwendet wird; die Phase wird nach dem Zweck der Tätigkeit zum jeweiligen Zeitpunkt beurteilt, nicht danach, was aus dem Code wird.
Aktivieren: der Build. Das Management genehmigt die Feast-Entscheidung und finanziert das Projekt. Die Entwickler deployen nun die Registry, schreiben Produktions-Feature-Definitionen, bauen Batch- und Streaming-Pipelines, integrieren den Online-Store in Ihren Inferenzdienst und führen Integrations- und Lasttests durch. Direkte Entwicklergehälter in diesem Zeitfenster sowie etwaige Auftragnehmerentgelte für die Implementierung werden aktiviert — vorausgesetzt, Sie können dokumentieren, wer wann woran gearbeitet hat.
Aufwand: alles nach dem Go-live. Ihre Rufbereitschaft optimiert die Redis-Latenz, füllt ein Feature nach einem Pipeline-Bug nach, bindet neue Modelle an bestehende Pipelines an, aktualisiert Feast-Versionen und pflegt die Monitoring-Dashboards. Nach der Implementierung — Aufwand. Wenn Sie sechs Monate später eine wirklich neue Fähigkeit hinzufügen, etwa eine Streaming-Pipeline für eine neue Produktlinie, kann diese diskrete Erweiterung für ihr eigenes Aktivierungsfenster qualifizieren.
Der mit Abstand häufigste Fehlermodus ist der fehlende Papierpfad. Eine Aktivierung ohne zeitnahe Zeiterfassung nach Projektphase übersteht eine Prüfung selten. Wenn die Zeit Ihrer Entwickler nicht danach erfasst wird, ob sie am Feature-Store-Build oder an Tagesgeschäft gearbeitet haben, wird Ihr Prüfer alles als Aufwand erfassen — was ohnehin die richtige Antwort sein mag, aber es sollte eine Entscheidung sein, kein Standard.
Was sich ändert, wenn Sie stattdessen Tecton kaufen
Der Kauf eines verwalteten Feature-Stores dreht das Bilanzbild um. Tecton ist ein Dienstleistungsvertrag, keine Software, die Sie besitzen, sodass die Abonnementgebühren über die Vertragslaufzeit erfasste Betriebsausgaben sind — einfach, vorhersehbar und prüfungssicher.
Der subtile Teil ist die Implementierung. Die Konfiguration einer SaaS-Plattform für Ihren Gebrauch — die Integration von Tecton in Ihr Data Warehouse, das Anbinden von Serving-APIs an die Inferenz, die Migration von Feature-Definitionen — folgt unter der Cloud-Computing-Leitlinie derselben ASC-350-40-Logik: Implementierungskosten in der Anwendungsentwicklungsphase können für eine Aktivierung qualifizieren, obwohl die zugrunde liegende Software vom Anbieter gehostet wird. In der Praxis sind Tecton-Implementierungen kurz genug, dass viele kleine Unternehmen sie aus Wesentlichkeitsgründen als Aufwand erfassen. Aber wenn Ihre Integration sechsstellige Beträge an Entwicklerzeit erreicht, gilt dieselbe Phasenanalyse, und derselbe Dokumentationsstandard greift.
Hier gibt es eine strategische Fußnote für Gründer, die Kapital einsammeln. Die Aktivierung eines Feast-Builds verbessert die EBITDA- und Bruttomargenoptik der laufenden Periode auf Kosten einer wachsenden Abschreibungslast und eines Vermögenswerts, den das Diligence-Team eines Käufers genau prüfen wird. Die Aufwandserfassung eines Tecton-Abonnements hält die GuV ehrlich gegenüber dem Run-Rate-Burn, lässt aber die Zahlen dieses Jahres schwerer aussehen. Keine der beiden Behandlungen ist „besser" — aber Investoren werden fragen, welche Sie gewählt haben und warum, also wählen Sie bewusst und dokumentieren Sie die Begründung.
ASU 2025-06: Das Phasenmodell verschwindet
Das Drei-Phasen-Modell stammt aus dem Jahr 1998, als Software in sequenziellen Wasserfallphasen mit klaren Grenzen gebaut wurde. Es passt schlecht zu agiler, iterativer Feature-Store-Arbeit — welcher Sprint ist „vorläufig", wenn jeder Sprint in die Produktion geht? Das FASB stimmte zu. Im September 2025 erließ es ASU 2025-06, das die phasenbasierten Regeln abschafft und durch einen prinzipienbasierten Rahmen ersetzt, der darauf abstellt, ob noch erhebliche Entwicklungsunsicherheit besteht.
Unter dem neuen Modell beginnt die Aktivierung, wenn das Management das Projekt genehmigt hat, Fertigstellung und beabsichtigte Nutzung wahrscheinlich sind und das Konzept erhebliche Unsicherheit über Leistungsanforderungen, Entwicklungsansatz oder Machbarkeit überwunden hat. Es gilt für Geschäftsjahre, die nach dem 15. Dezember 2027 beginnen, eine frühere Anwendung ist zulässig. Für einen heute beginnenden Feature-Store-Build ist der praktische Rat unverändert: Holen Sie das Genehmigungsmemo ein, erfassen Sie die Zeit gegen den Build und trennen Sie Bewertung von Konstruktion. Diese Gewohnheiten erfüllen sowohl die alten Phasen als auch die neuen Prinzipien.
Ein praktisches Playbook für Ihren Feature-Store-Build
Ob Sie sich für Feast, Tecton oder eine dritte Option entscheiden — fünf Praktiken halten die Bilanzierung sauber:
Holen Sie die Genehmigung schriftlich ein, bevor der Build beginnt. Eine E-Mail des CTO, die den Feast-Build, das Budget und die beabsichtigte Produktionsnutzung genehmigt, erfüllt die Genehmigungsschwelle. Datieren Sie sie. Prüfer fragen zuerst nach diesem Dokument.
Erfassen Sie Entwicklerzeit ab Tag eins nach Phase. Bewertungs-Spikes gehören in einen Topf, Produktions-Build-Arbeit in einen anderen, Wartung nach dem Launch in einen dritten. Tag-basierte Zeiterfassung oder Sprint-Labeling funktionieren beide; die Aufteilung sechs Monate später aus dem Gedächtnis zu rekonstruieren, nicht.
Aktivieren Sie nur direkte Kosten. Entwicklergehälter und Sozialleistungen für Stunden am Build sowie Auftragnehmerrechnungen, die an die Implementierung geknüpft sind. Schließen Sie Schulung, Datenmigration aus Alt-Pipelines, Gemeinkostenumlagen und die Cloud-Infrastrukturrechnung für den Betrieb des Online-Stores aus — Hosting ist eine Betriebskostenposition des fertigen Systems, keine Kosten seines Aufbaus.
Wählen Sie eine Nutzungsdauer, die Sie verteidigen können. Software für internen Gebrauch wird typischerweise linear über drei bis fünf Jahre abgeschrieben. Ein Feature-Store, der auf schnelllebiger Open-Source-Software aufbaut, bei der eine große Feast-Version einen Neubau erzwingen könnte, spricht für das untere Ende. Dokumentieren Sie die Begründung im Aktivierungsmemo.
Testen Sie auf Wertminderung, wenn sich die Fakten ändern. Wenn Sie den Feast-Build zur Hälfte aufgeben und mit Tecton abschließen, ist der aktivierte Vermögenswert wertgemindert — schreiben Sie ihn ab. Dasselbe gilt, wenn ein Pivot die Produktlinie zunichtemacht, die der Feature-Store bediente. Aktivierte Software, die keine Verwendung mehr hat, ist kein Vermögenswert.
Häufige Fehler, die zu Prüfungsanpassungen führen
Die Fehler, die Prüfer bei der Infrastruktur-Aktivierung finden, sind erschreckend gleichförmig. Die Aktivierung der Bewertungsphase — der Anbietervergleich, der Proof of Concept, der Spike — ist der häufigste; Arbeit der Vorprojektphase ist niemals aktivierungsfähig, egal wie nützlich sie sich erweist. Die Aktivierung von Wartung, die als Entwicklung getarnt ist, liegt an zweiter Stelle: das Tuning der Serving-Latenz und das Nachfüllen von Features ist Betrieb, nicht Konstruktion. Dritter ist das fehlende Memo: ein aktivierter Saldo ohne Genehmigungsdokument, ohne Phasenanalyse und ohne Abschreibungsbegründung wird nach allgemeinen Grundsätzen als Aufwand erfasst. Vierter ist die Abschreibung über Fantasienutzungsdauern — zehn Jahre für Infrastruktur, die an ein Open-Source-Projekt geklebt ist, das jährlich Breaking Changes ausliefert. Und fünfter ist das völlige Vergessen der Cloud-Rechnung: Teams, die sorgfältig Gehälter aktivieren und dabei eine sechsstellige jährliche DynamoDB-und-Compute-Run-Rate ignorieren, stellen den Build-vs-Buy-Vergleich falsch dar, der das Projekt überhaupt gerechtfertigt hat.
Verfolgen Sie den Build wie den Vermögenswert, der er werden könnte
Die Entscheidung Feast vs. Tecton wird gewöhnlich als Entwicklerstolz gegen Anbieterkomfort gerahmt. Rahmen Sie sie als finanzielle Frage, und die Abwägung schärft sich: Feast verwandelt Barvergütung in einen Vermögenswert mit einem Abschreibungsschwanz, während Tecton dieselbe Fähigkeit in eine saubere Betriebsausgabe mit einem Verlängerungsdatum verwandelt. Ihr Runway-Modell, Ihre Bruttomarge und Ihre Diligence-Geschichte ändern sich alle mit der Wahl — genau deshalb verdient die Bilanzierung einen Sitz in der Architekturprüfung, nicht eine Fußnote danach.
Das beginnt mit gewöhnlicher Buchhaltungsdisziplin: projektmarkierte Zeit, datierte Genehmigung, an den Build geknüpfte Auftragnehmerrechnungen und ein Aktivierungsmemo, dem Ihr Prüfer folgen kann. Wenn Ihre Feature-Store-Kosten derzeit als undifferenzierte Entwicklergehälter in einem einzigen Sachkonto liegen, haben Sie die Option zur Aktivierung bereits verloren — die Aufzeichnungen lassen sich nicht nachträglich rekonstruieren.
Vereinfachen Sie Ihr Finanzmanagement
Während Sie Ihre ML-Infrastruktur skalieren, ist es unerlässlich, klare Finanzunterlagen für Build-vs-Buy-Entscheidungen, aktivierte Software und Abschreibungspläne zu führen. Beancount.io bietet Plain-Text-Buchhaltung, die Ihnen vollständige Transparenz und Kontrolle über Ihre Finanzdaten gibt — keine Blackbox, kein Vendor-Lock-in. Starten Sie kostenlos und erfahren Sie, warum Entwickler und Finanzfachleute auf Plain-Text-Buchhaltung umsteigen.
