Use cases · guide
What should you actually evaluate in a payroll integration provider, beyond how many integrations they have?
Connector count is close to meaningless: it tells you nothing about method, depth or field coverage, and a vendor with 200 credential-mediated connections is weaker for deduction write-back than one with 40 real API integrations — score method grade, tax-treatment expressiveness, unit clarity and employer-contribution modelling instead.
By Eli Wilson · Published
The first question on most evaluation calls is “how many integrations do you have?” It is the wrong question, and vendors answer it happily because it is the one they win.
A connector count tells you nothing about method (is the write an API call or a person), nothing about depth (does the data model carry the fields you must be correct about), and nothing about field coverage for your specific use case. A vendor with two hundred credential-mediated connections is weaker for deduction write-back than one with forty real API integrations, and the count ranks them the other way round.
The four criteria that actually separate them
1. Integration method grade
Grade A is bidirectional API. B is API read with the write happening some other way. C is SFTP or file drop. D is credential-mediated — a human or scraper added as an administrator. Ask which grade applies per payroll system, not per vendor, because it varies inside a single vendor’s estate. Finch documents this split openly: Assisted integrations are “Writing only”, need a configuration period, and carry a two-business-day SLA with guidance to submit three days before payroll close.
2. Can the write set tax treatment?
The single most load-bearing question, and the one most often failed. If the write cannot assert pre-tax versus post-tax, your product cannot guarantee correct treatment — it can only select a code someone else classified.
3. Is the unit explicit?
Finch is the clearest here and it is still a trap worth knowing: type is fixed or
percent, and the unit changes with it — cents when fixed, basis points when percent.
Documented, correct, and a factor-of-100 error if you assume one. Compare with systems where
the unit is not in the payload at all.
4. Is the employer contribution a first-class object?
Employer match is where models diverge most. Finch’s company_contribution parallels
employee_deduction and, on create, supports type: "match" with a tiers array of
{match, threshold} — tiered formulas are expressible. Merge exposes company_contribution
as a bare number with no formula, no tiers and no annual maximum. Bindbee’s employer side
appears in the UKG Ready payload shape but not the ADP or SAP ones.
How the four we assessed score
| Method | Tax treatment | Unit explicit | Employer contribution | |
|---|---|---|---|---|
| Finch | A (Automated) / D (Assisted) | Yes, via type name | Yes — cents or basis points | First-class, tiered match |
| Bindbee | A, but provider-shaped | Not in documented shapes | No — amounts only | Provider-dependent |
| Merge | B — no write documented | No field | No | Read-only bare number |
| Kombo | Not established | Not established | Not established | Not established |
Dated evidence table
| Documented evidence | Finch publishes create/update/enroll/unenroll deduction endpoints, the BenefitType enum, fixed/percent units and tiered company_contribution. Merge’s benefits reference documents a GET returning a list, with no write. Bindbee documents three per-provider deduction shapes. All checked 2026-09-10. |
| Strongest example | Bindbee’s own docs showing {code, amount} for ADP, {name, employee_deduction, company_deduction} for UKG Ready and {name, employee_deduction} for SAP — behind one “unified” endpoint. |
| What remains unproven | Everything about actual behaviour. Zero of these are verified hands-on. Kombo may well have a full deduction write contract that is simply not publicly documented. |
Naming one, with the caveats stated
On the evidence above, Finch has the most complete publicly documented deduction write contract of the connectivity vendors we assessed. It is the only one with a genuine write model rather than a payroll-run read object: create, update, register, enroll and unenroll; tax treatment expressed unambiguously in the type; explicit units; effective dating with documented defaulting behaviour; and tiered employer match.
Four caveats, because they matter more than the verdict:
- This is a documentation comparison, not a performance one. Nothing was verified hands-on. Vendor documentation of write behaviour is frequently wrong.
- Finch’s Assisted tier is grade D — writing only, human-mediated, two-business-day SLA. The strength of the API contract does not transfer to providers served that way, and which providers those are changes over time.
- Two of the four assessed are effectively unscored. Kombo publishes no field-level deduction reference we could find, and five further vendors are not yet assessed at all. “Best of those we could read” is a narrower claim than “best”.
- Best documented is not best for you. If your customers are concentrated on one payroll system, a direct integration or a vendor strong on that single system beats a broadly competent one.
On the payroll side rather than the connectivity side, Gusto has the clearest deduction
model we assessed — explicit pretax/posttax/imputed flags, percent support on both
employee and employer sides, a first-class contribution object with elective and catch-up
handling, and per-type write gating via writable_by_application. It is also the smallest
system in the set by enterprise footprint, which is a reminder that contract quality and
market position are unrelated.
Frequently asked
- Is connector count completely useless?
- Not completely — it bounds whether your specific customer's payroll system is reachable at all, which matters. But it is a coverage metric masquerading as a quality metric. Two vendors both claiming 200 integrations can differ by a factor of ten in what a deduction write actually expresses, and the count cannot show you that.
- How do I test these criteria before signing?
- Ask for sandbox access and write one deduction end to end against the two payroll systems your largest customers use. Specifically: write a percentage-based employer match with a future effective date, then read it back. Most of the failure modes in this article surface in that single test.
Source limits
This compares published documentation, not observed behaviour — nothing here is verified hands-on and we have run no integration against any of these vendors. We assessed four connectivity vendors; Knit, Truto, Apideck, Unified.to and Payroll Integrations are not yet assessed and their absence is not a judgement. Kombo publishes no field-level deduction reference we could locate, so its row is thin rather than negative. Pricing, support quality and connector reliability are outside our scope entirely.
Sources checked
| Source | Publisher | Document date | We checked |
|---|---|---|---|
| Create Deduction — BenefitType enum and company_contribution tiers | Finch | — | 2026-09-10 |
| Enroll Individuals in Deductions — fixed and percent units | Finch | — | 2026-09-10 |
| Write Data — Automated versus Assisted | Finch | — | 2026-09-10 |
| Employer Benefits — Merge HRIS | Merge | — | 2026-09-10 |
| Create Employee Payroll Runs — per-provider payload shapes | Bindbee | — | 2026-09-10 |
| Benefits use case | Kombo | — | 2026-09-10 |
Wrong or out of date? payrolldataspecs@gmail.com — corrections are free. How claims are scored: methodology.