The publication

About Payroll Data Specs

An independent reference on what payroll systems and payroll-connectivity APIs let you read and write — deductions, contributions, income and employment, pay statements, direct deposit — including a published record of what no vendor documents.

Why this exists

Almost every page that compares payroll systems and payroll APIs is published by a vendor — a unified API describing its own coverage, a payroll system describing its own partner programme. None of them says what the other vendors' APIs actually do, or what nobody documents. We measured the gap before writing anything: on 2026-09-10 we recorded what language models cited when asked payroll-deduction questions. Of 64 capability questions with a factual, checkable answer, zero returned a neutral independent source — 86% led with a vendor's own documentation, and the only neutral citations were institutional (dol.gov, irs.gov), answering regulatory questions rather than capability ones.

Who this is for

The engineer or product manager whose product depends on payroll data — and who needs to know what a payroll system or provider will actually let them read or write before they commit to it:

Benefits, HSA/FSA and 401(k) platforms

Writing deductions and contributions into payroll, and reading them back.

Lenders, landlords and screeners

Reading employment, pay rate and income history for verification.

Banks and fintechs

Switching a customer's direct deposit to a new account.

Earned wage access providers

Reading hours and earnings before payday, as fresh as the payroll system allows.

HR and payroll software teams

Deciding whether to build direct integrations or buy a unified API.

One filter decides whether a topic is ours:

If the vendor's own documentation answers the question cleanly, we do not write the page.

Scope

The research is organised into 5 topics, the same way it is on the homepage:

Payroll systems

What each payroll system’s own API lets you read and write — employees, pay statements, deductions, bank accounts, W-2s, hours.

Payroll data providers

Who reaches payroll data on your behalf — employer-permissioned, consumer-permissioned or from a contributed database.

Use cases

Start from what you are building: what each use case needs from payroll, and which providers document it.

Deductions and benefits write

For benefits, HSA/FSA and 401(k) builders: tax treatment, amount vs percent, effective dating, codes and retro.

Choosing an integration

Build or buy, assisted or automated, and what to check in a provider beyond its integration count.

Coverage today: 18 payroll systems, 24 payroll data providers — unified APIs, consumer-permissioned APIs, deposit switching, verification databases, 401(k) and earned wage access — and 7 use cases. Systems located but not yet assessed are named in each index's roadmap rather than padded into the tables. Where a vendor ships several products we cover each separately — ADP Workforce Now and ADP RUN are different systems with different APIs, and treating them as one company is the most common error in this category.

What this is not

Not a verification or underwriting service

We document what the payroll connection returns for income and employment verification — which fields, how fresh, under whose permission. We do not verify anyone, score anyone, or advise on FCRA obligations for doing so.

Not payroll software shopping

We have no opinion on onboarding, pricing tiers or the mobile app. Our subject is the data contract, not the buying decision.

Not compensation benchmarking

We publish nothing about what people are paid — only about how the systems that pay them represent pay, deductions and deposits.

Not a directory, and not a lead form

Nothing is gated, no introductions are sold, and reader details are never passed to vendors.

Who publishes it

Payroll Data Specs is written and published by Eli Wilson, Austin, Texas, operating as an individual rather than a company. It is not owned by, funded by, or commercially partnered with any vendor in its indexes. Research is bylined to the person who did it; there is no organizational byline. Credentials are not yet listed and will be.

Standing refusals — no paid rankings, no link sales, no pre-publication review of findings — are printed on the methodology page so that they bind us.

Corrections

Corrections are free, unconditional, and open to anyone — reader, practitioner or vendor. A vendor who wants a finding changed gets the same process as a reader who spotted a typo. If something here is wrong we want to know, and the fastest route is to say which claim and what contradicts it.

One inbox, read by a person: payrolldataspecs@gmail.com. Use it for anything factually wrong — a wrong field name, a mis-scored cell, a stale claim, a broken source link, a confidence mark you think is too generous — and equally for a question we should be covering, an offer of sandbox or developer access, practitioner input, or press.

What to include

1. The page, and the specific sentence or table cell.
2. What it currently says, and what it should say.
3. A source, if you have one. A vendor's own documentation is ideal; a screenshot of current product behaviour is often better still, because that is what we cannot otherwise see.
4. Whether you want to be credited. We credit by default and will withhold your name on request — including in the vendor case, where naming you may not be welcome inside your own company.

You do not need a source to file one. “This does not match what I see in production” from someone operating the system is a legitimate report, and it gets marked practitioner-reported pending verification rather than dismissed for want of a document.

Tiers

We acknowledge within two business days and say what we intend to do. Where verification needs access we do not have, we say so and mark the cell unverified rather than leave a disputed claim standing unqualified. We never silently unpublish: a page that turns out to be wrong carries its correction, with the erroneous claim quoted rather than deleted.

Two things we will not do: accept an off-the-record correction (we will protect your name, not hide the substance), or downgrade a finding without evidence — “commercially damaging” is not a correction, “this field behaves differently, here is the documentation” is.

This page last reviewed 2026-09-26.