Part 121 Load Manifest Handoff: Data to Reconcile Pre-Loadsheet

Executive Summary

For a US Part 121 operator, the load manifest is a certificate-holder obligation, not a product feature. Under 14 CFR 121.665 the certificate holder is responsible for the preparation and accuracy of the load manifest form before each takeoff ^[1], and that form must be prepared and signed by employees who supervise loading or by other qualified persons the operator authorizes ^[1]. FAA Advisory Circular (AC) 120-27F, dated 6 May 2019 and listed by the FAA as "Active" at the time of this research, adds guidance on approved weight and balance control programs ^{[2] [3]}. It also says an onboard weight and balance system does not relieve the operator of completing and maintaining a load manifest ^[2].

The practical question is whether a late change to passengers, bags, cargo, aircraft configuration or fuel reliably reaches the final loadsheet and the crew's receipt of it. The regulation text does not define a late-change procedure; 121.693 lists contents such as the weight of the aircraft, fuel and oil, cargo and baggage, passengers and crewmembers ^[4], and the pilot in command carries a copy of the completed manifest in domestic and flag operations ^[4]. Late-change handling therefore lives in the operator's approved procedures. The FAA's one on-point statement is that an operator may prepare a separate, amended manifest if the flightcrew might unknowingly exceed a limit ^[2].

Jeppesen states that its eLoadsheet can be fully integrated with its flight planning solutions and third-party systems ^[5]; Evionica states integration with flight planning, scheduling, departure control and electronic flight bag (EFB) systems ^[6]; and Lufthansa Systems states that NetLine/Load connects to any passenger or flight planning system ^[7]. These are vendor claims. Bytron describes stored loadsheet status, timestamps, electronic signatures and revision history ^[8]. Test precise version binding, timestamp semantics, export format and operator-specific behavior, alongside duplicate, missing and out-of-order changes.

This report proposes an interface acceptance matrix rather than a new calculator. Three findings stand out. First, the 2021 revision cycle for OpSpecs A096 to A099 moved operators to survey-based or actual weights, so data provenance matters more than before ^{[9] [10]}. Second, mixed units remain a documented risk area: AC 120-27F says weight should be a consistent measure in pounds or kilograms, with a conversion method if both are used ^[2]. Third, a narrow data bridge is justified only where a test shows a gap the packaged product's documented interfaces do not close. Operators should confirm every conclusion against current 14 CFR text, their approved weight and balance program and their FAA oversight office. This report is not operational guidance and does not replace approved procedures.

Introduction and Background

Most airline discussion of weight and balance centers on calculation: standard weights, loading envelopes and center-of-gravity limits. This report addresses the step after calculation, the handoff. A final loadsheet is a snapshot of data owned by several systems that change until the doors close. Passenger counts originate in the departure control system (DCS), baggage and cargo counts originate with ramp and cargo systems, aircraft configuration originates in a fleet master record, and fuel originates with fueling and the flight crew. The question is whether the approved load-manifest process sees each late change once, in the right unit, in the right version, and whether the crew's acceptance of the result is recorded.

The scope is US 14 CFR Part 121 only; Part 135 and other jurisdictions appear as contrast, not generalization. The report explains system evidence and human responsibilities. It does not explain how to compute a certified weight and balance.

Regulatory text is quoted from the Electronic Code of Federal Regulations (eCFR), which describes itself as authoritative but unofficial, with its Title 14 display current as of 15 October 2026 ^[4]. Vendor statements are attributed as vendor claims and were read on public pages in October 2026; those pages are undated. No FAA approval claim is made for any product.

The audience is US Part 121 load-control managers, dispatch and operations control center (OCC) leads, and information technology (IT) integration owners. The publisher, LANDING.AERO, is a Montreal studio that builds custom flight operations software to order, including bridges between existing systems. It does not sell an off-the-shelf load-control platform and is not a certified weight and balance product; where this report discusses a narrow adapter, it is describing a category of integration work, not recommending a purchase.

Key Changes in the Guidance Stack

The guidance that shapes a Part 121 weight and balance program changed in several steps between 2019 and 2024. Each step affects what an integration has to carry.

AC 120-27F and the OpSpec re-issuance

