Aviation MRO software runs work orders against a specific aircraft or component serial, not jobs against a customer. It has to carry three things a general ERP does not: airworthiness traceability for every part fitted, life tracking on hours and cycles as well as dates, and a billing model that separates customer-paid work from warranty and contract work before the job starts.
Why a standard ERP cannot run an MRO shop
A general ERP treats a part as a quantity of an item. Ten of part number X are ten of part number X, and the system picks whichever is nearest.
In aviation that assumption is wrong in a way that cannot be configured around. A part is an individual: it has a serial, a history, an accumulated life, and paperwork establishing where it came from and what has been done to it. Two units bearing the same part number are not interchangeable if one has its certification and the other does not.
A part without traceable provenance is scrap, whatever its physical condition. That is a statement about the data model, not about the shelf.
Everything below follows from that single fact. It is why serial-level tracking is the floor rather than an enhancement, and why an implementation that starts from a standard inventory module spends its budget undoing assumptions.
The work order is the unit of record
Not the customer, not the invoice, not the aircraft. The work order is what everything attaches to, and if it is not the centre of the data model, the questions the business needs to answer become reconstructions.
| Attaches to the work order | Why it has to live there |
|---|---|
| Aircraft or component serial | The subject of the work, and the record the history writes back to. |
| Task lines, from the maintenance programme | Each is separately estimated, performed, signed and billed. |
| Parts fitted, by serial and batch | Airworthiness follows the individual part, not the part number. |
| Parts removed, and their disposition | Serviceable, repairable or scrap — each a different financial outcome. |
| Labour by person, licence and hours | Certifying work requires a person authorised to certify it. |
| Certification and sign-off | Who released it to service, under what authorisation, when. |
| Billing disposition per line | Decided at approval. See below — this is where margin leaks. |
The findings problem is worth naming separately. Work opened as a scheduled inspection generates unscheduled findings, and those findings are new work that was not estimated, not approved and not priced. A system that cannot raise a finding as its own approvable line forces the shop to choose between stopping for paperwork and doing unbilled work.
Three clocks, not one
A life-limited part has to come off at a defined limit. The limit may be flight hours, cycles, calendar time, or several at once — and the binding one is whichever arrives first.
- Hours — time in service, accrued as the aircraft flies rather than as the calendar advances.
- Cycles — one takeoff and landing. A short-haul aircraft accumulates cycles far faster relative to hours than a long-haul one, which is why fleet-wide assumptions fail.
- Calendar — the one every ERP already handles, and the reason teams believe they have life tracking when they do not.
Each serial therefore needs hours and cycles since new and since last overhaul, accrued from utilisation reporting. A system tracking dates alone will miss the limit that comes due first, and in this industry that is not a reporting gap.
What is billable, decided before the work
Every task line carries a disposition, and it is set at estimate and approval:
| Disposition | Who pays | Watch for |
|---|---|---|
| Time and materials | Customer, on actuals | Labour recorded late, or not at all, on a busy shop floor. |
| Fixed price | Customer, at quote | Findings absorbed into the fixed price by default. |
| Flat rate | Customer, per defined task | Actual hours drifting above the rate unnoticed for months. |
| Warranty | You, or the manufacturer | Manufacturer claims never raised — that is a receivable. |
| Contract or goodwill | You, deliberately | Goodwill with no approval step becomes the default answer. |
The failure mode is always the same. Dispositions reconstructed at invoicing cannot distinguish work nobody billed from work that was genuinely warranty, and the ambiguity resolves in the customer's favour because that is the conversation nobody wants to have. Decide at approval and the invoice is a report.
Turnaround, AOG and the pause states
Turnaround runs from arrival to release to service. The part that gets designed badly is everything in between that you do not control.
- Awaiting customer approval — a finding is priced and sitting with the customer. Your clock should not be running.
- Awaiting parts — on order, and separately, awaiting customer-supplied material, which is a different conversation.
- Awaiting external service — a component out at a specialist shop, with its own turnaround.
Without those states, a four-day customer approval is recorded as four days of your overrun, and the SLA report becomes something you argue with rather than something you manage by.
AOG — aircraft on ground — sits outside the normal queue. The aircraft is losing revenue every hour it is not flying, so AOG work takes priority over scheduled work and is measured on its own clock. If the system cannot express that priority, it gets expressed by someone walking across the shop floor, which works until the day it does not.
Rotables and the exchange pool
A rotable is repaired and returned to service rather than consumed. On an exchange, a serviceable unit ships to the customer and their removed unit comes back as the core.
Financially this is the same shape as a core charge in automotive parts distribution: the exchange unit leaves, an obligation to return a core exists, and until it arrives there is a value outstanding. Tracked against the original shipment it is a receivable you can age. Untracked, it is a pool that quietly shrinks, and the shortfall appears as unexplained inventory loss a year later.
The reporting that matters: units out on exchange, age of each outstanding core, and the repair cost against each rotable serial over its life. That last one tells you which rotables are worth continuing to repair and which have become more expensive than replacement — a decision most shops make by instinct because the data was never held per serial.