Census file vs HRIS integration: which path your employee data should take

Key takeaways

• An HRIS integration is the better path on every axis that matters: freshness, direction, data quality, and who carries the maintenance. Route to it whenever the employer's system supports it and they can authorize access.
• A census file drop is the fallback, not the co-equal. It exists for employers whose system of record has no usable API, or who won't authorize one.
• Fallback doesn't mean temporary. A durable share of most platforms' book will stay on files, so the file path has to be run properly rather than tolerated.
• The single most dangerous difference is that a census file is a full snapshot and an API integration delivers deltas. An employee missing from this week's file is not automatically a termination.
• File intake only works against a published template. If you don't hand employers a column spec, you inherit a different mapping problem per customer.
• Both paths should write to the same normalized model, so moving a customer from file to API later is a routing change, not a data migration.

Census file vs HRIS integration: which path your employee data should take

Ask a benefits-admin platform how employee data gets in, and you'll usually get two answers in the same sentence: a file lands in an SFTP folder, and an HRIS integration pulls the same information automatically.

Those are not two equivalent options. An HRIS integration reads from the system of record directly, on a cadence you control, and where the source system supports it, writes back. A census file is a snapshot an employer exports on their own schedule, in whatever shape their payroll system happens to produce, with no return path. On freshness, direction, data quality, and who carries the maintenance burden, the integration wins every time.

So the routing rule is simple: use an HRIS integration wherever one is available, and fall back to a census file only where it isn't. What makes that rule harder than it sounds is that "isn't available" is a permanent condition for a real slice of your customer base, and a fallback you run badly costs more than the primary path ever will.

This guide covers what each path actually delivers, where the file path is genuinely the right call, the template and full-snapshot semantics that keep file intake from breaking eligibility, who should host the SFTP endpoint, and how to run both against one data model.

The two paths, side by side

A census file drop is exactly what it sounds like: the employer, or someone acting for them, exports a list of covered employees and dependents and pushes it to an SFTP endpoint on a schedule they control, often weekly or tied to a payroll cycle. An HRIS integration is a programmatic link into the employer's system of record, it reads employee data directly, and where the system supports it, writes updates back.

Read that table in one direction and the conclusion is obvious. The interesting question is the last row.

Why the fallback never goes away

The case for treating file intake as a first-class capability isn't that files are good. It's that the employers who need them don't graduate off them.

Newfront runs the largest connector deployment in Bindbee's customer base, and still moves legacy CSV, XML, and fixed-width exports through the same normalized model as its native API connections. That's a well-resourced national brokerage that has not migrated everything to API, because a share of its employer accounts run systems that will never clear the bar for one. Integration deployment there went from 8–12 weeks to roughly 48 hours, and the file path came along rather than being retired.

The pattern holds at the segment level. The most file-entrenched buyers, established benefits administrators and TPAs with their own data ops teams,  are also the highest-ACV ones. Telling that segment to rip out its file feeds is not a migration plan; it's a lost deal.

There's a workforce-level version of the same story. Retirement benefits are available to 59% of private-industry workers at establishments with fewer than 100 employees, against 90% at establishments of 500 or more, per the Bureau of Labor Statistics' Employee Benefits in the United States, March 2025. Small employers are less benefits-mature in general, and a slice of them are running HR systems with no API worth connecting to. Treat that as directional colour rather than proof, benefit availability isn't a clean proxy for API availability, and plenty of 40-person firms run Gusto or Rippling, but it points the same way as the customer evidence does.

The conclusion is the same either way: build for the API path, and run the file path properly, because it is going to be there for a long time.

What a census file has to carry, and the template that gets it there

A census file earns its place only if it can become eligibility data, and eligibility data has a specific shape. The 834 Benefit Enrollment and Maintenance transaction set is the HIPAA-adopted EDI standard carriers expect for enrollment and eligibility, and every census file is in effect a rough draft of one (see our guide to the 834 format).

