Aircraft Load Control and Weight and Balance Software: The Last Six Minutes Before the Doors Close

Why load control is six minutes of arithmetic that carries an aircraft

Boarding closes. The load controller has final passenger numbers by cabin zone, checked bag count and weight, cargo and mail in identified hold positions, the fuel figure from dispatch, the pantry configuration and the aircraft's dry operating weight and index. From that they produce a loadsheet showing the takeoff mass and the centre of gravity, and it has to be with the flight deck before the doors close, because the crew set the trim from it.

Then, in the last two minutes, three passengers who were counted do not board and a late bag goes in the rear hold. That is a last minute change, and it is where the errors in this discipline concentrate. The controller has to decide whether the change stays within the approved tolerance for an amendment or whether the loadsheet must be recomputed and reissued, under time pressure, on a radio, with the ramp waiting.

The consequences of getting this wrong are not commercial. A trim set from a wrong sheet is a takeoff performance problem, and mis-loading is a recognised category of serious incident. This is why load control is a licensed, type-specific competency and why the software carrying it is treated as safety critical.

Lufthansa Systems NetLine/Load, Smart4Aviation Smart LOAD and Amadeus Altea Departure Control are the products in this space. They are mature, they are used by carriers that depend on them daily, and they are correct on the arithmetic. Where operators run into limits is not the calculation. It is the surrounding shape: which departure control systems they can consume, how many carriers a single controller can serve in one session, how loading instructions reach the ramp, and how the whole chain evidences itself afterwards.

Problem 1: the last minute change is where the risk lives, and the tooling is thinnest

Every load control system produces a loadsheet. The interesting behaviour is what happens after it is issued. A last minute change can be applied as an amendment within limits defined by your approved procedures, or it forces a recomputation. That decision is made by a person under time pressure, and it is the single most error-prone moment in the process.

The incumbents support last minute change handling. The gap we see repeatedly is that the change often arrives by voice, from a gate agent or a ramp lead, and is entered by the controller from what they heard. There is no structured capture at the point the change actually occurs, so the record afterwards is the controller's entry rather than the original event.

What a custom build does: capture the change where it happens. A gate agent's device reports the three passengers who did not board; the ramp reports the late bag with its hold position. The controller receives a structured change with its source and timestamp, and the system evaluates immediately whether it falls within amendment limits for that aircraft and that loadsheet, showing the resulting index shift rather than asking the controller to work it out. The decision remains human. The arithmetic and the tolerance check stop being human, which is the correct division of labour in a safety critical loop.

Problem 2: centralised load control means many departure control systems and many formats

A handler running centralised load control serves multiple airlines from one room. Each carrier brings its own departure control system, its own aircraft configurations, its own approved procedures, its own loadsheet format and its own message addressing. The controller may switch between three carriers in an hour, and each switch is a context change with different rules and, frequently, a different terminal.

This is the clearest structural limit of the incumbent products. They are built around an airline's own operation. A handler's operation is multi-tenant by nature, and the workaround is a desk with several systems open and a controller who remembers which is which. That is precisely the arrangement that produces a loadsheet issued against the wrong carrier's procedures.

What a custom build does: model carrier as a first-class dimension. Aircraft configurations, standard mass values, amendment tolerances, loadsheet layouts and message addressing all belong to a carrier profile, and the controller works in one interface that adapts. Integration to each departure control system happens once and is reused across every flight for that carrier. For a handler this is not an efficiency gain, it is the difference between a scalable service and a room that grows linearly with contracts.

Problem 3: the loading instruction is a printed sheet on a windy ramp

The loading instruction report tells the ramp what goes where: which unit load devices in which positions, which bulk in which hold, what the weight distribution must be. It is printed and handed over. What comes back is a signed copy stating what was actually loaded, sometimes hours later, sometimes not at all, and any deviation between planned and actual loading is a real balance question that arrived too late to matter.

What a custom build does: put the instruction on a ramp device with confirmation per position, so deviations report back while the aircraft is still on stand. If a container goes to a different position than planned, the controller knows immediately and can evaluate the index effect rather than discovering it from a signed sheet after departure. Devices on a ramp need to survive weather, gloves and poor connectivity, so this is a design problem as much as a software one, and offline capability with reconciliation is not optional.

The secondary benefit is that planned versus actual loading becomes a dataset. Over a few months you learn which stations deviate most and why, which is a training and process question you currently have no evidence for.

Problem 4: dangerous goods segregation is a rule set that must be applied before loading, not after

