Under a Microsoft Customer Agreement, Azure credits sit on the billing profile and a budget does not stop spend past them

Under a Microsoft Customer Agreement, Azure credits are applied to the invoice of a billing profile, not to the subscription an operator happens to be looking at. A Cost Management budget sends a notification when a threshold is crossed and stops nothing. The Azure spending limit, the one built-in control that disables resources automatically, is not available with pay-as-you-go pricing, and under this agreement it appears as a property of the billing profile that reads On or Off. Three separate facts, each easy to assume works like the others.

Last verified: 2026-09-15.

What Microsoft documents about credits

Track your Azure credit balance for a Microsoft Customer Agreement, read 2026-09-15, states where a credit lives:

In the billing account for a Microsoft Customer Agreement, credits are assigned to a billing profile. Each billing profile has its own credits that are automatically applied to the charges on its invoice.

The same page states what happens at the end of the balance: "When your available balance drops to zero, you're charged for all your usage, including products that are eligible for credits." Products the credits never cover, such as Azure support plans and non-Microsoft Marketplace offers, are "billed separately and charged regardless of your available Azure credit balance." In the scope table of Billing accounts and scopes in the Azure portal, the billing profile is the scope that carries the invoice and the payment methods, and its invoice sections carry the Azure subscriptions. The credit belongs to the invoice, and the charge past it goes to the payment method on that same profile.

Two redemption experiences for partner credits

Use your Azure credits, the Partner Center benefits page, describes two redemption flows side by side. The legacy one is explicit about where credits land:

You can use only the Azure credits provided with a new Microsoft AI Cloud Partner Program purchase, such as a Microsoft Action Pack subscription or legacy Silver or Gold, on a new Azure subscription. You can't use the credits on an existing Azure subscription. After you redeem any new Azure sponsorship, you must move all of your resources under this new subscription to use the sponsorship credits.

The modernized flow deposits credits on an MCA standard or MCA premier billing profile the partner selects, and the page states that all existing and new subscriptions under that profile can use them. Which flow applies is not the partner's choice. It depends on country or region rollout and on the parent offer: a benefit whose parent offer was bought in the legacy experience stays in the legacy experience even after the rollout reaches the partner. On timing the page says "Most countries/regions are expected to be covered by end of July 2026." That date had passed when this note was verified, so the Partner Center screen, read on the day, is the reliable answer. The modernized flow also states that the billing profile "must have a valid credit card or payment method linked" before credits can be deposited.

What a Cost Management budget actually does

Quickstart: Create a budget with Bicep says in its first paragraph: "When the budget thresholds you've created are exceeded, notifications are triggered. None of your resources are affected and your consumption isn't stopped." The notification is also late by design. Tutorial: Create and manage budgets states that "Cost and usage data is typically available within 8-24 hours and budgets are evaluated against these costs every 24 hours", and that email notifications are "normally sent within an hour of the evaluation."

Making a budget stop anything is a second project. Manage costs with budgets builds three components beside the budget: an Automation runbook that stops virtual machines, a Logic App the budget's action group calls, and the Azure Monitor action group itself, wired to the chosen thresholds. Its summary names the result: "You now have a fully functional budget for your subscription that shuts down your VMs when you reach your configured budget thresholds." None of those three exists until an operator builds and tests it. The budget tutorial adds that action groups "are currently only supported for subscription and resource group scopes", so a budget set on the billing profile, the scope where the credit sits, cannot call one.

flowchart TD
  accTitle: What stops Azure spend once the credit is used
  accDescr: Reading the billing profile spendingLimit property decides the path. When it reads On, deployed services are disabled at the limit. When it reads Off, a Cost Management budget only sends a notification, and an Azure Policy deny rule is what refuses a new matching request.
  A[Read spendingLimit] --> B{Value on profile}
  B -->|On| C[Disabled at the limit]
  B -->|Off| D[Budget notifies only]
  D --> E[Deny blocks new requests]

Where the spending limit lives

Azure spending limit describes the control that does stop spend. It is turned on by default for an Azure free account and for subscription types that include credits over multiple months, it equals the credit amount, and when charges exhaust it "the services that you deployed are disabled for the rest of that billing period." The same page says the limit is not available for subscriptions with commitment plans or pay-as-you-go pricing: "For those types of subscriptions, a spending limit isn't shown in the Azure portal and you can't enable one." The Azure Plan offer page puts the Microsoft Customer Agreement plan in that category: "An Azure plan gives you access to Azure services at standard pay-as-you-go rates under the Microsoft Customer Agreement." On Microsoft's Azure Offer Details list, read in the page source on 2026-09-15, the Spending Limit cell for Azure Plan, offer 0017G, is empty while the Free Trial row carries a check icon, above the footnote "There is no spending limit on offers where the Spending Limit column is left blank." Create a Microsoft Customer Agreement subscription also offers Microsoft Azure Plan for DevTest, which has no row on that list.

Under a Microsoft Customer Agreement the limit is also a billing profile setting. The Billing REST reference Billing Profiles - Get returns a spendingLimit property on the billing profile with the values On and Off, and a spendingLimitDetails list whose type values include FreeAccount, MpnSponsorship, AzureConsumptionCredit, Sponsorship and VisualStudio. Its sample response, with illustrative values, shows a profile reading On with a FreeAccount limit of 200 USD. None of the pages read for this note says whether a partner credit deposit sets that property to On, so the value on the profile is the one to plan against.

