Understand uncertainty propagation and how it affects reported values
Work with system ledgers for embodied emissions and renewable instruments
Handle methodology versioning and updates in existing projects
Design multi-project configurations for complex operations
This lesson covers techniques you’ll encounter in complex production projects — situations where the basic patterns from earlier modules need to be extended or adapted.
Carbon accounting methodologies often require reporting uncertainty ranges alongside point estimates. Uncertainty propagates through calculations — if your input measurement has ±5% uncertainty, the output will also have uncertainty.
When you multiply values with uncertainty, the relative uncertainties add (approximately):
Mass: ±5% uncertainty
Carbon content: ±5% uncertainty
Result: approximately ±7.1% uncertainty (√(5² + 5²))
Different methodologies have different rules for uncertainty propagation. Some use simple addition of relative uncertainties, others use root-sum-of-squares (RSS), and some specify fixed deductions. Always follow the methodology’s approach.
Beyond production ledgers that track physical material, some projects need system ledgers for tracking non-physical quantities:
Embodied emissions ledger
Renewable instruments ledger
Tracks the amortized carbon cost of facilities and equipment.
Credits: Annual amortization amount (e.g., 50 tCO2e/year from facility construction)
Debits: Monthly allocation to production batches
Purpose: Ensures embodied emissions are spread evenly and don’t distort individual batch calculations
This is configured as a separate ledger in the mass balance section, linked to the production model’s embodied emissions node.For a complete guide, see Embodied Emissions.
Tracks renewable energy certificates (RECs) or similar instruments that offset grid emissions.
Credits: Purchased RECs (in MWh)
Debits: Applied to production batches (reduces grid emission calculation)
Purpose: Projects that purchase renewable energy can reduce their reported emissions
The ledger balance ensures RECs aren’t double-counted across batches.For a complete guide, see Instruments.
System ledgers follow the same mass balance principle as production ledgers — what goes in must come out or remain in inventory. This prevents double-counting of embodied emissions or renewable instruments.
Methodologies evolve — emission factors get updated, calculation requirements change, new sources must be included. Your project needs to handle these transitions.
In the Model Editor, create a new version of the model with the updated calculations. Previous versions remain linked to historic batches — they aren’t affected by the change.
2
Update static inputs
Change emission factors and methodology parameters in the resource library. Set effective dates if the platform supports it, so historic and future calculations use the correct values.
3
Document the change
Record what changed, when, and why. This is critical for verification — auditors will want to see that the transition was handled correctly.
4
Test the transition
Generate batches for a period that spans the transition date. Verify that batches before the change use the old methodology and batches after use the new one.
Never modify a model version that’s already linked to generated batches. Always create a new version. Modifying an existing version could retroactively change historic batch outputs and break the audit trail.
Even with separate projects, some components can be shared:
Component
Can Be Shared?
How
Emission factors
Yes
Same static inputs across projects
Event type definitions
No
Each project has its own event types
Model logic
Partially
Similar structure but separate instances
Feedstock types
Yes
Common feedstock definitions
Reporting templates
Yes
Standardized report formats
Multi-project configurations are an advanced topic. For most implementations, start with a single project and only split into multiple projects when the operational differences genuinely require it. See the Guide to Production Accountingfor project configuration guidance.
Why should you never modify a model version that's linked to generated batches?
Modifying an existing model version would retroactively change historic batch outputs, breaking the audit trail. Verifiers expect that generated batches reflect the calculations as they were at the time of generation. Always create a new model version for methodology updates — this preserves historic batches while applying new logic to future ones.
What is a system ledger and when would you use one?
A system ledger tracks non-physical quantities like embodied emissions or renewable energy certificates. You’d use one when: (1) the emission source isn’t tied to a specific production event (like annual facility construction costs amortized monthly), or (2) you need to track instruments like RECs to avoid double-counting when offsetting grid emissions across batches.