There's a moment every aviation operator knows. You're sitting through a software demo. The UI is clean, the workflow makes sense, and the sales rep is saying all the right things: "fully paperless," "end-to-end traceability," "built for Part 145." There's a dashboard. There are charts. There's a mobile app.

You sign.

Six months later, an auditor asks for the receiving record on a purchase order from Q2. Your warehouse lead opens the system and there's nothing there. Someone deleted it. The system let them. There was a little recycle bin icon, and one afternoon when they were trying to fix a receiving error, they clicked it. No warning. No reversing entry. No audit trail. Just gone.

The software didn't fail. It did exactly what it was designed to do. The problem is that what it was designed to do and what a Part 145 or ASA-100 environment actually requires are two very different things, and nobody asked the right questions during the demo.

That's what this article is about.

When you're evaluating aviation ERP software, you're looking at a lot of the right things. Does it handle work orders? Can it manage my inventory? Does it integrate with ILS or PartsBase? Can my techs use it on a tablet?

Those are reasonable questions. But there's a more important one that almost never comes up:

Does this system enforce compliance, or does it just assume my team will remember to be compliant?

That distinction is the whole ballgame.

There are two fundamentally different ways to build a system like this. The first approach -- call it workflow-first -- is optimized for flexibility. Users can edit records, fix mistakes, reverse transactions, and adjust quantities directly. It's fast, it's intuitive, and it demos beautifully. When something goes wrong, a user can usually get out of the jam in a few clicks.

The second approach is built on an immutable ledger. Every transaction leaves a permanent mark. You don't "edit" a receiving record -- you create a reversing entry that references the original. You don't "delete" a quantity discrepancy -- you post an adjustment transaction with a reason code that gets routed to QA. The original event and the correction both live in the system forever, side by side.

One of these architectures is naturally compliant. The other one needs a binder full of SOPs and a team that never has a bad day.

Here's the part that should concern you: most providers don't tell you which one they are.

Let's be specific. The issues below aren't hypothetical. They're documented, supported workflows inside platforms being actively sold to Part 145 repair stations, ASA-100 distributors, and AS9120-certified parts suppliers right now.

The names don't matter for this conversation. The patterns do.

Some platforms let users "un-receive" a part on a purchase order by clicking a delete icon. The received record is gone. No reversing transaction, no mandatory reason code, no QA notification.

What compliance requires: When a receiving error happens -- wrong quantity, wrong part, wrong PO -- the fix is a reversing entry that references the original event. The original receipt and the correction both stay in the ledger permanently. An auditor can reconstruct exactly what happened and when.

What happens when your team forgets: You lose the evidence that the receiving inspection ever took place. ASA-100 Section 4 requires a definitive record-keeping system that proves the identity and condition of parts upon arrival. A deleted receipt record means that evidence doesn't exist anymore.

Several platforms allow users to reopen a closed or invoiced work order by reversing it -- sometimes with the ability to reassign the original invoice number and date before reinvoicing.

What compliance requires: When a work order is closed in an MRO environment, a qualified inspector signs a release to service. That signature is a legally binding statement about the airworthiness of a component at a specific moment in time. If subsequent work is needed, it lives in a new, formally linked document -- an amendment or supplemental work order -- that generates its own release certificate.

What happens when your team forgets: When a closed WO is reopened and edited, every digital signature applied to the original is retroactively invalid. FAA AC 120-78B requires that electronic records be protected from unauthorized alteration. A system that treats a closed work order as just another editable record doesn't meet that standard, regardless of how many authentication steps it took to get the user logged in.

Some platforms let users navigate directly to a stock record, change the quantity, and save. No transaction created. No reason code. No QA approval required.

What compliance requires: Any change to on-hand inventory in a certified environment needs to be a documented transaction. A cycle count adjustment. A scrap disposition. A lost parts report. The transaction type matters because it forces the question: where did those parts go?

What happens when your team forgets: If you're holding 50 serialized fasteners and a user edits the count to 45, the system has no record of what happened to the other five. AS9100 Clause 8.7 requires control of nonconforming outputs. You can't control what you can't account for. "Edit → Save" removes the friction that forces that accountability.