Why it is easy to get wrong

Two habits carry over from a free account or a Visual Studio subscription. The first is expecting the automatic stop: those offer types have the limit on by default, so resources stop at the credit amount without anyone configuring anything. A subscription on the Azure Plan does not inherit that behaviour, and whether its billing profile carries a limit has to be read from the profile.

The second habit is reading the word budget as a cap. A poster on Microsoft Q and A described the collision: a $150 monthly credit on a Visual Studio subscription, a $175 budget with an alert at 90 percent of it, and a month where "nothing turned off, no notification was received and it has consumed over $1500 in service costs." The answer the poster accepted, written by a volunteer moderator, does not blame the budget. It asks whether the spending limit had been removed indefinitely, because that setting was what had been turning the services off at $150 in earlier months.

The cost of the misreading is on the credit page quoted above: at a zero balance all usage is charged, to a payment method the modernized flow required before the deposit. A budget alert, on the cadence above, can arrive the day after that usage.

Recommendation

Read the billing profile's spendingLimit before deciding anything. Where it reads Off, or where the subscription runs on the Azure Plan, treat a Cost Management budget as a notification channel and nothing more. Where new spend has to be refused before it is billed, the mechanism that does that is an Azure Policy assignment with the deny effect, scoped to the resource types, SKUs and regions worth guarding. Azure Policy definitions deny effect documents the behaviour directly: "When creating or updating a matched resource in a Resource Manager mode, deny prevents the request before being sent to the Resource Provider. The request is returned as a 403 (Forbidden)." Where running spend has to be reduced after a threshold, wire a subscription-scope budget to an action group that calls a tested runbook, the way the automation tutorial above does.

Trade-offs

A deny policy refuses a matching request before any resource exists, so it is the only mechanism here that prevents the first unit of spend, and because it evaluates the request itself it does not wait on the billing pipeline. Its cost is coverage: it refuses only what its rule matches, and the rule needs upkeep as the estate grows. It also takes effect after a delay. Microsoft publishes a figure for one integration, Integrate Azure Key Vault with Azure Policy, where assigning a policy with the deny effect may take "up to 30 mins (average case) and 1 hour (worst case) to start denying the creation of non-compliant resources." That figure is Key Vault's own and shows only that propagation takes time.

A budget wired to an action group reaches further than a deny policy, because it can act on resources already running, but it inherits the cost data latency above and works only at subscription and resource group scope. A budget with no action group costs nothing and sees everything, but depends on a person reading an email in time, the step that failed in the Q and A example.

Where it does not apply

None of this describes a billing profile or subscription whose spending limit reads On: an Azure free account or an offer with credits over multiple months keeps its automatic stop until someone removes the limit, and a deny policy there is an added layer. It describes a partner still on the legacy redemption flow only in part, because there the credit sits on a new subscription created for the purpose. And it does not describe an Enterprise Agreement enrollment, an MCA individual or MCA enterprise billing profile, or a subscription under a Microsoft Partner Agreement: the partner credit page lists all of those as unsupported for credit deposits, and none was examined further here.

How to check it

Three read-only GET calls answer three questions: which billing profiles the caller can see, what credit sits on one, and whether that profile carries a spending limit. The credit page states that PowerShell and the Azure CLI are not supported for the credit read.

/* Read-only. Names in braces come from the response to call 1. */

/* 1. Billing accounts and the billing profiles under them. */
GET https://management.azure.com/providers/Microsoft.Billing/billingAccounts?$expand=billingProfiles&api-version=2019-10-01-preview

/* 2. Credit lots on one billing profile. Needs Owner, Contributor, Reader
   or Invoice manager on the profile, or Owner, Contributor or Reader on
   the billing account. Available balance = sum of closedBalance over
   active lots; expired and future-dated lots are returned too. */
GET https://management.azure.com/providers/Microsoft.Billing/billingAccounts/{billingAccountName}/billingProfiles/{billingProfileName}/providers/Microsoft.Consumption/lots?api-version=2023-03-01

/* 3. The billing profile itself. Read properties.spendingLimit (On or Off)
   and the type, status and amount in properties.spendingLimitDetails. */
GET https://management.azure.com/providers/Microsoft.Billing/billingAccounts/{billingAccountName}/billingProfiles/{billingProfileName}?api-version=2024-04-01

A profile whose spendingLimit reads Off has nothing that stops spend at the credit amount, and a missing value is safest treated as Off. Active lots summing to zero mean the next usage is charged to the payment method on the profile.

Limitations

This note does not establish what a partner credit deposit does to the billing profile's spendingLimit: the Billing API lists MpnSponsorship among spending limit types, and no page read here says when that type applies. It does not establish that closedBalance is current: the credit page defines it as the balance as of the last invoice, so usage since that invoice is not in it. It gives no date for regions the modernized redemption has not reached, because Microsoft states a target for most, end of July 2026, and nothing for the rest. The Azure Offer Details table was read from the page source, because a text extraction of the same page reported its check-icon cells as blank. And the Policy propagation figure is Key Vault's own, an illustration and no basis for a response-time plan.

Confirming the billing model before writing a budget, runbook or Policy rule around it is part of the groundwork in Azure cloud infrastructure engagements.