ecozoom balance sheets

The framework applies to carbon accounting models that natureOffice provides, configures or individually develops in ecozoom. ecozoom is the collective name for the accounting solutions covered here. Different use cases are not controlled via separate methodological frameworks, but rather via the respectively appropriate CCF or PCF framework and the specific template.

In particular, the framework describes:

• how the purpose and scope of a template are defined,

• how PCF and CCF rules are translated into data fields, system boundaries, modules and formulas,

• how input data and emission factors are linked with one another,

• how assumptions, standard values, proxies, estimates and data gaps are handled,

• how templates are documented, reviewed, released and versioned,

• how changes, historical results and error corrections are handled,

• what responsibility natureOffice bears and what responsibility lies with the customer or user,

• what information appears in the keyfactsheet, tracking and confidential documentation.

This framework does not define any additional type of accounting. Whether a result is a CCF, PCF, partial PCF, module value, screening or another key figure depends on the purpose of the accounting, the system boundary and the respectively applied CCF or PCF methodological framework.

The assessment of climate protection projects and the documentation of voluntary project commitment are not part of the accounting methodology. They are regulated separately.

Key principle: ecozoom technically implements documented accounting methodology. The software is neither a standalone accounting standard nor a seal of sustainability.

A template is a versioned calculation model for a defined area of application. It combines:

• the description of the object of the assessment,

• permissible reference quantities and system boundaries,

• default data and data to be entered by the customer,

• mandatory fields, selection options and modules,

• stored emission factors and data sources,

• calculation, allocation and assignment rules,

• units, conversions and rounding,

• technical mandatory field checks,

• the structure of how results are presented.

Each template has a unique technical identity. The template ID is saved and displayed in ecozoom. The name, language or presentation may change without losing the historical assignment. If the calculation logic or the methodological scope changes, a new version status is created.

A template can map a complete CCF or PCF, a partial PCF, an individual module or a recurring calculation case. Its scope is therefore explicitly designated.

The template is not to be equated with the finished assessment. It provides the calculation logic. The concrete result only arises from the template, active factor database, customer inputs and selection decisions.

Each template is assigned to a specific carbon accounting framework. For Product Carbon Footprints, the natureOffice PCF methodological framework applies. For Corporate Carbon Footprints, the natureOffice CCF methodological framework applies. These explain system boundaries, data requirements and applicable standards in more detail.

Depending on the type of carbon footprint and the commission, the following in particular may serve as a basis:

• the GHG Protocol Corporate Accounting and Reporting Standard,

• the GHG Protocol Scope 2 Guidance,

• the GHG Protocol Corporate Value Chain (Scope 3) Standard and the associated Calculation Guidance,

• the GHG Protocol Product Life Cycle Accounting and Reporting Standard,

• ISO 14064-1 for organisation-level greenhouse gas inventories,

• ISO 14067 as well as ISO 14040 and ISO 14044 for product-related carbon footprints,

• applicable Product Rules, sector-specific rules or contractually agreed calculation specifications,

• further statutory or programme-related requirements of the specific use case.

Depending on the type of carbon footprint, the calculation is carried out on the basis of the relevant GHG Protocol standards or the aforementioned ISO standards. The specific basis is stated in the footprint documentation. ecozoom technically implements these methodological rules; the software itself is not represented as verified or certified by the GHG Protocol. Likewise, template approval is not equated with an independent audit of the client's input data.

ISO 14064-1:2018 and ISO 14067:2018 currently remain the published international standard versions. New drafts are monitored, but will only be used as a new basis once they have entered into force.

For the sake of traceability, three levels of documentation are distinguished:

General CCF or PCF methodological framework

It describes the overarching technical rules for the respective balance type. These general rules do not have to be fully repeated in every template.

Template-related method documentation

ecozoom can automatically generate the essential details of a method profile from the stored template. This includes, in particular, template ID, template type, area of application, system boundary, reference value, method and factor status, GWP basis, and version.

For complex standard, industry, or individual templates, the documentation is deepened according to the methodological scope. It can include, for example, process maps, input structures, allocations, scenarios, formulas, and specific exclusion rules.

Balance-related documentation

It describes the concrete application of the template. Depending on the balance type and scope of services, this includes the subject of the balance, reference period, inputs or data sources, system boundary, significant assumptions and exclusions, result, and documentation date.

A new technical review or update of a specific balance is a separate scope of service. The subject, data basis, depth of review, and result are agreed upon in the order or offer.

ecozoom distinguishes between three basic forms:

Standard template

