Copilot Cost Management API: Was sie kann und wofür du sie nutzt

Die Microsoft 365 Copilot Cost Management API liest und steuert den Credit-Verbrauch deines Tenants über Microsoft Graph. Du siehst, wie viele Credits gekauft und verbraucht sind, welche Ausgaberichtlinien gelten, wer Warnungen bekommt und warum ein Nutzer einen Dienst nicht nutzen darf.

Das Cost-Management-Dashboard im Microsoft 365 Admin Center zeigt den Verbrauch nach Richtlinie, Nutzer, Gruppe, Agent, Dienst und Finanzierung. Die API gibt dir Rohdaten, die du in eigene Systeme übernehmen und mit anderen Daten verbinden kannst.

Ich habe sie am 29. Oktober 2026 in meinem Test-Tenant vollständig durchgespielt. Hier steht, was sie ist, was zurückkommt und wofür ich sie einsetze. Das Dashboard, das ich daraus gebaut habe, liegt im Lookbook und auf GitHub.

Was ist die Copilot Cost Management API?

Es ist eine Erweiterung von Microsoft Graph unter dem Pfad /copilot/costManagement. Sie gehört zur Abrechnung nach Verbrauch: Dienste wie Copilot Cowork und Work IQ rechnen in Copilot Credits ab, und Admins steuern über Ausgaberichtlinien, wer wie viele Credits verbrauchen darf. Diese Steuerung bildet die API ab.

Wichtig vorab: Die API liegt unter /beta. Microsoft schreibt in der Dokumentation, dass Beta-APIs sich ändern können und für Produktivanwendungen nicht unterstützt werden. Für eigene Auswertungen und Skripte heißt das: Prüfe die Aufrufe regelmäßig.

Was liefert die API, und was nicht?

Ich habe die Funktionen aus der Dokumentation von Microsoft in sechs Gruppen geordnet und zu jeder die Rechte ergänzt, die der Aufruf braucht.

Was die API bewusst nicht liefert, steht ebenfalls in der Dokumentation: Sie ist in Credits gerechnet und enthält keine Währungsbeträge, Rechnungen, Preise oder Prognosen. Den Euro-Betrag rechnest du selbst aus, mit dem Preis, der in deinem Vertrag steht.

Zwei Einschränkungen habe ich im Test selbst gesehen. Erstens liefert sie Momentaufnahmen. Beim Credit-Stand steht nur der Zeitstempel der letzten Aktualisierung, einen Verlauf gibt es nicht. Wer wissen will, wie sich der Verbrauch über die Wochen entwickelt, muss den Abruf regelmäßig selbst ablegen. Zweitens lässt sich die Liste aller Nutzersalden nicht abrufen: Der Aufruf auf userBalances ohne Nutzer-ID endet mit 404. Du fragst Nutzer für Nutzer ab und brauchst dafür die Nutzerliste aus einer anderen Quelle.

Was habe ich im Test-Tenant gesehen?

Ich habe alle 22 dokumentierten Operationen aufgerufen, in 62 Aufrufen innerhalb von rund 19 Sekunden: 51 liefen wie erwartet durch, 11 endeten absichtlich mit einem Fehler (zehn beim Schreiben, dazu der 404 auf userBalances), unerwartete Antworten gab es keine. Die Schreibaufrufe liefen gegen eine Testrichtlinie, die ich angelegt und am Ende wieder gelöscht habe. Namen, Kennungen und Adressen habe ich hier weggelassen.

Der Credit-Stand

Ein einziger Aufruf liefert den Stand für beide Abrechnungsarten:

GET https://graph.microsoft.com/beta/copilot/costManagement/getTenantCreditBalance

Zwei Dinge fallen auf. Die Daten waren beim Abruf über eine Stunde alt, der Zeitstempel stand auf 09:50 Uhr UTC, der Aufruf lief nach 11:05 Uhr. Und 50.000 minus 22.265,38 ergibt 27.734,62, die API nennt aber 25.029 als Rest. Die Differenz von rund 2.706 Credits kann ich aus den Antworten nicht erklären. Deshalb rechne ich den Restbestand nicht selbst nach, sondern lese das Feld remainingQuantity.

Für Pay-as-you-go nennt die API nur den Verbrauch. Bei 0,01 US-Dollar je Credit, wie im Artikel zum Copilot-Bezahlmodell beschrieben, wären das rechnerisch rund 31,52 US-Dollar. Diesen Schritt macht die API nicht für dich.

