Ein Google Cloud Rechnungskonto ist das, was zahlt: Jedes Projekt ist mit genau einem verknüpft, das Konto sammelt die Kosten aller seiner Projekte und begleicht sie über ein Zahlungsprofil, entweder Self-Serve, automatisch von Karte oder Bankkonto abgebucht, oder Invoiced, per Überweisung gegen eine monatliche Rechnung, sobald Google das Konto dafür freigegeben hat; ein partnerabgerechnetes Konto wird über den Reseller bezahlt. Organisation und Ordner sind, wo Projekte liegen und wo Tags vererbt werden, das Projekt ist die Einheit, zu der jede Kostenzeile gehört, und Labels und Tags sind die zwei Wege, Ressourcen für die Zuordnung zu markieren, die beide der Abrechnungsexport trägt. Auf der Rechnung ändert der Kontotyp die Zahlungsbedingungen und sonst nichts, während das Projekt das ist, wonach jede Kostenzeile, jedes Budget und jeder Export geschlüsselt ist.
Preisdimensionen
Rechnungskonten, Projekte, Labels und Tags kosten nichts; was jedes ändert, ist, wo eine Kostenzeile landet und was sie trägt. Jede Kostenzeile hat weiterhin ihre SKU und ihren Preis; die Tabelle listet die Mechanismen darum herum.
| Mechanismus | Was er ist | Was er an der Rechnung ändert | Wo er optional ist |
|---|---|---|---|
| Self-Serve-Rechnungskonto | Ein Online-Konto mit Zahlungsprofil, automatisch von Karte oder Bankkonto abgebucht am Monatsende oder beim Erreichen einer Schwelle | Berechtigt für Nutzungsrabatte; die monatliche Abrechnung, keine Rechnungsbedingungen | Die Vorgabe für neue Konten |
| Invoiced-Rechnungskonto | Ein Offline-Konto, von Google für Rechnungsstellung freigegeben, per Scheck oder Überweisung gegen monatliche Rechnungen per Post oder elektronisch bezahlt | Zahlungsbedingungen und ein Kreditrahmen; keine Nutzungsrabatte; die Rechnung als Dokument, das Finanzen abstimmt | Ja, nach Berechtigung |
| Partnerabgerechnetes Konto | Ein Rechnungskonto, das ein Reseller besitzt, mit dem Kunden als Unterkonto | Preis und Rechnung des Resellers; der Export zeigt die Nutzung des Kunden zu den Sätzen des Resellers oder zum Listenpreis, wo der Reseller sie zurückhält | Ja |
| Zahlungsprofil | Rechtsträger, Adresse, Steuerstatus und Zahlungsmittel hinter dem Konto; Geschäftsprofile für Unternehmen | Währung und Steuern auf der Rechnung; Umsatzsteuer für einen deutschen Rechtsträger | Nein |
| Projekt | Der Container, zu dem jede Ressource gehört, mit einem Rechnungskonto verknüpft; ein Projekt ohne Rechnungskonto kann keine kostenpflichtigen Dienste nutzen | project.id auf jeder Kostenzeile; die Einheit von Budgets, Kontingenten und Exporten | Nein |
| Organisation und Ordner | Die Hierarchie über den Projekten, mit der Organisation als Wurzel; die Vorfahren eines Projekts im Export | Die Struktur, der die Zuordnung ohne ein einziges Label folgt; woher Tags vererbt werden | Ja, keine Organisation für Einzelpersonen |
| Labels | Schlüssel-Wert-Paare, die der Dienst, dem eine Ressource gehört, auf ihr setzt, bis 64 je Ressource; auch auf dem Projekt | labels und project.labels auf den Kostenzeilen der markierten Ressource; die Zuordnung je Team, die keine Hierarchie braucht | Ja |
| Tags | Schlüssel-Wert-Paare, über Resource Manager an Organisation, Ordner, Projekt oder Ressource gebunden, mit IAM-Kontrolle über Schlüssel und Werte, die Hierarchie hinab vererbt | tags auf den Kostenzeilen, mit tags.inherited, wo die Bindung von einem Vorfahren kam; die Zuordnung, die der Hierarchie folgt | Ja |
| Credits | Promotions-, Freimengen-, Nutzungs-, Commitment- und ausgabenbasierte Credits auf den Zeilen, zu denen sie gehören | credits.type und credits.amount als negative Beträge neben dem Listenpreis; Promotionsguthaben aufgebraucht, bis es verfällt | Ja |
| Kaufoption | Keine; die Kontostruktur trägt keinen eigenen Rabatt |
Das Rechnungskonto ist ein Verwaltungsobjekt, kein Kostenobjekt: Es besitzt Zahlungsprofil, Währung, Rechnung und Budgets, und die Projekte, die es bezahlt, können überall in der Hierarchie der Organisation liegen, weshalb eine Organisation mehrere Rechnungskonten haben kann, eines je Rechtsträger oder Kostenstelle, und weshalb das Verschieben eines Projekts zwischen Rechnungskonten seine künftigen Kosten verschiebt, ohne das Projekt anzufassen. Der Kontotyp zählt an zwei Stellen: Ein Invoiced-Konto hat Zahlungsbedingungen und einen Kreditrahmen und bekommt keinen Nutzungsrabatt, ein Self-Serve-Konto bekommt den Rabatt und zahlt automatisch; die Preise sind dieselben. Labels und Tags sind die Zuordnungsschlüssel, und sie unterscheiden sich darin, wer sie setzen darf und wo sie gelten: Ein Label setzt auf einer Ressource jeder, der sie bearbeiten kann, und es gilt für diese Ressource allein, ein Tag ist ein Resource-Manager-Objekt mit eigenen Berechtigungen, einmal an einen Ordner oder ein Projekt gebunden und von allem darunter geerbt, was Tags zum Schlüssel für Verantwortung und Labels zum Schlüssel für Workloads macht. Der Export trägt beide, so dass eine Kostenzeile die Labels des Projekts, die Labels der Ressource und die geerbten Tags zugleich trägt. Die Mechanik aller drei Anbieter erklärt Abrechnungskonten und Hierarchien; wie Konten, Subscriptions und Projekte der Zuordnung dienen, Zuordnung nach Konto, Subscription und Projekt; was Labels leisten und nicht leisten, Tags und Labels.
Rechnungen, Exporte und APIs
Rechnungen. Ein Self-Serve-Konto erhält eine monatliche Abrechnung und eine Transaktionshistorie in der Konsole; ein Invoiced-Konto erhält eine Rechnung je Rechnungskonto und Monat, in der Währung des Zahlungsprofils, mit den Steuern des Profillandes, und die Zeilen der Rechnung sind je Projekt und Dienst. Der Rechnungsmonat ist der Kalendermonat der Nutzung, und invoice.month im Export ist der Schlüssel, der eine Zeile daran bindet; eine Gutschrift oder Korrektur erscheint als Zeile mit cost_type adjustment im Monat ihrer Ausstellung, nicht im Monat, den sie korrigiert. Kosten in einer anderen Währung als USD tragen currency_conversion_rate, und cost geteilt durch den Kurs ist der USD-Betrag, in dem die Preise veröffentlicht sind. Wie eine Gutschrift, eine Erstattung oder eine Korrektur landet, steht unter Gutschriften, Erstattungen und Korrekturen; was die Währung mit der Zahl macht, unter Rechnungswährung und Wechselkurse.
Exporte. Der Abrechnungsexport nach BigQuery ist je Rechnungskonto, in drei Formen: der Standardexport der Nutzungskosten mit einer Zeile je SKU, Projekt und Stunde, der detaillierte Export, der resource.name und resource.global_name hinzufügt, und der Preisexport, der den Listenpreis jeder SKU führt; die Exporte beginnen am Tag ihrer Aktivierung und füllen nie nach, was ihre Aktivierung zum ersten Schritt eines neuen Kontos macht. Jede Zeile trägt billing_account_id, project.id, project.number, project.name, project.ancestry_numbers für die Ordner darüber, project.labels, labels, system_labels und tags mit key, value, inherited und namespace; cost_type trennt regular von tax, adjustment und rounding error, und credits trägt jeden Rabatt und jedes Guthaben mit seinem Typ. Ein Unterkonto unter einem Reseller sieht seine eigene Nutzung. Den Aufbau beschreibt Google-Cloud-Abrechnungsexport und die Bedeutung der Spalten FOCUS-Spalten, wo BillingAccountId, SubAccountId für das Projekt, Tags und ChargeClass dieselben Fakten abbilden.
APIs. Die Cloud Billing API listet Rechnungskonten und die mit ihnen verknüpften Projekte und verschiebt ein Projekt zwischen Konten; die Cloud Billing Catalog API listet SKUs und ihre Preise, womit die sku.id einer Zeile auf einen Listenpreis abgebildet wird; die Resource Manager API legt Projekte, Ordner, Labels und Tag-Bindungen an. Der Bereich eines Budgets, das Dataset eines Exports und die Sicht eines Resellers sind alle nach der Rechnungskonto-ID geschlüsselt. Was die Berichte der Konsole über den Export hinaus zeigen, steht unter Google-Cloud-Abrechnungsberichte.
Stellhebel
Konfiguration: Der erste Hebel ist die Projektstruktur, weil jede Kostenzeile ihr Projekt trägt und ein Projekt je Team und Umgebung ohne ein einziges Label zuordnet; der zweite die Tag-Hierarchie, weil ein an einen Ordner gebundenes Tag jedes Projekt darunter erreicht und der Export es als geerbt trägt, womit Verantwortung dem Organigramm folgt; der dritte die Labels auf Ressourcen für das, was die Hierarchie nicht ausdrücken kann, Workload, Kunde oder Kostenstelle eines geteilten Projekts, mit einer Tagging-Richtlinie, die die Schlüssel nennt. Den detaillierten Export am ersten Tag aktivieren, weil Zuordnung auf Ressourcenebene erst von da an existiert.
Kaufoption: Keine; der Kontotyp entscheidet die Zahlungsbedingungen, und Rechnungsstellung ist eine Frage des Finanzprozesses, nicht des Preises, außer dass sie auf den Nutzungsrabatt verzichtet.
Architektur: Ein Rechnungskonto je Rechtsträger, der eine eigene Rechnung erhalten muss, und so wenige wie das, weil Budgets, Exporte und Committed Use Discounts je Konto sind und ein Commitment in einem Konto keine Projekte in einem anderen deckt; Ordner je Team oder Geschäftsbereich mit einem Tag je Ordner; und ein Projekt je Umgebung innerhalb eines Teams, damit Entwicklung und Produktion im Export ohne Label getrennt sind. Was die AWS- und Azure-Strukturen stattdessen tun, steht unter Organizations und konsolidierte Abrechnung und Azure-Abrechnungskonten: EA, MCA und CSP.
Wo es schiefgeht
- Der Export wurde im dritten Monat aktiviert. Der BigQuery-Export beginnt am Tag der Aktivierung und füllt nie nach; die ersten zwei Monate gibt es nur in den Berichten der Konsole. Die erste Handlung auf einem neuen Rechnungskonto ist der Export.
- Zwei Rechnungskonten, ein Commitment. Ein unter einem Rechnungskonto gekaufter Committed Use Discount deckt nur die Projekte, die es bezahlt. In ein anderes Konto verschobene Projekte verlieren die Deckung.
- Das Label liegt auf dem Projekt, nicht auf der Ressource.
project.labelstragen die Labels des Projekts auf jeder Zeile,labelsdie der Ressource; ein Bericht, der nur eines liest, verpasst das andere. Zuordnungsregeln lesen beide. - Das Tag wurde nachträglich gebunden. Tags gelten für Kosten ab dem Tag der Bindung, nicht rückwärts. Der Monat vor der Bindung hat im Export kein Tag.
- Der Reseller hält die Sätze zurück. Ein partnerabgerechnetes Unterkonto kann Nutzung zum Listenpreis sehen, während es den Preis des Resellers zahlt. Die Rechnung, nicht der Export, ist die Quelle für das, was bezahlt wurde.
- Das Invoiced-Konto hat den Nutzungsrabatt verloren. Der Wechsel von Self-Serve zu Rechnungsstellung beendet den automatischen Rabatt auf N1- und N2-Instanzen. Commitments ersetzen ihn.
- Projekte ohne Rechnungskonto. Ein Projekt, dessen Rechnungskonto getrennt wurde, stoppt seine kostenpflichtigen Dienste; ein mit dem falschen Konto verknüpftes Projekt belastet das falsche Team. Die Projektliste je Rechnungskonto ist die monatliche Prüfung.
Beispiel
Fakten und Zahlen, gelesen am 2026-10-22 aus der Cloud-Billing-Dokumentation, ohne Listenpreise, weil die Strukturen keine tragen: Ein Self-Serve-Rechnungskonto wird automatisch belastet, wenn seine Nutzung eine Zahlungsschwelle erreicht oder am Monatsende, ein Invoiced-Konto hat eine monatliche Rechnung mit Zahlungsbedingungen, und beide zahlen dieselben Listenpreise in USD oder der Währung ihres Zahlungsprofils.
Eine Organisation mit drei Rechtsträgern in Deutschland, Frankreich und den Vereinigten Staaten führt drei Rechnungskonten, eines je Rechtsträger, jedes mit eigenem Zahlungsprofil und eigener Rechnungswährung; ihre 40 Projekte liegen in Ordnern je Geschäftsbereich unter einer Organisation, mit einem Tag business-unit, das an jeden Ordner gebunden und von jedem Projekt geerbt wird, und einem Label env auf jedem Projekt für Entwicklung, Staging und Produktion. Im Export trägt eine Zeile für eine Instanz im Projekt payments-prod die billing_account_id des deutschen Rechtsträgers, project.id payments-prod, project.ancestry_numbers mit dem Ordner des Zahlungsbereichs, tags mit business-unit: payments und inherited: true, project.labels mit env: production und labels mit dem, was die Instanz selbst trägt, etwa team: checkout; ein Bericht nach Tag liefert den Geschäftsbereich, nach Projekt-Label die Umgebung, nach Ressourcen-Label das Team und nach Projekt den Dienst, ohne dass eines der vier zweimal gesetzt werden müsste. Ein unter dem deutschen Konto gekaufter Committed Use Discount deckt nur die deutschen Projekte; die Instanzen des französischen Rechtsträgers zahlen Listenpreis, bis er sein eigenes kauft. Das Beispiel zeigt, dass Hierarchie und Tags die ganze Rechnung ohne Ressourcen-Label zuordnen, dass Labels die Dimensionen hinzufügen, die die Hierarchie nicht kann, und dass Commitments und Budgets am Rechnungskonto enden.
Quellen
Gelesen am 2026-10-22. Dokumentation: Cloud-Billing-Konzepte und Kontotypen, Cloud-Rechnungskonto verwalten, Cloud-Billing-Daten nach BigQuery exportieren, Struktur des Standard-Exports der Cloud-Billing-Daten, Überblick über Tags.