Which cloud costs belong in a SaaS company's cost of revenue (COGS) is a policy you set and agree with finance, your accountant and, where you have one, your auditor. A workable policy puts the production environment that serves paying customers, plus its share of the shared platform, into cost of revenue; development, testing and experiments into research and development (R&D); and internal tools into general and administrative (G&A) or sales and marketing. Repeatability matters more than any single call: the same rule every month, derived from accounts and tags. This guide is a decision framework, not accounting or tax advice.
Keep the management metric and the statutory accounts apart
Statutory formats decide whether a gross profit line exists at all. In Germany, § 275 HGB allows the profit and loss account by nature of expense (Gesamtkostenverfahren) or by function (Umsatzkostenverfahren). Only the function format has a cost of sales line and a gross profit subtotal; the nature format lists expenses such as purchased services or other operating expenses, with no gross margin. In the UK, the Companies Act accounts regulations offer Format 1, with turnover, cost of sales and gross profit or loss, and Format 2, by nature. Directors keep the format once chosen unless there are special reasons for a change, which must be disclosed.
Where the statutory accounts have no gross profit line, SaaS gross margin is a management metric, and where cloud cost sits in the statutory accounts is decided by the directors with their accountant. Where Format 1 or the function format applies, your policy may feed the statutory line, so agree it with the accountant or auditor before the year-end. Either way, use one data basis, and if management and statutory classification differ, document the reconciliation so nobody has to defend two truths.
Classification table
| Cost type | Recommended classification | Reason or edge case |
|---|---|---|
| Production for paying customers: compute, databases, storage, data transfer, CDN | Cost of revenue | No service without it |
| Shared platform: clusters, network, observability, security services | Production share in cost of revenue, rest in R&D | Share by a documented key |
| Staging, development, preview environments, CI | R&D | Edge case: a contractually promised customer sandbox is service delivery |
| Production monitoring, on-call, status page | Cost of revenue | Protects the promised availability |
| Production backups and disaster-recovery standby | Cost of revenue | Part of the promised recoverability |
| Customer support tooling and support environments | Cost of revenue, if support is part of the service promise | Otherwise sales or G&A |
| Data and analytics as a product feature, such as customer reports | Cost of revenue | Customers use it |
| Internal BI and a data warehouse for management | G&A | Serves management, not delivery |
| AI inference in customer-facing features | Cost of revenue | Arises per use like other production load |
| AI training, evaluation, experiments | R&D | Edge case: regular retraining of a shipped model |
| Demo environments, website | Sales and marketing | |
| Internal IT: identity, email, staff tools | G&A | |
| Marketplace purchases through AWS or Azure | By the function of the product bought | The billing route does not decide the function |
| Provider support, such as AWS Support | Pro rata to the environments supported | |
| Amortised reservations and Savings Plans | Follow the covered usage | Unused commitments as their own line |
| Credits | Not netted against cost of revenue | Own line, see below |
| Tax | Outside the metric | Checked in the reverse charge review |
The shared platform needs a key that separates production from development load, such as CPU and memory shares per namespace in a shared cluster. Choosing such keys per component and keeping totals exact is covered in multi-tenant SaaS cost allocation.
FOCUS helps with commitments: EffectiveCost spreads prepayments across the covered usage and sets the purchase itself to zero when it is intended to cover future usage. A Savings Plan therefore lands where its usage sits, not as a lump in the month of purchase.
Credits distort the margin
AWS applies promotional credits automatically to eligible charges, starting with the largest service charge. With credit sharing active in an organisation, credits go first to the owning account and then to the account with the highest spend. Credits also expire. A margin after credits therefore shows neither the cost structure nor the margin once they run out.
Calculate cost of revenue before credits and show credits as their own line below the margin. In FOCUS data they carry ChargeCategory = 'Credit'.
Rules that make classification repeatable
Account structure is the strongest signal: production and non-production in separate AWS accounts, Azure subscriptions or Google Cloud projects. Tags refine within those boundaries. Evaluate the rules in a fixed order; the first match wins:
1. ChargeCategory = Credit -> credits, below the margin
2. ChargeCategory = Tax -> outside the metric
3. Tag cost_function = sales -> sales and marketing
4. Tag cost_function = internal -> G&A
5. Production account, tag cost_pool -> shared, split by key into cost of revenue and R&D
6. Production account -> cost of revenue
7. Non-production account -> R&D
8. Everything else -> unallocated, resolved before month-end close
The order is part of the policy. If rule 7 came before rule 3, a demo environment in a development account would land in R&D instead of sales. Record new accounts and tag values through a short approval step so the rules do not drift.
When production and development share an account
If both share an account, a tag such as environment with fixed values carries the split. Resources that cannot be tagged or that serve both, such as a NAT gateway or a shared cluster, are shared cost with a key. Measure the share that reaches no category every month as allocation coverage, and plan the move to separate accounts once that share is large enough to change what the margin says.
A policy sheet finance can sign
Keep the policy on one page with these fields:
- Effective from and version, with a change log
- Owners: one person in finance, one in engineering
- Cost basis:
EffectiveCostbefore credits, data cut at month-end - Categories: cost of revenue, R&D, sales and marketing, G&A, unallocated
- Rule order as above, with the account list per category
- Key for each shared component
- Review cadence: monthly in the cost review, yearly with the auditor or accountant
What investors and controllers need to see
A margin is only readable with its definition. Prepare these with every monthly figure:
- A written, dated definition. When the policy changes, restate prior periods and show the effect of the change separately.
- Margin before and after credits, with the expiry dates of remaining credits.
- Reconciliation to the bill. All categories plus unallocated equal the month's cloud cost; differences to the provider invoice are explained by the month-end reconciliation.
- Currency. Name the rate source and method for USD costs, as in pay AWS in euros.
- A margin bridge: revenue, usage volume, prices and discounts, rule changes. Management can then see whether margin improved through efficiency or only through reclassification.
- Capitalised development cost, if you capitalise after confirming it with your adviser: show which amounts no longer sit in R&D expense, and state in the policy where any later amortisation sits. Whether and what may be capitalised is a question for your adviser; the questions to ask are in capitalise cloud costs.
Distinguish technical gross margin, revenue minus the technology cost of delivering it, from the full gross margin in your policy, which may also include staff for operations and support. The glossary entry on technical gross margin defines it:
Technical gross margin = (revenue - cloud cost of revenue before credits) / revenue
At customer level the same logic continues as cloud cost per customer; the glossary entry on unit economics explains the basics.
What Costfluent covers
Costfluent reads billing data from AWS, Azure and Google Cloud through read-only connectors. Segments name a team, product and cost centre; allocation rules with one condition each on account or subscription, resource group, resource name or tag are evaluated in a fixed order, and anything no rule matches stays visible as unallocated. Cost marked as shared is spread in proportion to the segments' direct cost; for the platform that means in proportion to direct production versus direct development load. If that key does not fit your policy, calculate the share outside. Cost appears in euros by default, or GBP, with the ECB rate method stated, and a saved report can be emailed to finance on a schedule or exported as CSV. Costfluent has no revenue data, so the margin is calculated by your controller, and Costfluent posts nothing to your books. Reconciliation against the provider invoice is Planned. More on cloud cost reporting for finance.
Sources and method
Checked on 10 October 2026: § 275 HGB, profit and loss account formats, The Small Companies and Groups (Accounts and Directors' Report) Regulations 2008, Schedule 1, AWS: Applying AWS credits, FOCUS 1.2: ChargeCategory, FOCUS 1.2: EffectiveCost and FinOps Foundation: Unit Economics. The classification table, rule order, policy sheet and investor list are Costfluent recommendations. They are not accounting, tax or audit advice; statutory classification is decided by the directors with their accountant and, where applicable, auditor.
