Running a Flight School With Externally Managed Aircraft: Scheduling and Billing When You Don't Own the Fleet

Ask a software vendor to picture a flight school and they will picture a fleet: a row of aircraft the school owns, on the school's ramp, managed by the school, billed to students on the school's terms. Most flight-school software is built for that picture. But a large and growing number of schools do not fit it at all. They deliver world-class instruction on aircraft they do not own — aircraft owned and managed by other people entirely.

The instruction is the school's product; the aircraft are sourced. Sometimes from a single owner or a local FBO; increasingly from several different owners at once, each of whom manages their aircraft their own way. The school's value is the training — the syllabus, the instructors, the student outcomes — not the ownership of a depreciating airframe. It is a lean, capital-light way to run a school, and for many operators it is the only way the numbers work.

The trouble is that this model collides with the assumptions baked into most management software. Systems designed around "your fleet, your ramp, your Hobbs meter, your single set of rates" struggle the moment the aircraft belong to someone else, live in someone else's scheduling system, and have to be billed and reconciled per owner. The result is that some of the most operationally sophisticated schools end up wrestling their software instead of being served by it. This post is about what that model actually requires — and why the answer is configurability, not another rigid template.

The externally-managed-aircraft model is not a fringe case; it is a family of common arrangements that share one trait — the school instructs, someone else owns the metal.

The simplest version is the instruction-only school that rents its aircraft from an FBO or a single owner: the school books the aircraft it needs, its instructors teach in them, and the school bills the student for the whole experience. A step up in complexity is the school sourcing from multiple owners at once — two, three, or more individuals or entities whose aircraft the school uses, each with a different rate, a different agreement, and often a different way of tracking and scheduling their aircraft. There is the leaseback arrangement common to clubs and small schools, where an owner buys an aircraft and leases it to the operation under a written agreement that defines the hourly compensation and who pays for what. And there is the hybrid: a school that owns a couple of aircraft and rents the rest, running both models side by side.

Running through several of these is a further wrinkle: instructors who effectively manage their own training — independent or semi-independent CFIs who bring their students, use the school's or an owner's aircraft, and need the school's system to keep training records and billing straight without pretending they are salaried line instructors on a company fleet. In every one of these variants, the school needs a system built around the training and the student, with the aircraft treated as a sourced, billable resource rather than an owned asset it fully controls. That inversion — student and instruction at the centre, aircraft as an external input — is exactly what generic fleet-first software gets backwards.

Here is the operational fact that generic software ignores: when the aircraft belong to other people, those people very often have their own scheduling systems — and if the school sources from several owners, it is dealing with several different systems at once, none of which it controls. An owner may run their aircraft's calendar in one platform; a second owner in a spreadsheet; a third in a different tool entirely. The school cannot simply command everyone onto its own system, because it is the guest, not the fleet operator.

That means the realistic goal is not to replace the owners' scheduling — it is to run the school's own operating layer alongside it. The school needs its own home for the things that are genuinely the school's: the student roster, training records and progression, instructor management, and above all the billing. Aircraft availability may be governed elsewhere, but the training relationship and the money are the school's to manage, and they cannot live in an aircraft owner's booking tool.

The practical workflow becomes a coexistence: aircraft time is arranged with (or within) the owner's system, and the school records the lesson, the training outcome, and the charges in its own. Trying to force this into a single-fleet management tool that assumes the school owns and schedules everything produces constant friction — the tool wants to be the source of truth for aircraft it has no authority over. The right mental model is a school operating layer that is deliberately comfortable being one of two systems, capturing what it needs from a flight regardless of where the aircraft slot was booked. A school evaluating tools for this model should ask a blunt question: does this software insist on owning the fleet's schedule, or is it content to run the training and billing layer over aircraft it doesn't control?

Scheduling coexistence is awkward; billing is where the model genuinely breaks generic software. When you own your fleet, billing is simple in structure: one owner (you), one set of rates, one Hobbs-based charge to the student. When the aircraft are externally managed, every one of those assumptions falls away.

First, you have to bill the student for two different things that come from two different places: the instruction (yours) and the aircraft (someone else's). Those are naturally separate line items with separate economics — and they need to be visible as such, both to the student who wants to understand their invoice and to your own accounting. This is the itemised-billing problem we have written about in the context of transparent, itemised flight pricing, and it is acute here: instruction, aircraft, fuel or surcharges, and fees each want to be their own line.

Second, when the aircraft come from multiple owners, each owner has their own rate and their own agreement, and you owe each of them an accurate accounting of how much their aircraft was used and what they are owed. The school effectively sits in the middle: it charges the student, and it reconciles and reports back to each aircraft owner. A system that models only "your fleet" has nowhere to put "owner A's aircraft flew 6.2 hours this month at their rate, here's their statement." Per-owner usage reporting and reconciliation is not a nice-to-have in this model — it is the core of keeping the aircraft owners happy enough to keep supplying aircraft. Lose an owner's trust on the money and you lose access to their aircraft, which is the same death-spiral dynamic that threatens clubs and leaseback arrangements.

There is a deeper billing assumption hiding in most flight-school software, and it surfaces hardest in the externally-managed model: the billing basis itself. In much of the market — US-first software especially — billing is hard-wired to Hobbs time, the elapsed time from engine start to shutdown that is the standard rental-billing unit at most American schools. It is so standard that many systems treat it as the only option.

But Hobbs is a convention, not a law of nature. Other operations bill on tach time, which tracks engine revolutions and typically runs lower than Hobbs. Many schools outside the US, and any operation that has to match an owner's lease terms, bill on block time — measured block-to-block, the way civilian flight time is logged internationally — rather than engine time. Others sell training as prepaid block-hour accounts that draw down as flights are flown. And the choice interacts with the wet-versus-dry question of whether fuel is in the rate. The right basis is whatever matches how the school operates and what its aircraft-owner agreements specify — and when the aircraft come from several owners, the school may genuinely need to bill on different bases for different aircraft.

The point is not that block time is better than Hobbs. The point is that the software should not be the thing that decides for you. A school forced onto Hobbs because that is all its tool supports is letting a software limitation override its own operating model and its owners' lease terms — a tail-wags-dog situation that gets untenable the moment an owner's agreement is written in block time. The billing basis is a business decision. The system's job is to let you configure it, per aircraft if necessary, and then apply it consistently — not to impose one convention and make everything else your problem to work around.

Pulling the requirements together, a school running on externally managed aircraft needs a system that is built around configurability rather than a fixed fleet template. Concretely, the checklist looks like this.

This is exactly the kind of operation configurable billing is built for. Aviatize's rate engine treats aircraft cost, instructor cost, non-member charges, landing fees, and other charges as separate line items, so a school can account for each separately, carry them into its accounting, show instructors what they will be paid, and — critically for this model — report to each aircraft owner what their usage was. It tracks how much training value a student has left in a prepaid block in real time. And because the billing is configured rather than fixed, a school sets it up to match its own operation and its owner agreements instead of contorting the operation to fit the tool — the same idea behind our posts on software that adapts to your SOPs and pricing that fits how a school runs.

If you run a school on externally managed aircraft — renting from an owner, sourcing from several, or letting instructors bring their own students onto sourced aircraft — the questions to ask any system are simple. Can it itemise instruction separately from the aircraft? Can it bill on the basis my owner agreements actually use, not just Hobbs? Can it tell each owner what they're owed? And will it run happily alongside the scheduling those owners already use? When the answer is yes, the capital-light, instruction-first model stops being something you fight your software to support and becomes simply how your school runs.