EASA Fuel Consumption Monitoring: A Data-Lineage Test

Executive Summary

EASA's fuel/energy rules sit in CAT.OP.MPA.180 and CAT.OP.MPA.181 of the Easy Access Rules for Air Operations, republished as Revision 24 in March 2026 (Source: www.easa.europa.eu). An operator may run a basic scheme, a basic scheme with variations, or an individual scheme, and the scheme and any change to it "shall require prior approval by the competent authority" (Source: www.easa.europa.eu). An operator that applies for an individual scheme must establish a baseline safety performance of its current scheme and show that it can exercise operational control and exchange safety information with the flight crew. Nothing in the text obliges an airline to seek an individual scheme; the basic scheme remains the default path.

The data requirement is concentrated in AMC8 CAT.OP.MPA.181. It says a fuel consumption monitoring system "should be data driven" and should include a database of statistically significant data of at least two years (Source: www.easa.europa.eu), plus statistics and data normalisation and data transparency and verification. GM1 adds the per-tail rule: data collected from one aeroplane must not be used to vary another aeroplane's performance figures (Source: www.easa.europa.eu). These are acceptable means and guidance, not rule text, and the approved scheme in the operator's manual is what an authority actually assesses.

This report turns that wording into a data-lineage test: can a product chain show, for one tail, which approved configuration and which flight-plan version each planned figure came from, which observation each achieved figure came from, what was excluded, and what was later corrected? The report maps rule text to record fields and owners, proposes acceptance tests for missing ACARS readings, duplicate legs, configuration changes and outliers, and separates what a vendor product, the operator and a narrow data adapter can each evidence. The tests are the report's proposals, not EASA requirements.

Packaged analytics exist, but vendor pages document less than the authority question needs. GE Aerospace says Fuel Insight can "merge flight data with flight plans" ^[1], and IATA describes a voluntary data exchange for planned-versus-actual analytics ^[2]. Neither the GE Aerospace page nor the IATA page documents an EASA authority evidence chain.

EU ETS fuel monitoring is a separate regime, with a monitoring plan approved before the monitoring period (Source: climate.ec.europa.eu) and ten-year data retention (Source: climate.ec.europa.eu).

The stakes are material: IATA's June 2026 outlook puts fuel at 31.4% of airline operating expenses in 2026 ^[3]. Peer-reviewed work shows why aircraft-specific treatment matters, but also why sample size is a real constraint: one study of nine A320 airframes found an uncalibrated model underestimated fleet fuel burn by about 4.81% ^[4]. The EASA text does not define "statistically significant", so the operator and its authority must agree it.

Introduction and Background

European air operators often hold fuel facts in several systems. The flight-planning system holds a planned figure, ACARS (Aircraft Communications Addressing and Reporting System) reports hold achieved figures, flight data monitoring (FDM) holds detailed parameters, and a performance tool holds an aircraft-specific factor. An individual fuel/energy scheme asks whether those facts can be joined, per aircraft, into evidence an authority can inspect. This report addresses that question for European commercial air transport (CAT) operators under an air operator certificate (AOC). It applies EASA rules only; it does not transfer them to US Part 121 or 135 operations or to Canadian 704 or 705 operations, whose rules differ.

The regulatory sequence matters. Regulation (EU) 2021/1296 amended the Air Operations regulation, and EASA's explanatory note states the amended text applies from 30 October 2022 (Source: www.easa.europa.eu). EASA's Opinion 02/2020 explains that individual fuel schemes are "entirely approved and controlled by the competent authorities" (Source: www.easa.europa.eu), and describes them as fully performance-based. That is why the evidence question is local: the national authority, the operator's manual and the agreed safety performance indicators (SPIs) define what is sufficient.

Three limits frame the report:

• Explains, does not instruct. It does not calculate dispatch fuel, prescribe a fuel policy or replace the operator's approved procedures.
• Software grants nothing. Software cannot change a regulatory obligation or grant approval; only the competent authority approves a scheme.
• Separate guidance applies. EASA's Fuel Implementation Manual, which the rules text points to as guidance (the AMC/GM wording calls it the "EASA Fuel Manual"), is not analysed here. Readers should consult it and their authority.

