Evaluate air-cargo software around piece acceptance and flight handoff

A booking screen can hide the piece that never reached the terminal

An air-cargo booking lists eight pieces. Seven arrive, one of those is held, and the eighth is still with the origin operator. A system that displays “received” for the whole booking leaves the next team unable to tell what can move.

The most useful evaluation starts at that break in the handoff. Ask the software to identify each expected piece, record what actually arrived, preserve the hold and show which pieces were handed to the next authorised party. Then change the scenario and inspect the audit trail.

The IATA — Cargo Handling Manual describes cargo-handling stages including receipt, acceptance as ready for carriage and preparation for transport. Those stages provide a useful distinction for evaluation. The applicable terminal and carrier procedures must supply the actual acceptance conditions; a general process description is not a local operating instruction.

Establish what the system is responsible for recording

An evaluation should name the station, carrier relationship, cargo family and operating parties. Identify where booking data originates, where piece observations are captured and which external responses the system can receive.

The software may be a forwarder's workbench, a terminal operating application or an integration layer. Each has a different view of the movement. Do not require a forwarder screen to invent a terminal decision it has not received, or assume a terminal scan updates every partner immediately.

Create a responsibility map for booking changes, receipt discrepancies, physical holds, document review, authorised security and customs states, flight allocation and actual handoff. Each state needs a source, timestamp and scope. A manually recorded confirmation should identify who checked it and against what evidence.

The IATA — ONE Record offers a common approach to air-cargo data sharing. It can inform partner exchanges, but a supplier should demonstrate the particular connection and version it supports rather than claim that using the standard ensures every partner is connected.

Worked example: follow eight pieces through a partial movement

This illustrative scenario uses eight booked pieces, P1–P8. Before the applicable acceptance cutoff, P1–P7 reach the handling point. P7 is held after a discrepancy is identified. P8 has not arrived.

For the final row, assume the authorised flight record confirms P1–P5 loaded. P6 had met the defined readiness conditions but was not loaded. P7 remains held and P8 remains unreceived. The total still reconciles to eight: five plus one plus one plus one.

This is a recordkeeping scenario, not permission to split any real shipment. The responsible carrier and operational teams must determine whether partial carriage is allowed and what booking, document or other changes are required.

A weak implementation changes the shipment header to “departed” and leaves all eight pieces with that inherited status. A stronger implementation records the five-piece movement and makes the remaining three visible with their different reasons and next actions.

Ask for actions, not screenshots

Give the supplier the test records and ask an operator to execute the scenario. Observe whether the normal workflow supports it or whether someone edits the database between steps.

First, import the booking and reconcile the expected piece identifiers. Then record seven arrivals, raise P7's hold and attempt to make the booking ready. Inspect whether the screen explains the unresolved P8 receipt and P7 hold without requiring a separate spreadsheet.

Next, add the confirmed five-piece flight movement. Ask where P6 is, who owns its next plan and how a later movement will link to the original booking. Request the evidence supporting each status rather than accepting a colour or icon as proof.

Finally, correct an erroneous receipt event. The system should preserve the original observation, the correction reason and the authorised decision. A count that looks right only because an event disappeared is difficult to audit.

Compare capabilities that affect daily work

These are proposed evaluation checks. They do not assert that every vendor includes the same native features.

An extension to an existing system may be enough if the source events and piece identities are already reliable. Specialist terminal software may fit when local handling workflows are the main gap. An integration project may fit when each party has sound records but cannot exchange them. Compare the unresolved operational work remaining after each option, not just the number of modules offered.

Keep acceptance authority outside generic status automation

Software can organise required checks, expose missing evidence and route a decision. It should not convert an unverified document value into security clearance, customs release or a qualified acceptance decision.

For each relevant status, identify the authorised source and the conditions under which it becomes stale or requires review. A changed shipment detail may affect a prior approval; the responsible procedure determines the consequence. The system should surface that dependency rather than guess.

Also inspect access. A warehouse operator may record a piece observation without permission to amend commercial data or clear a specialist hold. The demonstration should use the actual proposed roles, including a user whose attempted action must be refused.

Measure the work left behind

Count unmatched expected pieces, unresolved holds, eligible pieces without a movement plan and partner states awaiting confirmation. Measure how long those exceptions remain without an owner.

For the demonstration, require eight of eight expected pieces to have a reconciled outcome and an appropriate next action where work remains. That is a proposed test gate for this case, not an industry service benchmark.

Record operator effort and recovery steps alongside accuracy. A system that preserves the truth but requires repeated re-entry may still be a poor fit. Conversely, reducing clicks is not useful if the five loaded pieces become indistinguishable from the three left behind.

Select software around the incomplete handoff

The decisive question is whether an operator can explain every expected piece after the plan changes. That capability connects booking data to physical handling and makes partner discussions more precise.

Next actions

1. Assemble one real partial-arrival or partial-flight case with authorised, anonymised evidence.
2. Define the local readiness conditions and the party responsible for each decision.
3. Run the same exception sequence in each shortlisted approach.
4. Review count reconciliation, authority and recovery before comparing commercial proposals.

For an assessment, bring the booking, piece records, terminal responses and actual flight outcome. They reveal more about system fit than a standard demonstration of a fully successful shipment.