Some platforms offer a "new item" path that creates a stock entry without a PO. The traceability field -- manufacturer, lot number, serial number, certification source -- is an optional free-text input.

What compliance requires: Traceability is the thread that runs from the manufacturer to the installed component. AS9100 Clause 8.1.4 and ASA-100 Section 8 both require that receiving inspection verify the identity of parts against documentation. An optional text field isn't a traceability system. It's a sticky note with a database behind it.

What happens when your team forgets: A part enters your inventory with no documentation linkage, no PO reference, and whatever someone typed into a free-text box. That part can be issued to a work order, signed off, and released to service. The chain of custody doesn't exist -- and you won't know it until the audit.

Several platforms offer a function to correct a part number typo after it's already been transacted -- a global find-and-replace that updates the PN across inventory, work orders, and purchasing records.

What compliance requires: If a part was received under an incorrect PN, used in a closed work order, and released on an 8130-3, that historical record reflects what actually happened. The correction belongs in a formal supersession or audited transfer record -- not a retroactive rewrite of every document that ever touched the wrong PN.

What happens when your team forgets -- or doesn't know the risk: A global PN edit can make it impossible to reconstruct the actual configuration of a component at time of release. An auditor reviewing a release certificate will see a PN that matches the current master record, but if that PN was different at the time of the work, the certificate is now describing something it didn't describe when it was signed.

Some platforms manage return merchandise authorizations and track parts sent out for repair, but don't document a quarantine or Material Review Board status that physically prevents a flagged part from being issued to a work order or shipped on a sales order.

What compliance requires: ASA-100 Section 8 requires that suspect material be segregated and held until disposition is resolved. "Segregation" in a digital environment means the system won't let you issue or ship the part. A warning message that a user can click past isn't segregation. A status that blocks the transaction is.

What happens when your team forgets: A part flagged as non-conforming or suspect counterfeit gets issued because the user didn't notice, was in a hurry, or didn't know the flag was there. The system let it happen. AS9100 Clause 8.7 and AS9120 both require hard systemic controls -- not reminders.

Some platforms market electronic signature support and two-factor authentication as compliance credentials. But if the records those signatures sit on can be reopened, reversed, or deleted after the fact, the authentication infrastructure is irrelevant.

What compliance requires: FAA AC 120-78B states that electronic signatures on maintenance records must be constructed so that any subsequent alteration of the signed data is immediately detectable. That requires the underlying record to be immutable once signed. Authentication proves who you are. It doesn't protect the document after you've left.

What happens when your team forgets: Nothing -- because this one doesn't require forgetting. The vulnerability is architectural. Any user with the right permissions can reverse a closed work order and the signature that lived on it is now meaningless. The 2FA was real. The compliance wasn't.

Some platforms describe their marketplace connectivity as an integration. The actual workflow is: label your parts, create a listing object, review and edit the listing, then push it to the marketplace. Parts can even be listed before they've been received into inventory.

What this means operationally: If your team doesn't push after every receiving event, every issuance, every shipment -- your marketplace listings are stale. A customer finds your part on ILS, calls to buy it, and it shipped last week. Or worse, it's committed to another work order and your team pulls it anyway because the sale came in.

What a real integration does: When a part is committed, it delists automatically. When it ships, it's gone. The inventory and the marketplace stay in sync because the system enforces it -- not because someone remembered to hit "push" after logging a receipt at 4:45 on a Friday.

This one isn't a regulatory violation. It's just operationally broken at scale, and the platforms selling it as an "integration" know the difference between what they have and what that word implies.

On some platforms, when an internal work order closes, the system returns the repaired part to inventory as a new stock line -- separate from the original. If the work order wasn't correctly linked to the exact source inventory line, the system creates an additional entry, which inflates the apparent on-hand count and disconnects the part's history.

What compliance requires: A repaired component's history is part of its identity. The as-received condition, the work performed, and the as-returned condition should all live on the same traceable record, linked to the same serialized unit. Repair is a transformation event -- not a disposal and a re-creation.