LANDING.AERO, the Montreal software studio that publishes this report, builds custom flight operations software to order for airlines, charter operators and flight departments. It does not sell an off-the-shelf fuel monitoring product, is not an avionics or certified airborne-software developer, and cannot provide or imply authority approval. Where this report discusses a narrow data adapter, it does so as one option among several, and the analysis would be the same without it.

Key Changes in the Fuel/Energy Rules

Change 1: Three scheme types and an approval gate

CAT.OP.MPA.180 requires the operator to establish, implement and maintain a fuel/energy scheme that is appropriate for the operation and matches the operator's capability to support it.

The scheme is one of three kinds:

• Basic scheme: derives from large-scale industry analysis.
• Basic scheme with variations: uses that analysis to establish a variation.
• Individual scheme: "derives from a comparative analysis of the operator's safety and operational data" (Source: www.easa.europa.eu).

Every scheme comprises a planning and in-flight re-planning policy, an aerodrome selection policy and an in-flight fuel/energy management policy.

For a reader deciding whether to pursue an individual scheme, the boundary is practical. An operator that stays on the basic scheme has no individual-scheme baseline to build. An operator that wants a variation faces a different monitoring expectation: Opinion 02/2020 states that a fuel consumption monitoring system is required for the 3% fuel ERA (en-route alternate) variation and other contingency fuel variations (Source: www.easa.europa.eu). The individual scheme adds the baseline, risk assessment and operational-control demonstration. Any change to the approved scheme also needs prior approval, which matters for data design because a changed policy changes the meaning of every downstream SPI.

Change 2: Rule text versus AMC versus operator approval

Three layers should not be conflated. The rule text (for example CAT.OP.MPA.180(d)) is binding. The AMC (acceptable means of compliance) describes one way to comply, and the GM (guidance material) explains. The operator's approved scheme and manual are what the authority holds the operator to. AMC8 CAT.OP.MPA.181 and GM1 are therefore evidence expectations to be agreed, not a certification checklist that a software product can satisfy on its own.

The 2020 Opinion also records that the 2-year period "is selected as it matches the interval for data collection for the statistical" contingency method. That is rationale for the period, not a definition of how many flights make data "statistically significant". AMC1 CAT.OP.MPA.180 adds that the number of flights should be sufficient to support the intended deviation, which ties the sample to what the operator is asking to change.

Change 3: Aircraft-specific data becomes the planning basis

CAT.OP.MPA.181(a)(4) requires fuel/energy planning to be based on "current aircraft-specific data derived from a fuel/energy consumption monitoring system", and on manufacturer data only if that is not available (Source: www.easa.europa.eu). GM1 repeats the preference: monitoring-system data is used in preference to manufacturer data. For an individual scheme, AMC1 CAT.OP.MPA.180 lists a suitable computerised flight-planning system among minimum capabilities. For a data team this means the flight-planning system is both a consumer of aircraft-specific factors and a producer of the planned figures against which achieved figures are judged.

The AMC to CAT.OP.MPA.175 adds a testing duty: where a computerised flight-planning system is used with variations or an individual scheme, the operator should ensure software quality and functionality "are tested after each upgrade" (Source: www.easa.europa.eu). In lineage terms, every planning-software release is a version boundary that the record contract must capture.

Change 4: AMC8 turns "monitoring" into a four-part system

AMC8 CAT.OP.MPA.181 lists four elements: a fuel performance monitoring system, a database with at least two years of statistically significant data, statistics and data normalisation, and data transparency and verification (Source: www.easa.europa.eu). Each element is a testable system property: retained history, the contextual variables (such as weather and route) that were normalised away, and a way to show an inspector how a figure was produced and to reproduce it. The AMC gives no further definition of "transparency", so the operator and authority must settle what reproducible means for the scheme.

