Deductions · reference
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.
By Eli Wilson · Published
The question assumes payroll systems have one answer. Most have one date field, which is not the same thing — and the one system that models the distinction properly shows why it matters.
Paylocity models it properly
Three date fields, three different meanings, documented:
| Field | Meaning |
|---|---|
| Effective Date | The date the change officially goes into effect for reporting purposes |
| Start Date / Begin Check Date | The first check date on which pay shows the change |
| End Date | The last check date on which processing takes place |
And a consequence that is easy to miss: the start date controls whether a record is
considered historical, current or future. Paylocity classifies records as Historical,
Current or Future Dated, so this field decides not only when the change applies but what
you see when you read the record back.
Collapsing Effective Date and Start Date into a single “start date” in your own model is a silent off-by-one-pay-period bug. It will not error. It will produce a deduction on the wrong check.
Everyone else has one date
Gusto carries effective_date — the date the employee benefit will start — and a nullable
expiration_date. There is no separate reporting-versus-check-date notion documented.
ADP Workforce Now requires effectiveDateTime on start and change events, and supports
asOfDate on reads. There is also a documented bug worth knowing before you write a parser:
known issue US1395531 states that in the GET payroll-instruction response, under
workAssignmentStatus, the field that should appear as effectiveDate is returned as
effectiveDateDate. No workaround.
Finch takes effective_date as mm/dd/yyyy, and this is the behaviour to watch: dates
undefined or in the past default to the date the request was made. Multiple distinct
effective dates in one request leave the job pending until the latest is processed.
Dated evidence table
| Documented evidence | Paylocity documents all three date fields with distinct definitions and the Historical/Current/Future classification. Gusto documents effective_date and expiration_date. ADP requires effectiveDateTime and documents US1395531. Finch documents mm/dd/yyyy and past-date defaulting. All checked 2026-09-10. |
| Strongest example | Paylocity’s own definition of Start Date as “the first Check Date on which an employee’s pay shows the new change”, separate from Effective Date’s reporting role — the distinction stated by the vendor rather than inferred. |
| What remains unproven | Which date each system actually uses for processing, since we have observed no write. How any system handles a change dated inside an in-progress run. Whether Gusto and Finch genuinely have only one notion of date or simply document only one. |
The scorecard
- How many date fields exist? If more than one, learn which drives processing before you map anything.
- Is the driving date a pay date or a period date? Paylocity says check date explicitly. Assume nothing elsewhere.
- What happens to a past date? Rejected, applied retroactively, or silently moved forward. Finch moves it — the failure mode that does not announce itself.
- Does the date affect readback classification? On Paylocity, yes.
- Test it in a sandbox before you trust it. One dated write, one observation of which check it lands on. No documentation we read answers this directly.
Frequently asked
- What is the ADP date bug?
- Known issue US1395531: in the GET payroll-instruction response, under workAssignmentStatus, the field that should be returned as effectiveDate is returned as effectiveDateDate. ADP states there is no workaround. It is cosmetic if you know about it and a parsing failure if you do not.
- What should I test first in a sandbox?
- Write a deduction change dated mid-pay-period and observe which check it appears on. That single test resolves this question for a given system, and no vendor documentation we read answers it directly.
Source limits
Not verified hands-on. We have not written a dated deduction change to any system and observed which pay period it landed in — which is precisely the test this question needs, and it is the single most valuable thing a sandbox would let us confirm. For Gusto and Finch we are inferring from field names and descriptions that only one notion of date exists; neither vendor states that explicitly. We did not assess how any system handles a change dated inside an in-progress payroll run.
Sources checked
| Source | Publisher | Document date | We checked |
|---|---|---|---|
| Pay Setup — Deductions & Earnings (date semantics) | Paylocity | — | 2026-09-10 |
| Gusto Embedded Payroll — employee benefits create | Gusto | — | 2026-09-10 |
| Deduction Instruction API Guide for ADP Workforce Now — Chapter 8, Known Issues | ADP | 2022-09-22 | 2026-09-10 |
| Enroll Individuals in Deductions — effective_date behaviour | Finch | — | 2026-09-10 |
Wrong or out of date? payrolldataspecs@gmail.com — corrections are free. How claims are scored: methodology.