Technical architecture · 1 November 2026 · Neerej Sasikumar

Order Fulfilment Evidence: Reconciling Delivery, Consumption and Accounting

Editorial scope: Public IATA standards and independent practitioner recommendations; no airline-specific implementation claims.

Why an Order confirmation is not delivery

An Order confirms a commercial relationship; it does not prove that every component has been consumed. This distinction becomes essential when one passenger buys a flight, checked baggage, a seat and an optional lounge service. Payment can settle before travel, while the delivery provider may report a sequence of milestones across different systems. An accounting team needs a defensible answer to what was sold, what was delivered, what remains owed and what requires correction. A single Order-level “complete” flag cannot provide that answer. This guide proposes a service-level evidence contract for retailing teams implementing or coexisting with ONE Order. It is a technical design proposal, not a claim that a particular airline or platform has adopted it.

What the standards establish—and what they do not

IATA describes ONE Order as an initiative to integrate the customer record and streamline fulfilment, delivery and accounting across the Order lifecycle. Its public 21.3 implementation guide explains that an OrderItem contains deliverable services and that an Ordered Service should represent the lowest granularity that can be delivered: one passenger and one flight segment in the illustrated model. That precision is needed for fulfilment tracking and revenue accounting. IATA AIDM models Service Delivery Status Code and Delivery Milestone Code separately. A milestone can record an event such as passenger boarding or a bag being loaded without necessarily changing the service status. The published AIDM delivery-status vocabulary includes DELIVERED, EXPIRED, FAILED TO DELIVER, IN PROGRESS, NOT CLAIMED, READY TO DELIVER, READY TO PROCEED, REMOVED, SUSPENDED and UNABLE TO DELIVER. Those are model definitions; they do not establish that every deployment exposes every code, or that every milestone is legally sufficient accounting evidence. Release, message, policy and contract must be checked before implementation.

Four independent ledgers

A useful operating design maintains four linked but separate records. The commercial ledger identifies Order, OrderItem, Service, passenger, segment, entitlement, terms and agreed consideration. The payment ledger records authorisation, capture, refund, chargeback and settlement references. The delivery ledger records provider acknowledgements, readiness, attempt, consumption, failure and reversal. The accounting ledger records recognition decisions, liability balances, accruals and correction postings. The word ledger here denotes an auditable record of state and history, not a requirement to deploy four databases. The critical invariant is traceability: each financial posting must point to the relevant service and evidence or an explicitly documented exception. Payment captured must never silently imply service delivered.

An evidence contract at service granularity

For each service, capture an immutable evidence event with a stable event identifier, source system, source timestamp, ingestion timestamp, Order ID, OrderItem ID, Service ID, passenger reference, segment or product reference, event type, provider reference, previous and proposed delivery state, schema version and correlation ID. Include a pointer to source proof rather than copying sensitive personal data into analytics logs. When the provider can issue corrections, retain both the original event and the superseding correction. Define the trust level and provenance of each evidence class: customer self-report, provider acknowledgement, scanned consumption, operational departure record or signed settlement advice may carry different weight. This contract is a practitioner recommendation. It is not an IATA message schema and should not be presented as one.

Worked example: one booking, four outcomes

Consider an illustrative Order for one traveller: a flight, a prepaid seat, checked baggage and lounge access. The flight is boarded and completed. A seat-selection record says the assigned seat was changed before departure; the original paid attribute may or may not have been preserved. The baggage system reports acceptance but no final delivery event. The lounge provider reports that access was never scanned. The booking can look fully flown while three service-level questions remain. The flight has strong consumption evidence. The seat requires an entitlement-equivalence check against the delivered product, not simply the boarding event. The bag needs a defined evidentiary threshold: acceptance may prove handover, not final handling. Lounge non-consumption could be customer choice, a provider failure or an expired entitlement. Each possibility carries different commercial and accounting implications, which depend on applicable terms. The correct output is not one binary Order status but a reconciliation worklist with service-specific evidence and decisions.

State and milestone mapping

Map incoming events to a controlled internal vocabulary without overwriting their original codes. For example, READY TO PROCEED may show an entitlement exists; READY TO DELIVER may show provider preparedness; IN PROGRESS may indicate delivery is underway; DELIVERED should be supported by the agreed proof threshold; FAILED TO DELIVER and UNABLE TO DELIVER require distinct investigation paths; NOT CLAIMED and EXPIRED should not be automatically treated as provider failures. A boarding milestone can be evidence toward flight consumption, while a baggage loading milestone is not proof that baggage was returned to the passenger. Maintain an explicit mapping table by service category and source release. Never infer a missing milestone as a negative event without checking the provider's reporting obligations and latency.

Exception taxonomy and ownership

Separate missing evidence from conflicting evidence, delayed evidence, failed service, customer non-consumption, duplicate event, reversed event and accounting mismatch. Missing evidence means the delivery provider has not reported within an agreed window; it does not establish non-delivery. Conflicting evidence occurs when two authoritative feeds disagree about consumption or state. Delayed evidence arrives after a financial close or refund decision. A reversed event invalidates an earlier conclusion but must remain auditable. Assign each exception a business owner, technical owner, financial impact estimate, next evidence request, deadline and closure reason. For interline or third-party services, record which party has authority to attest delivery and which party owns customer remediation. Do not assume that the retailer, supplier and delivery provider share identical operational data.

