A Safety Equipment Manufacturer Chose Files.com Over the Azure SFTP Server It Already Built

A safety equipment manufacturer makes the gear that keeps workers alive at height, and the training to use it. The manufacturer sells through distribution partners rather than direct, and behind that partner network the business runs on Epicor ERP, with EDI infrastructure hosted in Azure.

When the manufacturer set out to automate its finance reporting and invoicing, the design was straightforward: customers submit standardized forms, the manufacturer converts them to JSON, and Epicor runs the invoicing from there. The pipeline had every piece except the first one. There was nowhere for the files to land.

A New Invoicing Pipeline With No Front Door

The manufacturer had no centralized place for external parties to deposit files. During development, testing meant someone dropping files by hand into internal systems. Existing routes were not suited to a finance pipeline: vendors were pointed at an external SharePoint site to drop spreadsheets, and the manufacturer wanted one credentialed drop point built for finance documents.

The requirement sounded simple. Hand customers a credential, give them a place to drop standardized documents throughout the day, and pull the files into Epicor. But providing that in production means owning an internet-facing server: hardening it, patching it, keeping it online, managing every credential, and keeping each customer's files isolated from every other customer's. That is a permanent operating commitment, taken on before the workflow has processed a single production document.

The SFTP Server That Never Reached Production

The manufacturer did not take that trajectory on faith. The IT Systems Engineer who owns the platform built the self-hosted version first: an SFTP server stood up in the manufacturer's Azure environment and tested end to end.

The engineer who runs the manufacturer's EDI systems had reached the same conclusion independently: a self-run SFTP server was tempting, and not something the team wanted to manage.

The prototype made the requirements specific. The manufacturer needed a hosted endpoint it could hand out to customers, with an isolated folder and an individual credential per counterparty. It needed SFTP for automated senders and a browser upload for people. It needed files to arrive where the Epicor pipeline reads them, not in a mailbox someone empties. And it needed nothing of its own to patch, harden, or keep online. The manufacturer selected Files.com to be that hosted exchange layer, and the Azure prototype was retired before it ever reached production.

Customer Uploads Land Directly on the Server Epicor Reads

The systems engineer built the production system himself after a one-hour orientation. On Files.com, each counterparty received an isolated folder and an individual credential scoped by per-user permissions, so no counterparty could see that any other exists. Customers connect with any standard SFTP client, or upload through the web interface when a browser is all they have.

On the manufacturer's side, a Files.com Agent runs as a system service on the Azure VM that hosts its Epicor-connected systems. A Remote Server Mount connects the counterparty folders to that machine, so a document deposited on Files.com lands directly on the server the manufacturer's pipeline reads. There is no retrieval step and no polling job: the upload is the delivery. From there, the manufacturer converts each form to JSON and runs it through Epicor for invoicing and finance reporting.

Adding the next counterparty takes one folder setup: the folder-and-permission pattern repeats exactly, with a new credential and nothing new to build.

Live at Hundreds of Documents a Month, With No Server to Run

With the Files.com workflow in production, customers deposit hundreds of documents a month into their credentialed folders. Every document enters the Epicor invoicing and finance-reporting pipeline without anyone moving files by hand.

The manufacturer replaced a plan to operate its own internet-facing transfer infrastructure with a hosted exchange it configures rather than maintains. The maintenance and security burden the systems engineer saw coming stayed hypothetical because the prototype was retired instead of shipped. Onboarding a new counterparty went from a build question to a configuration step: one folder, one credential, and the same pattern applies again.

A Prototype That Did Its Job by Being Retired

The manufacturer ran the build-versus-buy comparison the most honest way there is: it built. The Azure server worked in testing, and working was exactly what exposed its cost, because a functioning server is a server somebody now patches, hardens, and answers for, every month, indefinitely. Sometimes prototyping the self-hosted route is the fastest way to see what it really charges. The trajectory shows up before production, while there is still time to hand the job to Files.com instead.