Audit-Ready Commute Emissions: How to Document Your Methodology

Document Scope 3 Category 7 commute emissions with clear boundaries, source logs, assumptions, and a single audit file.

AI-generated illustrative image.

If you cannot trace one reported commute-emissions number back to the raw file, the method is not ready for review.

For Scope 3 Category 7, keep the documentation simple and complete:

  • Set the boundary first: sites, legal entities, employee groups, commute modes, and exclusions.
  • List every data source: HR data, surveys, badge logs, rosters, and emission-factor sources.
  • Write the calculation path step by step: PLZ, assigned site, attendance, route, mode, distance, factor, total.
  • Mark what is from source data and what is modelled: for example, EXTRACTED vs INFERRED.
  • Log every assumption: owner, reason, source, period, and effect on the result.
  • State limits in plain words: survey gaps, PLZ-level origin data, modelled routes, and changing attendance patterns.
  • Keep one audit file: methodology note, source log, assumptions register, boundary note, and change log.

In practice, this means you can answer the main review question fast: where did this number come from, and how was it built? If that chain is clear, the reporting process gets much easier for both internal sign-off and external review.

A few points matter most in Germany-based reporting: use PLZ carefully, define ÖPNV as public transport once and stay consistent, and record the exact source and version of factors such as UBA/TREMOD. Also, keep units and factor types separate, especially if one figure is Tank-to-Wheel and another is Well-to-Wheel.

1. Set boundaries and register every data source

Document sites, employee groups, inclusions, and exclusions

Before you calculate anything, set the reporting boundary. List every site, every legal entity, and every employee group that sits inside the report. If you leave out a site or group, say why in plain language and keep that reason in the methodology note. An assurance reviewer will check whether the boundary is complete and whether each source can be traced back.

Your boundary document should also spell out which commute modes are in scope. If you use ÖPNV, define it once as public transport and stick with that wording throughout. If shift patterns or rosters affect how often people travel to work, explain that too. State which employee groups those patterns apply to and how they change commute frequency.

Build a Category 7 data inventory table

Register every source before the modelling begins.

Source Coverage Primary or secondary Data owner Strengths Limitations
HR export (anonymised PLZ) All permanent employees Primary HR department High coverage; official residence proxy Does not capture actual daily transport mode
Badge data or attendance logs On-site staff Secondary Facilities or IT Verifies actual days on site Privacy concerns; does not capture remote-work travel
Employee commute survey Sample population Primary Sustainability team Captures specific modes including cycling, ÖPNV, carpooling Subject to self-reporting bias and low response rates
Shift patterns or rosters Production or logistics staff Secondary Operations Predicts commute frequency for non-office staff May not reflect last-minute absences or schedule changes
German emission factors (UBA/TREMOD) National average by mode Secondary External, public Recognised standard for German transport modes May not reflect specific regional fleet or infrastructure variations

Mark each source as primary or secondary. That sounds simple, but it matters during assurance.

Record data lineage and governance

For each source in the table, record the exact field names you pulled, the extraction date, the system or file version, and the data owner [1]. If you anonymised PLZ data or badge records, document the steps in full, not just a short note saying anonymisation happened [1].

It also helps to tag each input as extracted or inferred. In practice, this shows a reviewer what came straight from source records and what came from assumptions or modelling.

With the boundary and source list locked in, the next step is to show how each input flows into the emissions result.

2. Write down the calculation method and modelling logic

State the primary calculation method and fallback methods

Once your boundaries and sources are set, the next job is to show how each input turns into an emissions figure. That means naming the main Scope 3 Category 7 method for each employee segment or site, then spelling out the fallback method and the exact trigger for using it when the main data is missing.

Be specific. If one segment uses a fuel-based method and another uses a distance-based method, write that down. If you switch to average data when employee-level inputs are not there, note that too. The point is simple: someone else should be able to follow your logic without guessing.

Describe the commute model from raw inputs to emissions output

Write the model flow in this order: location proxy, assigned site, attendance frequency, route logic, mode split, distance, emission factor, and aggregation.

That sequence makes the calculation reproducible for assurance.

Use the same input set for both measure simulation and Scope 3 Category 7 reporting: site locations, employee postal codes (PLZ), and shift patterns. For hybrid or remote workers, use attendance frequency and shift patterns to work out commute frequency. Tag any modelled or fallback value as INFERRED, and any source record as EXTRACTED.

Think of it like a chain. A postal code on its own does nothing. But once you connect it to a site, then to attendance, then to a route and transport mode, you can turn that raw data into a usable emissions output.

Add a method comparison table for traceability

