FF-ICE Flight Plan Revisions: An OCC Reconciliation Contract

Executive Summary

For IFR operators flying in the flight information regions (FIRs) and upper information regions (UIRs) of EU Member States, Norway and Switzerland, a filed flight plan is no longer a message that is simply followed by more messages. Under FF-ICE Release 1 (Flight and Flow Information for a Collaborative Environment) the Network Manager (NM) offers a Filing Service for "submission, update and cancellation" of electronic flight plans (eFPLs) (Source: www.eurocontrol.int), each tied to a Globally Unique Flight Identifier (GUFI) (Source: atmmasterplan.eu). The Commission Implementing Regulation (EU) 2021/116 (Common Project 1, CP1) sets 31 December 2025 as the date by which the services are to be provided by NM and consumed by airspace users and ANSPs (Source: sesardeploymentmanager.eu), and EUROCONTROL tells mandated operators to submit FF-ICE plans from 1 January 2026 (Source: www.eurocontrol.int), with third-country operators in scope (Source: www.ais.fi).

The revision evidence an operations control centre (OCC) can rely on has three layers. The GUFI is an immutable flight identifier (Source: fixm.aero). The operator flight plan version must increase by exactly one with every update (Source: atmmasterplan.eu). Feedback is split into a submission response (data validity) and a filing status (operational acceptability) (Source: www.icao.int). A cancellation returns only a submission response (Source: www.icao.int), and a refiled flight needs a new GUFI.

The risk sits in the seams. FPL2012 and eFPL are filed side by side, can receive different outcomes for the same flight, and one provider notes that CHG or DLA messages sent over AFTN leave the FF-ICE version identifier on record unchanged (Source: air-support.aero). In an SDM sample week in February 2026, 15.68 percent of filed plans were eFPLs ^[1], so mixed mode remains the norm in filing practice, and the global FPL2012 sunset date is 2034 ^[1].

The decision this report supports is narrow. If the flight-planning provider's interface exposes the GUFI, the version, both status layers, cancellation responses and a replayable event history to schedule, operational flight plan (OFP) and OCC screens, a custom adapter is not needed. If it does not, a downstream reconciliation ledger is justified, with a version mismatch treated as a review trigger for a named human owner and never as an automated decision to fly. Some operators using a provider may not need their own NM B2B certificate, and the exact interface field names sit in an NM manual that is not public.

Introduction and Background

This report examines one operational question: after an operator's flight-planning provider files, revises or cancels an FF-ICE flight plan with the Network Manager, does the operator's own stack (schedule, OFP archive, OCC screens) hold enough version, status and cancellation evidence to know which plan is current? The scope is IFR general air traffic (GAT) in EU, Norwegian and Swiss FIRs and UIRs, including third-country operators. It is not filing guidance, it does not replace an operator's approved procedures, manuals or operations specifications, and it does not claim that every operator must obtain a direct NM B2B certificate. Other regions follow different timelines: ICAO's Release 1 provisions became applicable on 28 November 2024 on a voluntary basis (Source: www.icao.int), and this analysis does not address US, Canadian or Asia-Pacific procedures.

The terms used throughout are defined here once:

• FF-ICE is the ICAO concept, and eFPL is its flight plan.
• FPL2012 is the ICAO 2012 flight plan message exchanged over AFTN or SITA.
• IFPS is the Integrated Initial Flight Plan Processing System operated by the Network Manager, and NM B2B is its machine interface.
• OFPV is the operator flight plan version.
• CFSP is a computer flight plan service provider, which is the flight-planning vendor in most operators' language.
• AIC is an Aeronautical Information Circular, and EOBT is the estimated off-block time.

