Baggage Reconciliation Software: Who Owns the Bag When It Misses the Connection?

Why mishandled bags are a coordination failure, not a technology gap

A passenger connects at your hub with a fifty minute minimum connection time. The inbound arrives eighteen minutes late on a remote stand. The bag comes off the aircraft, goes to the transfer infeed, and misses the sort window by four minutes. It flies six hours later, arrives at a station where your handler has two staff on shift, and is delivered by a courier the following afternoon. Between those events the bag was touched by three companies: the arriving carrier, the hub handler, and the destination handler. Each has a record. None of them has the same record. The passenger has one experience, which is that nobody could tell them where the bag was.

The tooling around this is real and mostly good at what it does. SITA WorldTracer is the industry backbone for tracing and for the file that carriers exchange, SITA BagManager handles reconciliation and tracking, and Amadeus offers baggage reconciliation as part of its airport suite. They exist because the problem is genuinely industry wide and needs shared standards. What they do not do is hold your operation: your handler contracts, your compensation policy, your interline cost recovery, your courier network, your station level performance data, and your rule for when a bag becomes a delivery job rather than a search.

The cost of the gap is not subtle. Every mishandled bag carries a real cost in compensation, courier delivery, staff time and station handling, and it is paid by whoever cannot prove it was not their fault. In our experience with carriers and handlers, the recurring damage sits in three places: bags that were physically scanned but whose scan never reached a system anyone could query, claims settled without recovering from the party actually responsible, and a total inability to answer which station, which shift and which process step is generating the mishandling in the first place. You cannot fix a rate you cannot attribute.

Problem 1: custody is the data model, and most systems do not have it

IATA Resolution 753 asks carriers to track custody at defined points: acquisition, delivery to the aircraft, transfer between carriers, and delivery to the passenger. That framing is exactly right, and it is also where most implementations stop, because tracking the points is easy and reconciling them is not. The hard question is not where a bag was scanned. It is which party held it at the moment it went wrong, and whether the absence of a scan means the bag was not there or the scanner was not working.

Most reconciliation deployments treat a scan as an event appended to a bag tag number. That produces a timeline. It does not produce accountability, because a missing scan is indistinguishable from a missing bag. A handler with a broken scanner at the transfer infeed looks identical in the data to a handler who never loaded the bag.

What a custom build does: model custody as an explicit chain with a holder at every moment, so the system always has an opinion about who has the bag and how confident it is. When a bag has no scan at a point where one was expected, the system raises a gap with the responsible party and the expected window, rather than silently leaving a hole. Scanner health becomes part of the record, which means an equipment failure produces an equipment ticket instead of a false accusation. This distinction sounds academic until the first time you try to recover cost from another carrier and discover your evidence is an absence.

Problem 2: reconciliation has to happen before pushback, on real hardware

Positive passenger bag matching is a security obligation in most jurisdictions and an operational necessity everywhere: a bag whose passenger did not board must come off before the aircraft moves. The moment that matters is the last ten minutes before departure, on the ramp, in weather, on a device with intermittent coverage, held by someone wearing gloves.

This is where general purpose products struggle, and not because the vendors are careless. Their reconciliation screens are designed to be complete rather than fast. What the loader needs is a single screen that says: these are the containers, this is the offload list, scan to confirm, and it needs to work when the network drops for ninety seconds, which it will.

What a custom build does: an offline first ramp application with local reconciliation state, deterministic conflict resolution when it reconnects, and a physical design tested with gloves on. Baggage source messages and baggage processed messages ingest continuously so the offload list is correct without a refresh, and the departure control interface confirms boarded status rather than assuming it. The build target is that a loader completes an offload decision in under twenty seconds without asking anyone. Anything slower gets bypassed on a tight turn, and a bypassed process generates no data at all.

Problem 3: the claim is a workflow across three companies and one policy

When the bag does not arrive, a file is created, and from that moment the operation has to run a search, a delivery, a passenger communication thread and a compensation decision, often across two carriers and two handlers. The industry file format handles the tracing. Everything around it is yours: what you pay for interim expenses, at what threshold you escalate, how many days before a delayed bag becomes a lost bag under your policy, which courier serves which postcode, and who signs off a payment above a limit.