Reconciliation algorithm

Start with the latest confirmed Order snapshot and enumerate all active and historically relevant Services. Join payment allocations and delivery evidence by stable identifiers rather than free-text product names. Normalize events while retaining original source values. Deduplicate by provider event ID and source version; apply corrections with explicit supersession links. Evaluate each service against a versioned evidence policy: required milestones, acceptable sources, tolerance window, entitlement equivalence and unresolved contradictions. Produce a deterministic result: evidenced delivered, evidenced not delivered, pending evidence, disputed or not applicable. Feed accounting a proposed disposition plus source references; do not allow an automated engine to invent accounting treatment. Record the decision policy version and a replayable evaluation timestamp. A human reviewer should approve material exceptions, especially when a refund, revenue recognition or supplier settlement is affected.

Illustrative reconciliation payload

The following JSON is an internal design example, not an IATA schema: { "orderId": "EX-482", "orderItemId": "OI-02", "serviceId": "SV-SEAT-1", "evidenceStatus": "DISPUTED", "sourceEventIds": ["evt-31", "evt-44"], "policyVersion": "seat-evidence-v3", "financialDisposition": "REVIEW", "reviewOwner": "service-assurance", "evaluatedAt": "2026-11-01T08:00:00Z" }. The use of a stable service identifier allows the review to survive itinerary updates. The policy version explains why the same evidence might be evaluated differently after a rule change. Financial disposition is intentionally not set to REFUND or RECOGNISE until an authorised process confirms the outcome. No field names here should be assumed to exist in published NDC or ONE Order messages.

Financial boundaries and liability

Service delivery evidence informs financial decisions; it does not by itself define revenue-recognition rules. Accounting treatment depends on applicable standards, contracts, tax rules and the entity's role. Keep cash movement, earned revenue, customer liability, partner payable and settlement separately visible. A captured payment may coexist with an undelivered service; a refunded service may coexist with a pending provider reversal. Avoid netting away a dispute simply because the total Order balance is zero. For a provider-managed ancillary, require an attributable provider settlement reference and a traceable commercial allocation. The control objective is to explain differences, not to force every system to display the same balance at the same instant.

Late arrivals, replay and audit

Delivery events often arrive after an Order has changed. An immutable event history plus versioned mapping enables replay without changing the original evidence. Late events should be compared against the current Service identity and its predecessor links. A refund issued before a delayed consumption event is an exception requiring review, not a reason to silently reverse the refund. Maintain idempotent ingestion, clock-skew tolerance, sequence-gap detection and replay checkpoints. Retain who changed a mapping, who approved a disposition and which upstream messages were considered. Set retention according to applicable privacy, financial and contractual requirements rather than assuming indefinite storage is safe.

Acceptance tests for production readiness

Test a delivered flight with no ancillary evidence; a duplicate baggage acceptance event; an out-of-order delivery event; a provider correction after financial close; a paid seat replaced with a non-equivalent seat; a service marked NOT CLAIMED with no scan; a service marked FAILED TO DELIVER with a successful payment; an Order amendment that changes Service identifiers; an interline service whose supplier feed is delayed; and a refund issued while delivery evidence remains disputed. Each test should assert the resulting exception category, ledger linkage, owner, audit trail and permitted financial actions. Test that no replay can create a second refund or double recognition. Include operational recovery tests where the evidence store is unavailable while Order servicing remains online.

Operational measures and release gates

Measure evidence completeness by service type and provider, age of unresolved exceptions, percentage of decisions supported by source proof, correction frequency, reconciliation latency, late-arrival rate and financial exposure under review. Publish both numerator and denominator: a high delivered percentage is meaningless if many services have never reported. Track time from service completion to accounting-ready evidence, not just ingestion throughput. Release gates should require traceable service IDs, deterministic reconciliation, a documented source-of-truth matrix, a replay drill, clear human escalation and agreement on evidence thresholds. These are proposed engineering controls, not mandatory IATA conformance tests.

Practical implementation sequence

Begin with a narrow service category and one provider rather than attempting universal reconciliation at once. Inventory the existing identifiers, event feeds, milestones and financial references. Establish the smallest evidence contract that answers a real operational question. Reconcile a sample of historical cases manually to expose ambiguous statuses. Introduce automated classification only after business owners approve the mapping. Shadow-run the reconciliation against current accounting outputs, quantify false positives and missing evidence, then expand to more services and partners. Preserve a visible distinction between authoritative source facts and derived practitioner classifications. That separation is the foundation for trustworthy Order-based fulfilment and financial control.

Original primary references

Related practitioner guides

ONE Order accounting controls · Partial cancellation and service dependencies · Order event replay.

Independent technical education. Illustrative contracts, mappings and accounting controls are recommendations, not IATA schemas or accounting advice. Verify deployed message versions, contracts and applicable rules.

Browse all articles