AC 120-27F, titled "Aircraft Weight and Balance Control" on the FAA's information page, is guidance rather than a separate basis for enforcement ^[2]. FAA Notice N 8900.551 states that the FAA will no longer publish average passenger or baggage weights, which moves the burden of data provenance to each operator. The same notice covers the revised OpSpec templates A096 to A099 and requires entries in a table that records the loading schedule and instructions for routine operations ^[9]. NBAA reported on 4 June 2021 that the 12 June deadline was nearing for operators to apply for the revised OpSpecs ^[10], and that a survey became the only means of determining average weights for all baggage ^[10]. NBAA's quoted consultant described the approach as performance-based rather than a prescribed method of compliance ^[10].

For integration owners the consequence is concrete: under AC 120-27F an operator using an onboard weight and balance system receives OpSpec A096, which documents the use of actual weights ^[2]. Whether a late bag count arrives as an actual or an assumed value is a program question first and a software question second. The FAA also directs its principal operations inspectors to record the weight and balance program under a Safety Assurance System data collection tool titled Flight/Load Manifest/Weight and Balance Procedures, which tells operators where oversight attention is likely to sit.

EFB guidance: AC 120-76E

The current EFB authorization circular is AC 120-76E. For operators that deliver loadsheets to tablets, three provisions matter. The AC states that applications are no longer identified or controlled in the OpSpecs ^[11], so EFB authorization sits within the operator's EFB program. It states that the operator should have a procedure allowing crewmembers to confirm revision numbers or dates ^[11], and that where data is under a revision cycle the loaded revision should be readily evident to the user ^[11].

Electronic records: AC 120-78B

The current electronic records circular is AC 120-78B. It says an electronic record should provide equivalent or better data integrity than paper ^[12] and that electronic signatures, recordkeeping and manuals require OpSpec A025 authorization ^[12]. AC 120-78B sections 2.3.2.2 and 3.3.2.2 address prevention of unauthorized modifications and changes requiring a new signature or authentication; section 3.2.2 describes preservation with appropriate certification, verification or authentication ^[12]. Controlled corrections must therefore be distinguished from unauthorized alteration when designing the audit-trail test; the AC is guidance, not a blanket prohibition on every correction.

The Part 121 Regulatory and Approved-Program Boundary

Four sections frame the boundary. Section 121.665 places the responsibility on the certificate holder and sets the signing rule. Section 121.693 sets contents: weights, a maximum allowable weight for the flight that must not exceed the least of several listed limits ^[4], a total weight computed under approved procedures, and evidence that the aircraft is loaded according to an approved schedule ^[4]. Section 121.695 requires the pilot in command of a domestic or flag flight to carry a copy of the completed load manifest or information from it, except cargo and passenger distribution information, and requires the certificate holder to keep copies for at least three months ^[4]. For supplemental operations, 121.697 allows copies to be held at an outstation for not more than 30 days before they go to the principal base ^[4].

Two boundaries follow. First, the regulation text does not describe late changes, versions or acknowledgment. The manual requirement in 121.135 asks for methods and procedures for maintaining the aircraft weight and center of gravity within approved limits ^[13], so the late-change method belongs to the operator's manual and its approved weight and balance program. Second, an FAA Chief Counsel legal interpretation from November 2010 said the general operations manual must contain procedures for completing the load manifest, including who may prepare and sign the form before takeoff ^[14]. The same interpretation addresses alterations to the original manifest after takeoff and, as worded, does not permit them ^[14]. It predates the 2019 AC and the 2021 OpSpec revision, so it is a historical anchor and should be read with current text.

The dispatch release is a different document: 121.687 lets it be in any form but lists required content ^[4]. A fuel figure on the release is therefore not the same field as the fuel weight on the manifest, a distinction that matters in the data map below.

What AC 120-27F recommends

The AC recommends that each operator develop a reporting system and encourage employees to report any discrepancies in aircraft loading or manifest preparation ^[2]. Corrective action may include a load audit on affected flights. It says nothing about a named form, a database or a late-change message format, which leaves the design to the operator.

Jurisdiction separation

Part 135 is different. Section 135.63 makes the certificate holder responsible for a manifest in duplicate for multiengine aircraft and sets a 30-day retention period at the principal operations base ^[15], against three months in Part 121.