Change 5: GM1 and hull-specific fuel bias

GM1 describes the fuel consumption monitoring system, "commonly referred to as 'hull-specific fuel bias'", as a process of comparing an aeroplane's achieved in-flight performance with its predicted performance (Source: www.easa.europa.eu). It then states that data from one aeroplane should in no case be used to vary another aeroplane's figures. It also says the operator should demonstrate that in-service data are accurate and that data should be collected automatically where possible. The UK CAA's retained version of this guidance (UK law, not EASA) points readers to ICAO Doc 9976, Appendix 5 to Chapter 5 ^[5], a readable cross-reference only.

Change 6: Baseline SPIs and continuous reporting

The guidance sets out a sequence of duties:

• Before submission: select SPIs and targets agreed with the competent authority and collect statistically relevant data for at least two years of continuous operation (Source: www.easa.europa.eu).
• SPI content: the non-exhaustive list includes the difference between planned and actual trip fuel.
• After approval: establish an effective continuous reporting system (Source: www.easa.europa.eu) and, on any SPI degradation, assess the root cause.
• Equivalence: compare SPIs and targets with those of the previously approved scheme.
• Authority view: inspector guidance sets a two-year minimum for data collection, and an approval may be rejected, suspended or revoked when findings remain unresolved (Source: www.easa.europa.eu).
• Scope: applicability can be limited to a fleet, type or area, so SPIs may need to be sliced the same way.

The Record Contract: From Approved Configuration to Fuel Observation

What the rules imply a record must carry

A record contract is a written specification of the fields, keys, units, timestamps and ownership that a fuel-performance dataset must carry so that any figure can be traced to its sources. The EASA text does not prescribe such a schema; the contract below is derived from what the text asks the operator to demonstrate. Operator documents already hold some of the data. The operational flight plan (OFP) content listed in the AMC to CAT.OP.MPA.175 includes aircraft registration and fuel calculations with records of in-flight fuel checks, and entries should be permanent in nature. The AMC to CAT.OP.MPA.185 says the operator should agree with the authority what constitutes relevant data and store the recorded data for at least two years (Source: www.easa.europa.eu).

Table 1 below maps the rule text to the fields a lineage test should expect, with a proposed owner. The owner column is an assignment suggestion for the operator's data governance, not a regulatory allocation.

The table's central message is that the tail key and the version keys appear in almost every row. A product that stores a fleet-level or flight-number-level summary cannot answer the per-tail row, however good its analytics. The interpretive test for any candidate system is therefore simple: for each row, can it produce the listed fields for one named tail and one named period without manual reconstruction?

The minimum record keys

A workable contract uses five keys:

• Tail key: the registration of the aircraft that actually flew the leg.
• Plan key: the OFP revision current at departure.
• Configuration key: the approved aircraft configuration on that date, so a performance-relevant configuration change opens a new fuel-factor period.
• Observation key: each reported fuel value by source (ACARS report, FDM, fuel uplift ticket), unit and timestamp.
• Correction key: each change to a prior value, with who, when and why.

The keys map onto the provenance vocabulary of the World Wide Web Consortium (W3C), which defines provenance as information about the entities, activities and people involved in producing a piece of data ^[6] and treats a revision as a derivation whose result is a revised version of an original ^[7]. W3C also notes that provenance of things that change over time is hard to express precisely ^[7], a reason to timestamp versions rather than overwrite them.

Units and density need explicit handling. EU ETS rules for aircraft operators allow fuel to be measured by volume, and the Commission's guidance says the density used must be the one used for operational and safety purposes, either a standard 0.8 kg per litre or an actual value (Source: climate.ec.europa.eu). The monitoring plan must contain a written procedure describing the density factor (Source: climate.ec.europa.eu). A supplier's reproduction of the DEF STAN 91-091 Jet A-1 specification allows densities from 775.0 to 840.0 kg per cubic metre at 15 degrees C ^[8], so a standard value and a measured value are not interchangeable. A record contract should store the unit and density basis with every volume-derived mass.

