Platform / Data Infrastructure / Transactions
The unit of data everything is built from
Every operational record becomes a structured transaction with a clear source, classification, and timestamp.
What raw data becomes once it's inside
A transaction is a single structured activity record inside the platform. It's what raw operational data becomes once it has been imported, standardised, and linked to the platform's internal structure. Every emission calculation, every insight, every report line item traces back to one or more transactions.
Each transaction contains: entity, supplier, asset, classification, timestamp, quantity, unit, and source reference. These fields define how the transaction behaves, how it's calculated, where it appears in reporting, and how it's audited.
Transactions are the foundation. If the transaction data is correct, reporting will be correct. If any attribute is wrong, wrong supplier, wrong classification, wrong asset, downstream outputs will reflect that error.
KEY DETAILS
How transactions work
Transactions define how operational data is structured, calculated, and reported across the platform.
Structured fields
Every transaction carries entity, supplier, asset, classification, timestamp, quantity, and unit
Created on import
Transactions are created when data is imported and standardised through the Collect capability
Foundation for outputs
Emissions, insights, and reports are all derived from transactions
Default aggregation
Transactions aggregate by month, classification, supplier, and asset by default
Source preservation
Original source values are preserved. Structure is layered on top, never overwriting the source.
The input to everything downstream
Transactions are the input to everything in the Measure and Report capabilities. The Audit Trail tracks every change to a transaction over time. Classification determines how the transaction is interpreted; supplier and asset determine how it's allocated.
Common questions about transactions
Answers to questions we hear from teams working with transaction data.
Entity, supplier, asset, classification, timestamp, quantity, unit, and source reference. These fields define how the transaction behaves in calculations, where it appears in reporting, and how it's audited.
Transactions are created when data is imported and standardised through the Collect capability. Whether data arrives via API, file upload, or manual entry, the result is the same structured transaction format.
Downstream outputs will reflect the error. Emissions calculations, reports, and insights all derive from transaction attributes. Correcting the classification updates future calculations. The Audit Trail tracks the change.
Yes. Original source values are always preserved. Structure is layered on top, never overwriting the source. You can trace any transaction back to the raw record that created it.
Every emission calculation traces back to one or more transactions. The Measure capability uses transaction data, specifically quantity, classification, and supplier, to select and apply the correct emission factors.
By month, classification, supplier, and asset by default. The Report capability uses these aggregations as line items. You can drill down from any reported figure to the individual transactions behind it.
Transactions are the foundation of Measure
Transactions feed directly into the Measure capability, where emission factors are applied and calculations are produced. Every reported figure traces back to transaction-level data.