From Legacy Client Systems to Azure: Evention Automates 4,000 Daily Files With Files.com

Evention is a Chicago software company that automates back-office accounting for hospitality and retail operators: hotel groups, restaurants, grocers, convenience-store chains, and casinos, including some of the largest hospitality and retail brands in North America. Its reconciliation platform carries cash, card, and gratuity data from the transaction all the way to the general ledger. The company pairs that software with cash-recycling hardware, the "reverse ATMs" that count and issue a property's cash, so reconciliation that most operators still do on spreadsheets happens by machine.

All of it runs on data Evention does not generate. Every product starts from files that originate in systems its clients operate: point-of-sale systems, property management systems, and the cash-recycling machines themselves. Evention controls none of those systems. Its products are exactly as good as the data that arrives from them. That made reliable intake foundational not only to the existing suite, but also to the new products Evention planned to bring to market.

Hundreds of Client Systems That Could Only Send Files

Where a client could offer a direct API, Evention took it. Most could not. What a hotel or grocery chain could almost always do was send a file. A point-of-sale system could schedule a nightly export. A property management system could push a report over FTP. A cash-recycling machine shipped with an embedded FTP client whose behavior nobody at Evention, and often nobody at the client, controlled. These endpoints were frozen. They could not be upgraded, they could not be standardized, and some could not even resolve a hostname: they dialed a fixed IP address or they sent nothing at all.

Receiving that data in-house would have meant running a transfer estate: FTP and SFTP servers kept online for hundreds of external endpoints sending on their own schedules, an encryption key for every client that mandated one, an exception for every legacy client that could not meet a modern TLS policy, and network arrangements for the ones that could only reach an IP. Every hour spent on that estate would have been an hour taken from the reconciliation products clients actually paid for. Because Evention did not control the systems sending the files, their differences could not simply be standardized away.

As the client roster grew into hundreds of properties, intake had to become a template rather than a project. The layer Evention needed had to speak the protocols its clients already had, keep each client's data apart from every other client's, absorb legacy quirks per client instead of per platform, be provisioned from code as new customers signed, and announce each arrival instead of waiting to be polled. Evention made Files.com that layer.

A Folder and a Credential for Every Client

Each client that delivered files received its own folder on Files.com and a login scoped to that folder and nothing else. No client could see another's data. Provisioning was templated: the implementation team entered a new client's details into an internal tool, and Files.com's bulk user import with automatic folder creation, supported by the Python SDK and CLI, created the folder and transfer access in one step.

That repeatable model also contained awkward endpoints as per-client configuration rather than platform-wide compromise. Files.com enforced TLS on FTP connections site-wide while allowing per-user exceptions for embedded cash-machine clients that could not negotiate it. A custom domain with dedicated IP addresses accommodated clients that could only dial an IP. For encrypted deliveries, the Files.com GPG Key Manager held a key per client folder and decrypted each file automatically on arrival, so encrypted uploads reached downstream processing in plain form with nobody touching a key by hand.

Webhooks Carried Each File Into Azure

Evention made the handoff out of Files.com event-driven. When a client file landed, a Files.com webhook called Evention's own service, which copied the file into Azure Blob Storage. Microsoft Fabric then read it into the data platform behind Evention's products. Because webhooks could be filtered to specific event types, Evention's servers heard about new uploads and nothing else, which cut a large amount of needless traffic to its own infrastructure. Inside Files.com, more than 1,000 Automations moved and routed files between folders, so a file arrived, was sorted, and reached Azure without a person or a polling job in the path.

Around 4,000 Files a Day, With Nobody Handling Them

With Files.com as the front door, Evention runs the data supply chain for its products without owning any of the transfer infrastructure underneath it. Most of the data its products run on arrives through the platform.

Around 4,000 client files arrive every day and flow into Azure with nobody handling them. About 600 retail and hospitality properties deliver cash-machine files over FTP through the same layer, alongside the point-of-sale and property-management feeds.

Onboarding a new file-delivering client is a folder and a credential, created from a template by the implementation team's own tooling, not an infrastructure project. A client's legacy quirk—an embedded FTP client or an IP-only connection—is a configuration setting rather than an engineering ticket.

That is the compounding result Evention is building on: the same intake layer can support new products without a new transfer estate behind each one.

“Sometimes not having a lot to talk about is good. That means the system is doing what we want it to do.”

A Perimeter Evention Never Had to Build

Today, Evention can onboard a new hotel group or grocery chain without building transfer infrastructure around that client's systems. Files.com is the perimeter, so Evention's engineering goes into the products behind it.