Microsoft 365 storage overages do not appear suddenly. They accumulate quietly, line item by line item, until an admin opens the Microsoft 365 admin center one day and sees a charge for gigabytes of storage nobody consciously chose to purchase. The mechanism behind the charge is not complicated, but the specific triggers that push a tenant over its included quota are routinely misunderstood, which is why the bill always comes as a surprise.
What counts toward your SharePoint storage quota
Microsoft 365 includes a shared SharePoint Online storage pool for the entire tenant. The baseline allocation is 1 TB plus 10 GB per licensed user. A 300-person organisation with Microsoft 365 Business Standard licenses therefore has a pool of 1 TB + 3 TB = 4 TB before any additional storage purchases apply. Every gigabyte above that pool costs $0.20 USD per month.
What draws from that pool is broader than most admins expect:
- Current file content in every site collection. Every document, image, video, and attachment stored in any SharePoint site draws from the pool. This is the obvious part.
- Version history of every file. Each stored version of each file consumes quota, whether or not any user ever retrieves it. For binary files (PDFs, images, videos), each version is a full copy. This is the part that surprises most admins.
- Recycle bin contents. Both stages of the SharePoint recycle bin count toward storage for their entire 93-day retention period. A user deleting a 10 GB video folder does not free 10 GB of quota; it keeps consuming 10 GB until the recycle bin entry expires or is permanently cleared.
- Microsoft Teams channel files. Every Teams team creates a SharePoint site collection in the background. Files shared in Teams channel conversations, meeting recordings sent to channel folders, and files attached to channel posts all land in that site collection and draw from the shared storage pool.
- OneNote notebooks stored in SharePoint. When OneNote notebooks are housed in a SharePoint library rather than OneDrive for Business, their storage consumption counts against the SharePoint pool and can be substantial for heavily used notebooks.
What does not draw from the SharePoint pool: user mailboxes (Exchange Online allocation), OneDrive for Business files (each user has a separate per-user allocation), and any Microsoft 365 Archive storage (archived content moves to a separate, lower-cost tier).
The five triggers most admins overlook
Knowing what counts is only half the picture. These are the specific behaviours and settings that push tenants toward overage charges faster than they expect:
| Trigger | Why it grows unnoticed | Typical impact |
|---|---|---|
| Version history accumulation | Default limit of 500 versions per file applies per file, not per library. Active libraries accumulate quietly over years. | Often exceeds current working content by a ratio of 5:1 to 50:1 in mature tenants |
| Recycle bin buildup | Deleted files appear to be gone from users' view, but continue counting against quota for 93 days | Project libraries after bulk cleanup events can add hundreds of gigabytes to the bin for three months |
| Teams channel file growth | Meeting recordings, pinned files, and channel attachments accumulate in hidden SharePoint site collections that most admins never visit directly | In active organisations, Teams-related SharePoint storage often rivals or exceeds traditional document library usage |
| Large binary files with versioning enabled | PDFs, high-resolution images, and ZIP archives store each version as a full copy. A library that regularly receives updated large files can accumulate version storage quickly | A 200 MB PDF updated weekly at version limit 500 can accumulate up to 100 GB in version history alone over time |
| Abandoned and empty site collections | Sites provisioned for projects, teams, or events that were never used or never cleaned up after completion. Each holds its allocation and any content left behind | Moderate individually but collectively significant in larger tenants; also draws IT support time to investigate |
Version history is consistently the largest single controllable storage consumer in tenants that have been running for more than two or three years. The 500-version default per file means any frequently edited document can accumulate hundreds of historical copies, most of which will never be retrieved. See the SharePoint version history trimming guide for the practical steps to address it.
Reading your Microsoft 365 storage report
Two reports in the Microsoft 365 admin center surface SharePoint storage consumption. Neither tells the complete story on its own.
The SharePoint storage card in the Microsoft 365 admin center home (Reports then Usage then SharePoint) shows total storage used versus total allocated for the tenant. It gives an immediate picture of how close you are to the quota ceiling but nothing about where the storage is going.
The site storage usage report (accessible from the SharePoint admin center under Reports then Site usage) shows storage consumed per site collection. This tells you which sites are the largest consumers, which is useful for targeting cleanup effort. What it does not show is the breakdown between current content, version history, and recycle bin within each site. That granularity requires PowerShell or a dedicated reporting tool.
The critical blind spot in native reporting is version history. A site showing 500 GB of storage in the admin center report might have only 40 GB of files that users actively access; the other 460 GB could be version history that no one has looked at in years. Without a tool that breaks storage down to the library level and separates current content from historical versions, you cannot target a cleanup efficiently.
When it is cheaper to clean up than to buy more storage
Microsoft sells additional SharePoint storage in increments of 1 GB at $0.20 USD per GB per month, billed annually. That works out to $2.40 per GB per year. For a tenant carrying 2 TB of unnecessary version history and recycle bin content, the ongoing charge is $400 per month or roughly $4,800 per year.
The cleanup calculation is straightforward: if the volume of storage that could be reclaimed through version trimming, recycle bin clearing, and empty site removal exceeds a few hundred gigabytes, a one-time investment in a tool that automates the process pays for itself in the first billing cycle.
The calculation shifts the other way when the volume of genuinely excess storage is small (a few dozen gigabytes), when compliance requirements mean version history must be preserved regardless of cost, or when the organisation is planning a major restructure that will naturally reduce the site count. In those cases, purchasing additional storage is the right call.
The comparison point most organisations miss: the native SharePoint admin center has no bulk version delete. Doing the cleanup manually, library by library, requires either PowerShell scripting skills (and the time to build and test the script safely in a production environment) or accepting that the cleanup will not get done at all. The $4,800 annual charge for excess storage often persists not because admins chose to pay it but because the manual alternative was too slow to prioritise.
Preventing overages before they happen
The tenants that avoid storage surprise bills share a few consistent practices:
Set version limits at library creation, not after the fact. The default 500-version limit is a placeholder, not a recommendation. For most document workflows, 10 to 20 versions per file captures all practical recovery value. Set the limit when the library is provisioned and it costs nothing; lowering the limit after three years of accumulation reclaims no historical storage automatically and still requires a bulk trim.
Schedule a quarterly version audit and trim. Even with a low version limit in place, active libraries accumulate storage. A quarterly pass using a version trimmer that targets files with more than a specified number of versions, or versions older than a set date, keeps the baseline from drifting upward. The audit also surfaces libraries where the limit was never set correctly.
Empty the recycle bin for completed project sites. When a project site is decommissioned, content is often bulk-deleted to clean up the site. Those deleted items then sit in the recycle bin for 93 days, keeping the site's storage allocation elevated. A deliberate second-stage bin clear at decommission time frees the storage immediately rather than waiting three months.
Review the storage report monthly, not quarterly. Storage accumulates continuously. A quarterly review gives problems three months of runway before they are detected. Monthly review is fast (five minutes with the admin center report) and catches drift before it becomes an overage charge.
A stable Microsoft 365 storage posture is not the result of a single large cleanup; it is the result of a few consistent habits applied on a short cycle. The cleanup tools make the habits feasible at scale.
Frequently Asked Questions
How much does Microsoft charge for SharePoint storage overages?
Microsoft charges $0.20 USD per GB per month for SharePoint Online storage consumed above the tenant's included allocation. The included allocation is 1 TB plus 10 GB per licensed user. A tenant with 500 Microsoft 365 Business Standard licenses has a base allocation of 1 TB plus 5 TB (500 x 10 GB) = 6 TB before any overage applies.
Do SharePoint recycle bin contents count toward storage quota?
Yes. Items in the SharePoint recycle bin continue to count toward the site's storage allocation for their full 93-day retention period. Both the first-stage and second-stage recycle bins count. A deleted item only stops consuming quota when it is permanently deleted from the second-stage bin or automatically purged after the 93-day retention window expires.
Does SharePoint version history count toward storage quota?
Yes. Every stored version of every file in SharePoint Online draws from the site's storage allocation. For Office documents (Word, Excel, PowerPoint), versions are stored as binary diffs so the per-version cost is a fraction of the full file size. For all other file types including PDFs, images, videos, and ZIP archives, each version is a full copy.