A standard template is developed for a recurring and sufficiently uniform use case. Several customers use the same methodological basic logic. Customer-specific elements are, in particular, input data and the resulting outcomes.

Sector-specific template

A sector-specific template maps typical processes, data structures, system boundaries or calculation rules of an industry. It can be used in a standardised way by several companies in a sector or further adapted for a specific use case.

Individual template

An individual template is developed for a specific customer, production process, service or a special data structure. It has a defined scope of application, its own template ID and its own version status.

Pure language, display or permission variants can use the same methodological identity if formulas, factors, system boundaries and selection rules remain unchanged. On the other hand, a change that can influence the result or the scope of the balance sheet is treated as a new methodologically relevant template version.

The development of a template generally comprises:

• clarifying the use case and intended purpose,

• defining the type of balance sheet and the methodological framework to be applied,

• specifying the reference value, system boundary, processes and data requirements,

• defining data fields, units, mandatory information and selection options,

• technically implementing formulas, factor links and result logic,

• carrying out mandatory field and function checks,

• verifying professional and technical results,

• activating and versioning the template,

• evaluating changes, errors and feedback during operation.

The professional responsibility lies with the project team in charge. Specification, technical implementation, verification and activation are assigned and documented on a project-specific basis. A template is only activated once the calculation logic, system boundary, factor links and presentation of results have been verified for the intended area of application.

Before implementation, the purpose for which a template is intended (e.g. balance sheet, decision, evaluation, or communication) is described. The purpose influences the level of detail, system boundaries, data requirements, and presentation of results.

The scope of application specifies, in particular:

• the type of balance sheet and the subject under consideration,

• intended sectors, products, processes, locations, or types of organisation,

• permissible reference units and time periods,

• the system, organisational, or reporting boundary,

• covered and non-covered emission sources,

• permissible input and calculation methods,

• known cases for which the template is not suitable.

A template is not used outside of this scope of application without first checking whether the data model, system boundary, factors, and formulas remain appropriate.

For example, a template for an intermediate product can calculate a cradle-to-gate PCF. It does not follow from this that it can generate a complete cradle-to-grave PCF for a final product without expansion. Similarly, a simplified screening does not become a complete balance sheet solely by outputting a total value.

The methodology profile is generated from the information stored in ecozoom. In particular, it can contain:

• Template name and unique template ID,

• Template type and consecutive template version,

• Associated CCF or PCF methodology framework,

• Applied standards and supplementary rules,

• Intended scope of application,

• Subject of the assessment and reference unit,

• System, organisational, or reporting boundary,

• Data and factor version,

• GWP basis,

• Template status,

• Date of the version status,

• Known significant limitations,

• Professionally responsible project team.

For more complex templates, the process map, life cycle modules, scopes and categories, inclusion and exclusion rules, input structure, default values, proxies, scenarios, formulas, allocations, and change history can additionally be documented.

The scope and depth of the further specification depend on the complexity and area of application of the template. The automatically generatable methodology profile forms the common minimum documentation.

Input fields are designed in such a way that it is professionally recognisable which information is required. This includes, in particular, field label, explanation, unit, reference period and mandatory status.

Depending on the template, the following may also be stored:

• geographical, technical or temporal reference,

• input as a single value, sum, average, proportion or selection,

• assignment to product, location, scope, category, process or life cycle phase,

• use as activity date, primary date, secondary date, proxy, default value or scenario,

• dependencies on other fields,

• use in the calculation.

Units are clearly indicated at the input. Necessary conversions are carried out via the documented calculation logic. The central formula documentation enables professional staff to understand how the inputs are used in the calculation.

Which information and modules are required is controlled by the system boundary and the logic of the respective template. ecozoom distinguishes between required fields and information that is not needed for a specific balance case.

Mandatory fields must be completed. If a required entry is missing, the system will point this out. Documents can only be downloaded from an active balance status.

An excluded module is not an arbitrary option to hide known emissions. The decisive factor is whether the process lies within the defined system boundary and is applicable to the balance case. The activation or non-consideration of a module must therefore match the designated system boundary.

Key takeaway: It is not the technical choice that determines the scope of the balance, but the previously defined system boundary.

ecozoom can process different types of data:

Activity and consumption data

This includes, for example, material quantities, energy consumption, fuel quantities, transport distances, passenger kilometres, waste quantities, processing times or piece counts.

Supplier- and process-specific data

This includes suitable supplier-specific PCF, site- or technology-specific factors and other sufficiently documented process data.

Secondary data

