Aviation Software

What aviation software actually is

"Aviation software" is a broad label. It covers everything from flight planning to crew rostering to engine health monitoring. This page is about a narrower and more commercially significant part of it: the systems that aviation parts suppliers, distributors, brokers, repair stations and MRO organizations use to run their business.

In that world, software has to hold two things at once. There is a commercial record — a customer, a price, an order, an invoice, a shipment. And there is an airworthiness record — what this specific unit is, where it came from, what condition it is in, what has been done to it and what paperwork proves all of that.

General business software handles the first one well. It has handled it well for forty years. The second one is where aviation diverges from every other distribution and manufacturing industry, and it is the reason a distinct category of aviation software exists at all.

Why aviation needs software built for aviation

The clearest way to see the difference is to look at what a "part" means in each world.

To a general inventory system, a part is a quantity of a SKU. Two hundred of item 4471-A are interchangeable with each other. You pick any two hundred, you ship them, the stock count goes down by two hundred.

To an aviation system, that abstraction breaks immediately. Two units of the same part number may be entirely different propositions:

• One is serviceable (SV) with a current dual-release tag. The other is as-removed (AR) and has never been to a shop.
• One is new surplus (NS) with a certificate of conformance. The other is overhauled (OH) with a teardown report and an 8130-3.
• One is owned outright. The other sits on consignment and belongs to somebody else until it sells.
• One has eighteen months of shelf life remaining. The other cured out last quarter and is now scrap unless it is re-certified.
• One traces cleanly back to the manufacturer. The other has a gap in its history that a Part 121 customer will not accept, however serviceable it physically is.

Those are not attributes of a SKU. They are attributes of an individual unit, and they change what the unit is worth, who can buy it, what has to travel with it and whether it can legally go on an aircraft. Software that cannot express the difference between those units is not describing the business.

The same divergence shows up everywhere else in the operation. Receiving is not a goods-in scan; it is an incoming inspection that may reject a unit on paperwork alone. A repair is not a work order with a cost; it is a unit leaving the building, going to a certificated facility, and coming back with a new airworthiness status and a document that has to be kept. A sale is not always a sale — an exchange creates an obligation to receive a core back, and that obligation carries real financial exposure until it is resolved.

The categories of aviation software

Most aviation organizations do not buy "aviation software" as a single thing. They assemble a set of systems, each of which owns a slice of the operation. The boundaries below are the ones the market has settled on.

ERP and finance

The system of record for the commercial transaction: customers, vendors, sales orders, purchase orders, invoicing, receivables, payables and the general ledger. In aviation this is often a vertical ERP that already understands part numbers, condition codes and exchange billing rather than a horizontal product retrofitted with custom fields. ERP is covered in more depth on the aviation ERP page.

Inventory and warehouse management

Where the units physically are and what they are. In aviation this has to work at the level of the individual serialized unit, not the line item: condition, ownership, warehouse and bin, hold status, shelf life, and which units are already committed to somebody. Rotables, expendables and consumables behave differently and the system has to know which is which. This is covered in depth on aviation inventory software, and specifically for parts businesses on aircraft parts inventory software.

Maintenance, engineering and MRO

The systems that run repair and overhaul work: incoming evaluation, work scope, routing through shops, quality inspection, and the return-to-service decision. For an operator this extends into maintenance programs, life-limited part tracking and airworthiness directive compliance. For a component shop it is closer to a job-shop system with certification obligations attached. Why that coordination is operationally hard is covered on aviation MRO software.

Document and compliance management

Where the airworthiness evidence lives: 8130-3 and EASA Form 1 tags, certificates of conformance, teardown and test reports, material certifications, packing declarations, and the customer-facing package assembled from them. The hard part is rarely storage. It is knowing which documents belong to which unit, which revision is current, and whether the package for a particular shipment is complete before it leaves. That last question is a quality decision rather than a filing one, and it is covered on aviation quality management software.

Purchasing and sales

RFQ intake, market sourcing, quoting, purchase orders and vendor management. In the parts trade this is a speed business — requests arrive through marketplaces and email, and the supplier who answers first with a credible, trace-backed quote frequently wins the order regardless of price.

Shipping and logistics

Packing, carrier selection, export documentation, dangerous-goods handling for items such as batteries and chemicals, and AOG courier coordination. The constraint that makes aviation shipping different is that the shipment is not ready when the box is packed. It is ready when the box and its paperwork are both correct.

Where the categories meet — and where work gets lost

