Carbon Accounting for Australian SaaS and Tech...

A typical Australian SaaS scale-up with 200 employees, a single co-working space, and a $50m annual cloud bill has Scope 1 and 2 emissions of perhaps 30 tonnes CO2-e per year. Then you measure the cloud computing footprint, the employee devices, the home office energy from a remote-first workforce, and the sales and marketing travel, and the number jumps to several thousand tonnes.

Tech companies have always had a peculiar emissions profile. Software runs on hardware. Hardware sits in data centres. Data centres consume electricity. The customer using the software pays an indirect carbon cost that flows through the SaaS provider's bill back to the underlying infrastructure. Where this lands in the carbon accounting depends on who's asking and what framework they're applying.

For Australian SaaS companies preparing for AASB S2 Group 2 or Group 3 disclosure, the methodology questions are unusually fraught. Here's how the data actually maps.

Where Scope 1 and 2 sit for a tech company

Operational emissions for a typical SaaS company are minor:

Scope 1: Limited to refrigerant leaks from HVAC and the occasional company vehicle. Most CBD or co-working tenants don't have direct gas or fuel use. Total is usually under 50 tonnes per year for a 200-person company.
Scope 2: Office electricity, sub-metered to the firm's tenancy. For a 200-person co-working space split with other tenants, the attributable consumption is often calculated by floor area or headcount allocation. Total is usually 50 to 200 tonnes per year.

The combined operational footprint is tiny compared to industrial companies. Tech companies looking only at their own utility bills get a misleadingly clean carbon profile.

The real footprint lives in Scope 3

For a SaaS company, the relevant Scope 3 categories are:

Category 1: Purchased goods and services. Cloud computing services (AWS, Azure, GCP), software-as-a-service tools (Salesforce, HubSpot, Atlassian, Zoom, Slack), professional services (legal, accounting, recruitment), telecommunications, and similar. For most SaaS scale-ups, cloud is the largest single line and software tools are the long tail.

Category 2: Capital goods. Employee laptops, monitors, servers (if any), office fitouts. Lifecycle factor: a $2,000 MacBook Pro carries roughly 350 kg CO2-e of embodied emissions per Apple's product environmental reports. For a 200-person company refreshing devices on a 3-year cycle, that's roughly 23 tonnes per year of device emissions.

Category 6: Business travel. Sales travel, customer site visits, conference attendance. Variable by company stage and customer geography.

Category 7: Employee commuting. Office attendance plus, increasingly, home office energy attribution for remote staff.

Category 11: Use of sold products. For SaaS companies, this is the energy consumed when customers use the product. Methodology is contested but increasingly expected.

The categories that dominate: 1, 6, and 7 for most SaaS companies, plus Category 11 if the company chooses to disclose it.

The cloud emissions piece

Cloud computing emissions live in three places:

Provider's published per-customer data. AWS, Azure, and GCP all publish per-customer emissions through customer-facing dashboards. The data is provided in tonnes CO2-e per month, attributed to the customer's actual consumption. The methodology varies between providers but generally includes the data centre electricity, allocated by the customer's resource utilisation.

The data quality is generally PCAF score 1 or 2: actual data, reported, sometimes verified. For SaaS companies with substantial cloud spend, this is the cleanest part of Scope 3.

Provider's location-based vs market-based methodology. The cloud providers report both location-based emissions (using local grid factors) and market-based emissions (after accounting for the provider's renewable energy purchases). For a tech company customer, both numbers should appear in the AASB S2 disclosure under paragraph 29(a)(v)... actually no, this is Scope 3 Category 1, not Scope 2. The methodology differs slightly: the cloud provider's market-based number is what flows into the customer's Category 1, with the customer relying on the provider's certificate surrender records.

Embodied emissions in the underlying infrastructure. The data centre buildings, servers, networking gear, and supporting infrastructure all have embodied emissions. The cloud provider amortises these across customers in their reported numbers, but the methodology varies.

For a SaaS company spending $5m per year on cloud, total cloud emissions typically come in at 200 to 800 tonnes CO2-e depending on workload mix and the provider's renewable energy position.

Device emissions for a remote-first workforce

Many Australian tech companies are remote-first or hybrid. Device emissions for a remote workforce include:

Laptop manufacture (embodied)
Monitor and accessory manufacture (embodied)
Daily energy consumption while working (operational)
Home office allocation of broader household energy

The embodied emissions are well-documented from manufacturer environmental reports. The operational energy is small per device but real. The home office allocation is methodologically contested.

