Aviation Parts Inventory Software: Why a Serialised Rotable Is Only Ever Worth Its Paperwork

Why a distribution ERP (Enterprise Resource Planning) is the wrong shape for rotables

A hydraulic actuator sits on your shelf. On the system it is one line: part number, condition serviceable, quantity one, cost figure. In reality it is a specific serial number with a repair history, an 8130-3 tag from the shop that overhauled it, possibly a dual release covering both FAA and EASA acceptance, a trace statement back to a last operator, and a shelf life or cure date if it contains elastomers. Strip any one of those away and the unit does not lose a percentage of its value. It becomes untradeable, which is to say it becomes scrap that you paid full price for.

That is the fact that makes aviation parts distribution different from every other kind of distribution, and it is the fact that general ERPs cannot express. They are built around quantity on hand. Aviation is built around a serial and its evidence.

Component Control Quantum Control and Pentagon 2000SQL both understand this world and are the serious incumbents. Inventory Locator Service and PartsBase are something else entirely, and it is worth being clear about it: they are demand channels where buyers search and you list, not systems that run your business. Plenty of distributors treat their marketplace listings as a second inventory system, which is exactly how a unit ends up sold twice or listed at a condition it no longer holds.

The leak has a recognisable pattern. Units sit uncertified because the tag was never scanned at receipt, so they are invisible to a quote. Cores go out on exchange and return late or never, and nobody can total the open liability without an afternoon of work. Quotes to AOG buyers go out slower than the competitor who answered in four minutes. And once a year a unit is written down because the paperwork chain cannot be reconstructed, which is a full loss on something physically perfect.

Problem 1: the unit of value is a serial plus its documents, and most systems separate them

In most implementations the part record lives in the ERP and the certification document lives in a scanned folder, joined by a filename convention and hope. That separation is where value evaporates: as a unit moves through receipt, inspection, storage, quote, sale and shipment, the documents must move with it, and every handoff is a chance to leave them behind. The incumbents do attach documents, and in a disciplined shop it works. The weakness is that the document is an attachment rather than a property of the unit's status, so nothing stops a unit being quoted as overhauled when the supporting tag has never been received.

What a custom build does: make certification state part of the unit's status, not an attachment. A serial cannot enter serviceable condition without a linked release document of the right type, with the certifying agency, the date, the release basis and whether the release is dual. The document is captured at receiving inspection by scanning it there and then, not filed later. Extraction pulls part number, serial, date and certifying reference off the tag automatically and flags mismatches against the purchase order, which is the moment you catch a tag whose serial does not match the unit in the box. That catch alone has justified the receiving module in more than one of our builds.

Problem 2: exchange and core liability is an open financial position nobody can total

You ship a serviceable unit on exchange. The customer owes you a core within an agreed period, or they owe you the outright difference. That is a real receivable with a deadline, and in most distributors it is tracked on a spreadsheet by one person, or worse, it is tracked in the salesperson's memory of who is usually good for it.

Standard ERPs model this as a sales order plus an expected return, which loses the important part. Core liability has its own lifecycle: due, arrived, inspected, found beyond economic repair, and then a commercial conversation about whether the customer pays the outright uplift. Each state carries a value and a date, and the sum across all open exchanges is a number your finance director should see daily and usually cannot.

What a custom build does: model the exchange as its own object with a core obligation carrying a due date, an expected condition, an agreed uplift schedule and a valuation. Open core liability becomes a live total. Overdue cores generate the chase automatically instead of depending on someone remembering. And when a returned core is inspected and found beyond repair, the system already knows the contractual uplift, so the invoice happens in days rather than after an argument in a quarterly review.

Problem 3: AOG quoting is a speed contest and your data is not ready for it

An operator has an aircraft on ground. The request goes to a dozen suppliers at once, and the order goes to whoever answers first with a credible unit, condition, trace statement and price. Second place gets nothing. Distributors lose those on response time, not price, because answering required someone to check whether the unit is genuinely serviceable, whether the tag is on file, and whether it is already promised.

Marketplace platforms surface your listing but they do not answer any of those questions, and a stale listing is worse than no listing because it burns your credibility with a buyer who was ready to pay a premium.

What a custom build does: quoting reads directly from unit state, so the screen shows condition, certification status, trace quality, cure date remaining where relevant, and any soft allocation to a quote in progress, and the quote goes out with the tag reference attached. Listing feeds to your marketplace channels generate from the same state rather than being maintained separately, so a unit sold at nine in the morning stops being advertised at nine oh one. Unglamorous plumbing that directly changes win rate on your best margin orders.

