Airport billing failures rarely make headlines, but their consequences do. Aeronautical charges, landing fees, passenger charges, and related tariffs generated 53.6% of global airport revenue in 2023, roughly $79 billion, according to ACI World's 2025 Airport Economics Report. When airports and airline partners dispute those charges, the fights are some of the costliest and most relationship-damaging in the industry.

The root cause is rarely a wrong number. It's a missing evidence trail. Billing processes that work fine day to day often fail an audit anyway, not because the charges are wrong, but because the systems behind them can't reconstruct a complete, tamper-proof record for regulators, airline partners, and internal auditors.

ICAO's Policies on Charges for Airports and Air Navigation Services (Doc 9082) builds airport charging on four principles: non-discrimination, cost-relatedness, transparency, and consultation with users. In practice, that means airports need to show how a charge was calculated, under which tariff, and against which contract, whenever a regulator or airline partner asks. Spreadsheets and PDF exports rarely hold up to that kind of scrutiny.

AirportLabs Billing was built to close that gap at the architecture level: a four-stage billing lifecycle, from draft to immutable, that makes financial integrity a property of the system rather than a matter of procedure.

The Four Stages of an Audit-Proof Billing Cycle

AirportLabs Billing structures every cycle through four sequential stages, each with defined entry conditions, outputs, and rules about what can and can't be changed. Together, they form a chain of custody for financial data that holds up under audit, regulatory review, or a partner dispute.

Stage 1: Draft

This is the working environment. Charge calculations run against live operational data, tariff applications are verified, and discrepancies are resolved. Draft is the only stage where data can be freely edited: charges added, amended, or removed. Nothing here is a commitment yet.

That flexibility is deliberate. Fixing an error costs nothing in Draft and costs a lot after approval, which is why service organization control frameworks like ISAE 3402 and SSAE 18 test for a clear line between who prepares a financial record and who authorizes it.

Stage 2: Under Review

Once submitted, the cycle becomes visible to approvers, but the team that prepared it can no longer edit it. That separation is the four-eyes principle: no single person can push a charge through unchecked, a standard control against error and manipulation across banking, auditing, and financial reporting regulation. Every query, return-to-draft decision, and approver action is logged with a timestamp and user identity, so the review process itself is auditable, not just its outcome.

Stage 3: Approved

This is the critical control. The system enforces one non-negotiable rule: a billing cycle can't be approved until it's complete. Every required charge type must be present, every tariff matched to a valid contract, and every calculation passed. If any condition is missing, nobody can push it through, regardless of role or permission level.

That matters because most incomplete sign-offs happen under time pressure, not because someone missed a requirement, but because a deadline forced a decision before the checks were finished. The gate removes that risk. Once a cycle passes, it becomes read-only: a financial record, not a working draft.

Stage 4: Immutable

Once invoices are generated and the ERP transmission completes, the cycle locks permanently. No user, at any level, can modify it. It functions as a legal document. EU VAT rules and HMRC's Making Tax Digital standards both require that issued invoices remain in a form that nobody can retrospectively alter, and AirportLabs Billing meets that requirement through its architecture, not through a policy that someone could override.

‍

Soft Delete: Preservation by Architecture

What happens when a contract expires, or a billing relationship ends? In most systems, records get purged. For financial compliance, that's a liability, not a cleanup.

AirportLabs Billing uses soft delete throughout instead. Expired contracts get flagged as inactive, so they disappear from the day-to-day workflow, but they stay fully intact in the data store. Every charge ever raised under that contract, every cycle it went through, every invoice it produced, all of it remains queryable and reportable.

Most national tax authorities require financial records to be kept for five to seven years, sometimes longer, depending on the jurisdiction. Soft delete satisfies that automatically, as a property of the architecture rather than a separate archiving process someone has to run. If an airline queries a charge from 18 months ago under a contract that's since been renegotiated, the original terms, tariff, calculation, and approved invoice show up in their exact historical form. If a civil aviation authority exercises its right to examine billing records, the answer is there, years after the relationship ended.

‍

ERP Integration: The Audit Trail Across System Boundaries

An immutable billing record only holds its value if that integrity survives the move into the airport's broader financial infrastructure. The risk in any ERP integration, whether SAP, Oracle, or Microsoft Dynamics, is translation loss: the point at which the audit trail in the billing system is severed from the summarized journal entry in the ERP.

AirportLabs Billing prevents that with a reconciliation reference on every ERP transmission: a unique identifier that maps each ERP entry back to its specific, immutable billing cycle. Analysts covering financial data integration, including Gartner, treat bidirectional traceability, from the financial statement entry back to the originating transaction, as a baseline requirement for audit-ready systems. AirportLabs Billing provides it natively, without a separate reconciliation project.

‍

The Human Layer: Segregation of Duties

Architecture prevents accidental error. Segregation of duties protects against deliberate manipulation, and it's one of the foundational controls in COSO's Internal Control, Integrated Framework, the standard most internal audit functions use to assess financial controls.

In AirportLabs Billing, the roles stay separate by design: the team that prepares a cycle can't approve it, the approver can't edit the underlying data, and the finance director who authorizes ERP transmission can't modify the approved record. The system enforces these boundaries itself. Every action, across every role, gets logged: user identity, timestamp, data state, in an audit log that is itself immutable.

‍

Finality You Can Trust

The move from Draft to Immutable is a legal and operational commitment. The number on the invoice reflects a verified, approved, unalterable record of what was charged, under what authority, and against what contractual basis.

Regulatory scrutiny is tightening. Airline partners are asking for more charge transparency. Internal audit functions are raising the bar on revenue integrity. Against all three, that guarantee isn't a bonus feature. It's what makes a finance team's numbers defensible when someone asks hard questions.

‍

Frequently Asked Questions

What makes a billing cycle "audit-proof"?

A billing cycle is audit-proof when every charge traces back to its calculation, tariff, and contractual basis, and the record locks into a form nobody can retroactively change. AirportLabs Billing enforces this through four stages: Draft, Under Review, Approved, and Immutable, each with its own rules about what can be edited and by whom.

Why can't an approved billing cycle be edited?

Once a cycle passes the Approved gate, it becomes a financial record instead of a working document. Editing it after that point would break the chain of custody that regulators and airline partners rely on to verify how a charge was calculated.

How long do airports need to keep billing records?

Retention periods vary by jurisdiction, but most national tax authorities require five to seven years, sometimes longer. AirportLabs Billing's soft-delete architecture preserves every charge, cycle, and invoice by default, so the record is available whenever a regulator or airline partner asks.

What is the four-eyes principle in billing approval?

It's a control that requires two people, the preparer and an independent approver, to review a financial transaction before it's finalized. AirportLabs Billing enforces this structurally: the team that prepares a cycle can't approve it.

‍

Want to see this process and architecture in action?

Book a personalized AirportLabs Billing demo and bring your toughest audit scenario.