The Montreal Convention sets a liability limit for baggage expressed in special drawing rights, and that limit is revised periodically. Local passenger rights rules layer on top in several markets. The consequence is that your compensation logic is jurisdiction dependent and changes without asking your permission, which is a terrible thing to hard code and a normal thing to hold as versioned data.

What a custom build does: one claim object with the status the passenger sees, the tasks the station sees, and the financial position finance sees, all from the same record. Passenger updates go out automatically at genuine state changes rather than on a timer, because a message that says nothing has changed is worse than silence. Courier dispatch is integrated so the delivery job is created from the claim rather than emailed, and proof of delivery closes the file. Compensation rules live in a versioned policy table with an approval ladder, so a change in a market takes an afternoon rather than a release.

Problem 4: nobody recovers the cost from the party that caused it

Interline baggage means the cost of a mishandling frequently belongs to a carrier or handler other than the one paying it. Recovering it requires evidence: the custody chain, the scan gap, the message trail, and a claim raised within the window the agreement allows. Most operations do not attempt this systematically, because assembling the evidence per bag costs more than the recovery is worth, so it is done for the big cases and abandoned for the rest.

What a custom build does: assemble the evidence automatically for every file, because the custody model already holds it, then apply your recovery rules to decide which files are worth pursuing and generate the packet. The economics invert once assembly is free. In our experience this is the feature that turns a baggage system from a cost centre into something the finance director defends at budget time, and it is only possible because of the custody modelling in problem one. The two are the same project.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape. A first release covering scan capture at each custody point, baggage message ingest, live reconciliation with an offline capable ramp application, and structured claim intake runs $80,000 to $180,000 and ships in 12 to 20 weeks. That is a system your ramp and baggage services teams use in production. A full platform adding interline messaging, courier dispatch with proof of delivery, cost recovery packet generation, and station analytics runs $200,000 to $500,000 phased over 6 to 12 months.

What drives the number up in baggage specifically: the number of stations, because each one has its own handler, its own devices and its own network reality. Messaging integration, because Type B message handling and departure control interfaces are their own engineering effort per host system. Hardware, if you are deploying rugged scanners or moving to RFID readers, since device management across stations is a real programme rather than an app install. Multiple handler contracts with different service definitions. And the largest hidden driver, which is the number of legacy stations still working on paper, because those need process change alongside software.

What keeps it down: starting at your hub and the top five stations by transfer volume, running the industry tracing tooling unchanged for the file exchange, and building your layer around it rather than trying to replace it.

Build versus buy, and when the industry tooling is enough

Buy and stop reading if you are a single hub carrier under roughly a million passengers with mostly point to point traffic and few interline bags. WorldTracer for tracing plus your handler's own reconciliation is genuinely sufficient, and a build would be a distraction from hiring a second baggage services agent, which will do more for your passengers.

Buy, then build a thin layer, if you are mid sized and the gap is only in claims and communication. In that case a claim workflow and passenger update layer sitting on top of the industry file, at the lower end of the first release band, gets most of the value.

Build properly when two or more of these are true. You run a hub with meaningful transfer volume, which makes custody genuinely ambiguous. You are a ground handler working several carriers, in which case your ability to prove you did not lose the bag is a commercial asset. Your interline recovery is happening on a handful of cases a year because assembling evidence is too expensive. Your compensation policy differs by market and currently lives in a document rather than a system. Or you have no reliable attribution of mishandling by station and shift, which means every improvement programme you run is guesswork with a budget attached.

How to choose a developer for baggage systems

Ask them to model custody on a whiteboard. A team that has done this draws bag, tag, journey leg, custody event, holder party and gap, and it asks within two minutes what a missing scan means. A team that draws bags with a status column has built a parcel tracker and has not yet met an interline transfer.

Ask how the ramp application behaves with no network for ninety seconds during an offload. The correct answer is local state, a clear offline indicator, and a defined merge rule on reconnect. Any answer involving a spinner means the tool will be bypassed on the turns that matter most.

Ask what they have integrated by name. Baggage source and processed messages, a departure control system interface, the industry tracing file, and a courier API are four separate problems. Ask them to describe how they tested message handling against malformed real world traffic, because real Type B traffic is not what the specification promises.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue the work. Baggage systems touch security processes and station operations, which makes vendor lock in genuinely dangerous rather than merely annoying. At Digital Heroes the code is yours from the first commit, and any developer who hedges on that is building a dependency rather than a system.