What happens when your team forgets to link correctly: You end up with two stock lines for one part. The original shows as still in stock. The returned part shows as a new entry with no history. An auditor trying to reconstruct the maintenance record for that serial number has to guess which line is which.

On some platforms, the automatic attachment of FAA Form 8130-3 and teardown reports to the corresponding work order is not a standard feature. It's a configuration that has to be enabled by the vendor's support team. Out of the box, the binding doesn't happen.

What this means: Every customer who doesn't know to ask for that configuration, doesn't complete the onboarding checklist that mentions it, or migrates to the platform and assumes the default setup is compliant -- is releasing parts with no automatic documentation trail.

The 8130-3 is the foundational traceability document in the global aviation supply chain. Binding it to the work order that produced it should be the default behavior of any platform that calls itself aviation compliance software. Making it optional, support-enabled configuration isn't a minor onboarding detail. It's a design choice about where compliance responsibility sits.

It sits with your team. Not the software.

The ten items above are about what happens when the auditor shows up. What follows is about what happens every day before the auditor ever gets there. It's a different category of broken, and it costs you differently -- in wasted hours, unnecessary headcount, and a sourcing operation that runs on human effort instead of system intelligence.

These aren't compliance violations. They're broken promises. And they tend to hide behind the same polished demo.

A lot of platforms in this space advertise marketplace connectivity. ILS. PartsBase. AVSpares. Aeroxchange. The logos are on the website. The sales rep says "integrated."

What that word means in practice varies enormously, and the gap between the best and worst versions of it is the gap between a real capability and a manual publishing workflow with a technical wrapper around it.

Here's what the manual version looks like: you provide your username and password, you label your parts, you create a listing object, you review it, and you push it to the marketplace. If you want your listings to reflect what you actually have in stock right now, you repeat that process every time something moves. A receipt comes in, you push. A part gets committed to a work order, you push. Something ships, you push.

Nobody pushes every time. Which means at any given moment, your marketplace listings are a historical snapshot of your inventory, not a live picture of it. A buyer finds your part on ILS, calls you, and it shipped three days ago. Or it's committed to a job and your team pulls it anyway because the sale came in and the system didn't say no.

A real integration doesn't have a "push" button. When a part is committed, it delists. When it ships, it's gone. The marketplace reflects the inventory because they're the same system talking to each other in real time, not because someone remembered to sync.

The platforms that have built actual real-time API connections to these marketplaces know exactly what distinguishes them from a listing tool. The ones selling listing tools as integrations know it too.

Some platforms that market themselves as paperless still generate documents that users fill out by hand.

Not forms that pre-populate from the transaction. Not documents that pull the work order number, the part number, the serial number, the technician, the date and time from what's already in the system. Blank forms that print out, get carried to the floor, get written on with a pen, and then get scanned back in -- or don't.

The screen is digital. The workflow is 1987.

This matters for two reasons. First, handwritten data on a printed form is a transcription step, and every transcription step is an error waiting to happen. The part number your system has is correct. The part number your tech writes on the traveler at 6am might not be. Second, a manually filled document that gets scanned as a PDF attachment isn't a compliance record in any meaningful sense. It's a picture of a piece of paper. It can't be searched, cross-referenced, or verified against the transaction that generated it.

A document that truly lives in the system -- generated from the transaction, populated by the system, signed within the system, and bound to the record it belongs to -- doesn't need a scanner. It also doesn't need someone to carry it anywhere.

Here's the operational consequence that nobody talks about in a demo but shows up fast in the first year.

When a platform's marketplace integration is weak or nonexistent, someone has to fill the gap. That means someone is opening ILS in one tab, your ERP in another tab, and cross-referencing manually. Someone is sending RFQ emails one by one. Someone is maintaining a sourcing spreadsheet that lives outside the system and becomes the actual record of what was quoted, who responded, and what it cost.

That person is either a hire you made specifically because the software couldn't do it, or it's a person you already had who now spends half their day on tasks that should be automated. Either way, you're paying for a capability the software promised to deliver.