Other authorities use different mechanics, and none of the following applies to a US Part 121 operator. The European Union Aviation Safety Agency (EASA) rule CAT.POL.MAB.105 requires mass and balance documentation that enables the commander to determine that the load and its distribution are within limits (Source: www.easa.europa.eu), lists load components including passengers, baggage, freight and ballast (Source: www.easa.europa.eu), and has the commander indicate acceptance by hand signature or equivalent (Source: www.easa.europa.eu). Its last-minute-change provision requires that a change after completion of the documentation be brought to the attention of the commander (Source: www.easa.europa.eu) and sets a maximum, beyond which new documentation is prepared (Source: www.easa.europa.eu). EASA's acceptance material also describes PIN-based signatures that log when and where each code was entered (Source: www.easa.europa.eu). Those texts are from EASA's Easy Access Rules, published 27 March 2026, and some provisions apply from 2028. The UK Civil Aviation Authority's guidance leaflet CAP 1008 says a change reported after completion must be brought to the attention of the captain and clearly entered on the documentation ^[16]. Transport Canada's Commercial Air Service Standards describe a weight and balance system covering preparation and disposition of documentation by the operator or other qualified personnel it authorizes ^[17], and CAR 705.39 requires airline operators to keep weight and balance forms, including amendments, for not less than 90 days ^[18]. ICAO Annex 6 Part I sets international standards for commercial air transport aeroplanes (Source: store.icao.int), but its load sheet provisions are not publicly quoted here.

Data Ownership Map: From Source Systems to the Final Manifest

A final loadsheet is assembled from fields with different owners, clocks and units. Table 1 below sets out a field-level source-of-record matrix. The "typical system of record" column is an analytical framing of common architectures, not a statement about any one operator; the right-hand column anchors each row to a cited source where one exists. SKYbrary, a safety knowledge base, notes that most multi-crew load sheets are produced by contracted handling agents who input flight-specific data into a proprietary DCS (Source: skybrary.aero), so some rows cross a company boundary.

Table 1 shows that three rows (passenger counts, aircraft configuration, final loadsheet) have an obvious identifier problem: the same flight can be re-sent with a different tail, a different version or a different time. The weight-basis row is easy to overlook because it is a program attribute, not a load attribute, yet N 8900.551 requires the loading schedule and instructions to be entered in the OpSpec tables. The fuel row carries the unit risk; the same AC says weight should be a consistent measure in either pounds or kilograms, with a conversion method in procedures if both are used.

Where the packaged product ends

A packaged calculation product normally owns the calculation and the output documents. It rarely owns the upstream events. Jeppesen describes Powerloader and eLoadsheet as two components sharing an aircraft master database and user management functions ^[5]. Damarel describes LodeStone as handling flights from an airline's own DCS ^[20] and accepting manual entry of freight, fuel, transit passengers, baggage and deadload figures ^[20]. Manual entry adds a human re-keying point; Damarel itself lists removal of manual re-keying as a benefit ^[20]. The operator needs to know, per field, whether a value arrives by interface or by keyboard.

Change Events, Late Correction and Acknowledgment

Handoff problems are best described as states, because each state needs different evidence. The list below is a design vocabulary for acceptance testing, not an FAA-defined model.

• Preliminary. A loadsheet produced before boarding closes. One vendor describes querying the DCS for passengers ^[21], then updating DCS figures and computing a preliminary loadsheet after final fuel is reported on an EFB ^[21]. This is a vendor workflow description from an earlier trial, not a statement of current product scope.
• Final issued. The version the operator treats as the manifest of record. In the Wizz Air example, Evionica describes an accredited-person check before the final loadsheet reaches the pilot in command; its workflow follows Wizz Air's Ground Handling Manual and may differ from other airlines' practices ^[21].
• Accepted. The crew's receipt. SKYbrary describes acceptance as the commander's signature on at least two copies (Source: skybrary.aero). Under Part 121 the operator's manuals define the actual procedure, and electronic signature use requires OpSpec A025 authorization.
• Late change pending. A change arrives after final issue. SKYbrary describes a late-change process that lets alterations be entered on a final loadsheet (Source: skybrary.aero), with a maximum allowable change in passengers or hold load set by the operator (Source: skybrary.aero), and notes that fuel changes should trigger a full recalculation (Source: skybrary.aero). These are industry practice descriptions, not US requirements, and the thresholds belong to each operator.
• Amended issued. A new version supersedes the old. A late change must be brought to the attention of the captain and clearly entered on the documentation (Source: skybrary.aero). The FAA's own text permits a separate, amended manifest where the flightcrew might unknowingly exceed a limit.
• Final copy on the ground. EASA's acceptance material says that when documentation is sent to the aircraft by data link, a copy of the final version accepted by the commander should be available on the ground (Source: www.easa.europa.eu). This is EU text, but any operator can test for the property.
• Contradiction check. From 27 March 2028, EASA's material says the mass and balance documentation and the loading instruction report must not contradict each other and must include any last-minute changes (Source: www.easa.europa.eu), a reconciliation test any operator can write.
• Closed at takeoff. The 2010 Chief Counsel interpretation indicates the original manifest cannot be altered after takeoff, so post-departure corrections belong in the discrepancy-reporting channel recommended by the AC, not in a rewritten manifest.