None of that shape arrives for free. Employers rarely export a census the same way, one labels a dependent record "EE + Spouse," another spells it "Employee + Spouse," a third uses a numeric code, so file intake has to run against a published template rather than accepting whatever an employer's payroll system happens to produce. Publishing the template is what lets one parsing pipeline handle every employer instead of one pipeline per customer.

Here is the minimum column set that maps cleanly into eligibility:

The identifier row is the one that causes the most damage when it's wrong. An employee ID that changes between uploads, because the employer re-exported from a different report, or because someone keyed off email, produces a terminated record and a new hire for the same person, on the same day.

The full-snapshot problem, and why it's the biggest gap between the two paths

An HRIS integration delivers deltas: you ask what changed since a timestamp and you get exactly that. A census file is almost always a full snapshot: the employer's entire covered population, re-stated every time.

That difference produces the most common census bug in benefits administration. An employee is in last week's file and absent from this week's. Terminated? Or did the employer's export silently truncate at 5,000 rows, or run before a system update finished, or get generated from a filtered view someone changed?

Get it wrong and you cancel someone's coverage.

Four rules keep that from happening:

1. Absence is not termination by default. Treat a missing row as an unknown, and require an explicit termination_date or a TERMINATED status to end coverage. If an employer genuinely wants absence-means-termination semantics, make it a per-customer setting they opt into knowingly.
2. Threshold the delta. If a file's row count drops by more than a set percentage against the last accepted load, halt and alert instead of processing. Most truncation bugs are caught by this one rule alone.
3. Validate before you commit. Column presence, enum values, date formats, and duplicate identifiers all get checked against the template before a single record is written.
4. Reconcile on identifier, not on position. Match every row to an existing record by the stable employee identifier, and report unmatched rows rather than inserting them blindly.

An HRIS integration sidesteps all four, which is the clearest single argument for routing a customer to the API path whenever you can.

What happens when a file never arrives

API-side failure is loud. A connector sync that fails throws an error, and a webhook on that connector's sync status tells you before the next scheduled run would have.

File-side failure is silent. Nothing happens. No error, no alert, just an employer whose Tuesday upload didn't run, and a platform working from three-week-old eligibility data because nobody was watching for an absence.

Monitoring the file path means monitoring for the thing that didn't occur:

• Expected-arrival windows per customer, with an alert when a file doesn't land inside one.
• A defined outcome for a malformed or partial file — rejected wholesale, or partially loaded with a report, decided in advance rather than at 2am.
• Ingestion status surfaced somewhere a human looks, the same way connector sync status is.
• A named owner for the alert on both sides: someone at the employer who can re-run the export, and someone on your side who chases it.

Who hosts the SFTP endpoint

Hosting an SFTP endpoint means running an authenticated SSH server that a customer's payroll or HR team uploads to. Per the IETF's SSH transport specification, the default port for that connection is TCP 22, registered with IANA. Someone has to run that server, manage its credentials, and notice when an expected file never arrives.

What's actually sitting on that server

A census file contains SSNs, dates of birth, dependent records, and coverage elections. It arrives as a flat file and it sits at rest until someone deletes it. That is the first question a security reviewer asks, and the hosting decision above is really a decision about who answers it.

Whoever hosts the endpoint owns four things: encryption at rest and in transit, key issuance and rotation, access logging on who read which file and when, and a retention rule, how long a census file stays in the drop after it's been ingested, and what deletes it. A file that has been successfully processed and is still sitting in the folder six months later is PHI exposure with no remaining business purpose.

If you're evaluating a partner for any of this, the posture worth checking is the same regardless of who you pick: SOC 2 Type II, ISO 27001, HIPAA compliance with a BAA available, GDPR DPA, encryption in transit and at rest, and, where residency matters, a deployment model that keeps data in the region you need. Bindbee's own certifications and reports are at its trust center.

Credential handling is where the two paths diverge most

