The publication
Methodology and standards
Every benchmark here prints its method next to its result. We never publish a benchmark whose method cannot be printed beside it — if the method is not publishable, neither is the number. Corrections are on the about page.
What we score
Three records, each answering a different question. Every cell in all three is sourced and marked.
- Payroll API capability record
- What a payroll system's own API lets you do — 9 plain questions, from “can you read pay statements?” to “can you write a direct deposit account?”. 18 payroll systems. Rendered in the Payroll API Capability Matrix.
- Provider record
- Which payroll data providers support which use case, under whose permission — 10 fields. 24 providers. Rendered in the provider directory.
- Deduction record
- What a deduction write actually expresses — tax treatment, amount vs percent, dating, retro and more, 10 fields. 22 payroll systems and unified APIs. Rendered in the deduction write detail.
Every record scores what a vendor documents about its own product. A unified API's claims about a payroll system are recorded against the unified API, never against the payroll system.
Confidence marks
Every cell in every record carries one of four confidence marks, and the count of unverified cells is stated in each table's header rather than buried underneath. “Unverified” means we looked and nobody publishes the answer — not that we have not looked. Systems we have not assessed are named in each index's coverage roadmap and kept out of both the table and the denominator.
| Mark | Definition |
|---|---|
| Verified hands-on | We performed the operation against the live system or its sandbox and observed the result. The date is the date we observed it. |
| Vendor-documented | The vendor states this about its own product in its own documentation. We have not observed it. Vendor documentation of write behaviour is frequently wrong, so this is weaker than it looks. |
| Practitioner-reported | A named practitioner who operates the system told us, or wrote publicly, that this is the behaviour. Not vendor-confirmed, not observed by us. |
| Unverified | Nobody publishes this. Not the vendor, not a practitioner, not us. The cell is empty because the information does not exist publicly — which is itself the finding. |
| Not offered | The vendor's own documentation shows the capability does not exist — a verification database does not switch deposits, a system with no payroll API cannot return pay statements. Not a confidence claim, so it is excluded from every count. Where a vendor plausibly could offer something and publishes nothing, the cell is unverified instead. |
We work primarily from public documentation, so most cells land on vendor-documented or unverified. Nothing on this site is yet verified hands-on, which requires sandbox access we do not have. The set of unverified cells is itself the most useful artifact we produce — what no payroll system or provider documents about its own API — so every one is marked as unverified and carries a note on what a correct answer needed to contain, on that system's or provider's profile page, rather than being left blank.
How claims are sourced
- Only vendor-primary counts as vendor-documented. A vendor's own API reference, developer guide or changelog. A third-party aggregator's directory page is not evidence about the vendor — competitors publish those to sell access — and anything sourced that way is marked unverified or practitioner-reported.
- Every claim carries a source and the date a person checked it. Where the document states its own last-modified date we record that too.
- Absence is a finding, not a skip. A field documented without its behaviour, or a specification behind a login or an NDA, is written down as an unverified cell with a note on what a correct answer needed to contain.
- Products are separated, not companies. One vendor shipping several payroll products with different data contracts is scored once per product.
- A vendor confirming its own documentation does not upgrade a mark. That is still vendor-documented. Only observing the operation is hands-on.
The two dates on every source
“We checked” is the date a person on this side opened the document. “Document date” is the date the source states for itself. They are separate columns because a guide last touched four years ago is a materially weaker source than one touched last month, and the reader should be able to see the difference. Where a document states no date of its own, the column reads “—”.
The payroll API capability record
One row per payroll system, one plain question per column. The question is always about the system's own API — not what a unified API or consumer login in front of it can reach.
| Question | What a documented answer has to show |
|---|---|
| How do you get API access? | The route to credentials: self-serve keys, customer-only, or a named partner programme. |
| Can you read employees and pay rates? | An endpoint returning employment and pay rate, not just a directory of names. |
| Can you read pay statements? | Per-pay-period earnings, deductions and taxes from a completed payroll. |
| Can you write a deduction? | An operation that creates or changes a deduction in payroll, not a portal screen. |
| Can you write a direct deposit account? | An operation that writes an employee deposit account; read-only bank data does not count. |
| Can you read W-2s? | W-2 or 1099 documents or their field values; W-4 withholding elections do not count. |
| Can you read hours worked? | Worked hours or timesheets; time-off balances alone do not count. |
| Does it push change events? | Push notifications or event subscriptions available to the integrator. |
| How does an integration authenticate? | The authentication scheme an integration uses in production. |
The provider record
The capability record covers payroll systems. The provider directory uses a wider record so that unified APIs, consumer-permissioned payroll APIs, deposit switching, verification databases, 401(k) and earned wage access providers can sit on one page. It has 10 fields: one per use case, then data freshness, permission model and the provider's coverage claim quoted as stated. Coverage claims are the provider's own numbers and are never restated as ours.
| Use case | Direction | What the cell asks |
|---|---|---|
| Income and employment verification | Read | Employer, job title, start date, pay rate, and gross and net income history. |
| Pay statements | Read | Per-pay-period earning and deduction lines, as parsed fields or source documents. |
| Tax forms | Read | W-2 and 1099 documents or their field values, and how many years back are available. |
| Direct deposit switching | Write | Write a deposit account into payroll, allocation by amount or percent, and confirmation of when it takes effect. |
| Deduction and benefit write | Write | Deduction codes, tax treatment, amount vs percent, effective dating and retro adjustment. |
| 401(k) and retirement | Read + write | Per-pay-period contribution and census data, and deferral changes written back into payroll. |
| Earned wage access | Read | Hours and earnings to date, pay schedule, and how fresh the data is before pay date. |
Capabilities a provider does not sell are marked not offered and excluded from the counts.
The deduction record
Every payroll system and unified API in the deduction record carries the same 12 fields, with no omitted fields. Ten carry a confidence mark and are counted; the documentation URL and the last-verified date are metadata rather than scored claims.
| Field | Permitted values |
|---|---|
| deduction read | Y / N |
| deduction write | API / file / portal / assisted / none |
| pre-tax vs post-tax at write | enforced / inherited / not represented |
| amount vs percent | both / amount only / percent only / code-dependent |
| effective dating | field names and which date actually drives the pay period |
| retro adjustment behaviour | documented / undocumented / not supported |
| employer contribution support | first-class object / modelled as earning / not supported |
| code taxonomy shape | vendor-fixed / company-defined / hybrid |
| auth model | OAuth 2.0 / API key / credential-mediated / other |
| data freshness | real time / batch / SLA-bound / unstated |
| documentation URL | the specific page, not the portal root |
| last verified | the date a person checked it |
How integration methods are graded
A recurring failure in this category is counting integrations. The number of providers a vendor claims tells you almost nothing; the method determines whether a write lands before payroll closes, and whether a read is fresh enough to act on. Cells are never averaged into a composite score, because a composite hides exactly the detail the reader came for.
| Grade | Method | What it means in production |
|---|---|---|
| A | API read and write | Real time, authenticated per request, auditable, and it fails loudly. The only method where a write can be confirmed programmatically. |
| B | API read only | Real time for retrieval; every write is somebody else's manual process. Read-only access sold as "integration" is a common source of the mismatch this publication documents. |
| C | SFTP or file drop | Secure when configured properly, but batch cadence bounds everything downstream. Legitimately beats an API for bulk work — correcting deductions across several hundred employees at once is one case, and we say so where it is true. |
| D | Credential-mediated or assisted | A human, or a scraper acting as one, is added as an administrator in the payroll system. Not real time, not robust, and it breaks whenever the vendor changes a screen. Sold in the same column as method A, it misleads the buyer. |
Standing refusals
Printed as refusals rather than described as principles, so that they bind us:
- Paid placement in any index, benchmark or comparison. Position is determined by the published method.
- Anchor-text link sales, link insertions, and guest posts carrying a commercial link.
- Undisclosed paid content. Any commercial relationship is labelled on the page where it appears.
- Sponsor review of findings before publication.
- Removing or softening a finding at a vendor’s request. Vendors get the corrections process, same as everyone.
- Charging for a correction, or making one faster for a sponsor.
Any commercial relationship is labelled on the page where it appears, in plain language, and never inside a table, index or benchmark. Where a vendor gave us sandbox access to enable hands-on verification, that is disclosed on the pages it produced. Today there are no commercial relationships to disclose.
This page last reviewed .