Message and transport layers

Late changes travel by messages, and the transport defines the failure modes. IATA's Type B messaging whitepaper states that the family is used for weight and load balancing information, for example via ACARS ^[22], that store-and-forward delivery means the order in which messages arrive is not guaranteed ^[22], and that a message is limited to 60 lines of 63 characters ^[22]. ARINC 633 defines the format and exchange of Aeronautical Operational Control messages ^[23] with data structures that include weight and balance and cargo planning load sheets ^[23]. ARINC 620 defines interfaces between the datalink service provider and the aircraft ^[24], and ARINC 618 covers the character-oriented data link between aircraft systems and ground systems ^[25]; SKYbrary adds that ACARS operational messages must meet at least the ARINC 618 guidelines (Source: skybrary.aero). On the ground side, the IATA Airport Handling Manual provides industry-approved policies and standards for ground handling ^[26], and IATA's XML toolkit lists a load and trim sheet schema ^[27] alongside a check-in and load control data exchange schema ^[27]. IATA's edition 45 article says AHM 561 outlines an approval process for departure control systems and data ^[28]. IATA also teaches developing X565 data for computerized load control systems ^[29]. The full load message content is paywalled, so this report does not characterize message fields.

Two design consequences follow: ordering is not guaranteed at the transport, so the proposed tests must distinguish complete snapshots from incremental events. Verify that a retained snapshot includes earlier changes; for incremental events, recover gaps and apply all required events in order. A size-limited message cannot carry an unbounded exception list.

Acceptance-Test Matrix

Table 2 below converts the data map into tests. Each row states a stimulus, the evidence that proves a pass and the signal that proves a gap. All rows are written to be run in a test environment against the operator's approved configuration; none requires computing a legal balance.

Proposed payload contract for these tests: declare whether each message is a complete snapshot or an incremental event. IATA warns that Type B message order is not guaranteed ^[22]; the tests below therefore distinguish replacement state from changes that must accumulate. For complete snapshots, verify against the source system that the retained snapshot includes all earlier changes. For incremental events, detect sequence gaps, recover missing events and apply every required event in order before declaring reconciliation complete. In both models, compare the final loadsheet state and source version against the source system before departure, including a test that drops the final event: no later version may arrive to expose its loss. These are proposed acceptance criteria, not prescribed regulatory procedures.

Reading Table 2, the tests fall into two groups. Rows on duplicates, order and versions test the data layer. Rows on receipt, revision visibility and retention test whether the system supports the human procedures the operator has approved. The latter group cannot pass on software alone: the crew must still follow the manual, and AC 120-76E says operators should define new roles for flightcrew and dispatch when an EFB is involved.

Synthetic before and after record (Hypothetical Example)

The record below is invented and does not describe any operator, product or flight. It shows how a late change can differ in count, mass, units, version and receipt time without any balance calculation. Times are minutes before scheduled departure.

field        version 1 (T-35 min)   version 2 (T-9 min)    check
passengers     118           121            +3, new version required
checked bags    96            99            +3
cargo        1,240 kg         2,734 lb         unit changed; 1,240 kg is 2,733.7 lb
fuel        9,400 kg         9,400 (no unit)      FAIL: unit missing
aircraft tail    Tail-1          Tail-2          configuration reference must change
loadsheet version  1            2             supersedes 1
crew receipt    accepted T-30 min    none recorded at T-5   FAIL: no receipt for version 2

The cargo line shows why a conversion must be explicit. Using the exact pound-to-kilogram factor of 0.453 592 37 published by the US National Institute of Standards and Technology (NIST) ^[30], 1,240 kg converts to about 2,733.7 lb, which rounds to 2,734 lb; converting 2,734 lb back gives 1,240.1 kg. The 0.1 kg difference is rounding, and a test should state a tolerance. The fuel line is more serious: an unlabeled 9,400 could be read as kilograms or pounds, a difference of roughly a factor of 2.2 (9,400 kg is about 20,723 lb). The record has no way to say which was meant.

