Aircraft Lease Management Software Problems: The 7 That Cost Lessors Real Money

Why does lease clause modelling always overrun scope?

Projects get scoped from a sample lease and a rate table. That is the mistake. A lease is not a rental agreement with a number in it. It defines a rent schedule that may step, supplemental rent per flight hour or per cycle or per month against separately reserved components, escalation against a published index with a stated lag and base date, what the lessee may claim and with what evidence, and the condition the aircraft must return in. Every one of those clauses was negotiated, and the next lease uses different words for the same idea.

So the scope written as configure the reserve rates meets a portfolio where one lessee accrues airframe reserve monthly and engine reserve per flight hour with a minimum monthly amount, where landing gear escalates on the delivery anniversary rather than the calendar year, where life limited parts accrue per cycle at rates differing by part group, and where an engine claim is capped at the amount accrued for that serial rather than the aircraft.

The fix is lease discovery as a funded phase before implementation. Somebody reads the actual documents and turns negotiated clauses into a formal model, and that is legal and commercial work as much as engineering. Start with your ten most recent leases rather than your oldest ten, because the recent ones reflect how your team trades now. Then treat each remaining lease as either fitting an existing pattern or being a new pattern with its own days attached.

What goes wrong migrating accrual history and utilisation records?

The workbook is the source, and workbooks lie by omission. Three problems surface reliably.

First, the spreadsheet balance has drifted from what the lease says should have accrued, usually because an escalation cell was updated late or a rate change was applied from the wrong date. Migration reveals it, and every difference is a commercial conversation rather than a data fix, because the lessee has a view.

Second, historical utilisation is recorded at aircraft level only. If reserves are being restructured to serial level, the history cannot simply be split, because nobody recorded which engine was on wing in which month. Reconstructing that from technical records is genuinely slow work.

Third, novations and portfolio transfers moved aircraft between owning entities and the accrual history did not always travel cleanly, so the balance in the workbook and the balance in the entity accounts differ.

The workable approach is to migrate opening balances as at a cutover date, agreed and signed off by finance, rather than attempting to rebuild history from first principles. Keep the legacy workbooks as the record for periods before cutover, and make the new system authoritative from that date forward. Where a specific aircraft has a live dispute or an imminent redelivery, do the deeper reconstruction for that asset only. Attempting it portfolio wide is how these projects lose a quarter.

Why do utilisation feeds and technical records integrations break after launch?

Utilisation reports are the fragile input, because they arrive from operators in whatever format the operator feels like sending. Columns move. A scanned page replaces a spreadsheet. An operator under commercial stress simply stops reporting.

The failure after launch is rarely a crash. It is silence. Accruals get estimated because no report arrived, the estimate persists, and six months later the true up is a negotiation instead of a calculation. The second failure is subtler: a report arrives with plausible looking numbers against the wrong engine serial after a swap the operator did not flag, and it posts cleanly.

Technical records integration breaks differently. It is usually treated as a phase two line item and quietly deferred, so claims assessment continues to depend on someone opening records manually, which was the original problem.

The fixes are procedural as much as technical. Assume manual formats forever and build ingestion that absorbs spreadsheets and documents with an exception queue, rather than mandating a template fifty operators will never adopt. Run plausibility checks against the previous report and fleet averages before anything posts. Alert on the report that did not arrive, with an ageing view by lessee, because a missing report is a commercial signal as well as a data gap. And scope technical records integration as its own phase with its own budget rather than as a bullet.

What happens when return condition monitoring is not covered?

This is the gap that turns into a cheque. The lease states minimum remaining green time, check status, records completeness for life limited parts and usually a compensation formula for shortfalls. If the position is only computed at redelivery, the calculation tells you what you owe rather than what you could have avoided.

