Every finance director who has tried to run airport billing out of a corporate ERP eventually hits the same wall. The system that handles payroll, procurement, and the general ledger perfectly well starts to buckle the moment it has to answer a much stranger question: how much does Airline X owe for 47 landings, 12 overnight parking stays, and three diversions last month, priced against a tariff schedule that changed twice during the period? The ERP wasn't built to answer that question, and the workaround — spreadsheets bolted onto the ERP, manual tariff lookups, and a finance team that becomes the human reconciliation engine — is where airport revenue quietly disappears. This isn't a failure of the finance team. It's a mismatch between what a general ledger is designed to do and what airport billing actually requires.
ERPs Are Built for Ledgers, Not Movements
An ERP's core competency is the general ledger: recording transactions, tracking accounts payable and receivable, and producing financial statements that satisfy auditors. That's a well-solved problem, and most ERPs solve it well. But airport billing doesn't start with a transaction — it starts with an aircraft movement. A landing, a departure, a parking event, a fuel uplift. Each of those events carries operational data — aircraft type, maximum takeoff weight, origin and destination, time of day, passenger count — that has to be captured accurately before anyone can calculate what's owed. ERPs have no native concept of a "movement." They wait for someone to translate that movement into an invoice line, which means a human being is standing between the runway and the ledger, manually keying in charges that should have been generated automatically the moment the aircraft touched down.
That translation step is where errors creep in. A landing weight gets transposed. A tariff category gets misapplied. A parking charge starts accruing but nobody notices the aircraft never left, so three weeks of fees go unbilled. None of this shows up as a bug in the ERP, because the ERP is doing exactly what it was designed to do — recording whatever numbers it's given. The problem is upstream, in the gap between the airfield and the accounting system.
Tariff Complexity the General Ledger Was Never Designed to Hold
Airport tariffs are not flat rates. They vary by aircraft weight bracket, by domestic versus international routing, by time of day, by aircraft category, and often by bilateral agreements specific to a single carrier. Many airports also run tiered incentive programs to attract new routes, which means the same landing fee formula can produce different numbers depending on how long an airline has been flying that route. A general ledger has no mechanism for holding that logic. At best, someone builds a tariff table in a spreadsheet and manually applies it before charges get entered into the ERP. At worst, the tariff logic lives in someone's head, and when that person leaves, so does the institutional knowledge of how charges are actually calculated.
This is exactly the gap a purpose-built airport revenue management platform is designed to close — tariff rules, weight brackets, and route incentives get encoded once and applied automatically to every movement, so billing accuracy doesn't depend on one analyst remembering the exceptions.
Actual vs. Estimated Charges: The Discrepancy ERPs Can't Catch
Most airports bill on estimated charges first — based on flight schedules and filed aircraft data — then reconcile against actual operational data later. That reconciliation step is where a lot of revenue either gets recovered or quietly written off, depending on whether anyone has the bandwidth to chase it down. An ERP has no way to flag that an aircraft's actual landing weight differed from its filed weight, or that a flight scheduled as a passenger service actually diverted and became a cargo movement with a different fee structure. Those discrepancies only surface if someone is comparing operational records against billed amounts line by line, and at a busy airport handling hundreds of movements a day, that comparison simply doesn't happen at the volume it needs to.
The airlines being billed, meanwhile, are running their own reconciliation processes and disputing charges that don't match their internal records. Airports without a systematic way to reconcile actual against estimated charges end up negotiating from a position of uncertainty — unable to say with confidence whether a disputed invoice is accurate, because the underlying movement data was never captured in a form that supports that kind of verification.
Passenger and Route Reconciliation Adds Another Layer
Beyond aeronautical charges, airports also need to reconcile passenger counts and route-specific fees against what airlines actually report and pay. A general ledger can hold the final invoice amount, but it has no visibility into whether the passenger numbers an airline reported match load data from the terminal, or whether a codeshare flight was billed to the correct operating carrier. This is a genuinely specialized reconciliation problem, and treating it as a generic accounts-receivable task means most of the discrepancies simply never get caught. Purpose-built airline airport billing tooling exists specifically to close this loop — matching operational passenger and movement data against airline-reported figures before an invoice goes out, not after a dispute comes in.
What This Actually Costs
The revenue lost to ERP-based billing rarely shows up as a single dramatic number. It shows up as a one or two percent gap between what should have been billed and what actually was, spread across thousands of movements a year. It shows up as finance staff spending days each month reconciling spreadsheets instead of doing higher-value analysis. It shows up as audit findings that take weeks to resolve because the underlying movement data was never captured in an auditable form to begin with. None of that is a line item anyone budgets for, which is exactly why it persists.
The fix isn't asking your ERP to do something it wasn't built for. It's recognizing that aeronautical billing is an operational discipline with its own data model, its own tariff logic, and its own reconciliation requirements — and giving it a system that treats those as first-class problems rather than an afterthought bolted onto the general ledger.