Hypothetical Example: a tail swap and a revised OFP

(Hypothetical Example) Consider two legs flown on the same day by a single operator. Flight 101 is first planned for Tail A with OFP revision 1 and configuration key K1. Before departure, operations control swaps the aircraft to Tail B (configuration key K2) and a revised OFP, revision 2, is issued. Flight 102 later flies on Tail A under its own plan, OFP revision 1. No fuel-minimum calculation is involved; the point is the join.

A system that joins plans to actuals on flight number and date will attach Tail B's achieved fuel to revision 1, which was calculated with Tail A's factor. The result contaminates two tails at once: Tail A's planned-versus-achieved record for Flight 101 contains another airframe's burn, and Tail B's record is missing the leg. That is exactly the cross-use GM1 says must not occur. A lineage-safe system instead keys the achieved observation to the tail and the plan revision actually in force at departure, retains revision 1 as a superseded record, and marks revision 2's tail and configuration keys. Its export for Tail A would then show Flight 101 as a cancelled-assignment record, not a data point. Three questions test any product against this example:

• Can it show revision 1 and revision 2 side by side with timestamps?
• Can it show that Flight 101's achieved fuel is attributed to Tail B only?
• Can it reproduce Tail A's factor history without Flight 101, from stored versions rather than a recomputed dashboard?

Reconciliation and Normalization Evidence

Reconciling planned and achieved values

The AMC for in-flight fuel management expects the operator to compare actual consumption with planned consumption at in-flight checks. For monitoring, the reconciliation joins three populations: planned values by plan key, achieved values by observation key, and exclusions. A Wildau study of one operator's Boeing 777-200 freighter fleet found mean planned trip fuel of 49,683 kg against an actual mean of 49,658 kg in its reference list ^[9], yet different reports in the same study held different flight counts, for example 40,166 flights in the fuel data validation report ^[9]. The authors list the missing fields that cause a record to be rejected ^[9]. Close averages can hide inconsistent populations, so reconciliation evidence should report counts by report type, not only means.

Normalisation: what must be stripped, and what must be kept

Normalisation removes effects that are not the aircraft's own performance, so the hull factor is not contaminated by weather or payload. An unmeasured effect cannot be normalised out. A study that merged flight recorder data with world area forecast data reported that forecast errors grow with time elapsed since departure ^[10], and its method removed step-climb segments to reduce measurement error ^[10]. A fuel-flow regression study found predictions sensitive to even a small take-off mass error ^[11], so weight-input quality limits any normalised factor, and a turboprop monitoring study required reference flights to span a whole year to avoid ignoring seasonal dependence ^[12].

Aircraft-specific calibration and sample size

Aircraft-level calibration shows measurable effects. A 2025 arXiv paper from EUROCONTROL's sustainability unit and TU Delft analysed approximately nineteen thousand quick access recorder flights from nine distinct airframes ^[4]. An uncalibrated reference model underestimated total fuel burn by approximately 4.81% (1,115 tonnes) in that dataset ^[4], and the paper cites earlier work reporting that per-aircraft coefficient tuning reduced prediction errors from around 3% to under 1% ^[4]. The authors note the limitation of "only nine aircraft of the same type" ^[4]. These are single-dataset research results and do not establish a threshold for any operator.

What "statistically significant" means for a proposed analysis is not defined in the EASA text. The NIST e-Handbook says the required sample size depends on assumed quantities and that without them "there is no correct answer" ^[13]. For an individual scheme the sample argument therefore belongs in the application: tails with few baseline flights, recently re-configured tails and newly inducted tails need explicit treatment, and the manufacturer-data fallback in CAT.OP.MPA.181(a)(4) is the rule-level route when monitoring data are not available.

Outlier handling

