payrolldataspecs.com

Indexes

Unified APIs: the deduction record

Employer-permissioned unified APIs scored on the same deduction record as the payroll systems they sit in front of. The question is not how many integrations they claim; it is what the deduction write actually expresses. Every other use case, and every other kind of provider, is in the provider directory.

4 entries · 40 cells · 16 unverified — 40% of the record. The grid below shows the confidence marks; the value and note behind every cell are in the entry detail underneath. Field definitions: methodology.

Entry Method ReadWriteTax at writeAmt/pctDatingRetroEmployerCodesAuthFreshness Verified
Finch A D D D D D U D D D D 2026-09-10
Merge B D D U U D U D D D U 2026-09-11
Bindbee A D D D D U U D D D D 2026-09-11
Kombo docs not public ? P U U U U U U U U U 2026-09-10

Entry detail

Finch

Finch · method grade A · field-level docs publicly readable · last verified 2026-09-10 · Finch Deductions API reference

Field Value Conf Note — and what a correct answer needed
Deduction read Yes — API D Deductions can be listed and retrieved, with separate endpoints for enrolled individuals and per-individual deduction state. Note that Assisted integrations are documented as "Writing only", so read is not universal across providers.
Deduction write API — full CRUD plus enrolment D The most complete deduction write contract assessed: create, update, register, enroll-individuals and unenroll-individuals endpoints. This is a genuine write model rather than a payroll-run read object.
Pre-tax vs post-tax at write Enforced by benefit type D Tax treatment is carried in the type name rather than a flag: custom_pre_tax vs custom_post_tax, hsa_pre vs hsa_post, 401k vs 401k_roth. The BenefitType enum spans 457, 401k, 401k_roth, 401k_loan, 403b, 403b_roth, 457_roth, commuter, fsa_dependent_care, fsa_medical, s125_dental, s125_medical, s125_vision, simple and simple_ira.
Amount vs percent Both — different units D type is fixed or percent, and the unit changes with it: amounts are in cents when fixed, and in basis points (one hundredth of a percent) when percent. Same field, two scales — an integration that assumes one unit is wrong by a factor of 100 or more.
Effective dating Yes — with defaulting D effective_date in mm/dd/yyyy. Dates that are undefined or in the past silently default to the date the request was made. Submitting multiple distinct effective_dates leaves the job pending until the latest one is processed.
Retro adjustment Unverified U Nothing documents correcting a deduction for a period that already ran. Note that past-dated effective_dates default forward to today rather than applying retroactively, which is adjacent to the question but not an answer to it.
Employer contribution First-class, tiered D company_contribution parallels employee_deduction with the same type and amount shape. On create, company_contribution supports type "match" with a tiers array of {match, threshold} integers, so tiered matching formulas are expressible.
Code taxonomy shape Vendor-fixed taxonomy D A fixed BenefitType enum, normalised across providers rather than exposing each payroll system’s own codes. The docs caveat that "these are general configurations and may vary per provider" and direct callers to the /provider endpoint for specifics.
Auth model Bearer token D HTTP bearer auth with an access token, plus a required Finch-API-Version header (default 2020-09-17).
Data freshness Method-dependent, SLA-bound D Automated integrations write "near-real-time in the provider". Assisted integrations are "Writing only", require a configuration period before the first write, and carry a stated two-business-day SLA — integrators are told to submit deduction requests three days before the customer’s payroll close date.

Merge

Merge · method grade B · field-level docs publicly readable · last verified 2026-09-11 · Merge HRIS — Employer Benefits

Field Value Conf Note — and what a correct answer needed
Deduction read Yes — API D Benefits, employer benefits and employee payroll runs are all readable. Deductions appear as line items on the employee payroll run object alongside earnings and taxes.
Deduction write None for benefits D The benefits endpoint is documented as GET /api/hris/v1/benefits returning a list, with no POST or PATCH. Merge's writing-data guide does not enumerate writable models — it directs readers to the per-model API reference — and the only HRIS write it demonstrates is /employees. So deduction write is absent from the reference rather than merely undocumented.
Pre-tax vs post-tax at write Unverified U No pre-tax or post-tax indicator on EmployerBenefit or Benefit. Merge's own blog describes payroll data as splitting into pre-tax deductions, tax, post-tax deductions and reimbursements, but that categorisation is not exposed as a field on any benefit object.
Amount vs percent Unverified U No percent-versus-amount field. employee_contribution and company_contribution are plain integer or number values with no unit or basis flag.
Effective dating Read-side only D The Benefit object carries start_date, effective_date and end_date. Since no write is documented, these are readable but not settable.
Retro adjustment Unverified U Not documented.
Employer contribution Read-only amount D company_contribution is present as a bare number, described only as "The company's contribution". No match type, no tiers, no annual maximum, no elective flag.
Code taxonomy shape Coarse vendor taxonomy D EmployerBenefit carries a deduction_code string of up to 60 characters, plus benefit_plan_type enumerated as only MEDICAL, HEALTH_SAVINGS, INSURANCE, RETIREMENT and OTHER. Five values to cover every deduction type a payroll system distinguishes — compare Bindbee's 30-value sub_type enum over the same ground.
Auth model Bearer key + account token D Two headers, both required on every request: Authorization: Bearer YOUR_API_KEY identifying the application, and X-Account-Token: END_USER_ACCOUNT_TOKEN identifying whose linked account to read. The account token is issued when the end user authenticates through Merge Link.
Data freshness Unverified U Merge's authentication and HRIS basics documentation states no sync frequency and no data freshness guarantee. Compare Bindbee, which publishes a 24-hour default. An integrator cannot size a pre-payroll sync window from Merge's public documentation.

