.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
How to Measure Carbon Footprint and Sustainability Impact a Guide for SaaS Executives
A SaaS company can produce a carbon number quickly. It can export a cloud invoice, apply an emissions factor, divide the result by revenue, and publish a chart. That number may be directionally useful. It will not, however, answer the questions that matter in an enterprise sales cycle, a board review, or a product decision: Which activities create the emissions? Which customer workloads drive them? What changes would reduce them? Can we defend the calculation six months later?
The pressure to answer those questions is rising. On February 26, 2026, the California Air Resources Board confirmed that companies above the statute’s revenue threshold that do business in California must begin reporting Scope 1 and Scope 2 emissions in 2026, with Scope 3 reporting beginning in 2027. Large customers are therefore moving from broad sustainability questionnaires toward requests for defined boundaries, methods, and evidence.
Monetizely's position is clear: SaaS executives should build a two-layer measurement system. The first layer is a complete company inventory across Scopes 1, 2, and material Scope 3 categories. The second is a product and customer allocation model led by workload consumption, not seats or ARR.
A reliable carbon number starts with the company boundary, not the product screen
Carbon footprint means greenhouse-gas emissions expressed in carbon-dioxide equivalents, or CO2e. The corporate inventory is the accounting foundation. The GHG Protocol Corporate Standard covers company-level inventories, while its Scope 2 Guidance addresses purchased electricity, steam, heat, and cooling.
For cloud-native SaaS, the first mistake is to treat the data center as the whole story. Public-cloud use is often a purchased service, which places it in Scope 3 rather than Scope 2 for the SaaS company. Business travel, employee commuting, laptops, office energy, and purchased professional services can also be material. The GHG Protocol’s Scope 3 Standard organizes indirect value-chain emissions into 15 categories, including purchased goods and services, capital goods, business travel, and employee commuting.
The practical question is not whether every category deserves equal effort. It is which activities are large enough, controllable enough, and important enough to the company’s buyers that they require stronger data.
| Emissions source | Likely accounting treatment | Typical SaaS activity data | Executive owner |
|---|---|---|---|
| Office fuel, refrigerants, company vehicles | Scope 1 | Utility invoices, fuel purchases, fleet records | Workplace and finance |
| Office electricity and company-operated data centers | Scope 2 | Electricity use by site and data center | Infrastructure and workplace |
| AWS, Google Cloud, Azure, and other cloud services | Scope 3, usually purchased goods and services | Provider carbon exports, cloud account and region data | Cloud infrastructure and finance |
| Servers and networking equipment owned by the company | Scope 3, capital goods | Hardware purchase records, supplier lifecycle data | Infrastructure and procurement |
| Employee travel, commuting, and remote-work energy | Scope 3 | Travel agency data, expense records, employee surveys | People operations and finance |
The table shows why carbon accounting must begin as an operating map. A finance-led inventory without infrastructure data will miss the clearest product lever, while an engineering-only view will omit the company footprint that customers and regulators ask to see.
Monetizely's 5-Step Pricing Framework offers a useful discipline because it forces leaders to settle the hard choices in order: goals and segmentation, packaging, pricing metric, price points, and operationalization. In Monetizing Agentic AI, the framework is used to prevent companies from choosing a price before they know whom they serve, what they offer, and what should be measured. Carbon measurement needs the same sequence. A company that begins with a dashboard or a per-seat number will often create a report that cannot guide either a buyer conversation or an engineering decision.
The framework changes the executive conversation from “What is our footprint?” to “What decisions must this footprint support?”
The implication is simple: one number should not serve every purpose. A CFO needs an auditable corporate total. A product leader needs emissions per workload. A procurement team at a large customer may need a customer-specific allocation with method notes and reporting-period dates.
Seats are a useful commercial metric. They are usually a weak carbon metric.
Consider two customers with 100 seats each. One uses a collaboration application for light document review. The other runs nightly data transformations, high-volume API calls, and generative-AI workflows. Dividing emissions evenly by 100 seats makes the two accounts look identical even when their infrastructure demand is radically different. It also gives product teams no reason to reduce heavy workloads.
The better approach begins with the cloud provider’s reported footprint at the account, project, service, and region level. It then maps that footprint to customer workloads using the nearest available physical driver: compute-hours, storage GB-months, network transfer, database capacity, or model-inference usage. AWS now allocates cloud emissions from clusters to racks, services, and customer accounts, prioritizing physical usage allocation and using economic allocation only where it is needed.
| Candidate allocation basis | Link to underlying emissions | Best use | Monetizely's position |
|---|---|---|---|
| Named seats | Low | Adoption and access governance | Do not use as the main carbon allocation basis |
| ARR | Low | Allocating corporate overhead that cannot be traced | Use only for residual shared functions |
| Cloud spend | Medium | Reconciling cloud invoices and early estimates | Use as an interim bridge, not the end state |
| Compute, storage, and network consumption | High | Allocating shared cloud operations to products and accounts | Use as the primary allocation basis |
| API calls or transactions | Variable | Products where each event closely tracks resource use | Use only after testing the relationship to compute demand |
| AI model tokens or inference time | High for model-heavy features | AI workload management | Track separately from ordinary application use |
The table points to a disciplined allocation rule: assign direct cloud emissions to workloads first, spread shared platform services by each workload’s share of measured use second, and use revenue only for overhead that has no credible technical driver. That approach is more defensible with customers and more useful for engineers.
Google Cloud’s methodology illustrates the direction of travel. As of July 29, 2026, its Carbon Footprint reporting calculates energy use from compute usage and data-center requirements, applies location- and market-based emissions methods, and allocates results to products and customers using SKU usage by region.
SaaS leaders should publish and manage two electricity views where provider data supports them.
Location-based emissions reflect the grid where the workload runs. They show the physical carbon intensity associated with electricity in that region. Market-based emissions reflect qualifying energy purchases and contracts, such as renewable-energy certificates or power-purchase agreements, under the GHG Protocol Scope 2 method.
Neither view replaces the other. Location-based reporting helps a product team decide whether to move flexible batch processing from one region or time window to another. Market-based reporting supports corporate inventories and customer Scope 3 reporting where contractual renewable-energy procurement is relevant.
A SaaS executive should therefore use:
- Location-based emissions for engineering, cloud placement, and capacity decisions.
- Market-based emissions for formal corporate reporting and customer disclosure.
- Both values in the internal record, tied to the same workload, provider account, region, and reporting month.
AWS added location-based data alongside market-based data in June 2025, and its sustainability service now provides estimated carbon and water impacts for AWS workloads using a methodology updated as underlying data improves.
A credible inventory does not pretend that every data point has the same precision. It records where each number came from, what factor or provider method was used, and whether the source can be reproduced.
The following ladder helps executives decide what can support an external customer claim and what should remain an internal planning estimate.
The table makes the reporting rule straightforward: the weaker the evidence, the narrower the claim. A per-seat average may help identify whether more investigation is needed. It should not be presented as a customer’s product footprint.
Version control matters as much as the initial calculation. AWS has updated carbon allocation logic and recalculated historical results when methods improved; Google Cloud similarly states that changes to data sources or methodology can revise current and past customer figures.
Sustainability impact needs an action scorecard, not a wider stack of claims
Carbon is central, but it is not the full sustainability story. A SaaS company should only track additional measures where it has a clear operating lever. Adding ten loosely defined ESG indicators often creates reporting work without changing behavior.
A focused scorecard links each measure to a decision that a leader can actually make.
The value of this scorecard lies in its limits. Each line points to a decision, an owner, and a source of evidence. AWS, for example, states that its current sustainability service covers carbon and water impacts associated with workloads on AWS-operated infrastructure, while excluding third-party software activities that occur outside that infrastructure.
The strongest public examples do not rely on a single branded climate claim. They show categories, boundaries, and management actions.
The common thread is not a shared target. It is a shared discipline: disclose the source categories, explain what changed, and connect the number to an action.
Annual sustainability reporting should be the output of a monthly operating rhythm, not a scramble that begins after year-end.
The monthly close should bring cloud, finance, procurement, people operations, and workplace data into one controlled record. Finance should own the reporting boundary and sign-off. Infrastructure should own workload data and cloud-provider exports. Procurement should own supplier requests and hardware records. A sustainability lead should maintain the method, factor library, and evidence file.
Three controls are particularly important:
- Lock each reporting month. Preserve source files, provider report versions, allocation rules, and approvals.
- Track material changes. Flag major shifts caused by region moves, cloud architecture changes, acquisitions, travel spikes, or revised provider methodologies.
- Reconcile management and external reports. The total customer allocations cannot exceed the related corporate footprint after documented exclusions and shared-service treatment.
CARB’s 2026 implementation process reinforces the need for this discipline. Its February 2026 rulemaking established initial reporting requirements and fees, while later rulemaking is intended to address requirements for 2027 and beyond.
Carbon measurement earns its place when it changes product and capital choices
The goal is not a more polished sustainability report. The goal is a system that changes decisions before the emissions occur.
Monetizely's position is that SaaS executives should treat carbon data as operating data. Build the corporate inventory for accountability. Build workload allocation for product management. Keep the two connected, but never confuse them.
Make cloud-carbon data part of architecture review. Require major platform, region, and AI-feature proposals to show expected workload growth and carbon effect alongside cost, reliability, and latency.
Use customer footprint reports as enterprise evidence, not marketing decoration. Provide reports only where the allocation method, period, boundary, and data source are clear enough for a procurement team to use.
Fund efficiency work through normal capital allocation. Compare the cost of refactoring, model routing, caching, and regional scheduling against avoided cloud spend and avoided emissions rather than treating sustainability work as a separate program.
Give the CFO ownership of the company total and the CTO ownership of product intensity. Shared accountability prevents finance from publishing numbers engineering cannot explain and prevents engineering from optimizing metrics that do not reconcile to the corporate record.
Set a board-level expectation that every annual claim has an underlying management action. A target without a product, supplier, travel, or energy decision attached to it is communications, not strategy.
Footnotes
- Monetizing Agentic AI: https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- GHG Protocol, Corporate Standard, Scope 3 Standard, and Product Standard; corporate guidance updated with Scope 2 Guidance in 2015, with product-level guidance published in 2011. (ghgprotocol.org)
- California Air Resources Board, California Corporate Greenhouse Gas Reporting Program materials and February 26, 2026 implementation announcement. (ww2.arb.ca.gov)
- AWS Sustainability, calculation methodology and allocation approach, current as of September 2026. (docs.aws.amazon.com)
- Google Cloud, Carbon Footprint reporting methodology, last updated July 29, 2026. (docs.cloud.google.com)
- SaaS company disclosures: Salesforce FY26 ESG materials published February 2025; Workday 2025 Global Impact Report; Atlassian FY25 Sustainability Report; ServiceNow 2025 Global Impact Report. (investor.salesforce.com)