Independent research · Baseline 2026-09-10
Payroll Data Specs
Independent, source-backed research on what payroll systems and payroll-connectivity APIs let you read and write — deductions, contributions, income and employment, pay statements and direct deposit.
A research library covering payroll systems, unified APIs, consumer-permissioned payroll APIs, deposit switching, verification databases, and the 401(k) and earned wage access providers that depend on them: documented capabilities, integration methods, implementation constraints, and what no vendor documents. Every claim carries a confidence mark.
Research topics
5 ways into the research, grouped by what you are trying to find.
Payroll systems
What each payroll system’s own API lets you read and write — employees, pay statements, deductions, bank accounts, W-2s, hours.
Payroll data providers
Who reaches payroll data on your behalf — employer-permissioned, consumer-permissioned or from a contributed database.
Use cases
Start from what you are building: what each use case needs from payroll, and which providers document it.
Deductions and benefits write
For benefits, HSA/FSA and 401(k) builders: tax treatment, amount vs percent, effective dating, codes and retro.
Choosing an integration
Build or buy, assisted or automated, and what to check in a provider beyond its integration count.
Complete research index
All 27 published articles, listed by section. Each carries a one-sentence answer and the date of its last substantive update.
Deductions (2)
A deduction is only portable if its amount type, tax treatment, limits and effective date are explicit in the payload rather than inferred from a code.
- Do payroll systems apply a deduction change based on the pay date or the pay period start date?
It depends on which date field you set, and Paylocity is the only system we could read that distinguishes them explicitly — its Effective Date drives reporting while its Start Date, also called Begin Check Date, is the first check date actually affected, so treating the two as synonyms is a silent off-by-one-pay-period bug.
Updated
- Does ADP Workforce Now let you set an employer HSA contribution by percent or only a fixed amount?
Neither cleanly, because the question's premise does not hold: ADP Workforce Now has no employer-contribution object at all — a contribution is recorded as a deduction multiplied by -1.00 in a calculation an ADP account manager has to build — and whether the value is read as a percent depends on whether the deduction code number falls between 81 and 96.
Updated
Write-back (7)
“Supports write” should be judged by mechanism — API, file or a human with admin access — and by what the write can actually set, not by a checkmark.
- Idempotency and payroll cut-offs for benefits deduction writes
Send every deduction write with a deterministic idempotency key derived from employee and pay period, retry only inside the window your vendor honours it (five minutes on Bindbee), treat timeouts as landed, and because Bindbee's API does not expose the payroll cut-off, read the run back after a sync to confirm which period the line landed in.
Updated
- How to Write Benefits Deductions Back into Payroll After Enrollment
After enrollment closes you turn each employee's elections into deduction lines and post them to the employer's payroll system against the employer's own deduction codes, but only some integration vendors support that write and each only on a specific list of payroll systems: Bindbee, Knit, Finch and Unified.to offer it to differing degrees, while Merge, Kombo and Apideck don't document deduction write.
Updated
- Payroll deduction write support by payroll system (ADP, Workday, Paylocity, Paychex and more)
Deduction write through a unified API covers a minority of payroll systems and differs sharply by vendor: of seven unified APIs compared, Bindbee, Finch, Knit and Unified.to document a deduction write while Merge, Kombo and Apideck do not, and none of the three with per-system lists documents it on Rippling, Paycom or BambooHR, or covers Gusto.
Updated
- Can you write a retroactive deduction adjustment through a payroll API, or only for the current period?
Only for the current period, on every system we could read: ADP explicitly documents that the goal accrued and adjustment fields are not supported from the API with no workaround, Paylocity and Gusto document forward accumulation but never a correction, and Finch silently defaults a past effective date forward to today.
Updated
- Can you push a deduction to ADP Workforce Now through the API, or do you have to use a file?
Through the API — ADP documents deduction start, change and stop events for Workforce Now — but the API cannot create pre-tax codes, cannot model an employer contribution, cannot adjust retroactively, and reading the resulting actuals back requires a different API, a report, or a file after all.
Updated
- What does "supports payroll write-back" actually mean, because every vendor seems to mean something different?
It means one of four materially different things — a real API write, an API write that cannot set tax treatment, a file drop someone uploads, or a human logging in as an administrator against a two-business-day service level — and all four are routinely sold in the same column of the same comparison table.
Updated
- Which payroll systems enforce pre-tax vs post-tax at the API write?
Of the systems whose write contract is publicly readable, only Gusto lets the API see and set tax treatment directly; Paylocity and ADP both make it a property of a code that someone configured beforehand, which means most integrations cannot guarantee through the API that the deduction they just wrote will be treated pre-tax.
Updated
Codes (4)
Codes are defined per employer in most systems, so a mapping has to be validated per company, not once per payroll provider.
- Can you pull an employer's deduction code list out of a payroll system through the API, or do you have to ask them?
Yes on ADP, Paylocity, Gusto and UKG, and both ADP and Paylocity explicitly instruct integrators to discover codes at runtime rather than hardcode them — but ADP documents a hole where one-time post-tax codes do not appear in the list at all.
Updated
- How do payroll systems represent an employer contribution separately from the employee deduction?
Four incompatible ways: Gusto and Finch treat it as a first-class contribution object with match formulas, Paylocity models it as a memo earning that bypasses tax calculation, ADP has no object at all and negates a deduction into an earning, and Merge exposes it as a bare read-only number.
Updated
- How do you tell from a payroll deduction code whether it is pre-tax or post-tax?
On Paylocity you read the code's detType, whose names encode it; on Gusto you read boolean flags on the benefit type; on ADP the category is attached to the code and not restated in the API response — so on no system assessed can you infer treatment from the code string itself.
Updated
- Every ADP client we onboard has different deduction codes — is there any standard at all?
No, and there is no partial standard either: ADP and Paylocity both let each company invent its own codes, so the only reliable move is to read the employer's code list from the API at onboarding rather than mapping to anything you expect to recur.
Updated
Retrieval (6)
A read integration is only as good as its freshness, its authorisation model, how much history it returns and how it behaves between pay runs.
- API vs SFTP connectors for benefits data
Use an API connector when you need to write deductions or new hires, and an SFTP connector when the API doesn't expose the data you need or the source only offers file exports — but file connectors are read-only in Bindbee's catalog, bound to the customer's export template, and not offered at all by Apideck, Knit or Unified.to.
Updated
- How Benefits Platforms Keep Employee Census in Sync with Payroll
Benefits platforms don't own census data: they read it from each employer's HRIS or payroll system, usually once a day, through direct integrations, a unified HRIS/payroll API or SFTP file drops, and the setups that hold up add change notifications that trigger a re-read, a periodic reconciliation pass that catches anything the notifications missed, and logic that acts on the effective dates in the record rather than on the day the change arrived.
Updated
- How to read benefit enrollments from an HRIS: the four unified benefits models
Reading enrollments through a unified API means reading up to four things — the plan catalog, each employee's enrollment, dependent coverage and coverage amounts — and the seven vendors compared here model these very differently, with availability varying by connector on every vendor that models them at all.
Updated
- Detecting employee terminations and benefits coverage end dates from HRIS data
Treat INACTIVE, RETIRED, DECEASED and INACTIVE_EXTERNAL as terminations (LEAVE is not), act on the termination_date, and take the coverage end date from the benefit record's end_date — how quickly you hear about a termination depends on the vendor's sync or pass-through architecture, so run a reconciliation pass.
Updated
- Reading data from bswift, Ease, Employee Navigator and PlanSource through a unified API
Sometimes, and only as file-based sources: of the seven unified APIs compared, Bindbee lists bswift, Ease, Employee Navigator and PlanSource as read-only SFTP connectors, Apideck, Knit and Unified.to list none of the four and document no file connectors, and Merge, Finch and Kombo were not verified.
Updated
- What is the difference between an assisted payroll connection and an automated one, and does the data differ?
An automated connection is software calling an API; an assisted connection is a person with administrator credentials performing the change, and the difference is not just latency — Finch documents assisted integrations as write-only, needing a configuration period, and bound by a two-business-day service level rather than a technical response time.
Updated
Use cases (6)
Each use case needs a different slice of payroll data; the right integration depends on which fields, which direction and whose permission.
- Choosing an HRIS Integration Vendor for a Benefits Platform: A 10-Point Checklist
A benefits platform should judge an integration vendor first on whether it connects to the payroll systems its employers actually run at the data-model level, whether it can read benefits enrollment data, and whether it can write deductions back into payroll on those systems, then on sync model and cadence, SFTP fallback, pricing shape, security and region, and access to un-unified fields; no vendor of the seven compared leads on every point.
Updated
- Building a quote-ready census from HRIS data
Most of a quote census comes from four HRIS models — Employee, Employment, Dependent and Compensation — but current coverage tier and enrollment data are the hard part: they need a benefits model, the seven vendors compared here differ widely, and where a vendor does model benefits, it is not available on every connector.
Updated
- Per-connection vs per-API-call pricing for unified HRIS APIs: how to model the cost
For a benefits platform with 30 to 50 customers and daily syncs, per-call pricing is usually cheaper at list prices for read volume alone (Unified.to's Grow plan matches $65 per connection at about 65,000 calls per connection per month), while per-connection pricing wins on predictability, and coverage of your customers' payroll systems and the write you need narrows the field more than price does.
Updated
- Which Unified HRIS API Generates EDI 834 Files? (None of Them, and What to Do Instead)
None of the seven unified HRIS/payroll APIs compared here (Bindbee, Merge, Finch, Kombo, Apideck, Knit and Unified.to) documents EDI 834 generation as a product as of 1 Oct 2026; they supply the inputs to an 834, such as census, dependents, enrollments and terminations, while carrier-specific files are built by your own EDI engine, a carrier-connectivity or EDI vendor, or a ben-admin system's feed marketplace.
Updated
- Should we build direct payroll integrations or use a unified API for a benefits platform?
Use a unified API for reach and build direct for the systems your customers actually concentrate on — because a unified layer removes far less provider-specific work than it appears to, with Bindbee's deduction write still taking a different payload shape per provider and Finch documenting that configurations vary per provider.
Updated
- What should you actually evaluate in a payroll integration provider, beyond how many integrations they have?
Connector count is close to meaningless: it tells you nothing about method, depth or field coverage, and a vendor with 200 credential-mediated connections is weaker for deduction write-back than one with 40 real API integrations — score method grade, tax-treatment expressiveness, unit clarity and employer-contribution modelling instead.
Updated
Compliance (2)
Tax treatment and limits are enforced somewhere — the question is whether the payroll system, the integrator or nobody holds that responsibility.
- Kombo and Merge Alternatives for a European Benefits Platform: GDPR, EU Data and US Payroll Write
No single vendor is strongest on EU HRIS coverage, region choice for data, and benefits read plus US payroll deduction write: the vendors that document US deduction write (Bindbee, Finch, Knit, and Unified.to on Paylocity only) are not the most EU-focused, and the EU-centred options (Kombo, Apideck) document no benefits model and no deduction write.
Updated
- Sync cadence and statutory deadlines for benefits platforms
No unified HRIS API makes an HR change arrive the moment it happens: stored-sync vendors copy the source on a schedule (24 hours by default on Bindbee, Finch automated and Knit Start Up, daily on Merge Launch), pass-through vendors read the source on request but still poll for change notification unless the source sends native events, so design for worst-case latency against COBRA's 30-, 14- and 60-day clocks.
Updated
Machine-readable discovery
Stable discovery and publication-policy resources: