An AP Automation Vendor Built Its Invoice Intake on Files.com Instead of Customer-Run SFTP Servers

An accounts payable automation software vendor builds AP automation and document and content management software. Its products support invoice capture, AP workflow, and payroll and year-end document production.

Its cloud AP automation platform is one of the vendor's flagship products. The product's job is to capture the data on a customer's invoices and carry each one through workflow until Finance pays it. Before any of that automation can start, every customer has to do the same thing: get invoice files into the vendor's cloud. That intake step is where the vendor's problem lived.

The Intake Edge Was the Part the Vendor Controlled Least

The intake path crosses three environments. The vendor's OCR layer runs in the customer's environment, converting PDF and image invoices into text, XML, or JSON. Those files then have to travel to the vendor's cloud, where the platform polls its Azure Blob storage for new files to ingest. The middle leg, the transfer itself, did not belong to the vendor.

The vendor had no SFTP capability to offer. A customer that wanted to deliver files over SFTP stood up its own server, opened a firewall port, and administered its own credentials. Every one of those endpoints was another environment the vendor's support team had to work through when an invoice feed broke. Diagnosing a problem at the edge of the vendor's own flagship product meant going through someone else's server, someone else's firewall, and someone else's IT department. The intake edge was the part of the product the vendor controlled least, and customers noticed: they were asking the vendor for an SFTP capability delivered as part of the platform itself.

The vendor needed a managed SFTP capability it could deliver with the platform rather than another collection of per-customer servers. The platform was early in its life and growing, and every new customer using OCR intake needed the whole path provisioned again. Per-customer intake arrangements stopped being something the vendor could absorb one at a time.

What the fix had to do was specific. The endpoint had to be one the vendor operates and can see into, carrying the vendor's own name. Files had to land directly in the vendor's Azure Blob storage, where the platform already collects them, so nothing about the product's ingestion would change. And setup for each new OCR intake customer had to be a routine rather than a project, because each one needs the same two things: a test environment and a production one.

The vendor selected Files.com to be that intake edge.

Managed SFTP in Front, the Vendor's Own Azure Storage Behind

The pipeline now runs as a single path. OCR output leaves the customer's environment over SFTP and lands on the vendor's Files.com site, which runs on the vendor's own domain, so the endpoint every customer connects to reads as the vendor's. Files.com Remote Server Mounts connect that site straight through to the vendor's Azure Blob storage: a file uploaded over SFTP passes through to the vendor's own backing store in real time, with nothing stored twice and nothing to keep in sync. The platform's polling jobs collect each file from Blob storage and run the invoice through workflow to Finance for payment.

Each platform customer that uses OCR intake is provisioned a pair of Files.com accounts when they come onboard, one for UAT and one for production. That pair is the Files.com intake setup.

Onboarding an OCR Intake Customer Is Now a Provisioning Routine

With Files.com in production as the platform's intake edge, the vendor created a managed alternative to per-customer infrastructure arrangements.

• When an invoice feed breaks, the vendor troubleshoots it on a platform it manages. The diagnosis starts with the file and the account, not with a request to a customer's IT team about their server and their firewall.
• Onboarding a new intake customer is a provisioning step: create the UAT and production accounts and point the customer's OCR output at the endpoint. The vendor adds new accounts every month as the platform sells.
• The path runs at product scale, with API transaction volume among the highest of Files.com's more than 4,000 customers.
• The capability customers asked for is now part of what the vendor delivers: a customer can get a managed SFTP endpoint with the product without standing up a server or opening a firewall port to send the vendor an invoice.

File Intake Became Part of the Product

Today, the vendor manages the intake edge for platform customers using its SFTP path without building file-transfer infrastructure or taking on administration of its customers' servers. Secure invoice intake now scales as a per-customer provisioning routine alongside the platform's sales. For a SaaS vendor whose product depends on customers delivering files into it, that is what the transfer layer should be: not a server anyone has to run, but a piece of the product.