Write-back · guide
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.
By Eli Wilson · Published
A benefits platform picks an integration partner on the strength of a table with a “deduction write-back” column. Six weeks into the build, the write turns out to be a person in a shared inbox. The column was not lying. It was compressing four different mechanisms into one tick.
The four things it can mean
We grade integration methods explicitly, because the method — not the number of connectors — determines whether a deduction lands before payroll closes.
| Grade | Mechanism | Latency | Fails how |
|---|---|---|---|
| A | Bidirectional API read and write | Real time | Loudly, with a status code |
| B | API read, write by some other route | Read real time, write manual | Silently, usually at month end |
| C | SFTP or file drop | Batch cadence | Loudly but late, or partially |
| D | Credential-mediated or assisted | Service level, measured in days | Quietly, when a screen changes |
Grade D is the one that surprises people. Finch’s implementation guide distinguishes Automated from Assisted integrations, and for Assisted it states the operations are “Writing only” — no read — that a configuration period is required before the first write, and that integrators should submit deduction requests three days before the customer’s payroll close date against a stated two-business-day service level.
That is not a slower API. It is a different kind of thing: a human being with administrator access, wearing an API’s clothes.
Dated evidence table
| Documented evidence | Finch publishes the Automated/Assisted split, the “Writing only” limitation, the configuration period and the two-business-day SLA. Bindbee publishes per-provider deduction payload shapes. Merge’s benefits reference documents a GET with no corresponding write. ADP documents deduction start/change/stop events. All checked 2026-09-10. |
| Strongest example | Bindbee’s own documentation shows the same “unified” deduction write taking {code, amount} for ADP, {name, employee_deduction, company_deduction} for UKG Ready, and {name, employee_deduction} for SAP SuccessFactors — three shapes behind one endpoint. |
| What remains unproven | Whether any of these writes behave as documented, since we have verified none hands-on. Whether assisted writes hit the stated SLA in practice. What the four systems that publish nothing do at all. |
The scorecard
Score any integration partner on these five, in this order. The first three are where the misrepresentation lives.
| Question | Grade A answer | Answer that should worry you |
|---|---|---|
| Who performs the write? | A service, over an API | “Our operations team”, or an unexplained SLA |
| Can the write set tax treatment? | An explicit pre-tax/post-tax field that is validated | It inherits from a code someone configured earlier |
| Is the unit in the payload? | A calculation-type or unit field | Inferred from the code, or documented per provider |
| What happens on failure? | Rejected with a specific error | Accepted, then reinterpreted or dropped |
| Is the payload shape provider-independent? | One schema for all providers | A different shape per underlying system |
On the second row, almost everybody fails. Of the systems whose write contract we could read,
only Gusto exposes tax treatment as readable state, via pretax, posttax and imputed
booleans per benefit type. Paylocity has no pre-tax field on its deduction code object at all
— treatment is a property of the company-level detType. ADP restricts its API to two
categories and requires a completed paper authorization form before a pre-tax code exists at
all.
What to do with this
Write the grade into your own vendor records, not the marketing claim. A grade-D connection for a payroll system with no public API may still be the right choice — it is often the only choice — but it should be planned as a batch process with a three-day lead time, not architected as if it were real time. The failure mode of assuming otherwise is a deduction that misses a payroll run, and the employee finds out before you do.
Frequently asked
- Is an SFTP file drop always worse than an API?
- No, and this is where most comparison tables get it wrong. For correcting deductions across several hundred employees at once, a single file beats hundreds of individual API calls with partial-failure handling and no atomicity. File-based transfer is worse on latency and on security posture; it is better at bulk. We grade it below API access and say plainly where it wins.
- Is 'write' the same as 'submitted to the current payroll run'?
- No. Writing a recurring deduction to an employee record and injecting a one-time amount into a specific run are different operations with different failure modes. ADP models these as separate deduction frequencies — OTO for one-time and EPR for every payroll — configured on the code itself rather than chosen at write time.
Source limits
Every claim here is drawn from vendor documentation and none is verified hands-on — we have no sandbox access, so we have not observed any of these writes actually applying. We could not read Rippling's, isolved's, Paychex's or Paycom's specifications at all, so this framework is built from the systems whose contracts are public and may not describe the ones that are not. The two-business-day assisted SLA is Finch's published figure and we have not timed it.
Sources checked
| Source | Publisher | Document date | We checked |
|---|---|---|---|
| Write Data — Finch implementation guide | Finch | — | 2026-09-10 |
| Create Employee Payroll Runs | Bindbee | — | 2026-09-10 |
| Employer Benefits — Merge HRIS | Merge | — | 2026-09-10 |
| Deduction Instruction API Guide for ADP Workforce Now | ADP | 2022-09-22 | 2026-09-10 |
Wrong or out of date? payrolldataspecs@gmail.com — corrections are free. How claims are scored: methodology.