Welche Cloud-Kosten in die Umsatzkosten (COGS, Cost of Revenue) einer SaaS gehören, legen Sie als Policy fest, die Finance, Steuerberatung und gegebenenfalls Abschlussprüfung mittragen. Eine tragfähige Policy rechnet die Produktionsumgebung, die zahlende Kunden bedient, samt ihrem Anteil an der gemeinsamen Plattform zu den Umsatzkosten, Entwicklung, Test und Experimente zu Forschung und Entwicklung (F&E) und interne Werkzeuge zu Verwaltung oder Vertrieb. Wichtiger als jede Einzelentscheidung ist die Wiederholbarkeit: dieselbe Regel jeden Monat, ableitbar aus Konten und Tags. Dieser Leitfaden ist ein Entscheidungsrahmen, keine Rechnungslegungs- oder Steuerberatung.
Managementkennzahl und Jahresabschluss trennen
§ 275 HGB erlaubt die Gewinn- und Verlustrechnung nach dem Gesamtkostenverfahren oder dem Umsatzkostenverfahren. Nur das Umsatzkostenverfahren kennt die Posten „Herstellungskosten der zur Erzielung der Umsatzerlöse erbrachten Leistungen“ und „Bruttoergebnis vom Umsatz“. Im Gesamtkostenverfahren stehen Aufwendungen nach ihrer Art, etwa „Aufwendungen für bezogene Leistungen“ oder „sonstige betriebliche Aufwendungen“; ein Bruttoergebnis weist es nicht aus.
Stellt Ihre Gesellschaft die GuV nach dem Gesamtkostenverfahren auf, ist die SaaS-Bruttomarge eine Kennzahl des Controllings, und wo Cloud-Kosten im Jahresabschluss stehen, legt die Geschäftsführung mit der Steuerberatung fest. Nutzt Ihre Gesellschaft dagegen das Umsatzkostenverfahren, kann Ihre Policy den Posten im Abschluss speisen; stimmen Sie sie dann vor dem Jahresabschluss mit Steuerberatung oder Abschlussprüfung ab. Nutzen Sie in jedem Fall eine gemeinsame Datenbasis. Grenzen Controlling und Abschluss unterschiedlich ab, dokumentieren Sie die Überleitung, damit niemand zwei Wahrheiten verteidigen muss.
Klassifikationstabelle
| Kostenart | Empfohlene Zuordnung | Begründung oder Grenzfall |
|---|---|---|
| Produktion für zahlende Kunden: Compute, Datenbanken, Speicher, Datentransfer, CDN | Umsatzkosten | Ohne sie keine Leistung |
| Gemeinsame Plattform: Cluster, Netzwerk, Observability, Sicherheitsdienste | Produktionsanteil in Umsatzkosten, Rest in F&E | Anteil nach dokumentiertem Schlüssel |
| Staging, Entwicklung, Preview-Umgebungen, CI | F&E | Grenzfall: eine vertraglich zugesagte Kunden-Sandbox ist Leistung |
| Produktions-Monitoring, Bereitschaft, Statusseite | Umsatzkosten | Sichert die zugesagte Verfügbarkeit |
| Backups und Notfall-Standby der Produktion | Umsatzkosten | Teil der zugesagten Wiederherstellbarkeit |
| Werkzeuge und Umgebungen für Kundensupport | Umsatzkosten, wenn Support Teil des Leistungsversprechens ist | Sonst Vertrieb oder Verwaltung |
| Daten und Analytics als Produktfunktion, etwa Kundenberichte | Umsatzkosten | Kunden nutzen sie |
| Interne BI und Data Warehouse für Steuerung | Verwaltung | Dient der Führung, nicht der Leistung |
| KI-Inferenz in Kundenfunktionen | Umsatzkosten | Fällt je Nutzung an wie andere Produktionslast |
| KI-Training, Evaluierung, Experimente | F&E | Grenzfall: regelmäßiges Nachtrainieren eines ausgelieferten Modells |
| Demo-Umgebungen, Website | Vertrieb und Marketing | |
| Interne IT: Identität, E-Mail, Werkzeuge für Mitarbeitende | Verwaltung | |
| Marketplace-Käufe über AWS oder Azure | Nach Funktion des gekauften Produkts | Der Rechnungsweg bestimmt nicht die Funktion |
| Provider-Support, etwa AWS Support | Anteilig nach den unterstützten Umgebungen | |
| Amortisierte Reservierungen und Savings Plans | Folgen der abgedeckten Nutzung | Ungenutzte Commitments als eigene Zeile |
| Gutschriften | Nicht gegen Umsatzkosten verrechnen | Eigene Zeile, siehe unten |
| Steuern | Außerhalb der Kennzahl | Prüfung gehört in die Reverse-Charge-Kontrolle |
Für die gemeinsame Plattform brauchen Sie einen Schlüssel, der Produktions- und Entwicklungslast trennt, etwa CPU- und Speicheranteile je Namespace im geteilten Cluster. Wie Sie solche Schlüssel je Komponente wählen und die Summe exakt halten, beschreibt Multi-Tenant-Kosten verteilen.
Bei den Commitments hilft FOCUS: EffectiveCost verteilt Vorauszahlungen auf die abgedeckte Nutzung und setzt den Kaufbetrag selbst auf null, wenn er künftige Nutzung abdecken soll. Damit landet ein Savings Plan dort, wo seine Nutzung steht, statt als Block im Kaufmonat.
Credits verzerren die Marge
AWS wendet Promotional Credits automatisch auf berechtigte Kosten an, zuerst auf den größten Servicebetrag. Ist die Kreditfreigabe in einer Organisation aktiv, gehen Credits nach dem Konto, dem sie gehören, an das Konto mit den höchsten Ausgaben. Credits haben außerdem ein Ablaufdatum. Eine Marge nach Credits zeigt deshalb weder die Kostenstruktur noch die Marge nach dem Ablauf.
Rechnen Sie die Umsatzkosten vor Credits und zeigen Sie Gutschriften als eigene Zeile unter der Marge. In FOCUS-Daten erkennen Sie sie an ChargeCategory = 'Credit'.
Regeln, die die Zuordnung wiederholbar machen
Das stärkste Signal ist die Kontostruktur: Produktion und Nicht-Produktion in getrennten AWS-Konten, Azure-Abonnements oder Google-Cloud-Projekten. Tags verfeinern innerhalb dieser Grenzen. Werten Sie die Regeln in fester Reihenfolge aus; die erste Übereinstimmung gewinnt:
1. ChargeCategory = Credit -> Gutschriften, unter der Marge
2. ChargeCategory = Tax -> außerhalb der Kennzahl
3. Tag cost_function = sales -> Vertrieb und Marketing
4. Tag cost_function = internal -> Verwaltung
5. Produktionskonto, Tag cost_pool -> geteilt, per Schlüssel auf Umsatzkosten und F&E
6. Produktionskonto -> Umsatzkosten
7. Nicht-Produktionskonto -> F&E
8. alles andere -> nicht zugeordnet, Klärung bis zum Monatsabschluss
Die Reihenfolge ist Teil der Policy. Stünde Regel 7 vor Regel 3, landete eine Demo-Umgebung im Entwicklungskonto in F&E statt im Vertrieb. Halten Sie neue Konten und Tag-Werte in einem kurzen Freigabeprozess fest, damit die Regeln nicht still veralten.
Wenn Produktion und Entwicklung ein Konto teilen
Teilen sich beide ein Konto, trägt ein Tag wie environment mit festen Werten die Trennung. Ressourcen ohne Tag-Unterstützung oder mit gemischter Nutzung, etwa ein NAT-Gateway oder ein gemeinsamer Cluster, behandeln Sie als geteilte Kosten mit Schlüssel. Messen Sie jeden Monat den Anteil, der keiner Kategorie zugeordnet ist, als Zuordnungsgrad, und planen Sie die Trennung in eigene Konten, sobald dieser Anteil groß genug ist, um die Margenaussage zu verändern.
Ein Policy-Blatt, das Finance unterschreiben kann
Halten Sie die Policy auf einer Seite fest, mit diesen Feldern:
- Gültig ab und Version, mit Änderungsprotokoll
- Verantwortlich: eine Person in Finance, eine in Engineering
- Kostenbasis:
EffectiveCostvor Credits, Datenstand zum Monatsabschluss - Kategorien: Umsatzkosten, F&E, Vertrieb und Marketing, Verwaltung, nicht zugeordnet
- Regelreihenfolge wie oben, mit Kontoliste je Kategorie
- Schlüssel für jede geteilte Komponente
- Prüfrhythmus: monatlich im Review, jährlich mit der Abschlussprüfung oder Steuerberatung
Was Investoren und Controlling sehen wollen
Eine Marge ist nur mit ihrer Definition lesbar. Legen Sie deshalb zu jeder Monatszahl bereit:
- Schriftliche Definition mit Versionsdatum. Ändert sich die Policy, rechnen Sie Vorperioden nach und weisen den Effekt der Änderung getrennt aus.
- Marge vor und nach Credits, mit dem Ablaufdatum der verbleibenden Credits.
- Überleitung zur Rechnung. Die Summe aller Kategorien plus nicht Zugeordnetes ergibt die Cloud-Kosten des Monats; Abweichungen zur Providerrechnung erklärt die Abstimmung im Monatsabschluss.
- Währung. Kursquelle und Methode für USD-Kosten nennen, wie in AWS in Euro bezahlen beschrieben.
- Bridge der Margenveränderung: Umsatz, Nutzungsvolumen, Preise und Rabatte, Regeländerungen. So sieht die Geschäftsführung, ob die Marge durch Effizienz steigt oder nur durch neue Zuordnung.
- Aktivierte Entwicklungskosten, falls Sie nach Klärung mit Ihrer Beratung aktivieren: Zeigen Sie, welche Beträge nicht mehr im F&E-Aufwand stehen, und legen Sie in der Policy fest, in welcher Kategorie eine spätere Abschreibung steht. Ob und was aktiviert werden darf, klären Sie mit Ihrer Beratung; die Fragen dazu stehen in Cloud-Kosten aktivieren.
Unterscheiden Sie dabei die technische Bruttomarge, also Umsatz abzüglich der Technologiekosten seiner Erbringung, von der vollständigen Bruttomarge Ihrer Policy, die etwa auch Personal für Betrieb und Support enthalten kann. Die Definition steht im Glossar unter technische Bruttomarge:
Technische Bruttomarge = (Umsatz - Cloud-Umsatzkosten vor Credits) / Umsatz
Auf Kundenebene setzt sich dieselbe Logik als Cloud-Kosten pro Kunde fort; die Grundbegriffe erklärt das Glossar unter Unit Economics.
Was Costfluent dabei abdeckt
Costfluent liest die Abrechnungsdaten von AWS, Azure und Google Cloud über lesende Konnektoren. Segmente benennen Team, Produkt und Kostenstelle; Zuordnungsregeln mit je einer Bedingung auf Konto oder Abonnement, Ressourcengruppe, Ressourcenname oder Tag werden in fester Reihenfolge ausgewertet, und was keine Regel trifft, bleibt als nicht zugeordnet sichtbar. Als geteilt markierte Kosten verteilt Costfluent im Verhältnis der direkten Kosten der Segmente; für die Plattform heißt das, im Verhältnis von direkter Produktions- zu direkter Entwicklungslast. Passt dieser Schlüssel nicht zu Ihrer Policy, rechnen Sie den Anteil außerhalb. Kosten erscheinen standardmäßig in Euro mit ausgewiesener EZB-Kursmethode, ein gespeicherter Bericht lässt sich per E-Mail planmäßig an Finance senden oder als CSV exportieren. Umsatzdaten kennt Costfluent nicht, die Marge rechnet das Controlling, und Costfluent bucht nichts. Der Abgleich gegen die Providerrechnung ist in Planung. Mehr unter Lösungen für Finance.
Quellen und Methode
Geprüft am 10. Oktober 2026: § 275 HGB, Gliederung der Gewinn- und Verlustrechnung, AWS: Applying AWS credits, FOCUS 1.2: ChargeCategory, FOCUS 1.2: EffectiveCost und FinOps Foundation: Unit Economics. Die Klassifikationstabelle, die Regelreihenfolge und die Liste für Investoren und Controlling sind Costfluent-Empfehlungen. Sie ersetzen keine Rechnungslegungs-, Steuer- oder Prüfungsberatung; die Einordnung im Jahresabschluss legen Geschäftsführung, Steuerberatung und gegebenenfalls Abschlussprüfung fest.