Most companies use a simple per-employee hybrid emissions factor for remote work. The GHG Protocol Scope 3 Guidance accepts simplified approaches where granular data isn't available.

For a 200-person fully remote company with average laptop refresh cycles, total device emissions land around 30 to 60 tonnes CO2-e per year, including amortised embodied emissions.

The Category 11 question

Scope 3 Category 11 is "use of sold products". For SaaS, the question is whether the customer's cloud and device emissions when using your platform should be in your Scope 3.

The GHG Protocol's position is that Category 11 applies when the product consumes energy in use. Software running on a customer's device or in a customer's cloud account does technically consume energy. But the energy is already counted in the customer's own Scope 1, 2, and Category 1 emissions, so the SaaS provider counting it again creates double-counting at the level of the broader economy.

In practice, most SaaS companies do not disclose Category 11 emissions. The materiality argument is that the energy attributable to use of the SaaS platform is small relative to the customer's total IT footprint, and the methodology for attribution is poorly developed. Some larger SaaS companies (Microsoft, Salesforce) do provide tooling for customers to estimate their share, but the SaaS provider's own Category 11 disclosure remains uncommon.

For an Australian SaaS company facing AASB S2 assurance, the position to take: document the Category 11 omission with materiality reasoning. Don't ignore it silently.

What changes with international customers

Most Australian SaaS companies sell internationally. The relevant question for AASB S2 disclosure is whether the cloud emissions for international customers should be in the SaaS provider's Scope 3.

The methodology answer: yes, all cloud emissions for the SaaS provider's own consumption are in Category 1, regardless of where customers are. The provider's cloud bill is the boundary. The customer's geographic location doesn't change that.

For a SaaS company with US customers running on AWS US-East-1, the emissions are calculated using the AWS-reported figures for that region, which use the relevant US grid factors. Same for European or Asian customers.

The result: a SaaS company with global customers has cloud emissions calculated using a mix of regional grid factors. The total is what matters; the regional split is methodology detail.

What the auditor will examine

For a tech company facing first-time AASB S2 assurance:

Cloud spend reconciliation. Does the cloud emissions figure tie to the cloud bills? The provider's per-customer data should match the customer's invoices.
Device inventory. Is the laptop and device count accurate? Embodied emissions should be calculated using current manufacturer data.
Travel data. Reconciliation between TMC data, expense system, and the disclosed total.
Office allocation. For co-working or shared offices, the allocation methodology should be defensible.
Category 11 disclosure. Is it omitted with reasoning, or simply absent?

The cleanest SaaS disclosures we've seen include a methodology note that walks through each category, explains the data source, and acknowledges the limitations. The auditor accepts what's documented and pushes back on what isn't.

Practical setup for an Australian SaaS company

If you're a SaaS company preparing for AASB S2:

Pull cloud provider per-customer data. Set up the dashboards or API feeds for AWS, Azure, GCP, and any other major cloud services.
Build the device inventory. Asset management tooling captures laptops, monitors, etc. Tie each to embodied emissions data from manufacturer reports.
Travel data integration. TMC feed plus expense system reconciliation.
Office utility data. Sub-metered electricity if available; floor area allocation if not.
Procurement spend mapping. Annual spend by category, with the long tail in spend-based estimation.
Methodology documentation. Per-category notes explaining the approach.

The complete data system mirrors what we built for our own carbon accounting needs. One ledger, multiple inputs, audit trail to source.

The customer carbon question

Increasingly, enterprise customers ask their SaaS providers for emissions data. The question typically arrives via supplier sustainability questionnaires or directly from the customer's procurement team running Scope 3 supplier data collection.

For a SaaS company with tier-one customers (banks, insurers, mining companies, ASX 200 corporates), this becomes a structured request: "what are the emissions allocable to our spend with you?". The answer requires the SaaS company to allocate its own emissions across customers, typically by revenue share or some usage metric.

This allocation logic is essentially the inverse of the cloud provider's per-customer attribution. SaaS companies that build the methodology now will be able to answer customer questions in days rather than months.

The bottom line

Tech company carbon accounting is dominated by Scope 3, with cloud and devices doing most of the work. The data is more available than it was five years ago, primarily because the major cloud providers now publish per-customer emissions. The methodology questions (Category 11, customer allocation, home office attribution) are still contested but tractable.

If you're a SaaS or tech company building out emissions data for first AASB S2 disclosure or for customer demands, email hello@carbonly.ai or join the waitlist. Happy to walk through the data architecture that handles cloud, devices, travel, and procurement from one source of truth.