EUROCONTROL describes FF-ICE/R1 as a set of six services, and NM implements all of them except the Planning Service (Source: www.icao.int). IATA's December 2024 whitepaper frames the FF-ICE workflow as the airline sharing flight plan information, including trajectory, with the ATM service provider ^[2]. OPSGROUP's June 2026 explainer says Europe switched on FF-ICE on 1 January 2026 (Source: ops.group). The Commission regulation that anchors the mandate is Implementing Regulation (EU) 2021/116 (CP1). National AIC text then carries the duty to operators, as the Finnish circular shows with "Airspace users shall consume the Filing Service provided by NM" (Source: www.ais.fi).

Limits of the evidence matter for the conclusion. The NM B2B Reference Manual, which holds the exact message element names, sits behind authentication and could not be read for this report. The analysis therefore rests on the IFPS User Manual (Edition 2.3, listed by EUROCONTROL as the current description of NM's FF-ICE implementation), on EUROCONTROL's mixed-mode transition publication (Edition 1.0, validity date 2 July 2024), on ICAO workshop material, and on the SESAR Deployment Manager (SDM) roadmap. Where these sources disagree or are silent, the text says so. LANDING.AERO, a Montreal studio that builds custom flight-operations software, publishes this analysis. Its role is relevant only if an operator has a proven gap after assessing its filing vendor, as discussed in the implementation section.

Key Changes in Flight Plan Revision Handling

Change 1: A Flight Becomes a Keyed, Versioned Record

FPL2012 associates messages by key fields, whereas FF-ICE associates them by GUFI. The GUFI is defined in FIXM (the Flight Information Exchange Model) as an immutable identifier that lets eligible ATM community members refer to a flight unambiguously (Source: fixm.aero). The FIXM requirements document adds that a GUFI is assigned to only one flight within a ten-year period (Source: fixm.aero) and that GUFI content must never be used in business rules (Source: fixm.aero). For an OCC this has a direct design consequence: the GUFI is a join key, not an attribute to parse.

The operator, or its designated representative, generates the GUFI ^[3]. EUROCONTROL's workshop slide describes it as a version 4 UUID plus a creation timestamp plus a namespace (Source: www.icao.int). The same GUFI must accompany every update or cancellation. Because NM treats the GUFI as mandatory in the submitted eFPL (Source: atmmasterplan.eu) and cross-checks it against the aircraft identification and aerodromes on later messages, a schedule system that regenerates or loses the key will lose the thread of the flight.

The ICAO provisions point the same way. ICAO workshop slides quoting Doc 4444 show that the originator "shall assign a single GUFI" to the flight (Source: www.icao.int). Those slides elide parts of the clause text, so the wording should be checked against the current Doc 4444 before it is quoted normatively.

Change 2: Feedback Splits into Submission Response and Filing Status

The Filing Service gives feedback on "whether the flight plan was successfully processed, and whether it is acceptable" (Source: dev.eur-registry.swim.aero). In IFPS terms these are two layers. The submission response (ACK, MAN or REJ) concerns data validity, while the filing status (ACCEPTABLE or NOT_ACCEPTABLE) concerns operational acceptability (Source: www.icao.int). FIXM defines the filing status as the status of the filed flight plan with respect to the eASP, the ATM service provider (Source: fixm.aero).

The IFPS User Manual lists the permitted combinations. A successful outcome is ACK plus ACCEPTABLE with the agreed trajectory (Source: www.eurocontrol.int), and a manual-handling outcome (MAN) is always followed by an ACK or a REJ. This matters for display logic: MAN is a transient state, and an OCC screen that treats it as final will show a false result. ICAO guidance material additionally lists PENDING (no evaluation performed, no operator action needed) as a filing status, but the EUROCONTROL slides list only ACCEPTABLE and NOT_ACCEPTABLE. A reconciliation layer should therefore store unknown status values rather than reject them.

Change 3: Version Numbers Become a Gatekeeping Rule

The operator provides a unique incrementing version for each FF-ICE plan and every update, and INF10.18, the ATM Master Plan objective for the Filing Service, requires that version in the submitted eFPL (Source: atmmasterplan.eu). The IFPS User Manual states that each update carries a version number that increments by 1 the previous one (Source: www.eurocontrol.int). Failure invalidates the submission, with the error text "AIRCRAFT OPERATOR FLIGHT PLAN VERSION NOT INCREMENTING BY 1" (Source: www.eurocontrol.int). When an eFPL or update arrives for a flight whose held data is already an eFPL, the manual's mixed-mode table updates the data only if the version is strictly higher and otherwise rejects automatically (Source: www.eurocontrol.int). The version thereby prevents plans being processed in the wrong order.

Two nuances should be kept. First, the starting value is not fully settled across sources. The SDM information exchange requirements say an initial eFPL submission carries version 1 ^[3], while a EUROCONTROL scenario deck cautions that "the first Filed Flight Plan may not be version" 1 (Source: www.icao.int), because earlier versions can exist through the Planning Service or a preliminary flight plan. NM does not implement the Planning Service, so version 1 is the expected start in Europe, but a ledger should not hard-code it. Second, FIXM's own documentation says the identifier should begin at one and increase by one with each revision (Source: fixm.aero), which matches the rule NM enforces.

A recipient's duty is stated in PANS-ATM as quoted by EUROCONTROL: the originator must include version information so that a recipient can verify that the version is more recent than previously received (Source: www.eurocontrol.int). This supports version checks for operator plan revisions. It does not make OFPV a unique event identifier: legacy changes can leave it unchanged ^[4].

Change 4: Update and Cancellation Carry Their Own Evidence

An update is a complete flight plan, not a delta. NM distributes "the full (updated)" eFPL after an accepted update, so the update overwrites the previous version. A legacy FPL record lacking a GUFI must be distinguished from a supported conversion to FF-ICE. The IFPS User Manual’s Appendix G.2 documents both eFPL and eFPL Update inputs against held FPL data: the record is updated with eFPL data, including GUFI, and becomes FF-ICE ^[5]. The mixed-mode publication also illustrates an FPU converting a held FPL record to eFPL ^[4]. The roadmap’s GUFI prerequisite should therefore not be read as an absolute prohibition on conversion. Confirm the current manual and provider interface requirements before specifying the operational process.

A cancellation is different. ICAO guidance states that a Flight Cancellation receives only a submission response, which is an ACK or REJ without a filing status. The registry entry for the NM Filing Service lists the cancellation operation by name (Source: dev.eur-registry.swim.aero). After cancellation the GUFI is spent: ICAO guidance says it cannot be reused or reinstated, and a cancelled flight that is refiled needs a new GUFI (Source: www.icao.int). In ledger terms, "cancelled" is terminal for a GUFI, and a later eFPL for the same city pair is a different flight record that must be linked by schedule data, not by identifier.

Change 5: Trial, Re-evaluation and Publication Add Asynchronous Events

Three further mechanisms create state changes that arrive without any action by the OCC. The Trial Service is a what-if request that does not create or change a flight plan (Source: atmmasterplan.eu). Its result is a planning status of CONCUR, NEGOTIATE or NON-CONCUR, and it has no influence on IFPS data for the flight. A trial response must therefore never be shown as a filed state. FIXM defines the planning status as the status of the preliminary flight plan with respect to the eASP (Source: fixm.aero). INF10.19 requires the filing status value to be provided in the flight data response (Source: atmmasterplan.eu). EUROCONTROL recommends using Trial before any eFPL or update.

Re-evaluation is the second mechanism. NM re-evaluates filed eFPLs every 30 minutes from 12 hours before the estimated off-block time (EOBT) until EOBT (Source: www.icao.int), and the process applies only to already processed eFPLs. A plan that was ACCEPTABLE can turn NOT_ACCEPTABLE without any operator submission, as a EUROCONTROL scenario shows (Source: www.icao.int). NM feedback does not include flow impact, so the filing status is not a slot or regulation indicator.

Publication is the third. The Data Publication Service provides flight plans, updates and cancellations to subscribers (Source: dev.eur-registry.swim.aero), and INF10.21 specifies distribution of accepted eFPLs together with the outcome of later re-evaluations (Source: atmmasterplan.eu). The Flight Data Request Service returns the filing status of a previously submitted plan, or the submission status after manual intervention (Source: dev.eur-registry.swim.aero), but is meant for single flights rather than as a general feed. EUROCONTROL recommends publish/subscribe for re-evaluation updates. Per-flight status requests can also retrieve changed filing status ^[5]; Irish AIC 011/2026 explicitly permits Data Publication or Flight Data Request for updates ^[6]. For this design, prefer publish/subscribe for timely event capture and use per-flight requests for current-state checks and recovery. Polling can detect changes late or miss intermediate transitions between requests; it does not inherently miss the latest status.

Change 6: Mixed Mode Keeps FPL2012 in the Loop

FPL2012 via AFTN or SITA and eFPL via NM B2B coexist (Source: www.eurocontrol.int). NM translates accepted FF-ICE data for ANSPs that are not yet FF-ICE enabled, and the mixed-mode publication calls translation a transitory capability. ICAO's draft principles for the end of FPL2012 would require FF-ICE content to allow translation to ATS messages (Source: www.icao.int) and would decommission the FPL2012 format after 2034. This is draft guidance, not adopted text, according to the ICAO slide set.

Applicability and Access: Who Must Do What

Legal Basis and What It Binds

The legal anchor is Implementing Regulation (EU) 2021/116 (CP1), and the operator-facing filing duty is stated in EUROCONTROL, SDM and national texts. SDM reads CP1 as covering all airspace users operating IFR/GAT or mixed VFR/IFR flights ^[1], and describes the services as provided by NM and consumed by airspace users or their designated representatives (Source: sesardeploymentmanager.eu). The ATM Master Plan objective says the Filing Service shall be consumed by the impacted airspace users (Source: atmmasterplan.eu). VFR, OAT, iOAT and mixed OAT/GAT operations are exempted ^[3].

Two dates appear in sources and should be quoted separately. The Regulation's implementation target is 31 December 2025, the Spanish AIC text uses the same applicability date ^[7], while EUROCONTROL's question-and-answer page cites 1 January 2026 as the start of filing, and the ICAO EUR/NAT material repeats it (Source: www.icao.int). The EASA Notice of Proposed Amendment 2025-09 would add FF-ICE duties to the EU rules of the air and operator requirements, and its explanatory note lists "operations control centres (OCCs)" among airspace users (Source: www.easa.europa.eu). It is a proposal, and its adoption status was not verified for this report. EASA also notes that operators may need to migrate progressively to NM B2B (Source: www.easa.europa.eu).

Full Versus Light eFPL

Civil GAT under IFR is required to include flight-specific performance data in a "full" eFPL (Source: eurocontrol.int). A "light" eFPL applies to mixed IFR/VFR civil traffic and to state air traffic under IFR, where performance data, take-off mass, expanded route and 4D trajectory are optional, according to the same EUROCONTROL page. An OCC that holds both business-aviation and airline flights should record which eFPL type each flight used, because the missing-value behavior of a field differs by type. Performance data is also thin in practice: a single-day check on 19 February 2026 found that only 4.55 percent of filed eFPLs contained a performance profile ^[1].

Direct B2B Access Versus a Provider

Most users connect to NM B2B directly and need an NM B2B certificate, but some operators using a flight plan service provider may not (Source: www.eurocontrol.int). The distinction is contractual and should be clarified with the provider. The SDM roadmap states that the requirements apply indirectly to ATS reporting offices and CFSPs filing on operators' behalf ^[1]. An operating certificate is not the end of the work: SDM states that holding one does not mean implementation is complete ^[1].

For direct users the process is documented. The SDM roadmap puts the whole path to an operational (OPS) certificate at around three months ^[1], and the nominal READ-validation test period is 10 days; NM and the customer may agree to reduce it when usage is sufficient and all interactions have been thoroughly tested ^[1]. About 130 airlines were linked through a declaration of use to CFSPs holding an operational certificate as of the roadmap's February 2026 snapshot ^[1], which illustrates that the provider route is common.

Third-Country Operators, Norway and Switzerland

EUROCONTROL states that the scope includes third-country operators, and the Finnish AIC text applies to non-EU based airspace users (Source: www.ais.fi). Norway is bound as a European Economic Area state: the Government's EEA note records the incorporation of CP1 through EEA Joint Committee Decision 222/2022 (Source: www.regjeringen.no), and the Norwegian civil aviation authority published AIC I 02/2025 (Source: partner.avinor.no). The legal instrument for Switzerland could not be confirmed from the sources reached, and the AIC status of each State changes over time, so an OCC should check the current AIP of each State it files into. The Irish circular, for instance, has operators receive an immediate submission response and filing status (Source: www.airnav.ie), and describes use of the Data Publication or Flight Data Request Service so that later updates can be received (Source: www.airnav.ie).

EUROCONTROL also notes that the area in which IFPS operates is larger than the mandated area, and that NM continues to accept FPL2012 for the foreseeable future. Acceptance by NM is a technical statement, though: EUROCONTROL states that continued submission of FPL2012 messages by mandated operators does not comply with the CP1 mandate (Source: www.eurocontrol.int). Air-filed flight plans are the exception, since they are filed as FPL2012.

Source-of-Truth Map and State Matrix

Table 1 below is the proposed field-level contract between the planning provider, NM filing status, the schedule and OFP systems, and OCC screens. It is a design reference built from the documentation cited above, and the "missing-value behavior" column states what the reviewed sources define or leave undefined. Exact element names live in the NM B2B Reference Manual, which was not accessible, and the IFPS manual itself says it is not a technical implementation document.

Table 1 shows that only three fields have an external authority (GUFI, filing status, submission response), one has a shared rule (version), and two are the operator's own (schedule identifier, receipt time). The practical conclusion is that the operator side owns the join between schedule record and GUFI, so any provider interface that does not expose the GUFI to the schedule system leaves the operator unable to prove which plan belongs to which flight.

Table 2 below is an illustrative state transition table. It is based on the documented message outcomes and shows which events a ledger should expect, including duplicate and out-of-order arrivals. It is not a specification of any provider's interface.

The proposed ledger needs separate handling for confirmed duplicate events, re-evaluation/status changes and changes made outside FF-ICE. Legacy CHG/DLA can change content without an OFPV increment ^[4]. Retain event identity, raw evidence and available ordering information; where source order is uncertain, reconcile current state through the provider before overwriting the OCC display.

Illustrative Version Ledger and Comparison (Hypothetical Example)

The ledger below is invented for illustration. Identifiers such as EX-GUFI-0001 are placeholders and are not real GUFIs, which are UUID-based. The sequence column is a local receipt order, not a time or authoritative event order. In row 6, assume the raw event identity and source ordering evidence confirm a replay of an earlier publication; its lower OFPV alone does not establish that verdict.

gufi=EX-GUFI-0001  sched=EX-SCHED-7781  adep/ades=EXAA/EXBB
seq event                       ofpv resp  fs              ledger_last  delta  verdict
1   trial                       -    ACK   (CONCUR)        -            -      trial only
2   submit                      1    ACK   ACCEPTABLE      -            -      filed v1
3   update                      2    ACK   ACCEPTABLE      1            +1     next
4   publication re-evaluation   2    -     NOT_ACCEPTABLE  2            0      flag, same version
5   update                      3    ACK   ACCEPTABLE      2            +1     next
6   publication replay          2    -     ACCEPTABLE      3            -1     quarantine
7   OFP archive shows           5    -     -               3            +2     review (check NM state)
8   cancel                      -    ACK   (none)          3            -      terminal, new GUFI to refile

The proposed ledger must distinguish operator revisions, re-evaluation/status events and legacy content changes. The +1 rule applies to eFPL updates submitted to NM ^[5]; it is not a gate for every downstream event. Re-evaluation can change acceptability, and legacy CHG/DLA can change held content without incrementing OFPV ^[4]. Process legitimate same-version changes and retain their evidence. Deduplicate using event identity and available source ordering evidence, not OFPV alone; local receipt order does not establish source order. If ordering is unresolved, retrieve current NM-held state through the provider and flag the uncertainty for the named owner. In row 7, archive value 5 versus last-observed 3 indicates a possible observation or reconciliation gap, not proven archive/NM divergence: accepted versions may have been missed by this ledger. First confirm the archive field is OFPV, check current NM-held version/status and recover available history ^[3]. These checks do not authorize flying or re-filing.

Implementation Considerations and Process Changes

Mixed-Mode Mapping and Unresolved Conflicts

FF-ICE feedback differs from FPL2012 feedback: FF-ICE gets a submission response and filing status, while FPL2012 gets operational reply messages. The same flight can therefore generate an ACK and a REJ, and OPSGROUP's June 2026 explainer reports that some operators received both ACK and REJ messages (Source: ops.group). The ledger should store the format of each response and never collapse them to one boolean.

The conflicts that remain open in the reviewed sources are these:

• Which record is authoritative. NM holds one flight plan data record per flight, typed as eFPL, FPL or FPL(FIXM), and updates it on each accepted submission (Source: www.eurocontrol.int). Converted FPL2012 plans "cannot therefore be referred to as eFPLs" because they lack data such as the GUFI (Source: www.eurocontrol.int).
• FPL after eFPL. The 2024 publication says an FPL2012 message received after the FF-ICE submission is rejected (Source: www.eurocontrol.int), and ICAO-hosted EUROCONTROL scenarios show a duplicate FPL answered with a rejection naming the existing plan (Source: www.icao.int). Whether CHG and DLA messages remain acceptable after an eFPL is governed by the IFPS User Manual table, which is the likely current authority, and the 2024 edition of the publication may be superseded.
• Version after legacy changes. A legacy change accepted outside FF-ICE can leave the NM-held version out of step with the operator's. One provider states that sending CHG or DLA over AFTN leaves the FF-ICE version identifier on record at EUROCONTROL not updated (Source: air-support.aero). External tools that still send legacy delay and cancellation messages are named as a dependency in a workshop deck from a flight-planning vendor and an airline group (Source: www.icao.int).
• Field 18 conversion. The main mapping problem arises in FPL2012 Field 18 where it contains multiple data items (Source: www.eurocontrol.int).

Procurement Questions for the Flight-Planning Vendor

Public documentation does not show what any given provider interface exposes. SDM's project on closing gaps for airspace users targeted "feedback provision (validation and filing status) to eFPL originators" (Source: www.sesardeploymentmanager.eu), which indicates that this was recognised as a gap area, but it does not say which products closed it. The questions below turn the matrix into contract language:

• Identifiers. Is the GUFI returned to the operator and stored against the schedule record, or generated and held only inside the provider?
• Versions. Is the OFPV visible to the operator on every submission and every publication received, and how does the provider handle the requirement that versions increment by 1?
• Two-layer status. Are the submission response and filing status delivered separately, with unknown values preserved?
• Cancellation. Is the cancellation response (ACK or REJ, no filing status) visible, and is "cancelled" distinguished from "not yet filed"?
• Asynchronous events. Are re-evaluation outcomes from publication subscriptions pushed to the operator, given they are not caused by operator action?
• Legacy messages. Which internal tools can still send CHG, DLA or CNL, and does the provider block or warn?
• Replay. Can raw messages with receipt time be exported for audit, and for how long are they retained?
• Access model. Does the operator need its own NM B2B certificate, or is the provider the filing party under a declaration of use?
• Training and manuals. Which procedures change? One provider lists dispatcher training and manual updates among the operational changes (Source: air-support.aero).

OPSGROUP expects flight planning systems to start asking for more detailed information over time (Source: ops.group), and describes providers as doing most of the work for most operators (Source: ops.group). That is a reasonable expectation for the filing function, but it does not establish that providers present revision evidence to the operator's own systems.

Conditions for a Custom Downstream Bridge

Table 3 below compares three responses to a gap, in the order an operator would normally try them. It is a decision aid, and the third row is a category of work rather than a recommendation to commission it.

A bridge is justified only when the assessment in the procurement section shows a gap that the vendor cannot or will not close. It consumes what the provider already receives (for example publication messages through the provider) and does not replace the filing party. If it files or cancels on the operator's behalf, it becomes a filer subject to the access rules above. Safety-critical decisions remain with dispatch and the pilot in command under the operator's approved procedures.

Data Analysis and Evidence

The available numbers describe the regulatory timeline, the access process and the pace of adoption. They do not measure revision quality, because no public source reviewed here reports rates of rejected updates, skipped versions or status flips. Claims about how often revision problems occur are therefore avoided, and the figures below are limited to what the originators publish.

Key dates and thresholds as of October 2026:

• 31 December 2025: the implementation target date in Regulation (EU) 2021/116 for the NM-provided and operator-consumed services, as SDM describes it.
• 1 January 2026: the date from which EUROCONTROL tells mandated operators to submit FF-ICE flight plans, and which ICAO regional material repeats.
• 28 November 2024: applicability of ICAO's Release 1 provisions, on a voluntary basis.
• 2034: the global sunset date for FPL2012 agreed at the ICAO Air Navigation Conference 14 ^[1].
• Version 1: the value of an initial eFPL submission in the SDM information exchange requirements, with a caution elsewhere that a first filed plan may not be version 1.
• Ten years: the period within which a GUFI may be assigned to only one flight.

Adoption data come from SDM. In the sample week of 2 to 8 February 2026, 15.68 percent of filed plans were eFPLs ^[1]. It is a single week of data. About 130 airlines were linked through a declaration of use to CFSPs holding an operational certificate, which suggests that the provider route carries many filers, although SDM does not publish how many flights use it. In process terms, the SDM roadmap estimates around three months to an OPS certificate. The nominal READ-validation test period is 10 days, with an agreed reduction possible between NM and the customer when usage is sufficient and all interactions have been thoroughly tested ^[1].

On the quality of filed content, only 4.55 percent of eFPLs checked on 19 February 2026 carried a performance profile. For the OCC the implication is that optional or missing fields are common, which supports the missing-value column in Table 1.

Version subtraction is one diagnostic in the proposed ledger, not the verdict for every event. The design also needs event identity, source ordering evidence where available, raw history, and separate plan-content and acceptability state. An unchanged OFPV can accompany a legacy content change ^[4]; a stored version integer alone cannot represent that change. Unresolved ordering or observation gaps should trigger reconciliation through the provider.

Implications and Future Directions

Three implications follow for operators:

• Audit objects. The version and GUFI become audit objects. A regulator or internal auditor asking which plan was current when a flight departed will be answered by the operator's own ledger, not by NM's, unless the provider can export the history.
• The legacy path. The OCC's weakest point is not the filing path but the tools that send delay or cancellation messages outside FF-ICE, noted earlier as an open dependency, together with the lessons-learned observation that many operators file eFPLs but keep sending FPL messages.
• Downstream visibility. As ANSPs implement the services, more recipients will see the full updated eFPL, so inconsistencies become more visible downstream.

Standards continue to move. ICAO's draft cessation principles, as presented in February 2026, would retire the FPL, CHG, CNL and DLA equivalents after 2034, and they are not adopted text. NM's FF-ICE services use FIXM payloads, and the registry describes the Publication Service as distributing accepted flight plans in FIXM. Operators should expect schema changes during the long transition and keep the ledger tolerant of unknown values. A tolerant ledger stores the raw message alongside the parsed fields, so that a later change in how a status or version is defined can be replayed against history without losing evidence.

Finally, the EASA proposal would write FF-ICE into the EU rulebook, and national AIPs continue to update. None of this changes an operator's regulatory obligations through software alone, and any procedure change belongs in the operator's own manuals under its competent authority's oversight.

Frequently Asked Questions (FAQs)

What is an FF-ICE flight plan update? A Flight Plan Update is the FF-ICE message that revises a filed eFPL. The Filing Service supports submission, update and cancellation, and each update carries the same GUFI and a version one higher than the previous plan.

How does FF-ICE differ from the ICAO FPL 2012? FF-ICE associates messages by GUFI where FPL2012 uses key fields, adds a mandatory version, and returns a submission response and filing status in place of FPL2012 operational reply messages ^[3].

What is the status of FF-ICE implementation in Europe? The Regulation's target date was 31 December 2025, EUROCONTROL cites 1 January 2026 as the start of filing, and mixed mode with FPL2012 continues.

Does an airline need its own NM B2B connection? Not necessarily. Most users connect directly and need a certificate, but some operators using a provider may not. The arrangement should be clarified with the provider.

What does a filing service do for an airline? It submits, updates and cancels eFPLs and returns feedback on processing and acceptability. The provider is typically the party operating this interface, as OPSGROUP describes it.

What is the flight data object (FDO)? The reviewed sources do not use that term for FF-ICE. NM's own record is the flight plan data held on record per flight, and the flight data request returns the accepted eFPL or its latest status.

How does an OCC reconcile flight plan changes? In the proposed GUFI-keyed ledger, distinguish operator revisions from re-evaluation/status events and legacy content changes. Process legitimate same-version events; legacy changes can leave OFPV unchanged ^[4]. Retain raw evidence, deduplicate by event identity and resolve ordering with available source evidence. If ordering or a version gap is unresolved, ask the provider for current NM-held state and available history, with review by the named owner. OFPV alone must not decide whether an event is a duplicate.

Conclusion

FF-ICE flight plan revisions in the European mandated airspace carry more evidence than FPL2012 changes did: an immutable GUFI, a version that must rise by exactly one, a two-layer response, an asynchronous re-evaluation stream and a defined cancellation. Whether that evidence reaches an operator's schedule, OFP archive and OCC screens depends on the planning provider's interface, and the public documentation reviewed here does not settle it for any provider.

Read together, the sources suggest a layered picture rather than a single source of truth. NM holds the plan record and the acceptance outcome, the operator controls the identifier and the version it sends, and the provider sits between the two. Responsibility for noticing divergence therefore falls on whoever holds the ledger, which is why the choice between relying on the provider and adding a downstream adapter is a question about evidence, not about filing. The practical test is the matrix in Table 1. If the provider exposes each field to the operator with replayable history, no custom adapter is needed. If it does not, the proposed downstream ledger should distinguish operator revisions, re-evaluation/status events and legacy content changes, process legitimate same-version events, and retain evidence. Legacy CHG/DLA can leave OFPV unchanged ^[4]. Deduplication should use event identity and available source ordering evidence. Unresolved ordering or version gaps require current-state reconciliation through the provider and review by a named owner. Facts that remain to be verified before an operator commits to a design are:

• Element names. The exact NM B2B message element names, held in the Reference Manual.
• Manual edition. The current IFPS User Manual edition as of the date of use.
• National text. Each State's current AIP or AIC text for the airspace flown.
• EASA proposal. The adoption status of the EASA proposal.
• Provider interface. What the chosen provider actually exposes to schedule, OFP and OCC systems.