Custom CO2 accounting software development
Carbon accounting is a general ledger for emissions. Consumption data from invoices, meters and systems is multiplied by an emission factor and becomes a figure that someone steers by or reports on. That figure is only worth something if you can show which measurement it came from, which factor was applied and which version applied. Appfront builds software that keeps that traceable.
Calculation work, not reporting
Carbon accounting, the international term for carbon accounting, is the process underneath every sustainability figure. You gather what has been consumed, transported and purchased, convert it into CO2 equivalents using emission factors, and keep every result traceable to its source. The comparison with financial bookkeeping goes beyond the name: there is a ledger, a period close, and someone who wants to audit a sample after the fact.
Is this the right page? This page is about that calculation work. If your question concerns broader sustainability reporting and the obligation to report, materiality, data points or the sustainability statement, you want CSRD and ESG reporting software. These are different systems: one produces the number, the other the accountability around it. Anyone who starts with the report and skips the accounting ends up at the first audit question in a spreadsheet nobody can reproduce.
Consumption is the input, not the emissions
Your sources supply litres, cubic metres, kilowatt-hours and kilometres. The emissions are a derived figure you calculate.
The factor determines the outcome
The same litre of diesel gives a different number under a different factor version. Without a recorded version, a figure cannot be reproduced.
Every figure must trace back to its source
From a line in the report to the invoice or meter reading beneath it, with no loose spreadsheet in between.
The plumbing is most of the building
When organisations first commission carbon accounting, they often think of the calculation core: consumption multiplied by factor. That core is the simplest part of the whole system. The real work lies in the data feeds. Your gas consumption appears on invoices from one or more suppliers, your electricity partly on invoices and partly on meters, your fuel on fuel card statements, your business mileage in a trip log or expenses system, your purchased goods in the ERP or procurement package, and your refrigerants in an installer's maintenance report. Six sources, six formats, six owners within the organisation.
Each of those sources has its own period. An energy invoice runs from meter reading to meter reading and so rarely coincides with your financial year. A fuel card summary runs by calendar month. An annual settlement corrects after the fact what the advance payments got wrong. Adding those series together without thought gives you an annual total covering eleven or thirteen months. A workable system therefore records a period with a start and an end for each line, pro-rates consumption to the reporting period when an invoice crosses the year boundary, and shows which part of the year each source covers. If a month is missing, that appears as a visible gap, not a silent zero.
On top of that, every source has its own key. The energy supplier knows connections, the fuel card provider knows card numbers, the ERP knows cost centres, the property administration knows buildings. To attribute emissions to a site, a department or a project, those keys have to be linked somewhere, and that mapping table has to keep up when a card changes hands or a building is sold. If you don't set that up explicitly, you only notice the problem when someone asks why the South site uses more diesel than there are cars on the road.
Finally, the input must be checkable. Consumption that suddenly doubles, a meter reading lower than the previous one, an invoice that has been imported twice, a unit that jumps from cubic metres to kilowatt-hours: these are signals the system should pick up on its own, with a worklist for whoever needs to resolve them. Validation at the point of entry saves a correction that would otherwise have to ripple through the whole chain of calculations.
The three scopes, and why scope 3 is the difficult part
The division into scopes comes from the Greenhouse Gas Protocol, developed by the World Resources Institute and the World Business Council for Sustainable Development. Its Corporate Accounting and Reporting Standard is the basis that almost every other scheme draws on. Scope 1 covers direct emissions from sources you own or control: your gas boiler, your vehicle fleet, leakage of refrigerants. Scope 2 covers indirect emissions from purchased energy: electricity, heat, cooling and steam. Scope 3 covers all other indirect emissions in the value chain, divided into fifteen categories in the Corporate Value Chain (Scope 3) Standard.
In principle, you calculate scopes 1 and 2 using data that already sits in your own administration. Scope 2 has one catch, however: the GHG Protocol asks for two calculations side by side, a location-based one using the average grid mix and a market-based one using what you actually purchased. Your data model therefore has to carry two answers per kilowatt-hour, not one.
Scope 3 is a different kind of problem. Your figure there depends on data from others: suppliers, carriers, processors, sometimes customers. You buy a product, not a dataset. Few suppliers have a figure ready that is tailored to your purchases; what they send is usually an average per product group. You estimate the rest: from spend per purchasing category, from weight and distance for transport, or from an industry average. Those estimates are legitimate, but they must remain recognisable as estimates, even when the number ends up three systems downstream on a dashboard. In transport-intensive chains, the input comes through the trip and shipment records.
Which entities and locations count
Before you can add anything up, you need to be clear about what you are adding up. This is called the organisational boundary, and the GHG Protocol devotes a separate chapter to it in the Corporate Accounting and Reporting Standard, under the heading Setting organisational boundaries. There are two routes. Under the equity share approach, you count an associate's emissions in proportion to your stake. Under the control approach, you count one hundred per cent of what you control, where control can be financial or operational. Both are permitted, but they give different answers, and the answer changes again if you pick one route one year and the other the next.
In practice the pain lies in the edge cases. A leased building where the landlord buys the energy and recharges it to you. A joint venture in which you hold half but do not decide. Lease cars registered to the leasing company but driven by your staff. A subsidiary acquired halfway through the year. Each case has a defensible choice, but the choice must be fixed and repeatable, because next year someone else may be doing the calculation.
For the software, this means the entity structure is not a dropdown but a model with validity over time. Every entity, site and integration has a period during which it belonged to you and a basis on which it counts. A takeover halfway through the year then naturally produces a part-year figure rather than a debate. And because certification and reporting schemes can apply their own boundaries, the same underlying data must be able to serve several boundaries without you entering the figures twice. The CO2 Performance Ladder, for example, includes business travel, a scope 3 category in the GHG Protocol, in the emissions inventory from the lower levels onwards.
Primary and secondary data in the supply chain
For scope 3, there is a clear hierarchy of data, and that hierarchy is spelled out in the schemes. Handbook 3.1 of the CO2 Performance Ladder calls for emissions data that is as specific as possible and well substantiated, so that the assumptions, sources and system boundaries used are clear. Preferably, product data comes from studies conforming to ISO 14067, on the carbon footprint of products, or to the GHG Protocol Product Life Cycle Accounting and Reporting Standard. If those are not available, you use data from your supplier or customer, provided it is demonstrably representative and supported by underlying studies or calculations. If that is also lacking, you fall back on the most specific factors available in the literature. For materials, the same handbook points to the Dutch National Environmental Database, or to data from an EPD or MRPI certificate.
This hierarchy is not theory: it determines what your data model looks like. Every supply chain data line carries not only a value, but also a level in that hierarchy, a source and a date. That way you can later show that the share of primary data is growing, which is exactly what a client or a certifying body wants to see.
That leaves the question of how to get suppliers on board. Sending out a questionnaire rarely works: it lands with the wrong person, asks for data that doesn't exist and returns answers you cannot verify. What helps is piggybacking on what already happens. Ask at an existing touchpoint, such as a contract renewal or a supplier review. Ask only for what you actually use in the calculation, and pre-fill the form with what you already know from the purchase order, so the supplier confirms rather than fills in. Reuse an answer for every line it applies to, and only ask again when it is out of date. Feed back what you do with the figure, because a supplier who sees their own position in your overview will respond faster next time. And bear in mind that there is now a limit on what you can require of smaller parties, as described below.
What the omnibus changed about who must report
The European reporting obligation has been substantially narrowed in two years. Following the European Commission's omnibus simplification package, the reporting obligation has been limited to the largest undertakings, with a threshold based on the number of employees combined with a turnover limit. This change affects the Corporate Sustainability Reporting Directive, Directive (EU) 2022/2464. Ask your accountant to confirm whether you fall under the obligation, as the thresholds and implementation dates have been amended repeatedly in recent years.
Whether you need a CO2 accounting system depends less than you might think. The same directive limits what reporting companies may request from smaller parties in their supply chain. A company that does not reach the average of a thousand employees is a protected undertaking: no more may be asked of it than the voluntary standard allows. So fewer parties publish their own figures, while the demand for emissions data continues to pass down through contracts and tenders. That is why the focus shifts from reporting to calculating.
What a CO2 accounting system needs to do
These components are connected. Version control without recalculation produces an unusable archive, and an audit trail without a data quality label shows where a figure came from, but not how reliable it is.
Input from invoices, meters and systems
Integrations with energy suppliers, meters, fleet management and procurement, with manual entry where there is no other option.
Version control of emission factors
Every factor with its source, year and validity period. The calculation records which version it used, not just the outcome.
Recalculation as a feature
Re-running a closed year with a different set of factors, alongside the original result, with the reason for the change noted.
Data quality per line
Measured, derived or estimated, with the method stated, so that a total never looks more certain than the underlying data allows.
Supplier data requests
A portal for supply chain data, with a fallback to a calculated estimate as soon as a supplier provides nothing usable.
Audit trail back to the source
From each line in the report back to the measurement beneath it, including who entered and approved what, and when.
What is deliberately missing here is the layer on top: dashboards, targets and a report in the form a reader expects. These matter, but they are only meaningful once the six components above are sound. A chart that falls while half of the underlying lines are estimates and nobody knows which factor version was used is not management information but decoration.
Where emission factors come from and why the version matters
For the Netherlands, the standard factors are published at co2emissiefactoren.nl, an initiative of SKAO, Stimular, Connekt, Milieu Centraal and the national government, managed by Rijkswaterstaat and Stichting Stimular. The figures are based on, among other sources, the latest IPCC report, research by CE Delft and data from CBS, and are updated annually around the turn of the year. RVO also publishes the Dutch list of energy carriers and standard CO2 emission factors.
That annual update is precisely why an emission factor is not a setting in a control panel. The advice for the Dutch list is to use the factor that corresponds to the year you are calculating: a factor published in January applies to the footprint of that year, not the year before. Only where new scientific insights show that a factor no longer holds is retrospective application advisable. In software, this translates into a factor table with validity periods, plus a calculation that records which row it used.
Internationally, it becomes more complicated. The Dutch figures apply to the Dutch situation, specifically for electricity, natural gas, biogas and heat here; for foreign sites, your model must record, for each measurement point, which list the factor comes from. See also energy management software.
- Source, year and version fixed on every calculated line
- Validity period per factor, not a single current value
- Location-based and market-based outcomes side by side
- Units stated explicitly, with conversion to CO2 equivalent
- Importing a new annual list without overwriting earlier results
- Foreign factors clearly identifiable as such
Units, system boundaries and the pitfall of double counting
An emission factor belongs to a unit, and that unit is not always what you think it is. For fuels there are factors per litre and per kilogram, for gas per cubic metre and per gigajoule, for transport per vehicle-kilometre, per passenger-kilometre and per tonne-kilometre. Swap one for another and the result is not off by a few per cent but by an order of magnitude. On top of that comes the system boundary of the factor itself: does it count only the combustion, or also the extraction, refining and transport of the fuel to get there? That choice must be the same across the entire inventory, otherwise you are comparing a lorry on one basis with a van on another.
The real danger lies in double counting. The three scopes are mutually exclusive, precisely so that the same emissions are not counted twice, but in a system fed by multiple sources it happens anyway. The classic example is the journey that enters both through your own driver's fuel card and through the shipment line of a carrier reporting the same freight. Or the electricity of a leased business premises that sits both in your own scope 2 and in the charge passed on to the tenant. Or a lease car you record under scope 1 while the leasing company reports it as part of its own fleet, so that two organisations claim the same kilometres.
Within your own accounts, this is solvable with a rule that is not up for debate: for each activity there is exactly one source that is authoritative, and the other sources serve only as checks. The system should flag when two records affect the same period, the same vehicle or the same connection. Between organisations it is harder, because you cannot enforce what the other party does. What you can do is record the basis on which you included an item, so that when a supply chain question comes up you can show that you are not double counting but applying a different boundary from your chain partner.
There is another form of double counting that is less conspicuous: the one between years. A correction invoice for December that arrives in January belongs to the old year, not the new one. Without a period assignment per line, consumption quietly shifts, and then a reduction appears to have been achieved that is merely a booking difference.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Recalculation is a feature, not an incident
Sooner or later, an earlier year no longer holds up. An emission factor has been revised, a calculation method adjusted, a site acquired, or a supplier finally sends the actual figure where an estimate once stood. The question then is not whether you need to do something, but whether your system can handle it. Anyone who lays the new factors over the old calculation loses the figure that went out last year.
The schemes are more explicit here than much software. Handbook 3.1 of the CO2-Prestatieladder, managed by SKAO, states that a methodological change in an emission factor is always a reason to recalculate the base year, whereas technological progress or changed market conditions are not. The recalculation must be clearly documented, and the handbook refers to NEN-EN-ISO 14064-1, the standard for quantifying and reporting greenhouse gas emissions at organisation level. Functionally, that means being able to re-run a closed year with a different set of factors, retaining both outcomes and keeping hold of the reason for the change.
Base year and recalculation policy
A reduction target needs a reference point, and that reference point is the base year. Everything you subsequently say about progress is a comparison with that one year. This makes the base year the most sensitive figure in the entire accounting: if it shifts, your whole story shifts with it. That is precisely why there should be a documented policy that determines when you recalculate retrospectively, rather than a decision made case by case by whoever happens to be preparing the report at the time.
Such a policy sets out at least three things. First, which events trigger a recalculation: a structural change in the organisational boundary through acquisition or divestment, a change in the calculation methodology, or the discovery of an error in previously reported data. Second, which events do not: organic growth or decline, or switching to a different fuel. Third, the threshold below which a deviation is not worth correcting, because correcting every tenth of a percent makes the series unreadable without making it any more accurate.
In software, that policy is not a document but a setting. The event is recorded, the system proposes the recalculation, someone with the right role approves it, and the new series sits alongside the old one with a reference to the reason for the change. Anyone who later looks up an old annual report should still be able to see which figure it originally showed, and through which steps it has become the current figure. Overwriting is not a technical choice here; it is discarding evidence.
Estimated, measured and the gap in between
Every CO2 accounting mixes three kinds of numbers. Measured values come from a meter or an invoice that states a quantity. Derived values are calculated from another record, such as kilometres taken from a trip log. Estimated values are an assumption: spend multiplied by a ratio, an industry average, or an allocation by floor area. All three are usable, provided the label is on the line itself and not in a footnote.
That label has to carry upwards. For each scope and category, it should be visible what share of the total rests on estimates, because a largely estimated footprint is a different claim from a measured one. It also shows where enquiries are worthwhile: in the category that is large and poorly supported. If a supplier later provides an actual figure, the line changes from estimated to measured, with the date and reason recorded as a visible amendment.
Treat data quality, therefore, as a property of every figure, just like its unit and period. Ideally a line carries four things with it: where the value came from, how it was arrived at, how certain it is, and when it was last confirmed. That last one is often forgotten, yet a supplier figure from a past calendar year is worth something different from one from last month. With those four fields you can produce a report that shows not only the total but how the total is built up, without anyone having to open the underlying tables.
That also makes the conversation more honest. An organisation that openly shows that a large part of scope 3 rests on industry averages is more credible than one presenting an exact-looking figure with the same assumptions underneath. And internally it gives direction: improvement starts with the item that is both large and poorly supported, not with the item that is easiest to measure.
The audit trail, and when a package is sufficient
Once an accountant or a verification body looks on, the question changes. They pick a line from the report and want the route back: what consumption lies behind it, from which source that measurement came, which emission factor was used and which version of it, who entered it and who approved it. If one link is missing, the figure cannot be verified. A closed year should be frozen, so that a later correction appears in the trail as a correction.
What a verifier concretely asks for
A verification rarely turns into a debate about methodology. It is a sample. The verifier selects a number of items, usually the largest and a few at random, and traces them back until he reaches a document that was not produced by your system: a supplier's invoice, a meter reading, a maintenance report, a delivery note. What he wants to see is that the path to that document runs without a manual intermediate step, and that the assumptions, sources and system boundaries are recorded at every stage. The standard for organisation-level greenhouse gas inventory reporting, NEN-EN-ISO 14064-1, asks for exactly the same of the report itself.
In practice this comes down to a handful of requirements for your system. Source documents must be retained and linked to the figure they support, not kept in a shared folder with their own naming. Changes must leave a trail showing who made them, when and why, and the system must distinguish between entering, changing and approving, so that one person cannot inflate a figure on their own. A published version of the report must be kept as a version, including the data it was based on. And the verifier needs read access to everything they must be able to trace, without being able to alter anything. If you only build this once the first verification has been announced, you will end up building it twice.
The footprint of a single product alongside that of the organisation
Sooner or later a customer will ask not about your organisational figure but about the figure for what you supply to them. That is a different method of calculation, and it is wise not to let the two become mixed up. An organisational footprint adds up everything emitted within a defined organisational boundary over a period. A product footprint follows one product through its life cycle, from raw material through production and use to disposal, and expresses the result per functional unit: per piece, per kilogram, per service delivered. The first is a period total, the second a ratio.
For substantiating product figures, schemes refer to their own standards. Handbook 3.1 of the CO2 Performance Ladder mentions studies conforming to ISO 14067 on the carbon footprint of products, or to the GHG Protocol Product Life Cycle Accounting and Reporting Standard, and for materials the Dutch National Environmental Database. The difference from organisational accounting lies mainly in allocation: your gas consumption is one number, but you must explicitly decide which part of it belongs to product A and which to product B, for example by machine hours, weight or order lines.
In software, that translates into two models built on the same source data. Consumption is collected once and validated once; an organisational model then sums it per period and per entity, and a product model distributes it to products or orders via an allocation key. Two separate systems side by side will inevitably produce two figures that cannot be reconciled, and that question will reach you sooner or later.
The level of assurance is fixed in European regulation. In the recent European simplification, a limited level of assurance was retained and the mandate to develop standards for a reasonable level of assurance was dropped. Have your accountant confirm which deadline applies to your situation, as those dates have shifted more than once in recent years. For certification schemes, NEN-EN-ISO 14064-3 covers the validation and verification of greenhouse gas statements. The audit trail is therefore not a module you switch on later, but a property of the data model, recognisable to anyone who has previously had audit software built.
Does that always mean custom development? No. Mature packages exist for carbon accounting, with factor libraries, supplier portals and ready-made exports. If your consumption comes from a handful of standard sources and an annual footprint is the goal, you can buy that off the shelf and shift your effort from building to configuring. Custom development becomes worthwhile for allocation: emissions per project, per product, per customer or per journey, in a structure that exists only for you. Or when the data has to come from your own operational systems in volumes nobody can upload by hand any more. See also software for manufacturing.
- Package software for consumption from a handful of standard sources
- Package software when an annual footprint is the goal
- Custom development for allocation per project, product or customer
- Custom development when the data has to come from your own systems
- Middle route: package software as the calculation core, custom development for the data feeds
Frequently asked questions about carbon accounting
Carbon accounting is the calculation work underneath: collecting consumption data, converting it using emission factors and keeping every result traceable to its source. Sustainability reporting is the accountability layered on top, covering materiality, defined data points and publication. You may need the first without being subject to the second, for example because a tender asks for figures.
You calculate Scope 1 and 2 using data already in your own administration: meter readings, gas invoices, fuel cards. Scope 3 concerns emissions generated by others in your value chain, divided into fifteen categories in the Corporate Value Chain (Scope 3) Standard. You are buying a product, not a dataset. Whatever a supplier does not supply, you have to estimate, and that estimate must remain clearly labelled as an estimate.
For the Netherlands they are published at co2emissiefactoren.nl, an initiative of SKAO, Stimular, Connekt, Milieu Centraal and the Dutch government, managed by Rijkswaterstaat and Stichting Stimular. The list is reviewed annually and usually updated around the turn of the year. The advice is to use the factor that applies to the year you are reporting on.
That depends on the cause. Handbook 3.1 of the CO2-Prestatieladder states that a methodology change always warrants recalculating the base year, whereas technological progress or changed market conditions do not. The recalculation must be clearly documented. Build it in as a feature, with both results shown side by side.
By putting the label on the line itself rather than in a footnote to the report. Every value carries a marker showing whether it is measured, derived or estimated, along with the method. The system aggregates that upwards, so you can see per scope how much of the total rests on estimates and where it is worth asking suppliers for data.
A trail from every line in the report back to the underlying measurement: which consumption, which source, which emission factor and which version of it, who entered it and who approved it. In addition, a closed year must be frozen, so that a later correction shows up as a correction and not as a silent overwrite.
Related services
CSRD and ESG reporting software
If the report itself, with materiality and data points, is the focus, CSRD and ESG reporting software is the place to start.
Energy management software
If you first want to get your consumption under control, with meter integrations and control per site, see energy management software.
Custom ERP system
If the figures must land within the administration itself, alongside purchasing and production, then a custom ERP system is the broader starting point.
Put your current calculation alongside our questions
Tell us where your consumption data comes from, which emission factors you use, and what happens when someone asks how a figure from last year was arrived at. Those answers usually show whether a package, custom development or a combination fits.
If you work with the CO2-Prestatieladder, also look at certificate file software and the on-site CO2 recording app.