Microsoft 365 Backup: what is billed?

A company cleans up SharePoint, reduces mailbox sizes and removes several accounts from protection. Operational reports show less data, yet its Microsoft 365 Backup charge does not fall at the same rate. The difference can be correct: a live-service report and the data protected for recovery measure different things.

Microsoft 365 Backup billing is not limited to the files and mailboxes currently available. Relevant archives and additional deleted or versioned content retained for recovery also matter. Removing an object from a protection policy is not the same as deleting its backups. To explain a charge, you need the protection scope, recovery window, object status and billing route.

This article covers the Microsoft 365 Backup tool available in Microsoft 365 administration. Partner applications built on Microsoft 365 Backup Storage can have their own offerings and partner-issued bills. We checked primary documentation on 14 October 2026. Verify the settings available to you and your contractual price when ordering.

A user licence is not the backup billing unit

Microsoft’s pricing model describes a PAYG service with a published list price of USD 0.15 per GB per month of protected content. This is not a fee per employee or a benefit automatically paid for by Microsoft 365 E3. The amount here is the stated USD list price, not a binding Czech quotation, a tax-inclusive price or a currency conversion.

Azure handles consumption billing. For this tool, the pricing document does not add Azure API or storage charges beyond the stated Backup consumption. That does not make other Azure services used alongside it free. For a partner application built on Backup Storage, the documentation instead says the partner bills for the application and Microsoft does not issue the customer a second, separate bill for its Backup Storage consumption.

When comparing offers, first record who bills for what. The direct Microsoft tool’s rate need not be a partner application’s price with different retention, service coverage or recovery features. Two offers cannot be compared using a single price per GB without defining what that GB includes.

Where the calculation grows

The pricing documentation distinguishes the live size of protected objects from additional recovery data. For SharePoint and OneDrive, it includes service size with the first-stage recycle bin and separately considers the second-stage bin. Supported mailboxes add associated online archives and deleted or versioned items retained in backups.

This table is a working inventory, not an exact invoice meter. Reports and estimates must use the same unit, period and object scope. Do not combine the entire tenant’s size with a policy that protects only some sites.

The pricing guide identifies admin-centre reports as incomplete for estimates because of second-stage recycle bins and online archives. It describes obtaining those sizes separately, for example through the appropriate PowerShell tools. A polished usage chart can therefore systematically underestimate the basis even when the chart itself is correct.

Model: 1,000 reported GB become 1,200

Hypothetical monthly illustration, not a customer invoice: all listed objects are protected, one consistent GB unit is used and changes during the month are ignored. Additional items are assumed to belong to the protected billing scope and not already be included in earlier totals.

The first three rows total 1,000 GB. Omitted rows increase the model by 200 GB, or 20% against the incomplete basis. At the published USD 0.15 rate, the simple illustration gives USD 180 per month rather than USD 150. It is not an actual invoice prediction: usage changes, measurement periods, contractual rates, currency and taxes affect the result.

For your own quotation, replace the rate with p: the estimate is 1,200 × p. Keep each volume’s source and measurement date in separate columns. A price change then does not require rebuilding inventory, and a data change is not mistaken for a rate increase.

Live-data cleanup has a cost tail

A backup is meant to retain content no longer present in the original service. After deleting files, you cannot simultaneously expect recoverability and assume their entire protected history immediately disappears from cost. Separate two timelines to explain the difference: live service size and content still available through recovery points.

Record the change month, deleted volume and applicable recovery window in the working budget. Then track actual billed consumption. Do not promise a precise reduction from a post-cleanup screenshot alone; older history may be expiring while new history is being created.

The calculator is not a billing meter either. Microsoft notes that its twelve-month estimate assumes no growth or data churn. For an organisation that creates and deletes large working files each month, a one-time size therefore does not describe the full annual budget. Produce low- and higher-churn scenarios grounded in your own history rather than one precise number without evidence.

Policy removal, offboarding and deletion

Removing a site, mailbox or account from its protection policy stops the corresponding new protection but does not request immediate deletion of all stored backups. The pricing document describes using size at removal as a proxy for live size during the remaining period. Backup deletion has a separate offboarding process.

The current guide specifies a standard 90-day offboarding grace period, with an option to shorten it to seven days for particular items subject to the required approvals. It separately describes the two-day aging window for a newly nominated approver, quorum and other conditions. This feature protects a particular accelerated-deletion action; it does not mean every administrative change uses the same approval process.

Offboarding is not routine cost optimisation with unchanged protection. It involves deleting recovery options. Before acting, establish who approved it, which data it affects and what recovery the company requires. Even the end of a grace period is not a universal promise of a zero invoice on that date without checking the current meter.

A one-year window is not universal

The Backup overview currently lists recovery windows of three months, six months, one year or two years by policy. Existing policies and artifacts default to one year. The FAQ and some billing examples still describe a one-year scope.

Record the actual policy for both budgeting and service-exit planning. Do not automatically apply a one-year tail example to every tenant item. Nor does a two-year window establish identical recovery-point density across that whole period: check the calendar and supported features for the particular service.

Supported object types are another boundary. The FAQ distinguishes user and shared mailboxes from other Exchange recipient types. If a budget totals every directory object or assumes recovery of the entire Teams application, first correct it to supported, selected units. The article on retention, archiving and backup explains their different purposes.

Attribute costs to the correct object

The Backup billing guide describes Azure Cost Management, tenant and service breakdowns and identification of protection units. SharePoint and OneDrive support attribution by Site ID. Breaking Exchange costs down by Mailbox ID requires an explicit setting and consent to send that identifier to Azure.

Do not confuse Mailbox ID with MailboxDbGuid. The documentation identifies the latter as internal and warns that its value may change. It is therefore unsuitable as a durable budget-to-mailbox key. Missing mailbox detail also does not automatically mean Exchange is not protected; attribution consent may simply be absent.

Departmental billing also involves permissions and the connection between billing policies and backup policies. Adding a department name to an invoice after the fact is insufficient. Verify that the administrator can see and use the relevant billing policy; an inaccessible policy can appear as Confidential.

Checks before enabling protection and after changes

1. Identify the billing route. Direct Microsoft tool or partner application; the relevant Azure subscription or partner account.
2. Record protection scope. Specific sites, OneDrive accounts and supported mailboxes. Include the recovery window and required restore outcome.
3. Add missing volumes. Assess second-stage recycle bins and online archives alongside live-service reports. Avoid counting included data twice.
4. Build an estimate with boundaries. Rate, unit, churn and measurement date. Distinguish a growth hypothesis from observed history.
5. Compare the first bill with the estimate. Match service and protection-unit breakdowns to the protected list. Actual cost takes precedence over the calculator.
6. Track the tail after cleanup. Record live-size changes separately from recovery-history and billing-basis changes.
7. Check offboarding when disabling protection. Distinguish object removal from backup deletion. Alongside cost, confirm which recovery options remain.

The outcome is an explainable budget and a verified recovery plan. A low bill alone does not prove good protection, and a high bill alone does not prove an error.