Die Richtlinien

In meinem Tenant gibt es eine Richtlinie mit dem Namen „All Users Policy“. Der Name klingt nach allen Nutzern. Der Typ im Ergebnis ist aber selectedGroupsSpendingPolicy, und die Richtlinie gilt für genau eine Sicherheitsgruppe. Wer nur auf den Namen schaut, liest etwas Falsches. Die API zeigt den tatsächlichen Typ, die zugewiesene Gruppe, die vier geregelten Dienste (cowork, workIQ, sharePointCopilot, oneDriveCopilot) und die Limits. Beide Limits stehen hier auf unbegrenzt.

An derselben Richtlinie hängt eine Warnung: aktiv, mit einer absoluten Schwelle von 25.000 Credits. Prozentuale Schwellen sind ebenfalls möglich, laut Dokumentation als ganze Zahl zwischen 1 und 100.

Warum darf jemand einen Dienst nicht nutzen?

Der Nutzersaldo beantwortet eine Supportfrage, die sonst Klickarbeit im Admin Center ist. Für das Konto, das ich abgefragt habe, kam das hier zurück:

"unevaluatedServices": [
  { "serviceId": "cowork", "reason": "noApplicablePolicy" },
  { "serviceId": "workIQ", "reason": "noApplicablePolicy" }
]

Für Cowork und Work IQ greift bei diesem Konto keine Richtlinie, die Liste der Dienstsalden ist leer. Die einzige Richtlinie im Tenant gilt nur für eine Gruppe. Ich lese das so, dass die Zuordnung fehlt und nicht ein Limit erreicht ist. Das habe ich an einem einzigen Konto gesehen, prüfe es bei deinen Nutzern nach.

Eine Warnung zum Datenschutz: Die Liste der Warnempfänger gibt komplette Benutzerobjekte zurück, bei mir inklusive Telefonnummer und Nebenadresse. Behandle das Ergebnis wie Personendaten und speichere nur, was du brauchst.

Was passiert, wenn du schreibst?

Schreibende Aufrufe prüfen vieles, bevor sie etwas ändern. Die Fehlerantworten zeigen die Regeln. Zehn davon habe ich absichtlich ausgelöst. Die letzte Zeile (409) kam, als ich die Abrechnungsart einer deaktivierten Testrichtlinie ohne Zielgruppe ändern wollte. Mein Testplan hatte 200 und 409 als mögliche Antworten vorgesehen:

Die Konsequenz für eigene Skripte: Jede Änderung an einer bestehenden Richtlinie beginnt mit einem Lesen, um den aktuellen ETag zu holen, und endet mit einer Prüfung der Antwort. Außerdem lässt sich ein Dienst nicht löschen. Laut Dokumentation setzt du ihn auf disabled, und der Eintrag bleibt stehen.

Wofür nutzt du die API?

Das Dashboard im Admin Center beantwortet die Frage „Was ist verbraucht?“. Die API lohnt sich, wenn du eine andere Frage hast. Die folgenden Punkte sind Einsatzideen, die sich aus den Antworten ergeben. Gebaut habe ich davon das Inventar-Dashboard unten, die übrigen sind nicht erprobt.

Wie übernimmst du die Daten in eigene Systeme?

Weil die Antworten JSON sind, kannst du sie dorthin schreiben, wo ihr ohnehin arbeitet: in eine Liste, eine Datenbank, ein Ticketsystem oder einen Flow. Ein nächtlicher Lauf legt zum Beispiel den Credit-Stand ab, und daraus entsteht der Verlauf, den die API selbst nicht hat. Ein Ticket kann entstehen, wenn bei einem Nutzer noApplicablePolicy steht. Und weil Richtlinien lesbar und änderbar sind, kannst du sie in einer Datei beschreiben und mit dem Ist-Zustand vergleichen, bevor jemand sie im Admin Center ändert.

Was lässt sich genauer auswerten?

Die API liefert Credits, kein Geld. Du kannst den Preis aus deinem Vertrag nehmen, nach Abrechnungsart getrennt rechnen und Szenarien durchspielen: Was kostet es, wenn die Pay-as-you-go-Gruppe doppelt so viel verbraucht? Wie weit reichen die vorausbezahlten Credits bei dem Tempo der letzten Wochen? Wer ist der größte Verbraucher je Dienst? Solche Antworten brauchen deine eigenen Annahmen, die API liefert dir die Zahlen dafür.

