A Health Plan Administrator Used Files.com to Support 300 Payroll Systems Without 300 Integrations

A preventive health plan administrator sells a plan that lives inside the paycheck. The Section 125 plan recalculates eligibility per employee, per pay cycle, from wages, hours, filing status, and dependents. The administrator covers the work of wiring the plan into each client’s systems.

A plan priced per paycheck has to live inside the payroll run. Every cycle, each employer client sends the administrator its payroll and census data: hours, salaries, locations, deductions. The administrator runs its analysis and returns a formatted payroll import file. That file is the last step before the client finalizes payroll.

The administrator’s clients run payroll on roughly 300 different payroll software products, and it controls none of them. The company spent a year building native integrations against that landscape, and by its CTO’s own count, the work covered less than 20 percent of the market.

Every new client on an unsupported payroll system presented a choice: join a build queue that a 300-product market guarantees will never catch up, or fall back into the manual handling model the company was founded to retire. The integration gap decided which employers the company could take on, at the same moment it was onboarding new client groups of several hundred members at a time.

The Manual Precedent Could Not Scale

The rest of the market had a precedent, and it was manual. Before the administrator was stood up as the automated line of the business, an affiliated back office had done this same work by hand for three years, moving files through ShareFile, client by client, cycle by cycle.

And this is not data that can travel loosely while the engineering catches up. A payroll file carries wages, deductions, dependents, and eligibility detail. The company is itself SOC 2 Type 2 and HIPAA compliant, and it sits at the final step before paychecks go out. A file that is late or lost does not inconvenience anyone; it holds up payroll.

A Directory Per Client, an Automation Behind Each One

No amount of integration engineering closes a 300-format gap. But every one of those payroll products, whatever its API story, can export a file and import one. What the administrator needed was not integration number sixty-one. It needed a layer that connects to any payroll system on day one: a place each client can drop files that only that client can reach, credentialed sign-ins with audit logging rather than open links, protocols any client’s payroll team already has, automation that picks up each file the moment it lands, and a HIPAA business associate agreement behind all of it. The company selected Files.com to be that layer.

The administrator created a directory for each client on Files.com, with credentialed user accounts for the client’s payroll and HR staff. A client signs in over SFTP or the web, sees only its own directory, and every access is logged. During a two-to-six-week onboarding, the client’s team uploads its census and payroll data there. After that, the exchange settles into the payroll-cycle rhythm: drop the file, pull back the result.

Files.com Automations were configured to watch the client directories. When a payroll file lands, the automation picks it up and hands it to the administrator’s processing chain. The company’s own systems drive the workflow from there through high-volume use of the Files.com REST API, creating an automated, end-to-end payroll exchange instead of another manual routine. The finished payroll import file returns to the client’s directory, formatted for that client’s own payroll system, and the client loads it before finalizing the run.

The administrator still builds native integrations for the payroll platforms large enough to justify one. Files.com carries every client the build queue has not reached, which is most of the market.

Every Payroll System Became a Supported Payroll System

With the pipeline in production, Files.com replaced both halves of the old model: the manual per-cycle handling the back office had run on ShareFile for three years, and the ceiling that native integration coverage put on which clients the company could sign.

• Any employer can become a client, whatever they run payroll on. The payroll system a prospect uses no longer decides whether the administrator can serve them; the file-drop pipeline works against the full market of roughly 300 products.
• Adding a client on an unsupported payroll system is a directory and a set of credentials, not an integration project. New employer groups, typically several hundred members each, onboard in batches and settle into a per-cycle exchange within two to six weeks.
• Per-cycle file handling runs end to end with nobody touching the files. Payroll files arrive, get processed, and return automatically, and billing runs automated alongside the file workflows.
• Sensitive payroll and census data moves through credentialed, logged accounts under a HIPAA BAA, not through ad hoc file sharing.

The Gap Stopped Mattering

The administrator did not close a 300-product integration gap by writing 300 integrations. It made the gap stop mattering. Every payroll system in the market can already export a file and import one, and Files.com turns that lowest common denominator into a governed, automated integration layer that reaches the whole market at once.