Sector-Level Data in CORSIA: What Must Be Held Per Flight
· DSTechnoverse · CORSIA & Carbon Markets
CORSIA reporting is aggregated by state pair, but the data behind it must exist per flight. Where aggregation is permitted, where it is not, and why aggregating too early hides errors.
The CORSIA emissions report presents figures aggregated by state pair. That leads some operators to build systems that aggregate early — summing fuel to monthly totals and deriving emissions from there.
This produces a report that looks correct and cannot be verified, because the underlying obligation is to hold data per flight. Aggregation is the last step, not the first.
What must exist per flight
| Data item | Level required |
|---|---|
| Fuel consumed | Per flight |
| Aerodrome pair | Per flight |
| Date of flight | Per flight |
| Aircraft registration | Per flight |
| Aircraft type | Per flight |
| Flight identifier | Per flight |
| CO2 emissions | Calculated per flight |
| State pair classification | Derived per flight |
| Offsetting requirement | Aggregated across applicable state pairs |
Only the last row is genuinely an aggregate. Everything above it must exist at flight level, be retained, and be available to a verifier who selects a sample of individual flights and traces each one end to end.
That sampling approach is why early aggregation fails. A verifier picking twenty flights from the year and asking for the fuel figure and its source for each cannot be answered by a system holding monthly totals.
Why early aggregation hides errors
Summing before checking removes exactly the signal the checks depend on.
| Error | Visible at flight level | Visible after aggregation |
|---|---|---|
| A single implausible uplift quantity | Yes | No — absorbed into the total |
| An uplift with no matching sector | Yes | No |
| A sector with no matching uplift | Yes | No |
| A date assigned to the wrong month | Yes | No |
| Wrong aircraft registration | Yes | No |
| A misclassified state pair | Yes | Only as an unexplained total |
| A duplicated record | Yes | No |
This was the sixth material finding in the verification described in fourteen findings from a first CORSIA verification: reconciliation checks were running after aggregation, so individual anomalies were invisible. The fix was to move the checks upstream, which is a data architecture decision rather than a reporting one.
The correct order of operations
- Capture fuel and flight data at flight level.
- Reconcile — match every uplift to a sector and every sector to an uplift.
- Resolve exceptions.
- Apply density and convert volume to mass, per record.
- Apply the emission factor, per flight.
- Classify each flight by aerodrome pair and state pair.
- Then aggregate by state pair for reporting.
- Derive the offsetting requirement from the aggregated figures.
Every check happens before step seven. Once aggregated, the data is a reporting output rather than a working dataset, and it should not be the thing anything is calculated from.
Retention
| Item | Retention |
|---|---|
| Flight-level dataset | Full CORSIA retention period |
| Source records — dockets, invoices, logs | Full retention period |
| Reconciliation and exception records | Full retention period |
| Data gap documentation | Full retention period |
| Aggregated report | Full retention period |
| Calculation methodology and version | Full retention period |
Retaining only the report is not sufficient. If a prior year is queried, the operator must be able to reproduce the aggregate from flight-level data and trace individual flights back to their source records.
The methodology row matters where systems change. If the emissions calculation was performed by a system since replaced, the retained dataset and a description of the method are what allow a prior year to be reconstructed.
Designing the data model
| Table | Grain | Key fields |
|---|---|---|
| Flights | One row per flight | Date, registration, type, origin, destination, block times, flight ID |
| Fuel uplifts | One row per uplift | Date, station, registration, quantity, units, density, supplier |
| Reconciliation | One row per match | Uplift ID, flight ID, allocation basis |
| Exceptions | One row per exception | Type, status, owner, resolution |
| Emissions | One row per flight | Fuel mass, factor, CO2, state pair classification |
| Report aggregate | One row per state pair | Total CO2, flight count |
Keeping uplifts and flights as separate tables joined by a reconciliation table, rather than forcing a single combined record, is what makes tankering and split deliveries representable. An operator that models one uplift per flight will find its data model cannot express a real operation — see when fuel records and flight records do not match.
For the systems that hold this see CORSIA data systems and automation; for the plan describing it, CORSIA emissions monitoring plan guide. Reporting requirements are defined in the ICAO CORSIA implementation elements.
Frequently Asked Questions
Does CORSIA require flight-level data?
Yes. Fuel consumed, aerodrome pair, date, aircraft registration and type, flight identifier and calculated CO2 must all exist per flight. Only the offsetting requirement is genuinely an aggregate.
Can emissions be calculated from monthly fuel totals?
No. Emissions must be calculated per flight and aggregated afterwards. A system deriving emissions from monthly totals cannot answer a verifier who samples individual flights and traces each to its source records.
Why does aggregating early cause problems?
Because it removes the signal the reconciliation checks depend on. Implausible quantities, unmatched uplifts, wrong registrations and duplicated records are all visible at flight level and invisible once summed.
What order should the calculation follow?
Capture at flight level, reconcile fuel to sectors, resolve exceptions, convert volume to mass per record, apply the emission factor per flight, classify by state pair, then aggregate — with every check completed before aggregation.
What data must be retained?
The flight-level dataset, all source records, reconciliation and exception records, data gap documentation, the aggregated report, and a description of the calculation methodology and system version, all for the full CORSIA retention period.
How should the data model be structured?
Flights and fuel uplifts as separate tables joined by a reconciliation table, rather than one combined record. Forcing one uplift per flight cannot represent tankering or split deliveries, which occur in any real operation.
Planning your CORSIA position? DSTechnoverse provides CORSIA carbon credit services for Indian operators and project developers — scope and readiness assessment, monitoring plans, data pipelines, verification support, unit sourcing and second-phase modelling. We are based in Indore, Madhya Pradesh and work across India.
Apply as a CORSIA buyer or seller
Talk to our carbon markets team about your position.