LLM-API-Kosten sind COGS, keine Gemeinkosten: Ein Bruttomargen-Leitfaden für KI-Wrapper

Ein Gründer, der einen KI-Schreibassistenten betreibt, erzählte mir, seine „Softwarekosten" lägen bei $40,000 im Monat. Als wir die Zahl aufschlüsselten, stellte sich heraus, dass $34,000 davon OpenAI- und Anthropic-API-Rechnungen waren — und keiner dieser Beträge war in seinen Herstellungskosten (COGS) enthalten. Er steckte in einer allgemeinen Position „Software & Abonnements", direkt neben seinem Projektmanagement-Tool für $19 im Monat. Seine ausgewiesene Bruttomarge lag bei 91%. Seine tatsächliche Bruttomarge, nachdem die Inferenzkosten dorthin verschoben wurden, wo sie hingehören, lag bei 58%.

Das ist keine buchhalterische Spitzfindigkeit. Es ist der Unterschied zwischen einem Unternehmen, das wie Software aussieht, und einem Unternehmen, das sich wie eine Fabrik verhält — eines, bei dem jede verkaufte Einheit einen realen, variablen Input verbraucht. Wenn Sie auf GPT-5, Claude, Gemini oder einem anderen gehosteten Modell aufbauen, ist Ihre LLM-Rechnung keine Gemeinkosten. Sie zählt zu den Herstellungskosten (COGS), und sie anders zu behandeln bedeutet, dass Sie in Wirklichkeit nicht wissen, wie viel Geld Sie verdienen.

Warum dieser Fehler so leicht passiert​

Traditionelles SaaS hat eine ganze Gründergeneration darauf trainiert, Softwarekosten als fix zu betrachten. Man zahlt fürs Hosting, man zahlt für sein CRM, man zahlt für Slack — und keine dieser Rechnungen bewegt sich im Gleichschritt damit, wie stark ein einzelner Kunde das eigene Produkt nutzt. Wenn dann die erste API-Rechnung von OpenAI eintrifft, ist es naheliegend, sie in dieselbe gedankliche Schublade zu stecken: „Tools, die wir zum Betrieb des Geschäfts bezahlen."

Das Problem ist, dass sich eine LLM-API-Rechnung nicht wie ein SaaS-Abo verhält. Sie verhält sich wie ein Rohstoff. Jedes Mal, wenn ein Kunde einen Prompt sendet, verbrauchen Sie Tokens, und jedes Token hat einen Preis. Ein Kunde, der 50 Anfragen pro Tag stellt, kostet Sie in der Bedienung spürbar mehr als einer, der nur 2 stellt. Das ist die Lehrbuchdefinition von Herstellungskosten: Kosten, die direkt mit der Auslieferung Ihres Produkts an einen bestimmten Kunden skalieren — im Gegensatz zu Kosten, die Sie unabhängig von der Nutzung einfach zahlen, um den Betrieb am Laufen zu halten.

Branchendaten bestätigen, wie bedeutsam das inzwischen geworden ist. Der „State of AI"-Bericht von ICONIQ vom Januar 2026 ergab, dass Inferenz bei AI-B2B-Unternehmen in der Skalierungsphase mittlerweile durchschnittlich 23% des Gesamtumsatzes ausmacht, und 84% dieser Unternehmen berichteten von einer Bruttomargen-Erosion von sechs Prozentpunkten oder mehr, die direkt auf KI-Infrastrukturkosten zurückzuführen ist. Das ist kein Rundungsfehler, den man einfach in „sonstige Betriebskosten" absorbieren kann. Es ist oft der mit Abstand größte Kostentreiber im Unternehmen und verdient auch so behandelt zu werden.

Die Grenze zwischen COGS und OpEx richtig ziehen​

Die Regel, die COGS von Betriebsausgaben trennt, hat sich nicht geändert, nur weil der Input eine Modell-API statt eines Lagers voller Bauteile ist: Kosten für die Auslieferung Ihres Produkts an einen zahlenden Kunden gehören in die COGS; Kosten für den Aufbau Ihres Produkts gehören unter OpEx in die F&E. Auf einen KI-Wrapper angewendet, sieht diese Aufteilung so aus:

Gehört in die COGS:

• Produktions-Inferenzkosten — jeder API-Aufruf, den Ihr Live-Produkt im Namen eines zahlenden Kunden ausführt, ob Chat-Completion, Embedding-Aufruf, Klassifizierungsdurchlauf oder Agent-Tool-Call-Loop
• Modell-Hosting / GPU-Rechenleistung — wenn Sie ein Open-Weight-Modell auf eigener oder gemieteter Infrastruktur betreiben, statt eine gehostete API aufzurufen, die Rechenzeit, die der Bedienung von Kundenanfragen zuzurechnen ist
• Unterstützende Inferenz-Infrastruktur — Vektordatenbank-Abfragen, Embedding-Pipeline-Durchläufe und Orchestrierungs-Overhead, die eigens zur Bedienung von Produktionsanfragen existieren
• KI-spezifische Support-Kosten — ein Support-Engineer, dessen Aufgabe es ist, Probleme mit Modellausgaben für Kunden zu triagieren, verursacht Kosten der Produktauslieferung, keine allgemeinen Vertriebs- und Verwaltungskosten (SG&A)