Problem 4: consignment means someone else owns your inventory, and the split is calculated by hand

A large share of surplus inventory sits on consignment. An operator or a lessor owns the units, you hold and sell them, and the proceeds split under an agreement that may vary by part category, by sale type and by whether the unit needed repair first. Reporting to the owner is usually a monthly spreadsheet assembled by an analyst.

The incumbents handle consignment as an ownership flag. What they handle poorly is settlement logic, especially when a consigned unit goes for repair and the cost must be recovered before the split, or when the agreement changes above a value threshold. What a custom build does: encode the agreement as rules against the owner, apply them at the point of sale (POS), and give the owner a portal showing their units, movements, sales and statement. Consignors renew with the distributor whose reporting arrives without being chased, which makes this a retention feature disguised as an accounting one.

Problem 5: repair routing, and the difference between sending a unit out and knowing where it is

Unserviceable units go out to repair vendors, so the unit becomes capital sitting in someone else's building against a promise date that is frequently fiction, while the same part number is quoted to a customer on the assumption it returns next week. What a custom build does: repair orders carry the unit serial, vendor, agreed scope, quoted cost and promised date, with slip tracked against the original promise rather than the latest revision. Vendor performance becomes measurable, which changes where you send work, and units at repair appear in availability as future stock with a confidence, so quoting uses them deliberately rather than accidentally.

What this costs and how long it takes

A first release covering serialised inventory with certification state, receiving inspection with document capture, exchange and core liability, and quoting from live unit state runs $80,000 to $170,000 and ships in 12 to 18 weeks. A full platform adding repair order routing with vendor performance, consignment settlement and owner portals, marketplace listing feeds, customer portals and finance integration runs $250,000 to $600,000 phased over 8 to 16 months.

What drives cost up here: dual release handling, because tracking both FAA and EASA acceptability per unit affects quoting, documentation and which customers you can serve. Marketplace integration, since each channel has its own listing format. Barcode and location management across warehouses, particularly with customer-owned stock held separately. Finance integration, because consignment settlement and core liability touch the ledger in ways a standard connector will not cover. And migrating existing units and their documents, where the documents are in worse shape than anyone admits until sampled. What holds cost down: starting with rotables only, since expendables are quantity-managed and the value at risk is a fraction of what one serialised unit carries.

Build versus buy, and when buying is right

Buy if your business is expendables, hardware, consumables and standard-certification distribution by quantity. Quantum Control and Pentagon 2000SQL cover that comfortably and a custom build would be an expensive way to reproduce a purchase order. Buy if you are a small rotable trader with a few hundred units and one person who genuinely knows them all, because at that scale the system is that person and software is overhead.

Build when two or more of these are true. Serialised rotables carry a large share of your inventory value and a tag failure is a full write-off rather than a discount. Your open exchange core liability cannot be totalled without an afternoon of work. You lose AOG orders on response time rather than price. You hold significant consignment inventory and settlement reporting is assembled by hand each month. Or you operate a pool where the same physical units cycle between customers and the paperwork has to follow them every time.

Our position, stated plainly: in this industry the software is not an efficiency tool, it is the mechanism that preserves the value of the inventory. Every other distributor's worst case is a stock write-down at market value. Yours is a physically perfect unit that becomes worthless because a piece of paper went missing. Systems that treat documents as attachments will keep producing that outcome, and no amount of process discipline fixes it permanently, because process discipline degrades and data models do not.

How to choose a developer for aviation parts software

Ask them to model a serialised unit before you sign anything. The answer should include serial, condition, certification document with type and release basis, trace to source, repair history, cure or shelf life where applicable, and ownership. If they draw a stock item with a quantity field, they have built a warehouse system for a different industry.

Ask how they will stop a unit being quoted as serviceable when the supporting tag is not on file. If the answer is user training, that is not an answer. It should be a state machine that makes the invalid condition unrepresentable.

Ask what they have integrated, naming the specific platform and interface: marketplace feeds, finance, barcode scanning and a customer portal are four separate problems. Ask what happens when a listing update fails silently, because that is the failure mode that costs a sale.

Ask how they will handle migration of existing units and documents, and insist on a sample of your actual archive being examined before a number is quoted. Document quality is the single largest unknown in this category.

Ask who owns the code and get it in writing before kickoff. You should hold the repository, the cloud accounts and the right to hire any other firm. At Digital Heroes the client owns the code from the first commit. Here it matters because your certification archive and your unit history are inseparable from the system holding them, and a hosting arrangement that makes bulk export difficult is a direct threat to the value of your stock.