Method Primary use by segment Fallback trigger Evidence to retain
Fuel-based Segments where fuel consumption data is available per employee or vehicle Use when distance or mode data is unavailable Fuel records, vehicle type, segment definition
Distance-based Segments with PLZ-to-site routing and known mode split Use when fuel data is unavailable but location data exists Route logic, distance calculation, mode allocation per segment
Average data Segments with no employee-level location or mode data Default fallback when primary inputs are missing Source of average, segment scope, reason for fallback

Cross-reference the chosen method in the data inventory. Then document the assumptions and emission factors behind the result.

3. Capture assumptions, emission factors, and limitations explicitly

Create an assumptions register with rationale and owner

Once your calculation logic is locked in, the next step is simple: write down the assumptions and factors that can still shift the final number.

Every assumption that changes the total should go into an assumptions register. That gives reviewers a clear way to check each judgement instead of guessing what sat behind the model.

For each assumption, record six items:

  • a plain-language description
  • the reason for using it
  • the data source
  • the reporting period
  • the named owner
  • the calculation step it affects

This sounds basic, but it saves a lot of back-and-forth later. If someone asks, “Why did this number move?”, you can point to the exact line.

Common assumptions include commute frequency, hybrid attendance treatment, carpool occupancy, survey non-response handling, and site-specific mode splits.

Field Example entry
Assumption description Average carpool occupancy is 2.0 persons per vehicle (illustrative example)
Rationale Based on internal employee commute survey data
Source FY2025 Employee Commute Survey
Reporting period FY2025
Owner Sustainability Manager
Materiality / impact Reduces total passenger-km attributed to private vehicles

Use the INFERRED and EXTRACTED tags here as well. They help show how much confidence you have in each input and make the register easier to review.

Reference German emission factors and transport modes clearly

For each emission factor in your model, document the source, year of publication, version, units, and scope. Keep the factor types separate. Do not mix Well-to-Wheel and Tank-to-Wheel figures.

Public transport also needs to be split by mode. S-Bahn, U-Bahn, Regionalbahn, and bus should each have their own factor. If your model uses one blended factor for a mixed-mode commute, spell out how that blend was built and which source supports each part.

For company-organised shuttle services, document the load factor used in the calculation and the cost per boarded rider, if you track it. Both numbers affect how shuttle emissions are assigned to each employee commute.

Disclose limitations, uncertainty, and what the model does not claim

After listing the factors, say plainly what they do not capture.

Each limitation should be stated in writing, along with its effect on the result. If possible, note whether it is more likely to overstate or understate emissions. That kind of plain wording goes a long way in review.

Common limitations include:

  • using postal code (PLZ) level origins instead of exact home addresses
  • modelling route choices rather than observing them directly
  • partial survey coverage where only part of the workforce responded
  • attendance patterns that may change during the reporting period

None of these make the method unusable. The key point is that they are written down, together with a note on the direction of possible over- or under-estimation.

4. Package the methodology for assurance and internal sign-off

Assemble the audit file: methodology note, source log, and change log

Once you’ve documented your assumptions and limits, bring everything together in a single audit file. This file should include the methodology note, boundary statement, data inventory table, source log, assumptions register, and change log. Put simply: a reviewer should be able to take any number in the report and trace it back to where it came from.

The table below shows the role of each artefact.

Artefact What it answers
Methodology note How were emissions calculated?
Boundary statement Which sites and employee groups are in scope?
Data inventory table What sources were used and who owns them?
Source log Where did each input come from?
Assumptions register Why were these values and factors chosen?
Change log What changed between reporting periods, and why?

Getting the method right is only part of the job. The figures in your report also need to match the files behind them. If someone can’t trace a reported figure straight back to the source log, assurance questions will follow. Clear versioning helps here. Each update should be recorded in the change log and linked to the exact assumption or input it changed.

Use one commute model for both reporting and decision-making

Use the same model for reporting and measure simulation. That way, planning and reporting are based on the same logic.

When one model does both jobs, it gets checked more often. Gaps show up earlier. And the audit file reflects actual business decisions, not a separate compliance-only workflow sitting off to the side.

With triply, you use one consistent model across all sites for both baseline reporting and pre-investment measure simulation. You can test measures such as shuttles or public transport incentives and estimate the emissions impact before any budget is committed. The same documented logic then flows straight into your Scope 3 Category 7 reporting, so there’s no need to keep a second model just for assurance.

Conclusion: The direct path to defensible Category 7 reporting

Audit-ready Category 7 reporting comes down to four documented steps: set clear boundaries and register every data source, state the calculation method and fallback logic, record all assumptions and emission factors with rationale, and disclose limitations openly. What matters is a clear written record of what you used, why you used it, and what it does not capture.

If you want to see how triply models your commute baseline, simulates measures before you spend, and produces documentation your assurance team can follow, book a demo.

Related Blog Posts

FAQs

Recent Blog