Guardian Fall Protection Removes Supplier EDI Acknowledgement Gaps on the Path to Epicor with Files.com

Guardian Fall Protection makes the equipment that keeps people alive at height: harnesses, lanyards, anchors, dropped-object prevention, and custom-engineered fall-arrest systems, designed and manufactured across North America and the UK.

Almost none of that product reaches a job site directly. Guardian sells through distribution partners, and the commerce of that model, from purchase orders to invoices to acknowledgements, moves as EDI. The company's systems of record run on Epicor ERP, fed by an EDI system on an Azure server that translates every trading partner's documents into Epicor's terms and back again. A manufacturer that sells through trading partners lives on document exchange with counterparties it does not control, and that is exactly where Guardian's problem sat. With Files.com, a supplier's upload and the EDI server's file became the same event, removing the unowned hops where acknowledgements went missing.

An Acknowledgement Path Nobody Owned End to End

Guardian's trading-partner connectivity was built the way most EDI estates are: on intermediaries and polling. Some documents moved through VANs, the value-added networks that act as P.O. boxes between trading partners. For direct connections, scheduled SFTP jobs on Guardian's own EDI server reached out into each counterparty's SFTP endpoint to see what was sitting in their folders and bring it back.

The cost of that architecture showed up in acknowledgements. Every EDI document Guardian receives generates a functional acknowledgement that must travel back to the counterparty, and when a partner connects to one system, that system hands off to another, and Guardian's server picks files up from folders on a schedule, there are several independent points where either the document or the acknowledgement can quietly fail. When an acknowledgement does not arrive, the counterparty says it never got one, Guardian's system says it sent one, and the dispute ends where EDI disputes end: in chargebacks. This was not an incident. It was a standing condition of the architecture, recurring whenever any hop dropped.

It also was not fixable with monitoring. Guardian could not prove or control delivery across hops it did not own. The failure points were structural, and the polling model compounded the problem at the margin: every new counterparty meant another scheduled job on Guardian's server reaching into infrastructure Guardian could not see into.

A Push Model Needed an Endpoint Guardian Could Hand Out

The condition became unavoidable when Guardian's supplier connections began shifting to a push model: instead of Guardian's server reaching out to retrieve files, suppliers would deliver EDI documents to Guardian. That required something Guardian did not have: a hosted, credentialed endpoint it could hand to each supplier.

The endpoint had to keep every supplier isolated from every other. It had to put inbound files where the EDI translation layer actually reads, rather than creating one more mailbox for Guardian to poll. And it could not become another piece of infrastructure to patch and secure. The obvious route was to run their own SFTP server, and Guardian had already been down it: the company's IT systems engineer prototyped exactly that in Azure and rejected the direction before it reached production.

“I created an FTP server in Azure, and I was doing all the testing. Then I realized where this was headed with the maintenance and security. It's like, why would we want to do this?”

Guardian selected Files.com to be that hosted endpoint.

The Mailbox and the Server Became the Same Place

Files.com hosts the endpoint suppliers connect to, over SFTP with a client or through the web interface. Guardian built a supplier directory with an inbound and outbound subfolder per vendor, and per-user permissions confine each supplier's credential to its own folders, so no counterparty can see what any other counterparty is trading.

The part that removes the hops is on the other side. Guardian installed the Files.com Agent as a Windows service on the Azure VM that runs its EDI system, and a Files.com Remote Server Mount joins the supplier directory to that server's own filesystem. The Agent connects outbound only, so nothing on the EDI server is exposed to the internet and no inbound firewall rule exists to maintain.

The consequence of that design is immediate delivery to the translation layer. The moment a vendor writes a document into its Files.com folder, the file is on the disk the Epicor-connected EDI system reads, and translation into Epicor's specifications proceeds from there. Outbound works in mirror image: the EDI system translates Epicor documents into the counterparty's specifications and writes them to the supplier's outbound folder, where the same write instantly becomes the file the supplier retrieves with the same credential. There is no mailbox between the trading partner and the translation layer, because the mailbox and the server became the same place.

One Credentialed Hop, Visible End to End

With the supplier path in production, Guardian established a single credentialed hop it can see from end to end. The clearest operating payoffs are the transfer infrastructure and polling jobs it no longer has to run, and a supplier-onboarding pattern that repeats without rework.

• Guardian runs no transfer infrastructure for the exchange: no SFTP server to patch and no scheduled retrieval jobs to maintain. Files.com carries the transport.
• Onboarding the next supplier is a folder pair and a credential. The same pattern repeats without rework, with no new job added to Guardian's server and nothing new for the EDI team to operate.
• A supplier's document lands directly on the server the EDI system reads, with no VAN mailbox and no Guardian-side polling job in between. The class of unowned hop where acknowledgements used to go missing does not exist on this path.
• Acknowledgements travel back over the same path, and the round trip lands within the roughly one hour Guardian's EDI team set as its tolerance for business-critical documents.

Transport That Is No Longer Guardian's Job

Guardian's EDI team asked for a specific division of labor: files appear in their folders, and everything upstream of that is a platform someone else runs. That is what Files.com now does for the supplier exchange. The team's work is translation and trading-partner logic, the part that actually requires EDI expertise, while the movement of the documents themselves happens without anyone at Guardian scheduling, watching, or retrieving anything.

The distance travelled is easiest to see in what an acknowledgement used to be: a message whose delivery Guardian had to infer across hops nobody owned, and defend when a counterparty said it never came. On the Files.com path, a supplier's write and the EDI system's read happen on the same disk. Guardian did not fix its acknowledgement problem by monitoring the failure points more closely. It used Files.com to remove them.