Airline Revenue Accounting Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why do revenue accounting projects turn into a big bang replacement?

Because the function feels indivisible. Sales feeds matching, matching feeds proration, proration feeds interline billing, billing feeds the ledger, so the instinct is to replace the whole chain at once. That is the biggest scope failure in this category, and it is dangerous in a way that is specific to revenue accounting: this function produces a line in your audited accounts. You cannot cut over on a single date and hope, and any plan that treats parallel running as a contingency rather than a phase is not a plan.

The second version of the same mistake is starting with proration because it is the intellectually interesting part. Proration is where the domain expertise shows, so teams gravitate to it. But the money that is currently disappearing is mostly in the matching residue, and a proration engine sitting on top of a matching process that still leaves an unexplained pile has not fixed anything you can show a finance director.

The fix is sequencing. Build the coupon level document model and the matching engine first, leave proration on the incumbent for one more phase, and prove the new system against the old on real periods before anything is switched off. Budget several reporting periods where both systems produce output and a reconciliation report explains every difference, line by line. Carriers that skip this find their differences during an audit rather than during a project.

What goes wrong when you migrate open documents and reissue chains?

A document is not an invoice. It is a set of coupons, each with its own status and value, and it can be partly flown, partly refunded, partly exchanged into a new document carrying residual value, and partly still sitting as an open liability. A reissue links forward and backward, and a refund can land against the second document while the original sale is what the money came from.

Migration is where models collapse. Loading balances is easy. Loading open documents with their full event history is often harder than building the new system, because the legacy data may record the current state without the sequence that produced it. When that history is lost, you can no longer trace residual value to an original sale, which means you cannot defend a refund calculation or explain a liability balance to an auditor. Teams discover this after cutover, when the first complicated reissue arrives and there is nothing behind it.

The fix is to insist that any developer whiteboards a reissue before contracts are signed: original document, coupons partly flown, residual value carried forward, later refund against the new document. If their model cannot represent that without losing the link to the original sale, stop there, because everything downstream will be wrong. On migration, load event history rather than end state wherever it exists, and where it does not, record explicitly that the history is unavailable rather than synthesising a plausible one. An honest gap is defensible. A fabricated sequence is not.

Why do sales, flown data and settlement feeds break after launch?

Revenue accounting consumes more external feeds than almost any other airline system. Flown coupon data from departure control. Sales from agency settlement plans, from your own direct channels, from partners. Interline billing files in and out of industry settlement. Refunds and exchanges from multiple points of origin. Each of those is maintained by somebody else.

They break in ways that produce residue rather than errors. A departure control upgrade changes how a code share sector is reported and your matching starts missing a category of coupons. A new distribution channel goes live and its sales file uses a slightly different document numbering convention, so its records land in the exception queue in volume. A partner changes their billing file format at their own project's convenience. A currency conversion source changes its rounding. None of these throw an exception. They all make the unmatched pile bigger, and because that pile is normal, nobody investigates a change in its shape.

The fix is reason coding and trend monitoring. Every exception must carry a reason code, and the mix of reason codes should be monitored over time, because a new feed problem shows up as a change in the mix long before it shows up in the total. Alert on absence as well: a settlement file that did not arrive on the expected day is a deadline risk, not just a missing file. And validate each incoming feed against expected record counts and structure on arrival rather than at the point of use, so the failure surfaces the same day it happens.

What happens when settlement deadlines and rejections are not managed?

This is the operational gap that costs the most and shows the least. Interline billings must be submitted inside the industry billing window. Rejections received from partners must be answered inside a correspondence window. A system that presents work as a queue ordered by arrival will always show the team what came in today, never what expires this week, and the items that expire are the ones that silently become revenue you never collect.

The second half of the problem is triage. A team facing two thousand rejections cannot work all of them, so they work the ones at the top of the list. Without value based ordering, the effort goes wherever the sort happens to land rather than where the recoverable money is.

The fix is to make the industry calendar the organising principle of the workflow rather than a note in a procedure document. Every billing carries its period and its deadline. Every rejection carries its correspondence deadline and its value. The default view is what expires soonest, weighted by amount, and the system reports at period close how much value expired unworked. That last number is the diagnostic. If nobody in your building can tell you how much revenue was lost last year to rejections that timed out, the answer is not zero, and it is recurring.

Should you build custom or configure what you already own?

Buy, and stay bought, if you fly point to point with no interline partners and no code shares, selling mostly through your own channels. Accelya Revera and Hitit Crane Revenue Accounting are serious systems built by people who understand this domain, and for a conventional carrier either will handle the core cycle competently. A custom build in that situation is an act of self harm, and the discovery phase alone would cost more than the licence.

Before building, check how much of your incumbent is actually configured. Special prorate agreements handled as manual adjustments are sometimes handled that way because nobody ever configured them properly, not because the product cannot hold them. The same is true of rejection triage rules and exception queues that were set up during implementation and never revisited.

Build, or build alongside, when interline is a material share of revenue and your bilateral agreements keep being handled as adjustments, when the unmatched coupon pile is written off annually with no cause analysis, when you need revenue recognised at coupon level rather than at ticket level, or when nobody can answer how much was lost to expired rejections. The most common shape we recommend is not replacement at all: keep the incumbent for the standard cycle and build the matching, exception analytics and deadline management around it.

How do hidden costs get into the quote?

Partner count and agreement complexity come first. The number of interline and code share partners, and how many carry special prorate agreements, drives the cost of this category far more than passenger volume does. A carrier with ten partners and two bilateral deals and a carrier with sixty partners and twenty are not running the same project.

Historical migration is second and is routinely underpriced. Migrating open documents with full event history is frequently harder than the build. Scope it as its own piece of work with its own investigation phase, because the answer depends on what your legacy system actually retained, which nobody knows until someone looks.

Parallel running is third, and it is not optional. Several reporting periods of dual output plus a reconciliation report is real cost in both engineering and finance team time, and quotes that omit it are quoting a different, riskier project.

Fourth is channel data quality. Every sales channel is a separate mapping and a separate argument about identifiers, and the quality is usually worse than the revenue accounting team believes because they have been absorbing it manually for years. Fifth, and easily forgotten, is tax, fee and charge handling. If your current model folds these into fare value, separating them is a data remediation project rather than a field change.

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

The working build starts from the coupon level document model and refuses to compromise on it. Document, coupon, status, value, and a complete history of every event that changed any of them, with reissues linking in both directions. Everything else in revenue accounting is downstream of that single decision, and no amount of later engineering recovers from getting it wrong.

The second difference is matching designed around near misses rather than exact keys. Flown data and sales data disagree on document numbers, dates and carrier codes more often than anyone admits. You want tiered rules with confidence scoring and an exception queue with reason codes, because the value of the system is in what it resolves at the later tiers, not in the exact matches you were already getting.

The third is proration agreements held as versioned objects with effective dates and market scope, so a proration challenged eighteen months later can be reproduced exactly as computed under the terms that applied then. Editing an agreement in place destroys that, and it is the kind of destruction nobody notices until a partner disputes a claim.

The fourth is that the system closes the loop back to commercial. Revenue per coupon by route, by partner and by channel, with the write off pile broken down by cause rather than presented as a total. The first time revenue accounting tells a network planner that a particular interline market consistently prorates badly, it stops being a back office cost. Settle code and infrastructure ownership in writing before kickoff; at Digital Heroes the client owns it from the first commit, which for a system producing a line in your audited accounts is a control matter rather than a commercial one.