Scope 3 Carbon Accounting Software: Can You Show the Auditor the Transaction Behind the Number?

Why the Scope 3 number falls apart the moment someone checks it

An assurance provider sits down with the sustainability team in February and asks a simple question about purchased goods and services: how was this category calculated, and can you show me the transactions behind this figure. The team opens the workbook. It has a spend extract pulled last September, a mapping tab where someone assigned emission factors to general ledger accounts, and a total. The extract was filtered, but the filter is not documented. Three accounts were reclassified in the ERP in November, which changes what the extract would return today. The factor set used was the version current when the work started, and it has since been updated. Two subsidiaries were excluded because their data arrived late, and the note explaining that was in an email.

None of this means the number is wrong. It means the number cannot be defended, which for assurance purposes is the same problem. And it means that next year the whole exercise starts again from scratch, because there is no reusable pipeline, only a workbook and a person who remembers what they did.

The products in this market are real and improving. Watershed and Persefoni are serious platforms with strong methodology teams. Sweep and Normative handle the mid market well. IBM Envizi and Sphera come from the operational data and EHS traditions and are strong where utility and site data dominates. If your emissions profile is conventional, one of them will serve you better than a build. Companies build when the data does not fit the model: when activity data lives in four ERPs with locally maintained charts of accounts, when logistics data comes from freight forwarders in incompatible files, when a large share of emissions sits in a category the platform models generically and your business does not, or when assurance requires a level of traceability that a subscription tool's black box cannot give you.

Problem one: spend based estimation is a starting point that becomes permanent

Spend based calculation is legitimate and it is where everyone starts. Multiply spend in a category by an economic factor and you get an estimate. The problem is that it is insensitive to everything you actually do. Switch a supplier to a lower carbon process and your reported emissions do not move, because you are still spending the same money. Negotiate a price reduction and your emissions fall, which is absurd. The method rewards nothing and detects nothing.

Moving to activity data means knowing quantities, not just amounts: tonnes of material, kilometres and weight moved, kilowatt hours consumed at a leased site, litres of fuel. That data exists inside your business, in purchasing quantities, in shipment records, in fleet telematics and in landlord billing. It is not in one place and it never will be.

What a custom build does: treat activity data as the primary object and spend as the fallback, per category and per business unit. Every calculated line records which method it used, so you can report the share of your inventory on activity data and improve it deliberately year over year. That percentage is the actual measure of programme maturity, and it is the number your assurance provider will focus on.

Problem two: emission factors are versioned data with a source, not constants

Factor libraries update. Grid factors are revised. Methodologies change. If your calculation stores a number rather than a reference to a factor version, you cannot explain a movement between years and you cannot restate a base year correctly.

What a custom build does: store factors as versioned records with source, publication year, region, unit and applicable date range, then bind every calculation to the specific factor version used. When a library updates, you decide explicitly whether to recalculate history, and the system produces the movement analysis showing how much of a year over year change came from activity, how much from factor updates, and how much from methodology or scope changes. That decomposition is exactly what a reviewer will ask for, and it is what turns a number into a defensible position.

Problem three: mapping is company specific and it is the actual work

The mapping from your data to emission categories is where the project lives or dies. It means deciding that this general ledger account in this entity maps to purchased goods with this factor, that this expense category is business travel by air with distance derived from an itinerary, that this cost centre's leased space is category eight upstream leased assets rather than operational scope two. Multiply by four ERPs with locally maintained charts of accounts and several thousand accounts and you have the reason these programmes take a year.

Packaged platforms give you a mapping interface and a default mapping, which is a reasonable start and always partly wrong for your business. The part they cannot solve is maintenance: new accounts appear, entities are acquired, coding practices drift, and an unmapped account silently drops out of the inventory.

What a custom build does: make mapping a governed dataset with owners, effective dates, review status and an unmapped queue that raises an exception rather than a silent zero. This is the honest place for machine assistance: suggest a mapping for a new account based on its description, its historical spend pattern and how similar accounts were mapped in other entities, then require a named human to approve it. Suggestion with mandatory confirmation, never automatic assignment, because an auto mapped account that nobody checked is exactly the finding an assurance provider writes up.

Problem four: supplier specific data collides with your calculation model

