Revenue per Flight reliably with Leon and Grafana: from KPI definition to an auditable data chain

Revenue per Flight sounds like a simple management KPI: one number that makes performance comparable across flights, customers, aircraft and time periods. In reality, the KPI often fails not because the idea is wrong, but because the data foundation is. When flight operations and billing are stitched together from different system snapshots, Excel exports or inconsistent filters, discussions revolve around “whose number is correct” instead of what to change.

For decision-makers in the DACH mid-market, the target picture is clear: an end-to-end, auditable data chain from the journey log to the invoice—and reporting that produces the same results at every month-end, reproducibly.

Why Revenue per Flight as a KPI often disappoints

Revenue per Flight quickly turns into a “felt” metric when there is no binding logic and no stable data provisioning. Typical symptoms:

• Different report filters and export times lead to different results

• Corrections (credit notes, cancellations, recharges) change figures retroactively, without reports following through cleanly

• Unclear definitions (leg vs trip vs rotation) make comparisons meaningless

For managing directors and department heads, this is critical: without a reliable baseline, it remains unclear whether an effect is operational, commercial—or purely a reporting artifact.

Clean definition: what “Revenue per Flight” actually means

Before building data models and dashboards, you need an unambiguous KPI definition. Two points are decisive.

1) Revenue is not contribution margin

“Revenue per flight” is not automatically “profit per flight.” Both perspectives are useful—but they should be managed separately.

• Revenue per Flight (revenue): reflects sales and pricing performance

• Contribution per Flight (contribution margin): reflects profitability (requires a cost logic)

2) What counts as a “flight”?

In practice, you must define which unit counts:

• Leg (a single segment)

• Trip/rotation (multiple legs as one continuous assignment)

Without this decision, values are not comparable across teams, periods or aircraft.

Minimum standard for a management-ready KPI

To make Revenue per Flight fit for steering, the definition should at least include:

• Period logic: by flight date, invoice date, or a clearly defined cut-off/accrual rule

• Currency logic: conversion method and reference date defined

• Status logic: which statuses count (e.g., flown, invoiced, cancelled)

• Unique flight ID: the bracket between journey log and billing

Where numbers typically diverge (and why)

Across flight ops and billing, deviations usually arise in the same places:

• Period shift: flight date and invoice date fall in different months—revenue “moves” in reporting

• Cancellations and corrections: revenue is changed retroactively, while exports are only snapshots

• Duplicates and versions: the same flights or invoices are exported multiple times or filtered differently

• Inconsistent marking of empty legs: complicates sales and utilisation analysis

• Missing stable fleet reference: revenue is not cleanly linked to registration/type

Business impact: teams spend time reconciling numbers instead of deriving measures (pricing, sales focus, fleet allocation).

Leon Software as a data source: what you actually need

Leon Software provides the operational backbone (flight lists, journey-log data) and—depending on setup—also the billing view. For Revenue per Flight, the following are typically relevant:

• Operations data: legs, times, aircraft/registration, status

• Billing data: invoices incl. line items as well as quotes, recharges and credit notes

• Master/structural data: fleet, customers, status definitions

What matters less is whether the data exists, and more whether it can be retrieved in a structured, historised and repeatable way—so reporting does not depend on the coincidence of a manual export.

Solution building block: Leon2DB as a reliable data pipeline

This is where the Arkcanis tool Leon2DB comes in: an automated data pipeline that imports data from the Leon GraphQL API into a PostgreSQL database. The goal is a stable reporting foundation on which Revenue per Flight can be calculated reproducibly.

To keep management reporting trustworthy, three principles are central:

• Stable access: automated token handling for reliable API queries

• Controlled imports: time-window imports (slices) to load data deliberately and repeatably

• Clean results: deduplication via IDs so repeated imports do not create double counting

Additional value comes from consistent post-processing—for example linking cancellations/corrections and assigning revenue to flights in a traceable way.

Visualisation with Grafana: turning data into steering

Once the data chain is in place, Revenue per Flight becomes actionable through clear dashboards. Grafana enables a single view for management, ops and finance—instead of parallel Excel logics.

Proven dashboard building blocks:

• Revenue per Flight by period, customer, route, aircraft type/registration

• Empty-leg transparency: share, trend and sales potential per base/fleet

• Correction monitoring: credit notes, recharges, cancellations—including traceable logic

Key for decision-makers: a small set of decision-relevant visuals—and documented definitions directly in the dashboard, so the KPI is interpreted consistently in reviews.

Implementation plan in 4 steps (pragmatic, without overhead) 1) Lock down the KPI definition

Define leg/trip logic, revenue logic, period logic and responsibilities between ops and finance.

2) Set up the data pipeline

Configure Leon2DB (time windows, deduplication, import intervals) and validate the data model and mappings.

3) Establish quality rules

Define plausibility checks (e.g., missing flight IDs, unusual deviations, cancellation chains) and set an approval process for KPI versions.

4) Introduce dashboard and review cadence

Build Grafana boards, plan month-end checks and maintain an action list (pricing, empty-leg sales, fleet allocation).

Result: a reproducible Revenue per Flight instead of ad-hoc evaluation.

What decisions become possible with clean Revenue per Flight

With consistent Revenue per Flight, management decisions become more robust:

• Pricing & quote quality: which customers/segments systematically underperform?

• Fleet allocation: which aircraft show weak revenue performance per leg/flight hour (basis for the next step: cost view)?

• Empty-leg sales: where does prioritisation by base/fleet actually pay off?

• Process quality: use credit notes as a signal for issues in quoting, ops or billing

An often underestimated benefit: less alignment effort between management, ops and finance—because the KPI does not need to be re-explained every month.

Conclusion: Revenue per Flight is only as good as the data chain behind it

Revenue per Flight can be a strong steering metric—if definition, data chain and reporting logic fit together. With Leon as the operational source, a stable pipeline (e.g., Leon2DB) and clear Grafana dashboards, a “discussion KPI” becomes a reliable management instrument.

Next step

If you want to establish Revenue per Flight reliably in your organisation, start with a clearly scoped KPI workshop (definition + cut-off logic) and a short data check in Leon. Based on that, you can implement a pilot dashboard quickly, validate it in the first month-end close, and then scale it step by step across fleet, bases and customer segments—until the KPI is not just reported, but consistently used to steer decisions.

---

About Arkcanis Consulting

Arkcanis Consulting GmbH is the specialized advisory unit of the Arkcanis Group. We design scalable process and data architectures for airlines, AOCs, operators, and technology-driven organizations — with a clear focus on aviation engineering, Leon integrations, Atlassian architectures, ETL pipelines, and real-time dashboards.

As the founder of catworkx GmbH — one of the largest Atlassian partners in the DACH region — Oliver Groht brings more than 25 years of experience in Jira and Confluence architecture, process consulting, and enterprise-wide scaling. He combines this background with deep technical expertise in Leon GraphQL, data engineering, Grafana, and Flight Ops workflows.

The result: measurable, transparent, and resilient structures that enable operational excellence and strengthen strategic decision-making at the management and C-level.

Contact us