Bindbee

Bindbee · method grade A · field-level docs publicly readable · last verified 2026-09-11 · Bindbee — Create Employee Payroll Runs

Field Value Conf Note — and what a correct answer needed
Deduction read Yes — API D GET endpoints for benefits, employer benefits, benefit coverages, dependent benefits, payroll codes, payroll runs, payroll run calendars and employee payroll runs.
Deduction write API — but provider-shaped D Deductions are written through create-employee-payroll-runs, which accepts a deductions array. The unified model is not unified here: the documented shape differs per provider — ADP takes {code, amount}, UKG Ready takes {name, employee_deduction, company_deduction}, SAP SuccessFactors takes {name, employee_deduction}. Note also that across the whole HRIS surface only four creates exist (employee, employee payroll runs, time off, timesheet entries) — there is no benefits write at all.
Pre-tax vs post-tax at write Not represented D Absent from both schemas that could carry it. The HrisPayrollCode object has no pre-tax or post-tax indicator, and none of the three documented per-provider deduction write shapes carries one either. A caller cannot assert tax treatment through Bindbee.
Amount vs percent Not represented D No percentage field on HrisPayrollCode and no percentage notation in any documented write shape — every example is a numeric amount.
Effective dating Unverified U No effective-dating field appears in the documented deduction write shape, and the payroll-code object carries none either. Dates on the parent payroll run describe the run, not the deduction change.
Retro adjustment Unverified U Not documented.
Employer contribution Provider-dependent D company_deduction appears in the UKG Ready shape but not in the ADP or SAP shapes, so employer-side support is a function of which provider sits behind the unified endpoint rather than a property of the API.
Code taxonomy shape Normalised read, passthrough write D Both at once. HrisPayrollCode normalises into type EARNING / DEDUCTION / TAX plus a 30-value sub_type enum (REGULAR, OVERTIME, HEALTH, DENTAL, VISION, HEALTH_SAVINGS, FLEXIBLE_SPENDING, RETIREMENT, GARNISHMENT, FICA, MEDICARE and so on) — a much finer taxonomy than Merge. But the write takes the provider's own raw code, for example ADP code "REI", so codes are normalised on the way out and passed through on the way in.
Auth model Bearer key + connector token D Two headers on every request: Authorization: Bearer YOUR_BINDBEE_API_KEY for the application, and X-Connector-Token: END_USER_CONNECTOR_TOKEN for the end user's connection, issued once the user completes Bindbee's Magic Link flow.
Data freshness 24h default, adjustable D Data synchronisation runs once every 24 hours by default, adjustable on request. Worth sitting with: a product used to move benefit deductions defaults to a one-day-stale read, which is longer than the gap between a mid-week election change and a Friday payroll close.

Kombo

Kombo · method grade ? · field-level docs NOT publicly readable · last verified 2026-09-10 · Kombo — no public field-level deduction reference located

Field Value Conf Note — and what a correct answer needed
Deduction read Yes — payslip line items P Kombo describes a Payslip object representing a completed pay run with line items including earnings, deductions, taxes, reimbursements, bonuses and allowances, and a PayRun object. Sourced from Kombo marketing pages rather than a field-level reference; docs.kombo.dev/hris/deductions returns 404.
Deduction write Unverified U Kombo states generally that customers can "read and write data across every supported system using the same set of endpoints", and that admins can manage payroll deductions. No field-level deduction write reference was located to confirm what that means for deductions specifically.
Pre-tax vs post-tax at write Unverified U No public field-level reference located.
Amount vs percent Unverified U No public field-level reference located.
Effective dating Unverified U No public field-level reference located.
Retro adjustment Unverified U No public field-level reference located.
Employer contribution Unverified U No public field-level reference located.
Code taxonomy shape Unverified U No public field-level reference located.
Auth model Unverified U No public field-level reference located.
Data freshness Unverified U Described as real-time employee change tracking in marketing material; no stated latency for deductions.

Coverage roadmap — located, not yet assessed

Named here rather than added to the table as unverified rows, and excluded from the counts above.

Not yet assessedStatus
Knit, Apideck, Unified.to, Truto Knit, Apideck and Unified.to are profiled on the use-case record in the provider directory; not yet assessed on this deduction record. Truto not yet assessed.
Payroll Integrations Point solution rather than a general unified API. Not yet assessed.