The maturity path pushes towards supplier specific emissions data for significant suppliers. That data arrives with its own boundaries, its own allocation method and its own vintage. Substituting it into your inventory is not a simple swap. You need to know which spend it replaces, avoid double counting the remainder, handle the case where a supplier reports at group level while you buy from one site, and record the provenance and quality of what they sent you.

What a custom build does: model supplier provided data as an alternative source competing with the calculated value for a defined scope of purchases, with an explicit precedence rule, a quality rating and an audit note. Then show both, so the effect of substitution is visible rather than hidden inside a total. Any platform that silently prefers supplier data over calculated data is making a materiality judgement on your behalf.

Problem five: restatement is a controlled process, not an edit

Prior year figures change. A subsidiary is divested, an error is found, a methodology improves, a factor library updates. Financial reporting has a mature discipline for this and sustainability reporting is being held to the same standard as assurance tightens.

What a custom build does: lock a reporting period after sign off so the underlying calculation is immutable, then handle changes as explicit restatements with a reason, an approver and a before and after. Base year recalculation follows your documented policy, including a significance threshold, and the system applies it consistently rather than leaving it to whoever runs the model. If you have science based targets, this is not optional housekeeping. Your target baseline has to survive every organisational change you make between now and the target year.

What this costs and how long it takes

Across the enterprise data and compliance work Digital Heroes has delivered, this is the honest shape. A focused first release, meaning activity and spend ingestion from your ERP and expense systems, the governed mapping layer with an unmapped queue, the versioned factor engine, and a calculation ledger where every result links to its inputs, runs $90,000 to $180,000 and ships in 12 to 18 weeks. That gives you a repeatable inventory rather than an annual workbook.

A full platform adding supplier data collection with a portal, logistics and utility ingestion, category specific models for your material categories, restatement and base year handling, target tracking, and assurance reporting packs runs $220,000 to $480,000 phased over 7 to 12 months.

What pushes cost up here specifically: the number of ERPs and charts of accounts, which is the single biggest driver. Logistics data, because freight forwarder files are individually awkward and each one is its own parser. Utility data for leased sites, where you are dependent on landlords and often on scanned invoices. Product level footprints, if customers are asking for them, since that is a different calculation model built on bills of material rather than spend. And acquisitions during the build, which will happen and will change your entity structure mid project.

What keeps cost down: build for the three or four categories that carry most of your footprint and leave the long tail on spend based estimation with a documented rationale. Precision in an immaterial category is a way to spend money on a rounding difference.

Build versus buy, and when buying is the right call

Buy, and do not call us, if you are reporting voluntarily, you have one ERP, and your footprint is dominated by categories the platforms model well. Watershed, Normative or Sweep will get you a credible inventory faster and cheaper than any build, and your constraint is data quality rather than software.

Build when two or more of these are true. Your activity data sits in several ERPs with locally maintained charts of accounts that no vendor's mapping engine will keep up with. A large share of your footprint sits in a category with a business specific calculation, for example a logistics network, a franchise estate, an agricultural supply base or use of sold products for a manufacturer. You are under limited or reasonable assurance and your provider has already asked for traceability you cannot provide. You need product level footprints for customers as well as a corporate inventory. Or you are paying for a platform and still doing the real work in spreadsheets alongside it.

A hybrid is often correct and we say so regularly: keep a platform for factor libraries, methodology updates and reporting formats, and build the ingestion, mapping and calculation ledger that makes your specific data usable. That combination costs less than replacing either half.

How to choose a developer for carbon accounting systems

Ask them how a calculated figure will be traced back to a transaction. If they cannot describe a lineage record joining source row, mapping version, factor version and result, they are building a dashboard, and a dashboard fails assurance.

Ask what happens when a factor library updates mid year. The right answer includes versioned factors, an explicit recalculation decision and a movement analysis separating activity change from factor change. Anyone who says the numbers just update has not sat through an assurance review.

Ask how they will handle an unmapped account. The only acceptable answer is an exception queue with an owner. Silent zeros are how inventories quietly lose entire subsidiaries.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit. Emissions data now sits in annual reports and increasingly in contracts, so the calculation engine behind it belongs to you in the same way your financial consolidation logic does.