Packaged Interfaces Versus a Narrow Adapter

The decision is not airline load control software versus custom software. A qualified product usually provides the calculation, the document formats and a maintained data model. The open question is what happens at the seams. Table 3 summarizes what public vendor pages state about interfaces and what they do not state. Entries are vendor claims, read in October 2026, and not independent verification; nothing here is a statement about FAA approval or product quality.

Table 3 is deliberately asymmetrical. The vendor rows are the vendors' own statements about their products. The final row describes a category of integration work: it carries no performance claim, and no claim is made that it is better than any packaged product. Bytron describes stored status, timestamps, electronic signatures and revision history ^[8]. Use the matrix to verify precise version binding, timestamp semantics, export format and operator-specific behavior.

When a packaged product is enough

A packaged product is likely sufficient when the vendor's documented interfaces cover the operator's DCS, ramp and flight planning systems, the Table 2 tests pass in a sandbox, and the approved manual describes the vendor workflow, including any manual entry. Evionica's public blog notes that its system monitors the DCS for changes in flight status ^[21], and an EFB vendor describes a pop-up for revised loadsheets (Source: www.bytron.aero); these suggest that event handling exists in some products, and the operator still needs to test it.

When a narrow adapter is worth scoping

An adapter is worth scoping where the tests show a specific gap, for example station systems that do not emit events in a form the product accepts, or a requirement to keep one reconciled change history across the DCS, the loadsheet product and an EFB. Even then the calculation, certified data and loadsheet output stay with the qualified product. The need is documented across vendors: one navigation vendor's app listing says last minute changes are now easily considered ^[31], which confirms that late changes are a product-level concern but not how a given operator's feeds behave. The adapter would carry identifiers, versions, units and timestamps and write logs; it would not decide limits, alter approved procedures or change a regulatory obligation. Any adapter that touches an EFB application falls under the operator's EFB program and the guidance on revision visibility, and any adapter that stores or signs records should be evaluated against the electronic recordkeeping AC.

Implementation Considerations and Process Changes

An operator can run the matrix without changing software. The steps below sequence the work.

• Inventory the approved program. Collect the OpSpec paragraphs (A096 to A099, E096 and A025 where used) and the manual sections that describe loading schedules and instructions for routine operations.
• Draw the field map. Fill in Table 1 for the operator's actual systems, noting for each field whether it arrives by interface or keyboard.
• Define identifiers. Agree flight key, tail, version and time standards. Sequence numbers are the practical protection against unordered delivery ^[22].
• Run the matrix in a test environment. Record results as evidence for internal review, not as a regulatory statement.
• Align the discrepancy channel. Make late-change anomalies reportable in the employee reporting system the AC recommends, with corrective action such as load audits.
• Review with FAA oversight. Changes to the weight and balance program, the loading schedule or electronic record use typically involve the principal operations inspector; the operator should confirm which changes need approval before implementing them.
• Keep the human steps explicit. Document the persons, signatures and checks specified by the operator's approved procedures. Section 121.665 requires preparation and signing by loading-supervision employees or other qualified persons authorized by the certificate holder ^[32]. Software should support the assigned human steps.

What the operator must verify

Before relying on any conclusion in this report, the operator should verify:

• the current text of 14 CFR 121.665, 121.693 and 121.695 on the eCFR or in the official annual edition;
• its own OpSpecs and approved weight and balance program, including any revisions after the 2021 cycle ^[10];
• the status of AC 120-27F with the FAA, listed as active on the FAA's page;
• whether the EFB, electronic signature and electronic recordkeeping authorizations cover the handoff path;
• each vendor's current interface documentation, since the public pages cited are undated.

Data Analysis and Evidence

The evidence in this area is mostly regulatory parameters, not market statistics. No public benchmark of late-change rates, loadsheet reissue rates or crew-receipt latency was found, and none is estimated here. The figures below are the ones that parameterize an acceptance test, each traced to its originator.

