A Back-Office Automation Provider Collects Emailed Client Reports Through Files.com Inboxes Alongside Its SFTP Intake

A back-office automation software provider automates the accounting that hospitality and retail operators still mostly do by hand: cash reconciliation, credit card reconciliation, tips and gratuities. Its software reconciles payments daily across tens of thousands of terminals, devices, and locations for major hotel brands, casinos, grocers, and convenience chains, and it pairs that software with cash-recycling machines to take manual cash counting out of the back office entirely.

None of that works without other companies' data. The company's products run on files produced by systems its clients already operate: point-of-sale systems, property management systems, and the cash machines themselves. Those systems ship reports on a schedule, and the company reconciles what they say against each other. Most of that data arrives over FTP and SFTP into Files.com, where hundreds of retail and hospitality properties deliver cash-machine files into a folder structure that gives every client its own credentialed drop point, at a rate of thousands of client files a day.

But a client system can only deliver what it knows how to send. For a meaningful share of the systems the company connects to, the only export mechanism on offer is scheduling a report to an email address. The company does not get to choose the channel. The sender does.

The company moved that intake to Files.com inboxes, making emailed reports part of the same automated, monitored pipeline as SFTP deliveries. It started with new clients, so hundreds of live senders did not have to be reconfigured.

Client Systems Whose Only Export Is an Email

The company collected those emailed reports with Microsoft Exchange Online: a set of mailboxes and routing rules directing each client's attachments into the right processing path. The company wanted those reports collected on the same platform as the rest of its client data, in the same per-client folders, under the same automations and the same monitoring.

The requirement had two parts. The first was onboarding: a client whose system can only email a report had to be provisioned the same way as a client that speaks SFTP, with a folder rather than a routing rule.

The second was monitoring. The company's products depend on client systems shipping data on a fixed cadence, so a report that fails to arrive has to be flagged the same way a missing SFTP delivery is.

The senders were not the company's to change. Every one of those email addresses was configured into a client's POS or event-management system, so replacing the collection point meant either forwarding the old addresses indefinitely or asking hundreds of clients to reconfigure where their systems send. The company had started designing its own collection service before finding the capability already built into the platform that handled the rest of its intake.

What the Replacement Had to Do

As the company's client base grew, so did the email channel. The collection point had to do four things: accept a file from a system whose only interface is a scheduled email, admit only the file types the company's platform actually processes, land the file in the same per-client folder structure that FTP deliveries use, and roll out one client at a time without touching a single live sender.

Files.com email inboxes met all four, and the company made them its collection point for emailed client data.

An Email Address That Lands in the Same Folder as SFTP

A Files.com inbox gives a folder its own email address. The company provisions one for a client, and the client's system schedules its report to that address exactly as it once did to an Exchange mailbox. Nothing changes on the sender's side except the address.

When the message arrives, extension filtering keeps everything but real data files out. The company's first test showed exactly why that filter matters: a single emailed CSV can arrive accompanied by every image file in the sender's email signature. With filtering in place, only the file types the company's platform processes ever land in the folder.

From there, an emailed file is indistinguishable from one delivered over SFTP. It sits in that client's folder in the same structure, where the same Files.com Automations and webhooks that handle FTP-delivered files pick it up and hand it to the company's ingestion code and onward into its data platform.

The rollout was deliberately incremental. The company tested the inboxes with a couple of new clients, then made them the standard path for every new client that delivers by email. No live sender was asked to change anything.

Every New Email Client Lands on the Platform

With Files.com inboxes as the standard path, a client that can only email a report is now onboarded the same way as a client that speaks SFTP: it gets a folder and an address, not another routing rule. Three things changed.

• Emailed client data runs through the same pipeline as everything else. Same folders, same automations, same webhooks feeding the company's downstream systems, with no separate handling for the email channel.
• Absence is detectable. Because emailed files land on the platform, the same monitoring that watches for missing FTP deliveries can watch emailed feeds too. A report that never arrives is a detectable event.
• Onboarding scales with the business. Every new email-delivering client lands on Files.com, so the email channel grows without a separate configuration to maintain.

One Collection Layer, However the Client Sends

Emailed data files, it turns out, belong in the file transfer layer, not the mail server. And moving them there did not require touching hundreds of live client configurations. The company started with the next client instead of the last one, and every email-delivering client since has landed on the platform.