API authentication can be delegated. The employer authorizes access in their own system, and the platform never holds or stores their raw credentials. File transfer has no equivalent: whoever hosts the endpoint holds the keys, and that's structural rather than a matter of implementation quality.

Bindbee's Magic Link is one example of the delegated version, employer authorization embedded directly into onboarding, in the browser, with no front-end code required. There is no file-side analogue to build.

Running both against one data model

A file path and an integration path only work together if they converge before anything downstream touches the data. Otherwise you have two customer records, two definitions of "dependent," and two different truths about who is enrolled in what.

Both the file parser and the API connector should write to the same normalized model, through the same connector layer, so "which path this customer is on" is a routing decision rather than a fork in your schema. (See how connectors work, the connector is the unit, whichever way delivery happens.)

Bindbee's shared model spans 40+ unified models across HRIS, payroll, ATS, and LMS, with the benefits surface covering employee and employer benefits, benefit coverages, dependents and dependent benefits, plan category, coverage tier, contributions, and effective dates. A coverage-tier change resolves to the same field on the same dependent record whether it arrived as a row in a census file or through a connector sync.

For employer-specific fields that don't fit the standard shape, Bindbee's Custom Fields map any upstream field onto the unified model through a JMESPath expression, scoped per integration or per connector, without a schema change.

With one model behind both, routing a customer is short:

1. Supported system, authorization available → HRIS integration. This is the default, and it should be the answer for most of the book.
2. No usable API, or the employer won't authorize one → census file. Run it against the published template with the snapshot rules above.
3. Neither routing is permanent. A customer moves from file to API later without a data migration, because both already write to the same model.

Routing to the API side also buys something the file path can't offer at all: because those connections read and write, a downstream change like a benefit election update can flow back out through the same connection instead of waiting for the next file cycle. (See two-way sync.)

Getting to production

Standing this up is faster than most teams expect. Typical customers go live in days, with contract-to-first-production-sync running around 48 hours once mapping, and for file customers, the template is settled. Pricing matters here too: a flat tier rather than a per-record or per-sync usage fee means carrying a file customer alongside your API base doesn't change your unit economics.

Whatever routes to the API side draws from 67+ connected HRIS, payroll, ATS, and benefits systems, feeding the same model your file path writes to. Bindbee builds both, the connectors and the file parsing, so your team spends its engineering time on the routing decisions above instead of on SSH servers and column mappings.

See how it works for census data sync, or book a demo.

FAQ

What is an HRIS integration? 

An HRIS integration is a programmatic connection into an employer's system of record that reads employee data, and where the system supports it, writes back,  normalizing it into a common model. It's the primary intake path for a benefits or HR-tech platform, with file feeds as the fallback for employers whose systems can't support one.

What columns does a census file need? 

At minimum: a stable employee identifier, name, date of birth, hire and termination dates, employment status, hours or classification where eligibility keys off full-time status, plan identifier, coverage tier, coverage effective date, and dependent rows carrying relationship and date of birth. The full column spec with formats and examples is in the template table above.

What happens if an employee is missing from this week's census file? 

Treat it as unknown, not as a termination. A census file is a full snapshot, so an absent row can mean a termination or a truncated export, and only an explicit termination date or status should end coverage. Row-count delta thresholds that halt the load are what catch the truncation case before it reaches eligibility.

Does SFTP use port 22? 

Yes. SFTP runs as an extension over the SSH-2 secure channel, and TCP port 22 is the IANA-registered default for SSH. Hosting an SFTP endpoint means running an authenticated SSH server that a customer's team uploads to, whether the platform, the customer, or a third party runs it.

What's the difference between an SFTP census file and an HRIS integration? 

An SFTP file is a full snapshot the employer pushes on their own schedule with no return path. An HRIS integration is a programmatic pull, and where supported, a push,  directly from the system of record, delivering only what changed. Both can land in the same data model; they differ in freshness, direction, data quality, and who maintains the pipeline.

‍