Matrix Imaging Solutions Standardizes FTP and SFTP Intake With Files.com—While Keeping Files on Its Production Servers

Matrix Imaging Solutions is an outsourced customer communications provider that designs, prints, and mails the transactional documents other companies bill with. Its DataProse operation produces billing statements and notices for utilities, municipalities, collections firms, and doctors’ offices.

The raw material of that business is other companies’ data. Every bill Matrix mails begins as a data file generated by a client’s billing system, and Matrix does not own, run, or standardize any of those systems. Getting each client’s file from the client’s server to the press is where this story starts.

Files.com gave Matrix a layer in the middle: it could standardize intake across client-owned FTP and SFTP servers, add an API path, and still land every file on the internal servers that run production.

Every New Client Brought Another Server, Another Login, Another Directory Tree

Client billing data reached the company two ways, and both had a problem. Some clients uploaded files directly to the company’s own SFTP server. For the rest, intake meant going out to each client’s own FTP or SFTP server, and every one of those servers was different: its own directory structure to check, its own set of logins to hold, and for some clients a separate UAT environment that multiplied the connections again.

That sprawl collided with a deadline that never stops. The service is time-sensitive: files have to be pulled down and processed throughout the day, because each file is rows of billing data, and a late file is a late bill. Once-a-day batch collection was never going to be enough.

Then a client asked for something the infrastructure could not do at all. The client wanted to submit files programmatically, over an API, and the company’s SFTP estate had no API front end to offer. There was no way to say yes.

Two Estates Matrix Could Not Change

The obvious fixes were unavailable, because neither end of the exchange was Matrix’s to redesign. The client side belongs to the clients: their servers, their directory conventions, their credentials, their test environments, all multiplying with every new relationship. And the company’s own side was not going to move either, on purpose. Statements and bills are produced and mailed from FTP and SFTP servers inside its own network, and the stated design goal was to keep it that way: whatever sat in front, files had to actually land on Matrix’s servers, inside Matrix’s network.

So the fix had to be a layer in the middle, and the requirements wrote themselves. It had to speak FTP and SFTP to whatever each client runs, without asking any client to change anything. It had to present a real API to clients who wanted programmatic submission. It had to deliver every file onto the internal servers where production happens, run all day rather than once a day, and be able to carry healthcare billing data, with a HIPAA path in mind from the first design conversation. Matrix selected Files.com to be that layer: the front end for client file exchange, with the files themselves landing on servers inside its own network.

A Ten-Minute Pipeline From Client Servers to the Production Floor

Files.com was configured with remote server connections to client endpoints, including production and UAT environments, and to sync against them on a ten-minute interval matched to the intraday cadence of the billing data.

The handoff was built as paired Files.com sync automations. Every ten minutes, they pulled new files from a client endpoint and delivered them through Files.com to Matrix’s internal FTP server. Success-based removal prevented duplicate collection. A file made the whole trip, client server to Files.com to Matrix’s own server, with no one touching it, and output files traveled back to clients over the same path in reverse.

The same platform also supplied the API foundation for the programmatic front door Matrix had lacked. Matrix’s engineers built against the Files.com REST API and JavaScript SDK, with folder automations that forwarded uploaded files onward into the same pipeline. Multiple concurrent outbound connections let the arrangement span clients’ directories, logins, and test environments at once.

One Intake Layer, Running All Day

With the pipeline in production since 2023, Matrix replaced fragmented, per-client collection with a single Files.com layer between client endpoints and its internal servers. Billing files now move to the production servers throughout the day, every ten minutes, with no one in the middle.

Onboarding the next client means another connection and another sync pair on a pattern that already exists, not a new integration project. That pattern is already expanding: one of Matrix’s larger clients has begun bringing its own downstream clients aboard, each routed through the same pipeline to the same internal server.

Neither Side Had to Change

Before Files.com, every new client made Matrix’s intake surface bigger: one more server to reach, one more credential set to hold, one more directory convention to learn, and still no answer for the client who wanted an API. Now the intake surface is one layer. Clients keep their servers, their directories, and their logins exactly as they are. Matrix’s production servers keep rendering and mailing statements exactly where they always have, inside its own network. Files.com carries everything between the two, all day, in both directions. A company that cannot dictate how its clients exchange files, and has no intention of moving production off its own infrastructure, consolidated the entire exchange anyway, by changing the middle instead of either end.