The accounting boundary: COGS vs operating expense
The first question is not how much — it is which dollars. Cloud cost of goods sold is the share of the hosting bill that delivers the live product to paying customers: production compute, production storage, production databases, and the bandwidth that serves real traffic. That is the cost-of-revenue line. It is the number that sets gross margin.
Everything else sits somewhere other than COGS. Development and staging environments, the analytics warehouse, internal tooling, and CI pipelines are operating expense — they support the business but do not deliver the product to a customer. Cloud spent building genuinely new internal-use software can, under ASC 350-40, be capitalizable rather than expensed at all; that is a determination to make with your accountant, not a default.
Get this boundary wrong in the obvious direction — treating the whole cloud bill as COGS — and you overstate the gross-margin headwind by twenty to forty percent for a typical SaaS company. This guide is the math companion to the cloud cost of goods sold definition; that entry covers what COGS is, this one covers how to compute it from a real multi-cloud bill.
- COGS is production compute, storage, databases, and customer-serving bandwidth.
- Operating expense is dev, staging, analytics, internal tooling, and CI.
- Internal-use software development may be capitalizable under ASC 350-40 — decide with your accountant.
- Treating the entire cloud bill as COGS overstates the margin headwind by 20 to 40 percent.
The allocation math, step by step
Step one is to split the bill. Use account, tag, and rule-based allocation to separate production from non-production: a dedicated production account or an env=prod tag is the cleanest signal, and where those are missing a resource-name regex carries the load. Sum the production side — that is the raw COGS pool.
Step two is shared services. Some spend genuinely serves both production and non-production — a logging pipeline, a shared network, a monitoring stack. Pick one allocation basis and apply it consistently: by production's share of compute, or by traffic, or a fixed agreed split. The basis matters less than applying the same one every month so the trend is comparable.
Step three is the calculation. Cloud COGS equals the production pool plus the production share of shared services. Worked example: a hundred-thousand-dollar monthly cloud bill, sixty-five thousand of it clearly production, ten thousand shared of which production takes seventy percent, gives cloud COGS of seventy-two thousand — and on four hundred thousand dollars of revenue, that is an eighteen percent cloud-COGS ratio.
- Step 1: split production from non-production with account, tag, and regex rules; sum production.
- Step 2: allocate shared services on one consistent basis — compute share, traffic, or a fixed split.
- Step 3: cloud COGS equals the production pool plus the production share of shared services.
- Worked example: $65K production plus 70% of $10K shared gives $72K cloud COGS.
Per-customer and per-product COGS
A single company-wide COGS number sets gross margin, but it hides the more useful story. Break cloud COGS down by product line and by plan tier and the picture changes — almost every SaaS business discovers that some cohorts are gross-margin-positive and some are quietly margin-dilutive, and the average concealed it.
The mechanics are the same allocation rules pointed one level finer: instead of mapping spend to production, map it to product=search or plan=enterprise. Where a resource serves all customers, allocate it by a usage proxy — seats, requests, or storage consumed. The output is cloud COGS per product and per tier, and from there cloud cost per customer.
This is what turns a COGS calculation into a pricing and strategy input. If the free tier costs more per user to host than the entry plan earns, that is a pricing decision the COGS breakdown just made visible. If one product line runs at half the gross margin of the others, that is a roadmap conversation. The company-wide number is for the board; the per-cohort breakdown is for the decisions.
- A company-wide COGS number sets gross margin but hides margin-dilutive cohorts.
- Allocate one level finer — product line, plan tier — using the same rule engine.
- For shared resources, allocate by a usage proxy: seats, requests, or storage.
- Per-cohort cloud COGS turns a P&L figure into a pricing and roadmap input.
Forecasting COGS as the business grows
Cloud COGS does not scale linearly with revenue, and forecasting it as if it does produces a gross-margin plan that breaks by Q2. Some COGS is fixed regardless of customer count — baseline production capacity. Some is step-fixed — you add a database replica at a usage threshold. And some is variable — bandwidth and per-request compute that move with every customer.
Forecast the three components separately. Hold the fixed baseline, model the step changes against your capacity thresholds, and drive the variable portion off the customer and usage forecast. Combined, that gives a forward cloud-COGS line — and dividing it into forecast revenue gives a forward gross-margin trajectory the board can actually plan a raise or a profitability path against.
Then close the loop. Each month, compare actual cloud COGS to the forecast, decompose the miss, and feed it back — the same monthly habit that makes any cloud forecast improve. A cloud-COGS number that is calculated once and never re-checked is a snapshot; one wired to the monthly close is a trajectory, and the board cares about the trajectory.
- Cloud COGS has fixed, step-fixed, and variable components — it does not scale linearly with revenue.
- Forecast each component separately, then combine for a forward cloud-COGS line.
- Forward cloud COGS divided by forecast revenue gives the gross-margin trajectory the board plans against.
- Re-check actual vs forecast monthly so the COGS number is a trajectory, not a snapshot.
Related concepts
Who tovin.io is for
Frequently asked
What counts as COGS in a SaaS cloud hosting bill?
The spend that delivers the live product to paying customers — production compute, production storage, production databases, and customer-serving bandwidth. Dev, staging, analytics, internal tooling, and CI are operating expense, not cost of revenue.
How do I calculate cloud COGS from a multi-cloud bill?
Split the bill into production and non-production with account, tag, and regex rules, sum the production side, add the production share of any shared services on a consistent basis, and report that total as cost of revenue. Do it the same way every month so the trend is comparable.
Is the whole cloud bill cost of goods sold?
No. Treating the entire cloud bill as COGS overstates the gross-margin headwind by roughly twenty to forty percent for a typical SaaS company, because it sweeps dev, staging, analytics, and internal R&D environments into cost of revenue where they do not belong.
How do I allocate shared cloud services to COGS?
Pick one allocation basis — production's share of compute, traffic, or a fixed agreed split — and apply it consistently every month. The choice of basis matters less than the consistency; switching bases between periods makes the gross-margin trend uncomparable.
What is the difference between this guide and the SaaS cost of goods sold guide?
The cloud cost of goods sold guide defines what COGS is and where the accounting boundary sits. This guide is the math companion — how to compute the COGS figure from a real multi-cloud bill, break it down per product and per customer, and forecast it forward.
Can cloud hosting cost ever be capitalized instead of expensed as COGS?
Cloud spend used to develop genuinely new internal-use software may be capitalizable under ASC 350-40 rather than expensed. That is a determination to make with your accountant — it is not a default, and most production hosting is straightforward cost of revenue.