How NetNada calculates your emissions (Basis of Preparation)
Last updated: 18 August 2026
Every figure NetNada reports can be explained, traced and reproduced. This article summarises the platform's Basis of Preparation — the methodology applied when your data is converted into reported greenhouse gas emissions — in plain language, so you know exactly what the platform does and what remains your responsibility.
The core principle: activity data × emission factor
Every calculation in NetNada reduces to one equation: an activity quantity (litres of fuel, kilowatt-hours, dollars spent, kilometres flown) multiplied by an emission factor for that activity, expressed in tonnes of CO₂ equivalent. This is the approach set out in the GHG Protocol Corporate Standard, and it applies to all three scopes.
Each transaction is routed to a specialised calculator based on how the data was provided — electricity, flights, fuel combustion, spend, weight, distance, accommodation and more. Purchased electricity is calculated under both the location-based and market-based methods, satisfying the GHG Protocol's dual-reporting requirement from a single set of data.
Categories are also kept consistent with the GHG Protocol's split between burning a fuel and supplying it. Well-to-tank emissions — those from producing and delivering a fuel before it is used — from flights and fuels are reported under the fuel- and energy-related activities category, rather than folded into business travel or the fuel's own category. The total is the same; the split between categories is what an auditor examines.
Where emission factors come from
Emission factors are sourced primarily from Climatiq, a curated database that aggregates published government and scientific sources. For each transaction, NetNada selects a factor in a fixed order of preference:
- Your own custom factors first — if you or a supplier has registered a specific factor (for example, from an EPD or LCA), it overrides the database.
- A structured database match — the factor is matched on sector, category, unit, region and year, then refined by comparing the description of your record against candidate factors.
- Year fallback — if no factor is published for the exact year, the most recent factor within the previous eight years is used, and the substitution is recorded. Where an older factor is genuinely the most recent one published for a category, the calculation log says so explicitly — so a correct fallback never looks like a mistake.
- Region fallback — if no factor exists for your exact state or region, the engine falls back to the country and then to a global factor, and records the substitution.
Waste factors are never guessed by AI. Where no factor exists for your region, the engine applies a defined general waste factor instead — slightly blunter than a regional match, but predictable and defensible under assurance review. Waste data dated before factor coverage begins rolls forward to the earliest available factor rather than failing, and the calculation log records which factor was applied and where it came from.
The calculation and audit trail
Every calculated line records the activity quantity used, the exact emission factor chosen, and a calculation log capturing any adjustments applied — unit conversions, currency conversion for spend data, inflation adjustment, and any year or region fallback. Nothing is adjusted silently.
You can trace every reported figure on the Audit page, which shows the source record, the factor applied and the methodology for each line, and can be exported for third-party verification. Every record also carries a link back to its originating file, form submission or accounting integration.
AI assistance and human review
NetNada uses AI to speed up data processing: reading uploaded invoices, mapping free-text descriptions to emission categories, and matching records to the best emission factor. Each match carries a confidence score so you can triage low-confidence items, and you always have the final say — you can review any AI-suggested classification and override it manually.
For spend-based purchases, matching considers what was actually bought — the description and context of each purchase — not just the supplier name, so different purchases from the same supplier can receive different emission factors. Results are consistent between runs, and the reasoning behind each match is recorded on the line, so you and your auditor can see why a factor was chosen.
The confidence scores are diagnostic aids for review, not statistical uncertainty bounds on your totals. Items the AI cannot map are flagged for you rather than guessed — they do not contribute to your reported emissions until you resolve them.
What NetNada does not do
The Basis of Preparation is deliberately explicit about the platform's limits, so you can plan complementary controls where required:
- NetNada is not an assurance provider. The platform calculates and documents your inventory; independent verification or assurance must come from an external provider you engage.
- Activity data is taken as you report it. The platform does not verify your data against meter readings or third-party records — retaining the underlying evidence is your responsibility.
- The platform is GHG Protocol-aligned, not certified. The engine implements the substantive methods of the GHG Protocol standards, referenced at framework level.
- No automatic materiality threshold. Everything inside your boundary is calculated; if you apply a materiality policy, document it externally and apply it through your boundary selections.
- Custom factors are accepted as-is. If you upload your own emission factors, their accuracy and provenance remain your responsibility.
Sharing the methodology with your auditor
When your inventory goes to assurance, give your auditor three things: this methodology description, an export from the Audit page showing every calculated line with its factor and calculation details, and the source evidence behind your activity data. Closed reporting periods preserve a snapshot of the boundary configuration used, so the settings that produced a result can always be retrieved.