From Legacy Client Systems to Azure: A Hospitality Accounting Software Company Automates Thousands of Daily Files With Files.com

A software company 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 the company 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. The company 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 the company planned to bring to market.

Hundreds of Client Systems That Could Only Send Files

Where a client could offer a direct API, the company 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 neither the company nor the client could change. 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, a connection setting for every embedded device with fixed behavior, 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 the company 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 the company 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. The company 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. Embedded cash-machine clients with fixed behavior were accommodated through per-user connection settings, and 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

The company made the handoff out of Files.com event-driven. When a client file landed, a Files.com webhook called the company's own service, which copied the file into Azure Blob Storage. Microsoft Fabric then read it into the data platform behind the company's products. Because webhooks could be filtered to specific event types, the company's servers heard about new uploads and nothing else, which cut a large amount of needless traffic to its own infrastructure. Inside Files.com, 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.

Thousands of Files a Day, With Nobody Handling Them

With Files.com as the front door, the company 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.

Thousands of client files arrive every day and flow into Azure with nobody handling them. Hundreds of retail and hospitality properties deliver cash-machine files 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 the company is building on: the same intake layer can support new products without a new transfer estate behind each one.

A Perimeter the Company Never Had to Build

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