From "Draft" to "Immutable": The Anatomy of an Audit-Proof Billing Cycle

TL;DR

An audit-proof billing cycle is one where charges are calculated from recorded operations, an invoice cannot be approved until its billing cycle has closed, and the approved invoice cannot be altered afterwards.

AirportLabs Billing, the aeronautical and commercial billing system from AirportLabs, moves every invoice through that sequence in order: Draft, Generated, Approved, Locked.

Airport finance carries a risk most finance functions never meet. Aeronautical charges are the single largest line in the industry's income: ACI World put global airport revenue at US$194.9 billion in 2024, with aeronautical sources accounting for 54% of it. Every dollar of that is invoiced against something that happened on the apron, to a counterparty with its own accounting team and a right to ask how the number was reached.

A retailer that misprices an order loses a margin point. An airport that misprices a landing fee ends up in a conversation with an airline's revenue accounting team six months later, with a published charging schedule on the table and no clean way to reconstruct what the system knew on the day the invoice went out. The argument is almost never about arithmetic. It is about whether anyone can still show their working.

That is the problem AirportLabs Billing was designed around. Speed is the easy part of automation. What makes a billing cycle survive an audit is that every change of state is deliberate, recorded, and at the point of finality, irreversible.

What this article covers, in short:

• Why aeronautical charges attract more scrutiny than ordinary B2B invoicing
• How an invoice moves from Draft to Generated to Approved, and what each status prevents
• Why an approved invoice should be locked rather than editable
• What soft delete does for contracts that have expired but still matter to an auditor
• How charges tied to AODB records turn a billing dispute into a lookup

What makes a billing cycle audit-proof?

A billing cycle is audit-proof when three conditions hold together: every charge traces to a recorded operation, the approval to issue was given by a named user after the cycle closed, and the approved document has not changed since. Break any one of them and the other two lose most of their evidential value.

Plenty of billing software satisfies the first condition and treats the other two as policy rather than mechanism. Policy is what fails at month-end, when somebody needs the run closed by Friday.

Why does airport billing get scrutinised harder than ordinary invoicing?

Because aeronautical charges are regulated, the counterparties are expert, and the figures come out of the operation rather than off a price list.

ICAO's Policies on Charges for Airports and Air Navigation Services (Doc 9082) set out the principles of cost-relatedness, non-discrimination, and transparency that national charging frameworks are built on, and the companion Airport Economics Manual (Doc 9562) takes those principles down to the level of cost allocation and accounting practice. Airlines know both documents well. IATA's airport charges programme exists partly to hold airports to them, and in Europe, Directive 2009/12/EC on airport charges turns consultation and transparency into a legal obligation for airports above a certain size. An airline that queries a charge is not being difficult. It is exercising a right the framework gives it, and it expects the airport to substantiate the number line by line.

Tax is the second layer. Multi-currency invoicing across VAT and GST regimes already demands care, and the ground is moving: the VAT in the Digital Age package adopted in March 2025 puts the EU on a path to mandatory structured e-invoicing and near real-time digital reporting for cross-border business transactions, built on the European standard EN 16931. In that world, an invoice is not a commercial document you can quietly revise. It is a structured record already transmitted to a tax authority, with its own retention obligations attached.

A billing system that treats invoices as editable rows fails both tests silently, and only at audit.

What actually goes wrong in a manual billing cycle?

The failure is rarely dramatic. It accumulates.

Charges get calculated from a movement extract that somebody exported, filtered, and pasted. A late correction to a turnaround lands after the extract was taken, so the invoice is right according to the file and wrong according to the operation. A contract renewal changes a rate mid-month, and half the cycle bills at the old figure. An invoice goes out, an error surfaces, and the fix gets applied by editing the original rather than reissuing it, so the version the airline holds and the version the airport holds stop agreeing. Multiply that across a group of airports, a dozen handling agents, and a few hundred contracted services, and the annual audit turns into archaeology.

None of that reflects badly on the people doing the work. It is what happens when nothing in the process prevents a step from occurring out of order.

How does an invoice move from Draft to approved?

Through a defined status sequence, and the sequence is the control. A billing cycle in AirportLabs Billing runs against the cycle written into the contract, weekly, bi-weekly, or monthly for the overwhelming majority of agreements. While the period is still open, the invoice sits in Draft and cannot be approved because it has not yet reached maturity. When the period ends, the system moves it from Draft to Generated automatically. That transition is what closes the cycle.

Approval becomes available at the Generated status, not before. From there, the user does one of two things: approve the invoice, or reject it. A rejection is not a dead end. The user corrects the underlying data and regenerates, producing a fresh Generated invoice with the corrected figures.

