Write-back · comparison

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.

By Eli Wilson · Published 2026-10-01

Deduction write through a unified API covers a minority of payroll systems, and coverage differs sharply by vendor. Of the seven unified APIs compared here, four document a deduction write: Bindbee, Finch, Knit and Unified.to. Merge, Kombo and Apideck do not. Three of the four publish per-system status:

• Bindbee lists deduction write as Supported for POST /employee-payroll-runs.
• Knit documents enrolling an employee in a deduction on ADP Run, ADP Workforce Now, Paycor, Paychex, Paylocity, PrismHR, Avionte and QuickBooks Payroll, with update and unenroll on a subset.
• Unified.to has deduction create and update endpoints, but among the US payroll systems checked only Paylocity lists them.

Finch sells deduction write on its Pro plan without a per-system list reviewed here. None of the three vendors with per-system lists documents deduction write on Rippling, Paycom or BambooHR, or covers Gusto.

Vendor-level summary (as of 1 Oct 2026)

For a broader vendor comparison, see choosing an HRIS integration vendor for a benefits platform.

Matrix: deduction write by payroll system

Sources: Bindbee’s model availability matrix; Knit’s docs for enroll-employee-in-deduction (updated 16 Jun 2026), update-employee-deduction, unenroll-employee-from-deduction and create-deduction; Unified.to’s per-integration pages. Last checked: 1 Oct 2026.

Key: for Knit, “Not documented” means the system is not in the supported-apps list for its deduction endpoints. For Unified.to, “Not verified” means the integration page was not checked for this article. For Bindbee, “Beta” means built but not battle-tested and enabled on request.

Knit’s marketing pages list deduction endpoints for some apps (for example BambooHR and Gusto) that its docs’ supported-apps lists don’t include; this matrix uses the docs lists only. Unified.to returns 501 for operations an integration doesn’t support.

Merge, Kombo and Apideck have no column because none documents deduction write on any system. Finch has no column because its per-provider deduction coverage was not reviewed.

Related models on the same systems (Bindbee)

Bindbee’s matrix also shows employee create and benefits read per connector, which matter if you plan to read elections or create employees on the same systems. Knit documents employee create on about 41 apps; Unified.to lists employee create and update on ADP WFN, Paycor, Paylocity, Dayforce and BambooHR, update only on Paychex and UKG Pro, and read only on Workday, Rippling, Paycom and UKG Ready.

The live model availability matrix is the source of truth and changes as connectors move from Beta to Supported. For how other vendors model benefits, see reading benefit enrollments from an HRIS.

How to read these lists against your customer list

Bindbee states 102+ HRIS integrations; its public integrations page at docs.bindbee.dev lists 90 HRIS/payroll connector entries today. Knit’s docs list 72 HRIS/payroll/directory apps. Unified.to publishes no single HRIS count. None of those numbers tells you about deduction write, so work system by system:

1. Export your customers’ payroll systems with headcount and plan-year renewal date.
2. For each shortlisted vendor, bucket them into documented write, Beta or partial (for example enroll only), not documented, and not listed.
3. For Beta or partial systems, test on a real customer sandbox before committing to a go-live date.
4. For not documented and not listed, decide whether you’ll keep a manual or file process, use passthrough where the vendor API allows it, or request a connector. Bindbee’s pricing FAQ says custom connectors “typically take 7-10 days” after a sandbox is received (its own figure); Apideck lists new connector builds as a paid add-on; for the others, ask.

What differs per system even when “Supported”

The endpoint is the same; the request is not. The detail below is from Bindbee’s docs, which publish per-connector request bodies. Knit’s and Unified.to’s endpoints are shaped differently (enroll / update / unenroll on an employee deduction, and create / update on a Deduction record), so ask what one call does in each payroll system.

In Bindbee, call GET /employee-payroll-runs/meta/post before each write to fetch the connector’s schema: required fields and integration_params. Known differences from the deduction write guide and the create endpoint docs:

• Workday identifies a deduction by type + id, accepts one deduction per request, rejects a body that has both earnings and deductions, and needs payroll_run set to null.
• ADP Workforce Now identifies a deduction by code, also takes payroll_file and payroll_process_name, and accepts earnings, deductions and taxes in one body.
• UKG Ready needs payroll_run and paystatement_type_id. Deductions are identified by name, with employee_deduction and company_deduction as separate amounts.
• SAP SuccessFactors needs payroll_provider_id, payroll_person_id, payroll_employment_id and a start_date / end_date. Deductions are identified by name, with employee_deduction.
• Every system uses the customer’s own payroll codes. Read them with GET /payroll-codes (type DEDUCTION). Which code maps to which plan is the customer’s decision, so build a mapping screen and don’t guess.