Average or background data originate from databases used, official sources, scientific publications or other professionally suitable sources.

Spend-based data

Expenditures are linked with monetary emission factors. Spend-based calculations are only permitted in ecozoom in exceptional cases, if no more appropriate quantity-, activity- or supplier-specific data are available and the method is suitable for the accounting purpose.

Proxies, estimates and default values

They can be used if more suitable data is not available with reasonable effort. Selection and suitability are the professional responsibility of the project team and are coordinated with the client as required.

In principle, data that is as specific as possible and representative of the technology, region and time period is used. A better data basis is prioritised for large or decision-relevant emission sources.

The emission factors normally required are selected from the databases connected to or used in ecozoom. Only in justified exceptional cases do natureOffice administrators create additional factors.

For each factor, the source or database, reference year, unit and technical classification are stored, where available. The selection is based on the type of footprint, process, region, technology, time period and system boundary.

ecozoom uses 100-year GWP. Wherever possible, the most current GWP version applicable to the calculation is used. If a database already contains characterised CO₂e values, the GWP basis contained in the respective database version remains authoritative. Different bases are not mixed unnoticed as far as practically possible.

In the case of licensed data, the database source and the year are always indicated in the key factsheet or in the external documentation. Individual licensed factor values are only disclosed within the permissible framework and after consultation with an authorised auditing body.

New factor versions do not retroactively change historical results. A recalculation is carried out using a verifiable, current factor status and generates a new result status.

The most common basic form of an emissions calculation is:

Activity data × emission factor = greenhouse gas emissions

Depending on the balance sheet case, direct measurements, mass and energy balances, stoichiometric calculations, allocations or other professionally suitable methods can also be used.

The formulas are documented centrally and can be verified by technical staff. The documentation includes the inputs used, calculation units, factor links, conversions, allocations and aggregations.

Intermediate results are kept with sufficient computational accuracy. The following standard rounding rules apply to the presentation of results:

• Total results in tonnes of CO₂e: three decimal places,

• Results per functional unit in kilograms of CO₂e: two decimal places.

Different output units can be used if they are more suitable for the order of magnitude and statement of the result. The unit is clearly indicated. A high number of decimal places is not presented as evidence of a correspondingly high data accuracy.

Not every balance sheet case has fully specific data from the outset. Templates can therefore contain assumptions, default values, proxies, and scenarios. These are not presented as measured facts.

The responsible project team makes a technical decision as to whether a value is sufficiently representative for the application. In doing so, particular consideration is given to the source, technological, geographical and temporal fit, system boundaries, and potential impact on results.

Assumptions and default values are adjusted as required and in consultation with the client. A proxy for a specific material or process is not transferred to other materials, suppliers, or technologies without technical verification.

A qualitative statement from a client can justify a preliminary assumption, but it does not replace an actually collected quantitative database. For essential sources, prioritisation is given to improving the database, in so far as this is necessary for the balancing purpose and scope of services.

Empty entries are not included in the calculation in ecozoom. In the case of mandatory fields, the system indicates that an entry is required.

'Empty', 'zero', 'not applicable', 'estimated' and 'excluded' have different technical meanings:

• Empty: No value has been entered; the field is not calculated.

• Zero: The activity has been checked and is indeed zero in the case under consideration.

• Not applicable: The process does not take place in the balancing case or lies outside the defined system boundary.

• Estimated or proxy: The source is calculated using an assumption, extrapolation or substitute value.

• Excluded: A fundamentally relevant source is not calculated; the exclusion must be justified.

The software cannot infer from an empty field whether the activity is actually zero, not applicable or simply not yet recorded. Correct and complete entry is therefore the responsibility of the customer or user. Mandatory fields, system boundary and result designation are linked in the template in such a way that the intended balancing scope remains recognisable.

If a process, consumption or emission value is to be jointly attributed to several products, sites, organisational units or reporting periods, an allocation may be necessary.

Depending on the template, the following is documented:

• which quantity is being distributed,

• why direct allocation is not used,

• to which balance sheet items the distribution is made,

• which allocation key applies,

• from which data the key is derived,

• when an update of the key is required.

Possible keys are, for example, mass, energy consumption, machine time, area, number of pieces, physical properties or – if objectively justified – economic values. The permissible hierarchy depends on the CCF or PCF methodological framework and, where applicable, an applicable Product Rule.

A technically stored allocation is not technically correct solely on the basis of its automation. It must fit the actual production or organisational context. The customer therefore provides the information required for selection or updating.