The dependency doesn't stay contained. When that person is sick, on vacation, or leaves -- the sourcing operation slows down or stops. Not because your business has a staffing problem, but because your software strategy has a single point of failure wearing a badge. A real marketplace connection means RFQs come in, get routed, and get responded to based on rules and inventory truth. The person manages exceptions. They don't run the process.

When the integration is real, you don't need a department to compensate for it. When it isn't, you do. And the department doesn't show up in the software demo.

Here's the part that's genuinely hard to explain away.

Some of the same platforms that allow receiving records to be deleted with a recycle bin will not let you delete an accounting entry. Instead, they make you create a "contra" -- an offsetting entry that keeps the original transaction visible while recording the correction. Both entries live in the ledger. Neither one disappears.

They know how to build immutability. They built it into the financial module.

The philosophy is even spelled out in some of their own documentation: "instead of deleting or overwriting a charge, a contra ensures that both the initial posting and the adjustment remain in the records."

That's exactly right. That's exactly how it should work. For every module. But the same logic that protects a $400 invoice doesn't protect the receiving record that proves the $400 part was the right part, from the right source, with the right documentation.

In aviation, that receiving record is more safety-critical than the invoice. By a lot.

The conclusion you're left with isn't that these platforms are badly built. It's that they were built with a different priority. Operational speed and user flexibility in the workflows that touch money. The workflows that touch airworthiness got the recycle bin.

To be fair, this isn't one company's problem. The workflow-first architecture is common across the space, and it shows up in different ways depending on which product you're looking at.

Some platforms handle work order management well but leave inventory quantity editing wide open -- no adjustment transaction required, no reason code, just a direct edit. The work order module might have all the right fields. The inventory module is a compliance gap waiting to happen.

Others have built their traceability story around document attachments rather than enforced transaction linkage. You can upload a C of C to an inventory record. Whether you do is entirely up to you. The system won't stop a part from moving without it. ASA-100 and AS9120 don't grade on a curve for "well-intentioned optional fields."

And some platforms that market heavily to the distributor space have supplier approval workflows that look complete in a demo but rely on users maintaining a separate spreadsheet for quality history -- the exact kind of compensating control that tells you the system doesn't actually enforce what the standard requires.

What they all have in common is this: the SOP does the work the system should be doing. Your team's memory, your training program, your internal audit cadence -- those are the guardrails. The software is the workflow tool.

That's fine if you know that going in and you've built your quality system around it. It's not fine if you bought the platform believing the compliance was built in.

These aren't gotcha questions. They're fair questions that any honest vendor should be able to answer directly. If you get a lot of "it depends on how you configure it" or "your team would manage that through your SOP," you have your answer.

1. If a user makes a receiving error and needs to correct it, what exactly happens in the system?

You're listening for: reversing entry, reason code, QA notification. You're not looking for: delete the record and re-enter it.

2. Once a work order is closed and signed, can it be reopened and edited? If so, what controls exist?

You're listening for: no, it generates a new linked amendment. Or: yes, but only through a formal change process that voids the original and creates a superseding document. You're not looking for: yes, there's a reverse invoice button.

3. Can a user change the on-hand quantity of a part without creating a transaction?

One word answer. If the answer is yes, ask what stops that from happening in your environment without a documented reason.

4. Is traceability enforced at receiving, or is it an optional field?

You're listening for: the system won't complete the receiving transaction without the required documentation fields. You're not looking for: "you can enter it if you have it."

5. Which compliance-critical document bindings are on by default, and which require configuration?

Every platform has configuration. That's fine. But you need to know what the default state actually is, and whether the default state would pass an audit.

The difference between a workflow tool and a compliance system isn't the feature list. It's what happens when your team is tired, distracted, or just trying to get through a busy Tuesday.

A workflow tool gives them options. A compliance system gives them guardrails. In a lot of industries, options are fine. In aviation, a guardrail isn't a nice-to-have. It's the point.

The demo will show you the options. It won't show you what happens on a busy Tuesday. That's on you to find out before you sign.

You know what to ask now.

Want the full evaluation checklist in a format you can bring into your next vendor demo? Reply and I’ll send it to you.