Multi-tenant SaaS makes carbon measurement harder than the formula — because you have to answer attribution questions: “Which tenant’s usage drove which emissions?” For CSRD/ESRS E1 oriented workflows, consistent allocation is often what turns a dashboard into a reporting artifact.
1) Attribute activity data using tenant_id (or equivalent)
Your best lever is the same as in billing and analytics: a stable key that links inference events to the customer/tenant context. In many architectures that is tenant_id.
If your usage pipeline does not carry tenant attribution, you can still compute totals — but allocation becomes a manual step later (and assurance will be harder).
2) Separate test vs production (if your boundary needs it)
Many teams run evaluation, staging, and experiments. If those should be excluded (or treated differently), keep separate aggregations:
- test events (QA, benchmarks, R&D) vs
- live events (customer-facing production inference)
3) Handle shared traffic deliberately
Not all inference calls belong cleanly to one tenant. Common examples:
- system-level background tasks
- shared “copilot” routes that mix contexts
- provider calls that serve multiple tenants before splitting
Decide your allocation rule once and document it. Even if you start with a “best effort” rule, it’s the documentation that keeps the process auditable.
4) Keep coefficient mapping consistent
Allocation is downstream of correctness. If two events share the same tenant_id but map to different coefficient rows due to model identifier changes, your per-tenant totals will be noisy. Use stable model keys and keep a versioned mapping table.
Practical tip: when you publish per-tenant totals, include a short “methodology header” so that the same coefficient table can be reconstructed later.
5) Turn allocation into a reporting artifact
Allocation work is only valuable if it becomes part of your reporting workflow. For example:
- Produce per-tenant totals for the same reporting window you use in climate disclosure.
- Keep an assumptions annex (uncertainty, limitations, and how shared traffic was treated).
- Optionally add a classification context note for Scope 3 discussions (category 1 vs 11 framing).
- Ensure the output is repeatable (same inputs → same totals, with coefficient versions recorded).
Bottom line
In multi-tenant SaaS, the “carbon reporting” challenge is mostly a data engineering challenge: attribution, separation of test/live, and stable mapping to coefficients. Once those are consistent, the token-to-CO₂e math becomes straightforward — and your ESRS E1 story becomes credible.