Codes · guide

How do you tell from a payroll deduction code whether it is pre-tax or post-tax?

On Paylocity you read the code's detType, whose names encode it; on Gusto you read boolean flags on the benefit type; on ADP the category is attached to the code and not restated in the API response — so on no system assessed can you infer treatment from the code string itself.

By Eli Wilson · Published 2026-09-10

The code string will not tell you. MED125, 401K, HSA — these are labels chosen by whoever configured the employer, and a code that looks pre-tax can be configured post-tax. What you need is the attribute hanging off the code, and where that lives differs per system.

Where to look, per system

Paylocity — read the detType, not the code

Paylocity’s deduction codes pair with a detType that, in its own documentation’s words, determines how payroll treats the amount. The naming convention makes the split explicit: HSA EE 125 Pretax Contribution and HSA EE Post Tax Contribution are two different types, as are 401K and 401k Roth, and 403b TSA and 403b Roth.

Note what this means structurally: DeductionCodeDto itself has no pre-tax field. The schema carries calculationCode, amount, rate, frequency, payPeriodMaximum, annualMaximum, w2Box, exemptTaxes, blockedTaxes, benefitType and priority — and treatment is not among them. You get it from the nested type, one level up.

Gusto — the only place it is a plain boolean

Each benefit type carries pretax, posttax and imputed flags directly, plus healthcare, retirement and yearly_limit. This is the cleanest model we assessed and it is readable before you write anything.

ADP — the category is on the code, and stays there

ADP’s API handles the Pre-tax and Post-tax categories, and pre-tax codes are created out of band via an authorization form that ADP processes. The guide does not document the category being returned in the deduction response, so a consumer reading a worker’s deductions has the code but not, from the API, its classification.

Dated evidence table

The procedure

1. Fetch the employer’s code list. Every system with a code-list endpoint exposes the nested type or flags alongside it.
2. Read the type, never the code string. Store both, and store which one you derived treatment from.
3. Where no field exists, ask and record it as reported. On Merge, and on ADP for reading purposes, this is the only route. Mark it as practitioner-reported so nobody downstream mistakes it for a vendor guarantee.
4. Re-check at plan year. Codes are tenant configuration and configuration drifts.

Frequently asked

Can I use the W-2 box to infer treatment?

Not reliably. Paylocity's DeductionCodeDto carries a w2Box field, and W-2 reporting correlates with treatment for some deduction types, but the mapping is not one-to-one and several pre-tax types are not W-2-reported at all. Use detType, which states it directly.

What about exemptTaxes and blockedTaxes?

Those Paylocity fields are closer to the real answer than w2Box, since a pre-tax deduction is definitionally exempt from specified taxes. But they describe the mechanism rather than declaring the classification, and we have not verified how they are populated in practice.

Source limits

Sources checked

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