• Retention: at least three months for Part 121 domestic and flag copies ^[4]; for supplemental outstations, not more than 30 days before copies go to the principal base ^[4]; 30 days for Part 135 ^[15].
• Dates of guidance: AC 120-27F is dated 6 May 2019 ^[2]; the OpSpec re-issuance deadline reported by NBAA fell on 12 June 2021 ^[10].
• Seasonal weight window: May 1 to October 31 for summer weights ^[2]. A data bridge that stamps a season tag needs this boundary configured per the operator's approved program, which may differ.
• Unit factor: one pound equals 0.453 592 37 kilograms exactly ^[30].
• Fuel basis: Transport Canada's standard requires the weight and balance system to address fuel load weight determined by either the actual or a standard specific gravity ^[17]. AC 120-27F gives no numeric fuel density constant, so a US operator should test which density basis its own system uses.
• Message limits: 60 lines of 63 characters per Type B message ^[22].
• Other retention periods (contrast only): three months for EU mass and balance documentation under ORO.MLR.115 as adopted in 2012 (Source: eur-lex.europa.eu), and 90 days for Canadian airline weight and balance forms ^[18].

These parameters show where tests have natural boundaries (retention period, season switch, unit conversion, message size). They do not show how often failures occur; an operator that wants a rate must measure it from its own logs. The synthetic record above is hypothetical, not a sample of real data.

Implications and Future Directions

Three trends follow from the guidance record. First, the FAA's move from published average weights to operator surveys and actual weights means the weight basis becomes data that must travel with the load, not a constant buried in the calculation. Second, EFB guidance now places Type B applications within the operator's EFB program rather than the OpSpecs, so revision visibility and role definition become operator-level evidence. Third, electronic recordkeeping guidance emphasizes records of equivalent or better integrity than paper, which sets the bar for change history.

For vendors, the public pages emphasize automation, such as flights automated on time thresholds, and mobile access to loading information ^[33]. Operators evaluating those claims should ask for the event model, not just the feature list. A reasonable procurement question is: for each row of Table 2, what does the product log, and where can the operator read it?

AI-assisted tools can help summarize discrepancies or flag mismatched fields, but they are not a basis for deciding loading limits or the legal accuracy of a manifest. That responsibility rests with the certificate holder. Any AI-assisted component should be limited to monitoring and reporting and tested like any other interface.

Frequently Asked Questions (FAQs)

Load manifest vs loadsheet: what is the difference?

In Part 121, the load manifest is the regulatory form whose contents are listed in 121.693. A loadsheet is the industry document carrying the final loading data, and many operators produce the manifest through a loadsheet process. An onboard system does not remove the manifest requirement. Whether the two are one document is set by the operator's approved program.

Can a late change be made after the crew has accepted the loadsheet?

The regulation text does not define the procedure. UK guidance notes that loadsheets often need adjusting after completion (Source: skybrary.aero), but that is not US material. The AC permits a separate, amended manifest in some circumstances, and the 2010 legal interpretation indicates that the original manifest cannot be altered after takeoff. The operator's manual defines the practice.

Why do zero fuel weight and unit discrepancies matter at handoff?

Because the fuel figure and the other weights come from different systems and can use different units. The AC asks for consistent units or a stated conversion method. A zero fuel weight mismatch between a DCS-side estimate and the final loadsheet is a symptom, not a cause: compare version, unit, tail and timestamp of the inputs first. AC 120-27F uses zero fuel weight in section 2.4.3.5 and defines maximum zero fuel weight in Appendix A.18 ^[2]. This report does not perform an operational calculation.

Is custom software required?

Not necessarily. The decision rests on test results. Where a packaged product's documented interfaces close the gaps, no bridge is needed; where they do not, a narrow adapter may be scoped around the specific gap.

Conclusion

The Part 121 load manifest remains a certificate-holder obligation that the operator's approved program must satisfy regardless of the software used. The regulation text and the FAA advisory material define responsibility, contents, retention and a recommended discrepancy-reporting channel; they leave late-change mechanics, version control and acknowledgment records to the operator's procedures. Packaged products from several vendors state broad integration and offline capabilities, and those statements are a starting point, not evidence of a specific behavior.

The useful artifact is therefore a field-level source-of-record map and an acceptance matrix that exercises duplicates, gaps, ordering, tail swaps, units, offline delivery and receipt. Run before purchase and again after each integration change, it shows whether an existing product already maintains a traceable final-load handoff. Where it does not, a narrow adapter can carry identifiers, versions, units and logs between systems while the qualified product keeps the calculation. Final loadsheet reconciliation, meaning load manifest data reconciliation across departure control, ramp, flight planning and EFB systems, is therefore best treated as a tested interface property rather than an assumption about any product. In every case the operator should confirm conclusions against current regulations, its own OpSpecs and manuals, and its FAA oversight office.