Outliers are where evidence quality is most visible. NIST defines an outlier as an observation that appears to deviate markedly from other members of the sample ^[14], and distinguishes labeling, which flags potential outliers for further study, from accommodation and formal identification ^[14]. It also warns that masking can occur when too few outliers are specified in a test ^[14], and that simple standard-score rules can mislead for small samples ^[14]. Regression-tree models are described as robust to outliers in the input data ^[11], which does not remove the need to document exclusions.

The Wildau study treated extreme taxi-fuel values as probable data errors and excluded them ^[9]. The lineage lesson is procedural: an excluded point should remain in storage with a reason code, the rule version that excluded it, and the date, so an inspector can see both the cleaned and the raw population. Deleting outliers is the opposite of transparency and verification.

Implementation Considerations and Process Changes

Baseline SPI lineage and authority-facing export

The baseline is built from historical data for agreed SPIs over a defined period, for example a minimum of two years, and later performance is compared with it. SPI lineage means each SPI value in a report can be traced back through the SPI definition version, the flight set, the planned and achieved records, the exclusions and the corrections. National forms show what a first submission looks like. Latvia's civil aviation authority, an EU Member State authority, asks for evidence of a fuel consumption monitoring system (Source: caa.gov.lv), a baseline safety performance of the current scheme for individual schemes (Source: caa.gov.lv), and an application at least 30 days before the intended start date (Source: caa.gov.lv). A checklist from North Macedonia's authority (a non-EU authority applying EASA material, cited only as an example of inspection questions) tells inspectors to check that the operator compares SPIs before and after the scheme is established (Source: www.caa.gov.mk).

An authority-facing export should therefore be a bundle, not a chart. A reasonable bundle contains:

• the SPI table with definitions and versions;
• the flight list behind each SPI;
• the exclusion register and the correction log;
• the factor history per tail;
• a manifest of source-system extracts with dates.

Whether an authority wants a specific format is for the operator to confirm; the EASA text cited here does not prescribe one.

EU ETS fuel monitoring is a separate evidence regime

Aircraft operators in the EU Emissions Trading System (EU ETS) must also monitor fuel, under a monitoring plan approved by the competent authority before the monitoring period starts (Source: climate.ec.europa.eu). The Commission's guidance for aircraft operators was updated on 9 February 2026 (Source: climate.ec.europa.eu). Each aircraft must use consistently one of two block-based methods, not both (Source: climate.ec.europa.eu); monitoring data are kept for 10 years (Source: climate.ec.europa.eu); and the percentage of flights with data gaps is reported (Source: climate.ec.europa.eu), with notification to the authority where gaps exceed 5% of annual flights (Source: climate.ec.europa.eu). The guidance says the monitoring must withstand a quite intensive verification test (Source: climate.ec.europa.eu) and that aircraft operators face one uniform data quality level, not tiers (Source: climate.ec.europa.eu).

The two regimes differ in purpose. ETS evidence supports an emissions report checked by an accredited verifier; EASA scheme evidence supports a safety case for a fuel/energy policy overseen by the aviation authority. They overlap in raw data (fuel uplift, tank content, block times, density), so a lineage design that serves both avoids two inconsistent fuel histories, but meeting one does not evidence the other. The ten-year ETS retention is longer than the two-year EASA recording period, so shared raw data would follow the longer period, subject to the operator's own advice.

Acceptance tests

The tests below are proposed by this report as a way to exercise the record contract. They are not EASA requirements. Table 2 lists each test, the setup, the expected behaviour and the artefact an inspector could be shown.

The table's pattern is that every test ends in a retained artefact, not a correct number. A system can compute a plausible hull factor and still fail the transparency and verification element if it cannot show the artefact. Rule-level tests differ by operator, so the agreed manual and authority expectations should shape which of these tests are mandatory.

Vendor and operator responsibilities