Gehört in die OpEx (in der Regel F&E):

• Entwicklungs- und Test-Inferenz — jeder Prompt, den ein Engineer sendet, während er an einem Feature iteriert, eine Regression debuggt oder eine neue Modellversion evaluiert
• Fine-Tuning- und Evaluierungsdurchläufe — den Aufbau oder die Verbesserung des Modells voranzutreiben ist F&E, keine Auslieferung
• Interne KI-Tools — die ChatGPT-Enterprise-Lizenzen oder GitHub-Copilot-Lizenzen Ihres Teams sind eine Produktivitätsausgabe, keine Kosten für die Bedienung von Kunden

Der praktische Schritt, der diese Aufteilung erst möglich macht, ist unspektakulär, aber essenziell: verwenden Sie von Anfang an getrennte API-Keys oder Abrechnungsprojekte für Produktions- und Entwicklungs-Traffic. Wenn Ihre Engineers Prompts über denselben Key testen, den Ihr Produkt in der Produktion nutzt, haben Sie im Nachhinein keine Möglichkeit mehr, die Rechnung korrekt zuzuordnen, und Sie werden Ihre tatsächliche Marge Monat für Monat entweder über- oder unterschätzen.

Wie die „echte" Bruttomarge bei KI-Produkten aussieht​

Sobald Sie diese Aufteilung vorgenommen haben, sollten Sie damit rechnen, dass die resultierende Zahl anders aussieht, als Sie es gewohnt sind. Traditionelle SaaS-Unternehmen streben nahezu selbstverständlich Bruttomargen von 70–80% an. KI-native Produkte kommen auf diesem Weg nicht dorthin. Das Pricing-Playbook von Bessemer Venture Partners vom Februar 2026 setzt typische Bruttomargen von KI-Produkten bei 50–60% an, deutlich unter der Spanne von 80–90% für traditionelles SaaS, und die Daten von ICONIQ zeigen, dass die branchendurchschnittliche Bruttomarge von KI-Produkten steigt — aber nur auf 52%, gegenüber 41% im Jahr 2024 und 45% im Jahr 2025.

Eine nützliche Faustregel, die sich bei Betreibern herausgebildet hat, die das genau im Blick behalten: halten Sie die LLM-Kosten unter etwa 20% der gesamten COGS, wenn Sie ein tragfähiges, skalierbares Geschäftsmodell wollen. Überschreiten Sie diese Schwelle, neigt die Margenkompression dazu, mit dem Wachstum zuzunehmen statt nachzulassen, weil größere Kunden das Produkt mehr nutzen, nicht weniger. Manche KI-intensiven Kategorien — Coding-Assistenten, Dokumentenverarbeitungs-Agenten — fahren LLM-Kostenquoten von 30–40% der COGS und bleiben trotzdem tragfähig, aber nur, weil sie bewusst um diese Realität herum bepreist haben, statt sich hineinzumanövrieren.

Die Zahl, auf die es wirklich ankommt, ist nicht Ihre unternehmensweite Mischbruttomarge — es sind die Kosten pro Kunde. Intensivnutzer eines KI-Features können Sie in reinen Inferenzkosten 50 bis 100 Mal mehr kosten als leichte Nutzer auf derselben Abo-Stufe. Wenn Sie das nicht erfassen, wissen Sie nicht, welche Kunden profitabel sind und welche Sie stillschweigend jeden Monat subventionieren. Ein Flatrate-Plan, der bei Ihren ersten zehn Kunden noch gut aussah, kann in dem Moment beginnen, Geld zu verlieren, in dem einer von ihnen einen Workflow in die Produktion bringt und sein Anfragevolumen mit 20x multipliziert.

Aufbau des Kostenmodells pro Anfrage​

Um anzufangen, brauchen Sie kein aufwendiges Tooling — Sie brauchen Disziplin dabei, bei jeder Anfrage die richtigen Zahlen zu protokollieren. Die Kernformel ist einfach:

request_cost = (input_tokens / 1,000,000) × input_price_per_million
             + (output_tokens / 1,000,000) × output_price_per_million