This control is worth being precise about. Nobody has to remember that the period is still open, and nobody can approve a cycle that has not closed, because the status itself carries that information and the system will not offer approval before it. In a manual process the equivalent judgement is made under month-end pressure by somebody with no reliable way of knowing whether the underlying data has settled. Here the calendar decides when a cycle is closed, and a person decides only whether what came out of it is right. That separation is close to what an auditor means when they ask how the airport knows its revenue is complete and correctly authorised.

Why should an approved invoice never be editable?

Because a document that can still be changed cannot serve as evidence of what was billed.

Rejection and regeneration exist precisely so errors are resolved before approval rather than after. The finance team questions everything it can while the invoice is still a candidate. Once approval is given, AirportLabs Billing locks the result, and the invoice an airline received in March is still, in October, the invoice it received in March.

Locking is also what gives the audit trail its worth. A timestamped record of who changed what only means something if the final state is protected. Otherwise, the trail is a list of edits to a document that can be edited again.

What happens to billing data when a contract expires?

It stops being active. It does not stop existing. That distinction is what soft delete protects.

Contracts expire, handling agents lose concessions, airlines drop routes. The commercial relationship ends, but the record does not, because tax authorities and auditors ask about closed periods routinely. A soft delete model removes an expired contract, service, or counterparty from operational views while preserving the underlying data and its links to every invoice ever raised against it. Nothing is destroyed, nothing clutters the working screens, and retention is measured in the timescales audit works to rather than in the weeks an operational system tends to think in.

Here is the practical test. Years after a ground handler's contract ends, can you open an invoice raised under it and still see the operations behind every line? If not, the airport is carrying an exposure that will surface at the least convenient moment.

Where do the numbers actually come from?

From the operation. This is the part of the chain that is easiest to underestimate and hardest to retrofit later.

AirportLabs Billing calculates charges from operational data held in the AODB and connected airport systems, so a landing fee traces to a recorded movement and a stand charge to a recorded occupancy. The pre-invoice table keeps that lineage visible, showing a detailed breakdown of how service prices are applied for every tariff. Around it sits the contract and service catalogue, where each service carries its pricing unit, currency, and the flight conditions under which it applies.

Visibility is handled separately, and deliberately so. Access to financial data is governed by permissions managed in iAM, the AirportLabs identity and access product, which covers the wider platform rather than contracts and services alone. Keeping that layer outside the billing application is what lets an airport give a handling agent's account manager a different view of the same data a finance controller sees, without maintaining two sets of rules.

That lineage is what turns a dispute into a lookup. When an airline queries a charge, the answer is a record rather than a recalculation, which is a different conversation entirely. It also means billing inherits the data quality of the wider airport platform rather than depending on a monthly export that ages badly.

Questions airport finance teams ask about audit-proof billing

Is an audit trail enough on its own? No. An audit trail records changes. It does not stop someone from changing the final document again. Pairing the trail with a locked invoice state is what makes the record hold up.

What does the Generated status actually mean? It means the billing period defined in the contract has ended and the invoice is complete enough to be judged. Before that, the invoice is still a Draft, and approval is not available. After that, the cycle is closed, and the decision passes to a person.

What happens if an invoice is wrong? It gets rejected rather than edited. The user corrects the underlying data and regenerates the invoice, which is why the correction happens before approval and leaves the approved record untouched.

What is the difference between soft delete and archiving? Archiving moves data somewhere else, usually with its own access route and its own risk of drifting out of sync. Soft delete keeps the record in place and marks it inactive, so the links between an old invoice and the contract behind it stay intact.

Does automation reduce financial control? It depends entirely on where the constraints sit. Automation that removes steps without adding controls reduces it. Automation that closes the cycle on a defined date and locks the invoice after approval increases it.

How does this connect to e-invoicing mandates? Structured e-invoicing regimes assume the invoice you transmit is the invoice of record. A billing system that can still rewrite an approved document is a poor fit for that assumption, whatever format it exports.

Finality is a design decision, not a setting you switch on later

Finance software usually sells flexibility. Airport billing is the case where controlled inflexibility is the point. A cycle that closes on a defined date rather than when somebody is ready, an invoice that can be rejected and regenerated but not quietly edited once approved, and a history that cannot be pruned are all constraints, and they are exactly the constraints that make the output defensible when an airline's revenue accountant, a tax authority, or an external auditor starts asking.

Every billing cycle ends in one of two things: a record you can stand behind, or a file you have to explain. AirportLabs Billing is built for the first.

If you want to know how your current billing process would hold up under that kind of scrutiny, get in touch – we will walk you through the cycle end to end.