What actually happens without it: an aircraft comes back with less remaining life than the lease requires, the compensation formula produces a number, and you either accept a payment that does not cover the shop visit or you argue. Meanwhile the aircraft cannot go to the next lessee until the work is done, so you carry it. None of that was unforeseeable. It was unmonitored.

There is a records dimension too. Back to birth traceability on life limited parts is a return condition in its own right, and gaps found at redelivery are expensive because the parts may be unusable to the next operator regardless of their physical condition.

The fix is to compute the return position monthly against every lease, not at redelivery, and surface aircraft trending toward a shortfall with the projected compensation and the projected cost to remedy side by side. That gives the commercial team time to plan a shop visit, negotiate an extension or price a transition while options still exist. Make records completeness a tracked field rather than an assumption, so a gap is a task rather than a discovery.

Should you build custom or configure what you already own?

Configure, if your leases share a shape. AerData LEASE is purpose built for this industry and understands reserves, utilisation and technical asset structure in a way no general leasing tool does. Odessa is a strong equipment leasing platform with real depth on contract accounting and portfolio administration. If your portfolio came from one or two sale and leaseback programmes and the clause structure repeats, either will carry you and a build would be waste.

Configure also if your business is primarily trading aircraft rather than managing them through a full term. Then the asset, the appraisal and the transaction matter more than the accrual engine, and money spent on a bespoke reserve system is money not spent on records.

The build case is not about size, it is about how many of your leases have migrated out of the packaged system into spreadsheets. That migration is the diagnostic. Lessors accumulate unusual clauses because unusual clauses win deals, and over time the product holds the tidy leases while the interesting ones live beside it. When a claim or a redelivery dispute requires evidence from the product, the spreadsheets and the records team all at once, the coordination layer is the thing you are missing.

A hybrid is often right: keep the packaged system for portfolio administration and accounting, and build the per contract calculation, claims workflow and return condition monitoring around it.

How do hidden costs get into the quote?

Distinct lease structures are the first. Quotes price the model, not the population, and every lease that will not fit an existing pattern is real engineering. Count your structurally different leases before you sign, not your aircraft.

Novations and portfolio transfers are the second. Moving an aircraft between owning entities has to preserve accrual history and produce clean accounting on both sides, and it is usually mentioned late because it happens irregularly.

Multi currency and multi entity structures are the third. Special purpose vehicles, intercompany positions and reporting in more than one currency each add work that looks like configuration and is not.

Technical records integration is the fourth, and it is a substantial project of its own rather than a connector.

Lender and investor reporting is the fifth. Where aircraft sit in financing structures, that reporting is contractual, it runs on the lender's schedule and format, and it is normally compiled by hand until someone automates it. It is also the item most often discovered after go live.

Ask for those five as named line items with days. Then ask what the recalculation story is, because the ability to reproduce a prior period's accrual exactly as it was computed is engineering that never appears in a demonstration.

What separates a build that works from one that fails here?

The builds that work model the contract as an executable specification rather than a rate table. Each lease carries its own accrual basis, rate, escalation formula, index source, base date, caps, floors and claim eligibility, versioned so that a change made this year does not silently rewrite last year's accruals. Amendments are effective dated and prior periods recalculate on demand to what they were, not to what the current terms would produce.

They hold reserves at the level the lease protects. Airframe by check interval, each engine by serial with performance restoration and life limited parts separated, landing gear by position, auxiliary power unit separately. Aggregating at aircraft level is the shortcut that fails at claim time, and it is very expensive to unpick afterwards.

They build the exception queue before the happy path. Operator data will be late, wrong and inconsistent for the life of the system, so the workflow around bad input is the product rather than an edge case.

They put claims and evidence in one place. The submitted invoice, the workscope, the technical assessment, the balance check and the approval sit against the reserve, because that record is what ends arguments two years later when the people involved have moved on.

And they settle ownership before kickoff: repository, cloud accounts, and the right to bring in another firm. The system holds accrual history on assets your lenders have security over, and that history has to outlive any vendor relationship.