Write-back · comparison

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.

By Eli Wilson · Published 2026-09-10

No system we could read exposes a retroactive deduction adjustment through its API. On ADP this is documented as a limitation; elsewhere it is documented by omission.

What each system says

ADP — stated outright, twice

ADP’s Chapter 8 is unusually candid, and two entries bear directly on this. US1395538: the goal ACCRUED and ADJUSTMENT fields are not supported from the API. Suggested workaround: there is no workaround available.

Then US1390613, on the one adjacent field that does exist: the write payload uses deductionGoal.goalBalanceAmount for the field the UI calls Additional Amount Already Taken, while the meta response specifies GoalAccruedAmount for that purpose. Also no workaround. So the field you would reach for is documented as pointing at the wrong concept.

Paylocity and Gusto — the shape of the silence

Paylocity documents Goal as a lifetime deduction limit accepting only positive values, PaidToDate as a running tally toward it, and PaidYearToDate as not interacting with either. All three describe accumulation going forward. Nothing describes unwinding a period that already ran.

Gusto’s API reference has no correction operation. Its help centre carries Fix past benefit amounts and Benefits deduction corrections — which implies a support-mediated path exists, and implies equally that it is not something you can call.

Finch — the dangerous one

Finch documents that effective_date values which are undefined or in the past default to the date the request was made. A backdated correction therefore returns success and applies from today. Nothing fails. Your reconciliation shows the deduction fixed; the prior periods are untouched.

Dated evidence table

The scorecard

1. Is there a documented correction operation? If no, assume none exists and design for escalation.
2. What happens to a backdated effective date — reject, apply, or silently move? Finch moves it. Test this specifically; it is the failure that does not announce itself.
3. Can you read enough to compute the delta? You need per-period actuals, which usually means the payroll-run read rather than the configured deduction.
4. Who performs the amendment, and how do you hand off? This is a product requirement, not an edge case. A misclassified deduction discovered at W-2 time spans many periods.
5. Do you log the escalation? If treatment was wrong for six months, someone will ask when you knew.

Frequently asked

What does ADP's US1395538 actually say?

That the goal ACCRUED and ADJUSTMENT fields are not supported from the API, with the suggested workaround recorded as: there is no workaround available. Those are precisely the fields you would need to correct an amount already taken.

What about Finch's effective_date — can I backdate?

No. Finch documents that effective_dates which are undefined or in the past default to the date the request was made. So a backdated write is accepted and silently applied forward, which is arguably the most dangerous behaviour in this article because it does not fail.

Source limits

Sources checked

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