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

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:
EXTRACTED vs INFERRED.
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.
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.
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.
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.
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.
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.
| 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.
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:
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.
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.
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:
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.
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 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.
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.