Dangerous goods carry acceptance rules, quantity limits and segregation requirements under the IATA Dangerous Goods Regulations, and the notification to captain must reflect what is actually on board and where. In practice acceptance happens in cargo, the load plan happens in load control, and the segregation check depends on both agreeing.

What a custom build does: validate segregation at the point the load plan is built, using the accepted shipment data rather than a separate manual check. Incompatible classes in adjacent positions are refused by the planning step rather than caught by an alert reader of the notification. The notification to captain is then generated from the same plan the ramp is loading to, which removes the class of error where the document and the aircraft disagree.

Problem 5: the audit trail exists in fragments, and audits are frequent

Load control is audited: by the carriers a handler serves, by regulators, and internally after any event. The questions are always the same. Who computed this loadsheet, were they qualified and current on that type, what data did they use, what changed after issue, and who approved the change. Today those answers come from several systems plus a training spreadsheet.

What a custom build does: bind qualification to action. A controller cannot produce a loadsheet for a type they are not currently qualified on, because the system checks currency at the moment of the action rather than in a monthly report. Every input, every version of the sheet and every amendment is preserved with its source. Then an audit is a query rather than a week of preparation, and a carrier's annual review of your handling contract becomes a demonstration rather than a defence.

What this costs and how long it takes

A first release covering the balance calculation for one aircraft type family with your approved procedures, loadsheet and loading instruction production, and structured last minute change handling runs $120,000 to $250,000 and ships in 16 to 24 weeks. Verification consumes a disproportionate share of that and should be planned as its own phase with your own load control specialists. A full multi-carrier platform adding several departure control integrations, dangerous goods segregation, ramp devices with offline capability, qualification enforcement and full audit runs $350,000 to $800,000 phased over 9 to 18 months.

What drives cost up here specifically: the number of aircraft types and configurations, because each carries its own balance data, hold structure and limits. The number of departure control systems you must consume, which is the dominant factor for a handler. Message formats and addressing, since loadsheet transmission and the messages exchanged around a departure follow established industry formats that must be produced exactly. Ramp hardware, and the offline behaviour that goes with it. And validation, which in this category means computing thousands of historical flights both ways and reconciling every difference before a single live sheet is issued.

What holds cost down: one carrier, one type family, one station for the first release, proven properly before the second is added.

Build versus buy, and why we tell most airlines to buy

Buy if you are an airline. If you operate one or two types under a single departure control system, NetLine/Load, Smart LOAD or the load control within Altea will do this more reliably and far more cheaply than a build, and the arithmetic is not where your competitive difference lies. We say this knowing it costs us the work, because putting a bespoke safety critical calculation into an operation that does not need one is a bad trade for the operator.

Build when two or more of these are true. You are a ground handler providing centralised load control to several carriers and your controllers switch between multiple systems in a shift. You cannot get the departure control integrations you need from a single product because your carrier mix spans several. Your last minute changes arrive by voice and are entered by the controller, so your record of a change is a recollection. Your loading instructions come back signed on paper, hours after departure. Or your qualification and currency evidence lives in a spreadsheet beside the system that lets anyone produce a sheet.

Our position: this is the one aviation category where we routinely advise against building, and the exception is genuinely narrow. It applies to handlers whose product is load control itself, because for them the multi-carrier, multi-system problem is the business, and no vendor is going to solve a problem shaped like that for a single customer.

How to choose a developer for load control software

Ask who on their side will own the correctness of the balance calculation. The right answer names a load control specialist, either yours or one they bring, with type experience. If the answer is that developers will implement from the manual, decline. The calculation is not complicated mathematics and it is unforgiving domain knowledge, and that combination is where confident errors come from.

Ask how they will validate. The only acceptable answer involves recomputing a large historical sample against the existing system and reconciling every single difference, with sign-off from your own specialists before any live use.

Ask what happens when a departure control feed is late or partial, because it will be. The system must refuse to produce a sheet on incomplete data rather than filling gaps with assumptions, and the controller must see exactly what is missing.

Ask about the ramp device experience specifically: gloves, sunlight, rain, and a connection that drops behind an aircraft. Offline with reconciliation is mandatory, and a developer who has not thought about it will deliver something that gets left in the office.

Ask who owns the code and settle it before kickoff. You should hold the repository, the infrastructure accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. In load control this is a safety governance question: the system participates in producing a document the flight crew act on, and you must be able to demonstrate control over how it computes, what changed and when.