An Aviation Management Company Began Replacing Manual Invoice Routing With a Cloneable Files.com Intake for Kanverse and Oracle

A US private aviation management company operates a fleet of hundreds of privately owned aircraft on behalf of their owners from dozens of base locations across the country. The operating model is deliberately decentralized. A dedicated aviation manager and crew work with each owner at the aircraft's home base, while headquarters provides the oversight, from safety and regulatory compliance to the financial side of ownership. The company negotiates fleet-wide programs for fuel, maintenance, crew training, and insurance on its owners' behalf.

Financial oversight at that scale has a physical form, and it is mostly invoices. Every managed aircraft generates a stream of vendor bills, and all of them converge on the accounts payable operation at headquarters, where each one has to be processed against the right aircraft and the right owner.

To replace that manual routing without forcing every vendor into the same delivery method, the company built one cloneable Files.com intake pattern: vendors could deliver by email, portal, or SFTP while Kanverse collected from a single source for processing into Oracle.

Invoices Arrived as Attachments and Moved by Hand

Those invoices arrived the way vendor invoices arrive almost everywhere: as email attachments, routed by hand. Someone pulled each file out of a mailbox and moved it into the accounts payable process.

The cost was not any single invoice. It was that every invoice-producing vendor amounted to a standing manual arrangement. A mailbox is the least structured place a business file can land: no credential establishes who sent it, the filename is whatever the sender chose, and nothing about the arrival tells any downstream system where to look. Multiply that by the vendor list behind a fleet of hundreds of aircraft, and intake itself became work that grew in step with the business.

The email path survived for the reason it survives everywhere. Email was the one delivery channel every vendor already had, and the company did not control its vendors' billing systems. Moving a vendor's invoices out of a personal mailbox meant giving that vendor a delivery path it could use, without interrupting the flow of its invoices while the change happened. That was real per-vendor work, and with no pattern to repeat, it stayed undone.

Kanverse and Oracle Needed a Feed, Not a Mailbox

What made hand-routing untenable was the company's own automation. The company processes invoices with Kanverse, an AP automation platform that extracts invoice data and feeds it into the Oracle ERP. That investment only pays off against a structured source: a predictable folder, files that arrive machine-ready, a connection a service account can hold open. An attachment in a mailbox, routed by a person, fails every one of those tests. As long as intake ran on email, each additional vendor added more manual routing instead of more automation.

So the fix had a specification before it had a product. Give each vendor a way to deliver that suits that vendor. Land every invoice in one predictable, governed place. Present a single stable connection to the AP system on the other side. And make the whole arrangement repeatable, so the next vendor costs a copy of the last one rather than a new project.

The company selected Files.com, already its portal for exchanging files with outside partners, to be that intake layer.

One Vendor Workflow, Built as the Template

On the vendor side, Files.com gave the company several doors into the same place. A vendor that can run SFTP connects with its own per-user credentials. A vendor's staff can sign in to the company's portal as an external organization. And a vendor that will only ever email its invoices can keep emailing: a Files.com Inbox carries its own email address, so the attachment lands directly in the folder the company chose instead of in a person's mailbox. The vendor's habits do not have to change. Where the file lands does.

On the AP side there is exactly one connection. A Kanverse service account signs in through Files.com and pulls the landed invoices for processing into Oracle. However many vendors deliver, and however each one chooses to deliver, the downstream pipeline sees a single structured source.

The company built the first vendor workflow deliberately as a reference: the intake path, the folder structure, and the hand-off to Kanverse, designed to be cloned for each vendor that follows rather than redesigned each time.

Invoices Now Land Once and Move on Their Own

With the first vendor workflow in production, the company replaced mailboxes and hand-routing on that path with a feed its AP pipeline collects on its own.

• Invoices on the Files.com path land once and move without a person in the loop. Kanverse pulls them into Oracle, and nobody handles files between arrival and processing.
• Every invoice on the Files.com path arrives in a known folder. SFTP and portal uploads arrive under vendor credentials, while emailed attachments land at the folder's Files.com Inbox address rather than in a person's mailbox.
• The next vendor has a reference to clone rather than a workflow to design from scratch. The reference workflow already defines how a vendor delivers, where files land, and how Kanverse collects them. The downstream connection does not have to change.

Structure the Intake Once, Not Per Vendor

That is the lesson a company with a mailbox full of invoices can take from a company with hundreds of aircraft. AP automation runs end to end only after intake is structured, and the company's first workflow established a cloneable Files.com template for moving vendor onboarding beyond bespoke work.