Workday, one deduction per request:

POST /api/hris/v1/employee-payroll-runs
X-Idempotency-Key: payroll-019b2647-8e14-7fcf-aa9e-aeff6ab205b2-2025-12-31

{
  "employee": "019b2647-8e14-7fcf-aa9e-aeff6ab205b2",
  "payroll_run": null,
  "start_date": "2025-12-01",
  "end_date": "2025-12-31",
  "deductions": [
    { "type": "Workday_Deduction_Code", "amount": 200, "id": "W_1042S_2015" }
  ]
}

ADP Workforce Now:

{
  "employee": "01929ee7-28b6-7abc-b4d3-e78610669c82",
  "deductions": [
    { "code": "REI", "amount": 0.01 },
    { "code": "KL1", "amount": 0.04 }
  ],
  "payroll_file": "023321",
  "payroll_process_name": "Ded Ear writeback"
}

Rules that apply to all Bindbee connectors:

• Each write targets one pay period or one payroll run, not a recurring deduction election (create endpoint docs). Workday and SAP SuccessFactors take start_date / end_date, UKG Ready takes a specific payroll_run id, and ADP takes a payroll_file batch. To keep a deduction running, write it every period. To change a contribution, write the new amount for the next period. To stop one, don’t write the next period. There is no PATCH or PUT.
• The docs don’t say whether a second write with the same code in the same period adds to or replaces the first line. Read the run back to confirm.
• Send an X-Idempotency-Key derived from employee + period (idempotency). Bindbee honours a key for five minutes. Reusing a key with a different body returns 409, and a key derived from employee + period collides on a same-period correction. Passthrough writes cannot carry an idempotency key.
• Writes go straight to the source system. They don’t appear on a GET until the next sync, and a timed-out write may still have landed.
• Payroll periods close. A late write can land in the next open period, and the cut-off isn’t exposed through the API. Read back start_date, end_date and check_date. More in idempotency and payroll cut-offs for deduction writes.

The full step-by-step flow is in how to write benefits deductions back into payroll after enrollment.

Limits by vendor

Bindbee

• Deduction write: Supported.
• No deduction write on Rippling, Paycom (API), BambooHR, HiBob, Deel or TriNet. If they make up a large share of your book, this matters more than any price.
• Gusto is not listed. SFTP connectors are read-only, so payroll reachable only by file can’t receive writes.
• No update endpoint and no standing election: your system owns the per-period schedule. Compensation changes have no unified write; use passthrough where the vendor’s API allows it.

Merge

• Deduction write is not documented in Merge’s HRIS common models as of 1 Oct 2026. Documented HRIS writes are Employees and Time Off.

Finch

• Deduction write is on Pro, marked “Employer Fee Required”, and Pro pricing is not published.
• Per-provider deduction coverage was not reviewed here. Assisted connections write changes back within 2 business days.

Kombo

• No deduction write path in Kombo’s OpenAPI; payroll read (pay runs, payslips) lists UKG Pro and UKG Ready only.

Apideck

• No deduction or contribution write. Payroll is read-only, with deductions and benefit amounts inside employee payroll records.

Knit

• Enrollment is documented on eight systems; update on five (ADP Run, ADP WFN, Paycor, Paychex, Paylocity); unenroll on six (those five plus QuickBooks Payroll). PrismHR and Avionte list enroll only.
• Workday is listed only for company-wide deduction create. Not documented for UKG, Dayforce, SAP SuccessFactors, Rippling, BambooHR or Paycom. Gusto is not in the docs HRIS list.

Unified.to

• Paylocity is the only US payroll system checked with deduction create/update. Paychex and UKG Pro list read and remove only; ADP WFN, Paycor and UKG Ready read only.
• Workday, Rippling, BambooHR, Dayforce and Paycom list no Deduction object at all.

Next step

Bucket your customers’ payroll systems against each vendor’s published write coverage before choosing: Bindbee’s live model availability matrix, Knit’s supported-apps lists for its deduction endpoints, Unified.to’s per-integration pages, and Finch per provider.

Frequently asked

Can I write deductions into Workday?

Bindbee lists Workday as Supported, one deduction per request. Knit lists Workday only for company-wide deduction create, not employee enrollment. Unified.to's Workday integration has no Deduction object.

What is the difference between Supported and Beta?

In Bindbee's model availability matrix, "Beta" means built but not battle-tested and enabled on request. "Supported" carries no such caveat. Knit and Unified.to don't use this distinction in the lists checked.

Source limits

Sources checked

Wrong or out of date? payrolldataspecs@gmail.com — corrections are free. How claims are scored: methodology.