Manufacturing & Industrial
Carbon Reporting Intelligence API
The reporting deadline is fixed, the methodology is prescribed, and most of your emissions sit with suppliers who have never measured anything.
- Sustainability software vendors
- Manufacturers
- ERP and procurement platforms
- Auditors and assurance firms
- Industrial groups
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Direct emissions are the easy part. Fuel burned on site and electricity purchased are metered, invoiced and straightforward to convert with a published factor. Any competent spreadsheet handles it. The difficulty is that for a typical manufacturer those categories are a small fraction of the total, and the regulations increasingly ask about the rest.
The rest is purchased goods and services, which means suppliers. Some will provide a product-level figure. Most will provide nothing, or a company-wide number with no allocation basis, or a figure computed on a methodology they cannot describe. Faced with that, the standard practice is spend-based estimation: multiply what you paid by an industry average emission factor. It produces a number, it is accepted under the protocols, and it is extremely coarse — switching to a lower-carbon supplier at the same price changes nothing in the result.
What makes this an engineering problem rather than a consulting one is the audit trail. Every figure in a disclosure has to be traceable to a quantity, a factor, a factor version and a methodology choice, and reproducible a year later when an assurance provider asks. Doing that across tens of thousands of purchase lines, several factor databases that get revised annually, and a methodology that changes between reporting standards is exactly the kind of work an API should absorb.
Who buys this
Sustainability software vendors, Manufacturers, ERP and procurement platforms, Auditors and assurance firms, Industrial groups
What the API returns
What comes back
- Scope 1 and 2 calculations from activity data with market and location-based electricity treatment
- Scope 3 estimates by category, with the method used stated per line rather than in aggregate
- Supplier-level estimates with the allocation basis and data quality tier recorded
- Emission factor resolution with source, version and effective date on every figure
- Data quality scoring per line, so a supplier-specific figure is distinguishable from a spend average
- Full calculation audit trail, reproducible against the factor versions used at the time
- Reporting outputs shaped for the frameworks you are obliged to use
- Hotspot analysis showing where better supplier data would most change the result
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/calculate/scope12 | Calculate direct and energy emissions from activity data |
| POST | /v1/calculate/scope3 | Estimate value chain emissions from purchase and logistics data |
| GET | /v1/suppliers/{id}/emissions | Supplier-level estimate with allocation basis and quality tier |
| GET | /v1/factors/resolve | Resolve an emission factor with source, version and date |
| GET | /v1/reports/{period}/audit-trail | Full reproducible calculation trail for a period |
| GET | /v1/hotspots | Categories and suppliers where better data would most change the total |
Request and response
illustrativeRequest
{
"entity_id": "ent_group_uk",
"period": { "from": "2026-01-01", "to": "2026-12-31" },
"activity": {
"natural_gas_kwh": 4120000,
"electricity_kwh": 9840000,
"electricity_contracts": [{ "type": "REGO_backed", "kwh": 6000000 }],
"diesel_litres": 182000
},
"purchases_file": "s3://sustainability/2026/purchase_lines.csv",
"framework": "ghg_protocol",
"factor_set": "defra_2026"
}Response
{
"entity_id": "ent_group_uk",
"period": "2026",
"calculated_at": "2026-10-21T16:27:00Z",
"factor_set": { "name": "defra_2026", "version": "2026.1",
"published": "2026-06-30" },
"results_tco2e": {
"scope_1": 1042.4,
"scope_2_location_based": 2038.9,
"scope_2_market_based": 814.2,
"scope_3": {
"purchased_goods_services": 41820.6,
"upstream_transport": 3104.2,
"waste": 188.4,
"business_travel": 402.1
}
},
"scope3_method_mix": [
{ "method": "supplier_specific", "share_of_tco2e": 0.21, "quality_tier": 1 },
{ "method": "average_product_data", "share_of_tco2e": 0.34, "quality_tier": 3 },
{ "method": "spend_based", "share_of_tco2e": 0.45, "quality_tier": 5 }
],
"hotspots": [
{ "supplier": "Westmoor Precision Ltd", "category": "purchased_goods",
"estimate_tco2e": 3820.4, "method": "spend_based",
"improvement_if_supplier_specific": "±62% uncertainty reduction" }
],
"audit_trail_reference": "trail_ent_group_uk_2026",
"caveat": "45% of Scope 3 by mass is spend-based. Figures are estimates, not measurements, and are not an assurance opinion."
}Where the data comes from
| Published emission factor databases | Government and institutional factor sets, which are the recognised basis and are revised annually — version pinning is essential |
| Your activity data | Metered fuel, electricity, refrigerant and fleet consumption from invoices and meters |
| Your purchase ledger | Spend by supplier and category, which is what spend-based estimation runs on |
| Supplier-provided emissions data | Product or company figures suppliers disclose, with the allocation basis recorded where they state one |
| Grid emission factors by region and year | Published grid intensities, which move annually and differ sharply between markets |
| Industry life cycle inventory data | Sector average intensities, some freely published and some commercially licensed with redistribution restrictions |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Factor versioning as a first-class concept: every calculated figure stores the factor, its source and its version, because factor sets are revised and a restated prior year has to be reproducible
- Method hierarchy applied per line — supplier-specific, then average product data, then spend-based — with the method recorded rather than blended invisibly into a total
- Purchase line classification to activity categories, which is the bulk of the engineering effort and the main source of error in practice
- Data quality tiering per line following the recognised scoring approach, so a disclosure can state its own reliability honestly
- Dual electricity accounting, since location-based and market-based figures differ substantially and both are typically required
- Uncertainty propagation through the aggregation, because a total built mostly from spend averages carries uncertainty that a single figure conceals
- Full recalculation capability against historical factor versions, which is what a restatement or an assurance review actually requires
- Hotspot analysis ranked by the effect better data would have, so supplier engagement effort goes where it changes the number
What it changes for the business
Audit-ready arithmetic
A reproducible trail per figure is what an assurance provider asks for and what spreadsheets cannot produce.
Supplier engagement prioritised
Hotspot ranking shows which twenty suppliers would actually move the total.
Reporting cycle compressed
Calculation across tens of thousands of purchase lines stops being a manual quarter-long exercise.
Defensible uncertainty
Stating method mix and quality tiers is more credible than a single precise-looking number.
How it fits into your product
How it embeds
- Purchase and activity data ingested from your ERP on a schedule or by file
- Calculation results written back against the period, entity and supplier records
- Audit trail endpoints your assurance provider can be given scoped access to
- Framework-shaped reporting outputs for the disclosures you are obliged to file
- Deployment inside your infrastructure where ledger data cannot leave
- Per-entity and per-subsidiary scoping for groups consolidating across legal entities
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Is this an assurance or audit service?
No. It calculates, documents and makes figures reproducible. Assurance is an opinion given by a qualified provider, and it is not something software supplies. What this does is make the assurance engagement far cheaper, because the trail the provider asks for already exists in the form they want it.
How accurate are spend-based Scope 3 estimates?
Coarse, and the number should be presented as such. Multiplying spend by a sector average intensity has an uncertainty you would measure in tens of percent, and it cannot distinguish between two suppliers at the same price with very different footprints. It is accepted under the protocols because nothing better is available at scale. The API reports the method mix and quality tiers explicitly so a reader can see how much of the total rests on averages, and the hotspot analysis exists to shrink that share over time.
Can you get emissions data from our suppliers?
We can build the collection mechanism — structured requests, a submission interface, validation of what comes back. We cannot make suppliers respond, and most initially will not. Realistically you get supplier-specific data from your largest suppliers first and spend-based estimates for the long tail for several years. A proposal implying otherwise is not describing how this actually goes.
What happens when factor sets are revised?
Historical calculations stay pinned to the factor versions in force at the time, so a published prior year does not silently change. Where a restatement is needed, the recalculation runs against the new factors as a separate, labelled result with both figures retained. This is handled as core design rather than as a later feature, because getting it wrong makes every prior disclosure unreliable.
Are the factor databases redistributable?
Government factor sets generally permit this use. Several commercial life cycle inventory databases restrict redistribution and sometimes restrict API exposure of derived values, which matters if you are a platform reselling calculations. We check each source during discovery and design around any that do not permit your intended use.
Related blueprints
Industrial Supplier Intelligence API
Capacity, financial distress and disruption signals for the suppliers a manufacturer depends on, delivered as monitoring rather than a one-off report.
Utility Asset Risk API
Deterioration, weather exposure and failure risk scoring for distributed utility assets, as a planning layer for network operators.
Predictive Maintenance API
Failure probabilities, anomaly scores and maintenance recommendations for industrial equipment, served to your CMMS or plant software.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.