Womit kombinierst du die Daten?

Der größte Nutzen entsteht, wenn du die Antworten mit Daten verbindest, die Microsoft dir nicht mitliefert:

• Gruppenmitglieder aus Microsoft Graph: Erst damit weißt du, für wie viele Personen eine Richtlinie überhaupt gilt. Mein Sammelskript fragt dazu die Mitglieder der zugewiesenen Gruppen ab.
• Verzeichnisdaten wie Abteilung oder Kostenstelle: Damit lässt sich der Verbrauch auf Bereiche umlegen.
• Lizenzzuordnung und Nutzungsberichte: Wer hat eine Lizenz, nutzt sie aber nicht, und wer verbraucht Credits ohne Richtlinie?
• Eigene Budgets: Credits gegen die Planung des Controllings gestellt.

Gibt es ein fertiges Dashboard dazu?

Aus diesem Test ist ein Werkzeug entstanden: das Copilot Cost Inventory. Zwei Sammelskripte (PowerShell für Windows, zsh für macOS) lesen nur, sie senden ausschließlich GET-Anfragen. Getestet habe ich das macOS-Skript. Das PowerShell-Skript für Windows habe ich nicht selbst ausgeführt. Das Ergebnis ist eine JSON-Datei. Die ziehst du in eine einzelne HTML-Datei, die offline im Browser läuft und nichts hochlädt. Dort siehst du Credit-Stand, Verbrauch je Dienst und je Richtlinie, die Auslastung des Limits je Nutzer, die größten Verbraucher und eine Diagnose aller API-Aufrufe.

Im Lookbook läuft das Dashboard mit erfundenen Beispieldaten eines fiktiven Tenants, du kannst es dort ausprobieren. Die Oberfläche ist englisch. Das Paket mit Dashboard-Datei, beiden Skripten und Anleitung lädst du im Lookbook kostenlos und ohne Anmeldung herunter. Den Quellcode gibt es unter MIT-Lizenz auf GitHub. Es ist ein Community-Projekt von Copilot Coaching und steht in keiner Verbindung zu Microsoft.

Zwei Hinweise vor dem Einsatz im eigenen Tenant:

• Die erzeugte JSON-Datei enthält Namen, Anmeldenamen, Verbrauch je Person und Warnempfänger. Gib sie nicht weiter und lege sie nicht in ein Repository.
• Bei der ersten Anmeldung fragt das Skript einen Admin nach den Berechtigungen für die „Microsoft Graph Command Line Tools“. Diese Zustimmung bleibt im Tenant bestehen, bis ein Admin sie entfernt. Das Skript weist selbst darauf hin.

Was solltest du vor dem Einsatz wissen?

• Rechte: Fast alle Operationen kennen nur delegierte Berechtigungen, also eine Anmeldung mit Arbeits- oder Schulkonto. Nur der Credit-Stand lässt sich auch mit einer Anwendungsberechtigung lesen. Eine Richtlinie anzulegen verlangt zusätzlich die Rolle Billing Administrator oder Global Administrator.
• Beta: Felder und Fehlercodes können sich ändern. Prüfe ein Skript nach Änderungen bei Microsoft erneut.
• Ein Tenant: Ich habe die API in einem einzigen Test-Tenant geprüft. Wie sie sich in großen Tenants mit vielen Richtlinien verhält, habe ich nicht gemessen.
• Schreiben mit Vorsicht: Teste jede Änderung zuerst mit einer eigenen Testrichtlinie, so wie ich es getan habe.

Wenn du die API für deinen Tenant einsetzen oder die Auswertung mit euren Daten verbinden willst, ist das ein Thema für das Coaching für IT und Admins.

Quellen

• Microsoft Learn: Microsoft 365 Copilot Cost Management API overview, costManagementRoot: getTenantCreditBalance
• Microsoft Learn: Understand usage-based billing and cost management for Copilot Credits
• Eigene Aufrufe vom 29. Oktober 2026 in einem Test-Tenant, 62 Aufrufe gegen alle 22 dokumentierten Operationen

Stand: 29. Oktober 2026. Die API ist eine Beta, Felder, Rechte und Fehlercodes ändern sich erfahrungsgemäß ohne Vorankündigung.