Output-Tokens kosten pro Einheit typischerweise das 2–5x eines Input-Tokens, weil die Generierung rechenintensiver ist als das Lesen eines Prompts — ein Kostenmodell pro Anfrage, das nur die Gesamtzahl der Tokens erfasst, ohne Input und Output zu trennen, wird deshalb alles mit langen Completions systematisch falsch bepreisen. Als praktisches Beispiel bei Preisen von Mitte 2026: Eine Anfrage mit 2,000 Input-Tokens und einer 500-Token-Antwort gegen ein gängiges Modell der mittleren Preisklasse (etwa $3 Input / $15 Output pro Million Tokens) kostet ungefähr $0.0135. Führen Sie dieselbe Art von Anfrage 50,000-mal im Monat aus, landen Sie bei etwa $675 Inferenzkosten für dieses eine Feature — eine Zahl, die unsichtbar bleibt, wenn sie in einer fünfstelligen „Cloud-Kosten"-Position vergraben ist, aber sehr sichtbar wird, sobald sie dem Feature und dem Kundensegment zugeordnet wird, das sie verursacht hat.

Um das umsetzbar zu machen:

1. Protokollieren Sie bei jeder Anfrage die Token-Anzahl, nicht nur die Kosten — die meisten Modellanbieter liefern Input-/Output-Token-Zahlen bereits in der API-Antwort selbst, das ist also eine Änderung am Logging, keine neue Datenquelle.
2. Versehen Sie jede Anfrage mit einer Kunden-ID und einer Feature-Kennung, damit Sie Kosten nach Account und Produktbereich aggregieren können, nicht nur nach Monat.
3. Berechnen Sie die Kosten pro Kunde und Abrechnungszeitraum und vergleichen Sie sie mit dem, was dieser Kunde Ihnen zahlt. Das ist die Kennzahl, die Ihnen sagt, ob Ihre Preisstufen tatsächlich zu Ihren Auslieferungskosten passen — nicht Ihre gemischte Durchschnittsmarge.
4. Leiten Sie Anfragen an günstigere Modelle weiter, wo die Qualität es zulässt. Nicht jede Anfrage braucht Ihr leistungsfähigstes (und teuerstes) Modell — Klassifizierung, Extraktion und einfache Formatierungsaufgaben laufen oft auch auf einem kleineren, günstigeren Modell akzeptabel, und Modell-Routing ist einer der wenigen Margenhebel, die Sie vollständig selbst kontrollieren, im Gegensatz zur Preisgestaltung der Anbieter.

Preisgestaltung zum Schutz der gerade gefundenen Marge​

Sobald Inferenz korrekt als COGS klassifiziert ist, verändert sich Ihr Pricing-Gespräch. Ein gängiger Ankerpunkt, den Betreiber verwenden, ist, etwa das 3–5x der Token-Kosten pro Einheit zu berechnen, sodass eine $0.30-Aufgabe mit $1.00 oder mehr bepreist wird — nicht weil dieser Multiplikator magisch ist, sondern weil er Spielraum lässt, um Nutzungsschwankungen, Modellpreis-Volatilität sowie die Support- und Infrastrukturkosten abzufedern, die mit der reinen Inferenz einhergehen.

Nutzungsbasierte Abrechnung ist für KI-Unternehmen zum Standardweg geworden, Pricing und COGS im Gleichschritt zu halten: Berechnen Sie pro Token, pro Anfrage oder pro abgeschlossener Aufgabe, dann skaliert Ihr Umsatz mit derselben Variable, die auch Ihre Kosten treibt, statt sich davon zu entfernen, wie es bei einem Flatrate-Abo passiert, sobald die Nutzung ansteigt. Wenn Sie noch nicht bereit sind, vollständig auf nutzungsbasierte Preise umzustellen, bauen Sie zumindest Stufen mit garantiertem Mindestbetrag plus Überschreitungsgebühr, damit ein Kunde, der die typische Nutzung sprengt, nicht stillschweigend für den Rest des Monats zum Verlustbringer wird.

Halten Sie Ihre Kostenstruktur so prüfbar wie Ihren Code​

Nichts davon ist optionale Buchhaltungshygiene — es ist der Unterschied, ob Sie wissen, dass Ihr Geschäftsmodell funktioniert, oder es erst während eines Due-Diligence-Gesprächs bei der Finanzierungsrunde erfahren, wenn der Mitarbeiter eines Investors das Pro-Kunde-Kostenmodell erstellt, das Sie eigentlich schon sechs Monate früher hätten bauen sollen. Die Gründer, die sich dieses Gespräch ersparen, sind diejenigen, die Inferenzkosten von der allerersten API-Anfrage an Kunden und Features zuordnen — nicht diejenigen, die warten, bis die OpenAI-Rechnung zu groß wird, um sie zu ignorieren.

Beancount.io bietet Ihnen versionskontrollierte Buchhaltung im Klartextformat, mit der Sie Inferenzausgaben unkompliziert dem richtigen Konto zuordnen, Produktions- von Entwicklungs-API-Nutzung trennen und Ihre tatsächlichen COGS jeden Monat mit dem Umsatz abgleichen können — keine Black-Box-Kategorisierung, kein Vendor-Lock-in. Jetzt kostenlos starten und erfahren Sie, warum Entwickler und KI-native Gründer zu klartextbasierter Buchhaltung wechseln.