ecozoom calculates results from the active template version, the assigned factor statuses, the entered data and the selection decisions made.

Depending on the type of balance sheet, results can include in particular:

• Total value in grams, kilograms or tonnes of CO₂e,

• Result per functional unit, reference flow or other reference quantity,

• Result per product, order, location, organisation or reporting year,

• Breakdown by life cycle stages, processes, scopes or Scope 3 categories,

• market-based and location-based Scope 2 results,

• absolute and intensity-related key figures,

• contributions of significant emission sources.

Different result logics are clearly designated. Market-based and location-based Scope 2 values are presented in parallel, but are not added together. A cradle-to-gate PCF is not referred to as a complete cradle-to-grave PCF.

A voluntary commitment to climate protection projects is not included in the CCF or PCF. It does not change the balance sheet value or the underlying result version.

ecozoom performs the calculation within the structure defined for the respective template. Stored formulas, units, factor links, mandatory fields and access rights ensure a consistent technical process. If a required detail is missing, the system alerts the user.

The scope of automated checks depends on the design and area of application of the template. However, technical checks cannot assess whether a customer entry fully and factually reflects the actual operational circumstances. This distinction is central: ecozoom controls the stored calculation logic; responsibility for the provided activity and company data remains with the customer.

Key point: A technically consistent calculation path and a resilient database belong together – but fulfil different tasks.

New and methodologically modified templates are professionally and technically verified before their activation. The scope and depth depend on the complexity, scope of application and possible impact on results.

In particular, the following are verified:

• Formulas and factor links,

• Units and conversions,

• System boundaries and module allocation,

• Aggregations and presentation of results,

• Mandatory fields and permitted selection options,

• Effects of methodologically relevant changes.

Professional approval lies with the responsible project team. Activation confirms that the template can be used for its documented scope of application. It does not confirm the factual correctness of subsequent customer entries and does not constitute an independent verification of each individual carbon footprint calculated with it.

For templates or productively usable calculation states, ecozoom uses the statuses:

Draft

The template or state is currently being edited and cannot be used for new balance sheets eligible for publication.

Active

The template or balance sheet state can be used in the intended scope of application. Customers can only download documents from an active state.

Obsolete

The state has been replaced and cannot be used for new balance sheets.

The status "active" describes the technical usability of the template or balance sheet state. It is not a confirmation of the completeness or correctness of customer inputs. If a specific balance sheet is additionally verified professionally or externally, the subject and scope of this audit will be agreed and documented separately.

Templates are saved with consecutive version numbers, for example Version 1, Version 2, and Version 3. This ensures that the chronological sequence of the approved calculation statuses remains clearly traceable.

A new version is created when calculation logic, factors, system boundaries, data requirements, or other result-relevant components are changed. Editorial changes with no impact on the calculation or application can be tracked within the documentation.

Emission factors are marked with their respective used or current version or data status. The template ID remains as a technical identity; the version number indicates the respective development status.

A new template or factor version does not retrospectively alter already calculated results. A recalculation generates a new balance status.

Calculated results will not be altered retrospectively without notification. Historical versions remain traceable as separate calculation statuses.

Input data of released balance sheet statuses are not overwritten or deleted by subsequent updates in the regular versioning process. Statutory, contractual, and data protection requirements remain unaffected. An exact historical recalculation is possible if the inputs, factors, template versions, and data statuses used at the time are fully documented and remain available.

For traceability, the following are specifically stored or referenced:

• Template ID and template version,

• input data used,

• factor and data status,

• balance sheet object, reference unit, and period,

• significant selection decisions,

• result and documentation date.

For older templates or balance sheet statuses, full technical reproducibility is reviewed on a case-by-case basis. Limitations are transparently stated and not masked by a recalculation using current factors. Technical regulations regarding data security, backups, and recovery are described in the designated performance and security documentation.

A template update and the recalculation of a specific carbon footprint are different processes.

Template update

natureOffice modifies the calculation model, for example due to new emission factors, amended GWP bases, new standards, technical developments, customer requirements or identified errors.

Carbon footprint update

A specific carbon footprint is recalculated with new activity data, a new template or factor version, or corrected information. It receives a new footprint status.

An updated template does not automatically change existing carbon footprints. A recalculation becomes necessary if the existing footprint status is no longer sufficiently representative of the product, company, time period or intended use.

Whether an additional technical review takes place depends on the agreed scope of services. The subject, depth of review and documentation are specified in the offer or contract.

The quality of a result does not only depend on technically correct formulas. Completeness, temporal, geographical and technological representativeness as well as the reliability of the data used are also crucial.

