Aviation Parts Distribution Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the unit keep getting modelled as a stock line with a quantity?

Because that is what distribution software is for, and the scoping conversation borrows its vocabulary. Somebody asks how many of a part number you have. The answer is a number, so the system stores a number, and certification documents get attached to it like an invoice attaches to a purchase order.

In aviation the unit of value is not a quantity, it is a specific serial and the evidence supporting it. A hydraulic actuator carries a repair history, a release document 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. Remove any one of those and the unit does not lose a percentage of its value, it becomes untradeable.

The failure that follows is specific and repeatable. A unit gets quoted as overhauled because somebody set the condition, while the supporting tag was never received. The customer's receiving inspection rejects it, the unit comes back, and now you are arguing about freight on top of losing the order.

Make certification state a precondition of condition. A serial cannot enter serviceable status without a linked release document of the right type carrying the certifying agency, the date, the release basis and whether the release is dual. Ask a developer to model a serialised unit before signing. If they draw a stock item with a quantity field, they have built a warehouse system for a different industry.

What goes wrong when existing units and their documents get migrated?

The documents are always in worse shape than anyone admits, and nobody finds out until somebody samples the archive. Tags exist as scans named by whatever convention the person filing them used that year. Some are photographs taken at an angle. Some cover a serial that was later replaced during a repair and never re-tagged. Trace statements exist as email threads. A meaningful share of units on the shelf have no retrievable document at all, and their book value assumes otherwise.

The damaging version is not the missing document, it is the false confidence. A migration that imports every unit as serviceable because that is what the old system said produces a catalogue you can quote from and cannot deliver against.

Handle it as an inventory verification exercise rather than a data load. Import units in an unverified state, then work the shelf: match each serial to a retrievable document, record what is genuinely missing, and let the system show you an honest split between saleable and paperwork blocked stock. That number will be uncomfortable and it is the most valuable output of the project, because it tells your finance director which part of the balance sheet is actually realisable.

Insist that a developer examines a sample of your real archive before quoting migration. Document quality is the single largest unknown in this category and a fixed price offered without a sample is a fixed price that will be renegotiated.

Why do marketplace and finance integrations break after launch?

Marketplace listing feeds break because they are one way and nobody watches them. Each channel has its own format and update mechanism, an update fails, and the failure returns something that looks like success. Your listing then advertises a unit sold three days ago, and the buyer who calls about it forms a permanent view of your reliability at exactly the moment you needed the opposite. Treating platforms such as Inventory Locator Service or PartsBase as a second inventory system, maintained separately, is how the same unit gets sold twice.

Finance integrations break for a different reason: consignment settlement and core liability touch the ledger in shapes a standard connector does not cover. A consigned sale is not one journal entry, it is a sale, an owner liability and possibly a repair cost recovery. An exchange creates a receivable that is not an invoice. Standard connectors post the simple case and quietly mishandle the rest, and the difference surfaces at month end as a suspense balance somebody clears by hand forever.

The fixes are unglamorous. Generate listings from the same unit state that drives quoting, so a unit sold in the morning stops being advertised immediately. Make failed listing updates visible on an operations screen with an owner rather than a log entry. And map the awkward finance cases explicitly during design, with your accountant in the room, rather than discovering them in the first close.

What happens when exchange core liability and repair routing are not covered?

Both are financial positions disguised as logistics, and both get deferred because they are not on the sales screen.

When you ship a serviceable unit on exchange, the customer owes you a core within an agreed period or owes you the outright difference. That is a receivable with a deadline. Most systems model it as a sales order with an expected return, which loses the lifecycle: due, arrived, inspected, found beyond economic repair, then a commercial conversation about the uplift. Without that model, open core liability cannot be totalled without an afternoon of work, overdue cores get chased only when somebody remembers, and a core returned beyond repair becomes an argument in a quarterly review instead of an invoice in days.

Repair routing is the second gap. Unserviceable units sit in someone else's building against a promised date that is frequently optimistic, while the same part number is being quoted on the assumption it returns next week. If repair orders are not tracked with the unit serial, agreed scope, quoted cost and promised date, with slip measured against the original promise rather than the latest revision, you cannot see vendor performance and you cannot quote against inbound stock deliberately.

Both are cheap to include and expensive to add later, because both change the shape of the unit record and the availability calculation everything else reads from.

Should you build custom or configure what you already own?

If your business is expendables, hardware and consumables distributed by quantity with standard certification, configure Quantum Control or Pentagon 2000SQL properly and stop. Both understand aviation far better than a general enterprise system, both handle purchasing, sales and quantity managed stock comfortably, and a custom build would be an expensive way to reproduce a purchase order.

The same answer applies to a small rotable trader with a few hundred units and one person who genuinely knows every one of them. At that scale the system is that person, and software is overhead rather than an advantage.

Where the incumbents strain is narrow and identifiable: certification state as a precondition rather than an attachment, open core liability as a live financial position, and consignment settlement where repair costs must be recovered before an owner split. If those three describe your daily friction, price a build around or alongside what you have rather than replacing it wholesale. A layer that owns unit state, certification and quoting, sitting beside an incumbent that owns purchasing and finance, is often the cheaper and lower risk route.

Build outright when serialised rotables carry a large share of your inventory value, when you lose orders on response time rather than price, or when you operate a pool where the same physical units cycle between customers and paperwork has to follow them every time.

How do hidden costs get into the quote?

Dual release handling is first and it is rarely priced properly. Tracking both FAA and EASA acceptability per unit affects quoting, documentation and which customers you can serve, and it is not a checkbox on the part record.

Marketplace channels are second. Each has its own listing format and update mechanism, so three channels is three integrations, and they should be priced individually rather than as one line called listings.

Barcode and location management is third, particularly where customer owned stock is held separately from your own and must never be commingled. That segregation requirement changes warehouse logic in ways that surprise people.

Document migration is fourth and largest, covered above.

The item most often missing entirely is the receiving inspection workflow. Capturing the tag at receipt, extracting part number, serial, date and certifying reference, and flagging mismatches against the purchase order is where you catch a tag whose serial does not match the unit in the box. That catch alone has justified the module more than once, and it is the first thing cut when a budget tightens.

What separates a build that works from one that fails here?

The ones that work start with rotables only and leave expendables on the incumbent. Expendables are quantity managed and the value at risk per line is a fraction of what one serialised unit carries, so including them early spends budget where the return is smallest.

They make invalid states impossible rather than discouraged. If the answer to how you stop a unit being quoted without a tag is user training, that is not an answer. Process discipline degrades over time. Data models do not.

They capture documents at the point of receipt rather than filing them later, because every handoff between receipt and sale is a chance to leave paperwork behind and the loss is permanent.

And they settle ownership before kickoff. You should hold the repository, the cloud accounts, the document archive and the unrestricted right to hire another firm. At Digital Heroes the client owns the code from the first commit. In this business that is directly financial rather than contractual housekeeping: your certification archive is inseparable from the value of your stock, so any hosting arrangement that makes bulk export awkward is a threat to the balance sheet.