Packaged products cover part of the chain. GE Aerospace describes Fuel Insight as software that can "merge flight data with flight plans" ^[1], lets users drill down from macro trends to a per-flight level ^[1], and lets organisations control how and where data flows ^[1]. The GE Aerospace page does not describe an EASA scheme evidence chain, per-tail factor history or correction logging. IATA describes its Flight Operations Data Exchange (FOX) as enabling analytics that link planned and actual performance ^[2], with understanding planned-versus-actual deviations as a benefit ^[2]. FOX is a voluntary data-sharing initiative, and IATA's FOX page does not describe a fuel scheme approval.

Other vendors document adjacent capability. OpenAirlines describes fuel estimations computed with a fuel factor for the individual aircraft ^[15], a recommended new fuel factor based on performance history ^[15], over 100 quality checks ^[16] and an export function to external reporting tools ^[16]. Jeppesen describes a fuel dashboard example using quick access recorder and flight-plan data to compare planned and actual take-off weight ^[17]. Honeywell states that its Forge Flight Efficiency platform is designed to help build the kind of data needed for the statistical contingency fuel method ^[18], in an article that lists the planning-tool, equipment, data-gathering and operational-control requirements for an individual scheme ^[18]. These are vendor statements. The vendor pages reviewed do not document audit trails, correction histories or authority exports in those terms, which is a finding about documentation coverage, not about the products' full capability. Buyers should ask vendors directly, for example:

• Are superseded flight-plan versions stored, or overwritten?
• Is achieved fuel attributed to the tail that flew, after a swap?
• Are excluded records retained with a reason code and rule version?
• Can an earlier period's figures be regenerated as originally issued?
• What export formats and field-level documentation exist?

Table 3 below separates responsibilities. The category rows are generic; named products appear only where a cited vendor page documents the capability.

The first message of this table is that no single layer evidences the whole chain. The second is that the authority row is not delegable: a vendor can supply data and analysis, but the approval decision, and what data are "relevant" for recording, are agreed between operator and authority. The adapter row is deliberately narrow. A custom adapter adds value mainly when the existing planning, fuel and safety systems each hold part of the chain but nothing joins them on the tail, plan and correction keys, and when a packaged product's export does not carry those keys. If a packaged product already stores them, an adapter adds little.

Data Analysis and Evidence

Economic stakes. IATA's June 2026 industry outlook forecast fuel at 31.4% of airline operating expenses in 2026 ^[3] and global airline fuel costs rising from $252 billion in 2025 to $350 billion in 2026 ^[3], with total consumption flat at 104 billion gallons ^[3]. IATA also said a lack of new aircraft halted gains in fuel efficiency in 2024 and 2025 for the first time in history ^[3]. Because consumption is flat, the cost rise comes from price, so a monitoring programme's economic case is sensitive to fuel price; these are forecasts as of June 2026. EUROCONTROL estimated ATM-related fuel and CO2 benefits (theoretical optimum) of approximately 9% for flights in its area in 2025 (Source: www.eurocontrol.int), a ceiling, not a recoverable target.

Regulatory parameters. The EASA parameters are time and structure: at least two years of data for the baseline and for the monitoring database, a two-year storage period for recorded fuel data and four monitoring elements. The EU ETS parameters are a 10-year data retention period (Source: climate.ec.europa.eu) and a 5% data-gap notification trigger (Source: climate.ec.europa.eu). The Commission states that over 99.5% of aviation emissions are usually covered by surrender of allowances (Source: climate.ec.europa.eu). The sources cited here do not give the number of AOC holders operating an approved individual fuel scheme, so adoption cannot be quantified.

Research results. An uncalibrated model underestimated fleet fuel burn by about 4.81% over nine airframes ^[4], and per-aircraft tuning is reported elsewhere to cut prediction error from about 3% to under 1% ^[4]. Weather-forecast error, route effects and data-quality effects appear in separate studies ^[10] (Source: journals.open.tudelft.nl) ^[9]. Aircraft-specific treatment can matter at the percent scale, but none of the sources cited here defines a sample size at which hull-specific monitoring becomes statistically significant for an EASA scheme; that remains an item to agree with the authority.

