Write-back · comparison

Which payroll systems enforce pre-tax vs post-tax at the API write?

Of the systems whose write contract is publicly readable, only Gusto lets the API see and set tax treatment directly; Paylocity and ADP both make it a property of a code that someone configured beforehand, which means most integrations cannot guarantee through the API that the deduction they just wrote will be treated pre-tax.

By Eli Wilson · Published 2026-09-10

This is the question the property exists for, so here it is answered plainly: for most payroll systems, your API write cannot assert that a deduction is pre-tax. It can only select a code that somebody already classified, and trust them.

System by system

Gusto — the only clean model

Each benefit type carries booleans stating whether it is deducted before tax calculation, after it, or treated as imputed income. A separate deduction_reduces_taxable_income field is settable on the employee benefit, but the documentation scopes it to Group Term Life rather than presenting it as a general switch. Note also that write access is gated per type by writable_by_application — being able to read the taxonomy does not mean you may write to it.

Paylocity — treatment lives one level up

DeductionCodeDto exposes calculationCode, amount, rate, frequency, payPeriodMaximum, annualMaximum, w2Box, exemptTaxes, blockedTaxes, benefitType and priority. There is no pre-tax or post-tax field. Instead the company’s detType decides it, and the vocabulary makes the split visible: HSA EE 125 Pretax Contribution and HSA EE Post Tax Contribution are two different types, as are 401K and 401k Roth.

The write therefore expresses treatment only by choosing correctly between codes whose names happen to encode it.

ADP Workforce Now — a form, not a field

ADP’s Deduction Instruction API handles only the Pre-tax and Post-tax categories. For pre-tax, the guide states that the client must select and complete an authorization form to request that ADP set up the code, after which ADP notifies them it is ready. Direct Deposit, School District Tax, Medicare Surtax and liens are explicitly not handled by the API at all.

So a product claiming to configure pre-tax deductions in ADP Workforce Now is configuring codes a human created out of band, on ADP’s timeline.

Dated evidence table

The scorecard

For any payroll system you are integrating, establish these four before you build:

1. Is treatment a field or a code attribute? If a code attribute, your onboarding needs a mapping step and your product cannot promise correct treatment on its own.
2. Can you read the treatment before writing? If yes, you can at least validate. Gusto, Finch and Paylocity allow this; ADP puts the category on the code.
3. Can you create a correctly-classified code? Gusto yes, per type. ADP no, not for pre-tax. Paylocity’s codes are company-level configuration.
4. What is the correction path if treatment was wrong? On most of these, undocumented — which makes the first three questions considerably more expensive to get wrong.

Frequently asked

Does Gusto validate that a pre-tax election is legal?

Unverified. Gusto's benefit objects carry a yearly_limit flag indicating a government-mandated annual limit exists for that type, which implies some enforcement, but the documentation we read does not state what happens when a write would breach a limit or elect an impermissible treatment.

Can we detect the treatment before writing?

On Gusto and Finch, yes — read the benefit type and its flags. On Paylocity, you can read the company's deduction codes and their detType, which carries the treatment, so you can infer it before writing. On ADP the category is on the code; the write does not restate it.

Source limits

Sources checked

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