The responsible project team takes these characteristics into account when selecting and technically classifying data and factors. Significant assumptions, proxies, estimates, scenarios and spend-based calculations are identified – as far as they are relevant to the balance sheet case.

natureOffice does not use a flat-rate public overall score that condenses different data qualities into a seemingly unambiguous number. Such a key figure could hide weaknesses, especially with important emission sources. The professional classification of the data basis actually used therefore remains crucial.

Responsibility is divided between natureOffice and the customer or user.

natureOffice or the responsible project team is particularly responsible for:

• methodological design and documentation of the template,

• selection and technical allocation of centrally stored factors,

• implementation and technical verification of the documented formulas,

• technical structure of units, mandatory fields and selection rules,

• template ID, status and versioning,

• evaluation and correction of identified methodological or technical errors,

• additional technical verifications, provided these have been explicitly commissioned.

The customer or user is particularly responsible for:

• correct and complete description of the subject of the balance sheet,

• accuracy, completeness and temporal allocation of their input data,

• selection of the actually applicable product, process, location and supplier information,

• use of the template within its intended scope of application,

• updating of modified production, organisational and supplier data,

• provision of agreed evidence and explanations,

• appropriate use of the generated results and documents.

In ecozoom, customers have admin or user rights with different access levels. Methodologically relevant template and factor changes remain reserved for the designated natureOffice roles.

The specific form of data provision and any agreed customer confirmation is defined in the quote or order. Subsequent significant data changes create a new balance sheet status and must be reclassified from a technical perspective.

The key factsheet contains, in particular:

• type and subject matter of the assessment,

• reference unit and reference period,

• system, organisational or reporting boundary,

• applied CCF or PCF methodological framework,

• result and key breakdown of results,

• role of key primary, secondary, proxy or spend-based data,

• key assumptions, scenarios and exclusions,

• factor or database source and year specification in a legally permissible licensing form,

• date of documentation.

The template ID and the technical version status are saved in ecozoom and ensure the internal traceability of the calculation status. The key factsheet puts the result into a professional context; it is not a certificate of conformity and not a sustainability seal.

Public tracking can display emissions data and the information intended for its contextualisation. Further documentation is provided in compliance with GDPR and, if applicable, under password protection, access restrictions or a confidentiality agreement.

In particular, the following remain confidential:

• recipes, bills of materials and specific process parameters,

• purchasing and supplier conditions,

• personal or security-relevant information,

• license-protected individual factor values,

• internal test protocols and technical system details.

Confidentiality must not be used to misleadingly present the subject of the assessment, reference unit, system boundary or key exclusions.

Voluntary commitment to climate protection projects is not part of the CCF or PCF calculation. It is treated separately from the balance sheet value technically, computationally, and communicatively.

This means:

• The calculated CCF or PCF is reported without deducting any project commitment.

• Project support is not entered into the balance sheet as a negative emission value.

• No net PCF, net CCF, or result after project commitment is calculated.

• The commitment does not make a product or company emission-free or climate-neutral.

• Changes to the commitment do not alter the underlying balance sheet version.

Tracking reflects this separation accordingly. A separate Climate Engagement Record documents the voluntary commitment and the associated project information. It does not mathematically assign the commitment to a product or its emissions, and alters neither PCF nor CCF.

For project assessment, verification, and communication, the separate natureOffice framework for voluntary project commitment applies.

If a possible formula, factor or mapping error is detected, it is evaluated from a functional and technical perspective. The intended procedure includes:

• investigating the cause and potential impact on results,

• identifying affected template and balance sheet versions,

• preventing the further use of a faulty version if necessary,

• checking and activating a corrected template version,

• documenting changes and impact on results,

• specifically informing affected customers,

• coordinating necessary recalculations.

The methodological and quality framework is versioned and regularly reviewed. Adjustments may become necessary, in particular, due to new standards, changes in CCF or PCF methodology, new databases, technical developments, customer feedback, errors or new template types.

The functional responsibility lies with the respective project team. Changes that are methodologically or technically significant are coordinated between the participating functional and technical roles.

For new and significantly modified templates, the current methodological and quality framework is used as a basis. Historical balance sheets are not rewritten retroactively, but retain their original template, data and factor basis.

A change to this general framework does not automatically alter existing results. The decisive factor is whether the previous calculation remains representative for its subject matter and intended purpose.

Closing statement: It is not the software interface that makes a CO₂ value comprehensible, but the documented connection between method, data, calculation logic and version.