One discrepancy deserves flagging. The two-year figure appears in the AMC for three purposes: the SPI baseline, the monitoring database and storage of recorded data. The wording differs ("statistically relevant" for the baseline, "statistically significant" for the database) and no definition separates them. A conservative design treats them as one two-year window but records period and sample counts separately.

Implications and Future Directions

For operators. A lineage audit should precede any decision to seek an individual scheme. It asks whether the five record keys exist in current sources. If they do not, the two-year baseline cannot start with trustworthy data, and a gap or key change inside the window needs a treatment agreed in advance. Operators already using the 3% fuel ERA variation have part of the evidence, because monitoring is required there too.

For authorities and standard setters. The EASA text leaves "statistically significant" and "transparency" undefined, while authority forms already ask for evidence of the monitoring system (Source: caa.gov.lv). The rules text points to the EASA Fuel Implementation Manual and ICAO Doc 9976 for guidance, and a future clarification could specify what an acceptable export looks like.

Artificial intelligence. Machine-learning models appear in the fuel research cited above, but they enlarge the evidence burden: a learned factor needs a model version, training window, input snapshot and validation result stored like a regression coefficient, and it must still respect the per-tail rule. AI-assisted tooling can speed data preparation; it does not substitute for authority approval.

Frequently Asked Questions (FAQs)

What are the EASA fuel monitoring requirements? Planning must use aircraft-specific data from a fuel consumption monitoring system where available; AMC8 CAT.OP.MPA.181 describes the four-part system for individual schemes.

What is an individual fuel scheme under EASA? A scheme derived from a comparative analysis of the operator's own data, with an equivalent or higher level of safety than the basic scheme, and needing prior approval.

What does fuel consumption data lineage mean for an airline? Tracing each planned or achieved fuel figure to its sources, versions and corrections, using vocabulary such as W3C's definition of provenance ^[6].

Is there an EASA fuel efficiency monitoring requirement for operators generally? Every operator must have an approved fuel/energy scheme under CAT.OP.MPA.180, and the guidance material lets it choose between a basic scheme, a basic scheme with variations and an individual scheme. The AMC expects a data-driven fuel consumption monitoring system for an individual scheme. A separate, voluntary fuel efficiency programme is not itself required by these rules.

What is an audit trail for aircraft fuel burn data? The rules do not use that phrase; the nearest wording is "data transparency and verification". In practice it is the correction log, exclusion register and version history.

How do EU ETS fuel monitoring plans relate? They are a separate regime with an approved monitoring plan (Source: climate.ec.europa.eu) and verification (Source: climate.ec.europa.eu); the raw data overlap, but the evidence does not substitute.

How good is fuel data quality in flight operations? Studies report missing and incorrect records in operational ACARS data ^[9], and their treatment changes results.

Is there fuel consumption monitoring software for airlines? Yes; examples include GE Aerospace ^[1], OpenAirlines ^[15] and Jeppesen ^[17]. Lineage features should be confirmed with each vendor.

What does EASA fuel scheme compliance require of software? Testing of flight-planning software after each upgrade; approval rests with the authority, not any product.

Conclusion

EASA's text sets a clear sequence for an individual fuel scheme: prior approval, a baseline, demonstrated operational control, and a data-driven monitoring system with at least two years of statistically significant data, normalisation, and transparency and verification. GM1's per-tail rule turns those requirements into a design constraint: every planned and achieved figure must carry the tail, plan and configuration it belongs to.

The data-lineage test in this report asks whether an operator's systems can meet that constraint with stored, versioned records rather than reconstruction. The record contract, the tail swap example and the acceptance tests are tools for that test; they are not regulatory requirements and do not predict what a given authority will accept. Packaged analytics cover part of the chain, and the vendor pages reviewed do not document the rest. A narrow adapter can join existing systems when keys are missing, but the approval question stays between the operator and its competent authority.

Operators weighing the decision should confirm the current text and national practice with their authority, read the EASA Fuel Implementation Manual, and run their own systems through the acceptance tests before committing to the two-year baseline.