Codes · comparison
How do payroll systems represent an employer contribution separately from the employee deduction?
Four incompatible ways: Gusto and Finch treat it as a first-class contribution object with match formulas, Paylocity models it as a memo earning that bypasses tax calculation, ADP has no object at all and negates a deduction into an earning, and Merge exposes it as a bare read-only number.
By Eli Wilson · Published
Ask five payroll systems how they represent the employer side of a benefit and you get four different answers, none of which is a superset of the others. This is the field where the “unified data model” idea comes closest to breaking outright.
The four models
| System | Model | Formula support |
|---|---|---|
| Gusto | First-class contribution object | Amount, percentage or tiered, plus elective and catch_up |
| Finch | First-class company_contribution | type: "match" with a tiers array of {match, threshold} |
| Paylocity | Memo earning, not a deduction | Automated calculation based on plan compensation and deferrals |
| ADP Workforce Now | No object — negated deduction | None; a custom calculation built by ADP staff |
| Merge | Bare read-only number | None |
Gusto and Finch — a real object
Gusto’s employee benefit carries contribution with type and value, an elective boolean
marking the contribution as matching, company_contribution_annual_maximum, and catch_up
scoped to 401(k) and Roth 401(k) for employees over 50. Finch’s company_contribution
mirrors employee_deduction in shape, and on create supports a tiered match — the only
tiered-formula support we located in any public specification.
Paylocity — it is an earning, and it is informational
Paylocity does not model the employer side as a deduction at all. Memo: Employer Match is
documented as automatically used for retirement employer match codes such as 401ER, and
HSA Employer Contribution is a separate earning type. Memo earnings report informational
amounts — for example employer-paid benefit contributions — without directly affecting net
pay, and bypass tax calculation.
This is coherent, and it means an integration looking for employer contributions on the deduction side will find nothing.
ADP — the negation
Covered in detail in our reference on employer HSA contributions in ADP Workforce Now: there is no contribution object, and the documented approach is a calculation built by an ADP account manager that multiplies the employee deduction by -1.00 to produce an earnings code.
Merge — a number with no formula
company_contribution exists on the Benefit object as an integer or number, described only as
“The company’s contribution”. No match type, no tiers, no annual maximum, no
elective flag — and no documented write.
Dated evidence table
| Documented evidence | Gusto publishes contribution, elective, catch_up and company_contribution_annual_maximum. Finch publishes company_contribution with type: "match" and tiers. Paylocity documents Memo: Employer Match and HSA Employer Contribution as earning types that bypass tax calculation. ADP documents the ×-1.00 mechanism. Merge documents a bare company_contribution. All checked 2026-09-10. |
| Strongest example | Paylocity placing employer match on the earnings side as a memo type is direct evidence that “employer contribution” is not a deduction concept on every system — a mapping assumption that fails silently. |
| What remains unproven | Whether any of these apply as documented; none is verified hands-on. How each surfaces on the pay statement. Whether ADP’s workaround is still current. |
The scorecard
For each payroll system you support, establish:
- Which side of the ledger is the employer contribution on? Deduction, earning, or neither.
- Is the formula stored, or only the result? If only the result, you cannot recompute after a compensation change — and you should store the formula yourself.
- Is tiered matching expressible? Rarely. If your product supports tiered match, expect to model it internally and write the computed amount.
- Can you read it back? Read and write asymmetry is common here.
- Does the employer side affect net pay? On Paylocity’s memo earnings, explicitly not. Reconciliation logic that assumes it does will not balance.
Frequently asked
- Can I express a tiered match formula through an API?
- On Finch, yes — company_contribution supports type 'match' with a tiers array of {match, threshold} integers. That is the only tiered-formula support we found in a public specification. Gusto supports percentage or tiered contribution values plus an elective flag for matching.
- Can I read employer contribution amounts back out?
- It varies. Merge exposes company_contribution as a number on the Benefit object, read-only. Bindbee's company_deduction appears in the UKG Ready payload shape but not the ADP or SAP shapes. On Paylocity you would read the memo earning rather than a deduction.
Source limits
Not verified hands-on. We have not written an employer contribution to any of these systems, so we cannot confirm that Finch's tiered match applies as documented, that Paylocity's memo earnings behave as described, or that ADP's negation workaround is still current guidance. We did not assess how any of these systems report the employer side on the pay statement, only how the API models it. Rippling, isolved, Paychex and Paycom publish nothing readable.
Sources checked
| Source | Publisher | Document date | We checked |
|---|---|---|---|
| Gusto Embedded Payroll — employee benefits create | Gusto | — | 2026-09-10 |
| Create Deduction — company_contribution match tiers | Finch | — | 2026-09-10 |
| Pay Setup — Deductions & Earnings (memo earning types) | Paylocity | — | 2026-09-10 |
| Deduction Instruction API Guide for ADP Workforce Now | ADP | 2022-09-22 | 2026-09-10 |
| Employer Benefits — Merge HRIS | Merge | — | 2026-09-10 |
Wrong or out of date? payrolldataspecs@gmail.com — corrections are free. How claims are scored: methodology.