Each of those categories is a legitimate discipline, and the products that serve them are often very good at what they do. The difficulty is not the quality of any individual system. It is that no single unit of aviation work stays inside one of them.

Consider an ordinary exchange transaction, which is not an edge case but a routine part of the components business:

1. A customer requests a part. Sales quotes it from available stock — purchasing and sales.
2. The unit is reserved and allocated — inventory.
3. The order is booked and billed on exchange terms — ERP.
4. The trace package is assembled and sent with the shipment — documents.
5. The unit ships — logistics.
6. The customer's core comes back and is booked in — inventory and receiving.
7. The core is inspected and dispositioned — quality.
8. It goes to a shop for overhaul and returns with a new tag — MRO and documents.
9. The exchange is financially resolved against what came back — ERP.

Nine steps, six systems, and one unit that has to remain the same unit throughout. Every arrow between two systems is a place where somebody re-keys a serial number, forwards an email, or remembers something. The transaction is only as reliable as the least reliable handoff in it.

This is where operational problems actually originate. Not in a module failing, but in the space between modules where no system holds the whole picture:

• Cores that quietly ageThe sale is closed and invoiced, so the commercial system considers it finished. The obligation to receive a core back is still open, and its financial exposure sits with whoever remembers it. Explained in full on exchange core tracking.
• Shipments held on paperworkThe unit is picked and packed. One certificate is a revision behind. Nothing in the picking system knows that, because documents are a different system.
• Repairs with no ownerA unit is at a vendor. Whether it is late depends on a promise date that lives in an email rather than in a record anyone can query.
• Quotes against stock that is spoken forAvailability looks real. The unit is already allocated to another order, or on hold pending inspection, and the quote is wrong before it is sent.
• Receiving that stalls silentlyMaterial arrives and sits pending inspection. Purchasing thinks it is received; sales thinks it is sellable; quality knows otherwise.

None of these are exotic failures. They are the ordinary friction of running an aviation business on systems that each hold one true, partial view.

How organizations compensate today

Every experienced aviation operation has already solved this problem. The solution is usually people.

There is a spreadsheet that tracks open cores because no system does. There is someone in the office who knows which vendor is slow this month. There is a morning email that reconciles what shipped against what was invoiced. There is an expediter whose entire job is to stand in the gaps between systems and keep work moving across them.

This works, and it is worth saying plainly that it works because the people doing it are good at it. But it has three costs that compound as an organization grows:

• It does not scale linearly. Twice the volume needs more than twice the coordination, because the number of things that can be out of step grows faster than the number of transactions.
• It is held in individuals. When the person who tracks cores is on leave, the tracking is on leave. Operational knowledge that lives in a spreadsheet and a habit is not an asset the company owns.
• It is invisible until it fails. The compensating work does not appear in any system, so it cannot be measured, staffed for, or improved. It only becomes visible when something is missed.

How to evaluate aviation software

If you are assessing systems, the feature lists will look similar. These questions tend to separate them faster:

• Is the serialized unit a first-class object, or a line on a document? Ask to see the same physical unit across a purchase, a repair and a sale. If its history has to be reconstructed, it was never really tracked.
• Where does the paperwork live? If documents are attachments on records rather than evidence bound to units and transactions, completeness will always be a manual check.
• What happens to an exchange after the invoice? This single question separates systems that model aviation commerce from systems that model ordinary distribution.
• Can the system tell you what is blocked? Not what the totals are — what is stuck right now, and on what. Reporting on the past is common. Visibility into the present is not.
• How many systems does one transaction touch? Count the handoffs honestly, including the email ones. That count is a good predictor of how much coordination work the software will leave behind.
• Does it speak aviation natively? Condition codes, trace, cores, tags and return-to-service should be part of the vocabulary, not custom fields somebody configured.

Where AERONEXUM fits

AERONEXUM was built from the observation at the center of this page: that the categories divide vertically while aviation work runs horizontally, and that most of the operational cost in a parts or repair business is generated at the seams rather than inside any one system.

Rather than being another entry in one of the six categories above, it is designed so that the commercial record, the physical unit and the airworthiness evidence stay attached to each other across the whole transaction — quote to inventory to purchase to repair to invoice to shipment — and so that the state of that work is legible while it is happening rather than reconstructable afterwards.

That is a different category of system from an ERP, and it does not replace the disciplines above so much as connect them. We call it an Aviation Operating Platform, and the clearest way to understand why the category is emerging is to look first at what aviation ERP established and where its model reaches its natural limits.

Common questions