What Is Payroll Integration? A Complete Guide (2026)

Payroll integration is the process of connecting external applications to payroll systems such as ADP, Paychex, Paylocity and Workday to read, and sometimes write, payroll data: pay runs, payslips, deductions, benefits, time worked and bank accounts. Unified.to does this through its HR & Directory API, reading the source system at request time. This guide is for B2B SaaS teams adding payroll features, and payroll data doesn't live only in the payroll system.

Employee compensation data spans the HRIS, the payroll, the identity, time-tracking, and accounting layers. For B2B SaaS products integrating payroll, the practical work is rarely about one payroll API; it's about reading payroll data across the HR, time and accounting systems where it lives.

This guide covers what payroll integration means in practice, which payroll systems can be integrated, what payroll data looks like through a unified API, and why payroll integration is architecturally different from other integration categories.

Key takeaways

• Payroll integration connects external applications to payroll systems to read and write payroll-relevant data: pay runs, payslips, deductions, benefits, time worked, and bank accounts. Most B2B SaaS products integrating payroll are reading historical payroll data for analytics, financial reporting, or audit purposes, not running payroll.
• Payroll data spans more than just the payroll system. Employee compensation, time worked, bank accounts, and deductions live across the HRIS, payroll, identity, time tracking, and accounting layers. A practical integration architecture covers the full workforce data surface, not just the payroll endpoint.
• The canonical payroll objects are Payslip (pay-period snapshots with gross_amount, net_amount, paid_at, start_at, end_at, details[]), Timeshift (compensation for a time window), Deduction (employee-specific benefit enrolment with the employee's portion), Benefit (company-wide benefit plans with employer contribution), and BankAccount (direct deposit destinations). Pay runs (hris_payroll: status, period, totals, the employees and payslips in the run) and pay codes (hris_paycode: the payroll system's earning, deduction, tax and contribution codes) are read-only objects on Check, Deel, Employment Hero Payroll, Paychex, Paycor, Remote.com and Rippling (pay runs) and Check, Employment Hero Payroll, Paychex and Paycor (pay codes). Records join on Employee ID. Earnings (hris_earning) are amounts added to a pay cheque, the counterpart to deductions: one-time or recurring, under a pay code, on ADP Workforce Now, Check, Employment Hero Payroll, Paychex, Paycor, Paylocity, Remote.com and UKG Pro HCM, and on Workday and Xero (as of 19 October 2026); methods (create, list, retrieve, update, remove) vary by integration.
• Unified.to does not provide a separate Payroll API. Payroll integration is delivered through Unified.to's HR & Directory API, which spans 711 integrations. Payslips, pay runs and deductions come from payroll integrations such as ADP Workforce Now, Deel, Remote.com, UKG Pro HCM and Xero, plus Paychex, Paycor, Paylocity and Rippling (as of 19 October 2026); HR, identity and time-tracking integrations supply the employee and hours data around them.
• Payroll integration is architecturally different from CRM or marketing API integration. Pay runs are batch-driven processes that happen on weekly, biweekly, or monthly schedules. Pay runs send no change events; payslips do on some integrations, such as Remote.com and Xero, through virtual webhooks. Most payroll integration is about reading recorded pay data, not subscribing to frequent change events.
• Payroll data is highly sensitive (tax IDs, bank accounts, compensation, SSN equivalents) and carries strict compliance requirements. Architecture choices about whether the integration vendor stores customer payroll data at rest meaningfully affect compliance scope.

What is payroll integration?

Payroll integration is the connection between an external application (typically a B2B SaaS product) and a payroll system, enabling programmatic access to payroll and compensation data. The payroll system varies (ADP, Paychex, Paylocity, Workday, Rippling, Deel and many others), but the data shape is consistent: who got paid, how much, when, for what period, with what deductions, into which bank account.

For most B2B SaaS products, payroll integration means reading payroll data rather than running payroll directly. Common reasons:

• Analytics and reporting: labour-cost dashboards, compensation analysis, budget reconciliation
• Financial reconciliation: feeding payroll runs into accounting systems
• Audit and compliance: surfacing payroll history for audit trails, tax filings, and regulatory reporting
• Workforce planning: combining payroll with time-tracking and HR data for capacity and cost forecasting
• Employee financial applications: building applications that show employees their income, deductions, and benefits over time

A smaller subset of products write to payroll systems: HR platforms that initiate pay runs, contractor payment applications, compensation management applications. These are operationally heavier integrations because writes have direct financial and compliance consequences.

What data lives in payroll integration?

The core objects are Employee, Payslip, Payroll (pay run), Paycode, Earning, Deduction, Benefit, BankAccount, Timeshift and Time Off. They join on employee identifiers.

Payslip: pay-period snapshots

A payslip represents what was actually paid for a specific pay period. Unified.to's Payslip model includes:

• id, created_at, updated_at
• user_id (joins to Employee)
• company_id (joins to Company)
• start_at, end_at — pay period
• paid_at — when the payment was made
• payment_type — DIRECT, CHEQUE, or CASH
• gross_amount, net_amount, currency
• details[] — itemized earnings, taxes, and deductions
• payroll_id (the pay run), type (REGULAR, OFF_CYCLE, BONUS, CORRECTION, TERMINATION, CONTRACTOR), hours, employee and employer tax totals, deduction_amount, employer_contribution_amount and year-to-date gross and net, where the integration supplies them

Each details[] entry has its own structure: type (one of EARNING_SALARY, EARNING_OVERTIME, EARNING_BONUS, EARNING_COMMISSION, PRETAX_DEDUCTION_HEALTH_INSURANCE, PRETAX_DEDUCTION_RETIREMENT, TAX_FEDERAL, TAX_REGION, TAX_LOCAL, POSTTAX_BENEFIT, POSTTAX_GARNISHMENT, REIMBURSEMENT, and others), name, amount, plus employee_amount and company_amount for the employer/employee split. A details entry can include the full deduction object inline when the line represents a benefit deduction. Each line can also carry hours, rate_amount, ytd_amount and the paycode_id it was paid under.

Benefit: company-wide benefit plans

A Benefit represents a benefit plan offered by the company (e.g., "401(k) Plan"). The Benefit model includes:

• id, name, description, company_id
• type — one of RETIREMENT, HEALTH, DENTAL, VISION, LIFE, HSA, FSA, SHORT_TERM_DISABILITY, LONG_TERM_DISABILITY, WORKERS_COMP, HOUSING_STIPEND, EMPLOYER_TAX_CONTRIBUTION, GARNISHMENT, LOAN_REPAYMENT, CHARITABLE_CONTRIBUTION, OTHER
• tax — PRE_TAX, POST_TAX, TAXABLE, NON_TAXABLE, TAX
• frequency — ONE_TIME, DAY, WEEK, MONTH, QUARTER, YEAR, HOUR, BIWEEKLY, SEMIMONTHLY
• employer_contribution_type (PERCENTAGE or FIXED), employer_contribution_amount, employer_contribution_max_amount
• coverage_level — EMPLOYEE_ONLY, EMPLOYEE_SPOUSE, EMPLOYEE_CHILD, EMPLOYEE_CHILDREN, EMPLOYEE_FAMILY, FAMILY, OTHER
• currency, is_active

Deduction: employee-specific benefit enrolment

A Deduction represents an individual employee's enrolment in a benefit (the link between an Employee and a Benefit, with the employee's portion). The Deduction model includes:

• id, user_id (Employee), company_id, benefit_id (joins to Benefit)
• amount, type (FIXED or PERCENTAGE)
• coverage_level (same enum as Benefit)
• frequency (same enum as Benefit; should match the parent Benefit's frequency)
• start_at, end_at, is_active, notes
• employer_amount, max_amount, paycode_id and garnishment_type for court-ordered deductions

Architectural distinction worth understanding: Benefit is company-wide, Deduction is employee-specific enrolment. A health plan exists once at the Benefit level; each enrolled employee has their own Deduction record referencing it.

Bank Account: direct deposit destinations

The Bank Account model includes:

• id, user_id (Employee), company_id
• account_type — CHECKING or SAVINGS
• bank_name, routing_number (9-digit US format), account_number, account_number_last4 (when full number isn't returned)
• name — account nickname (e.g., "BoA Checking")
• is_primary — primary direct deposit destination

For non-US accounts the model has iban, bic and country_code, and split_type, split_amount and priority describe how net pay is split across accounts. Bank accounts are read on integrations such as ADP Workforce Now, Deel and UKG Pro HCM, and send no change events.

Timeshift: compensation for a time window

Timeshifts represent worked hours and their compensation for a specific time window. Verified fields:

• start_at, end_at, hours
• compensation[] entries with amount, currency, frequency (HOUR, DAY, ONE_TIME, etc.)
• employee_user_id (joins to Employee)
• Server-side filtering via start_gte and end_lt (availability varies by integration)

Joining the data

• payslip.user_id === employee.id
• deduction.user_id === employee.id
• deduction.benefit_id === benefit.id
• bankaccount.user_id === employee.id
• timeshift.employee_user_id === employee.id

The most important architectural detail: payroll history is encoded in Payslip records, not in the Employee record's compensation[] field. An Employee's compensation[] represents current-state compensation only; there are no effective dates, no history semantics. For historical payroll analysis (audits, trend reports, longitudinal compensation tracking), Payslip and Timeshift are the source of truth. This is consistent with how Unified.to returns the data and avoids fabricating payroll history from current-state fields.

How does payroll integration differ from HRIS, ATS, and accounting integration?

Payroll, HRIS, ATS, and accounting integrations all touch employee or workforce data, but they operate against different category boundaries.

That's why Unified.to keeps payroll, HR, identity and time data in one HR & Directory category instead of separate APIs.

What does payroll integration data actually look like?

Through Unified.to's HR & Directory API, payroll data is read with the same endpoints on every integration that supports the object.

Listing payslips for an employee:

GET https://api.unified.to/hris/{connection_id}/payslip?limit=100&user_id={employee_id}
Authorization: Bearer YOUR_API_KEY

Listing employees:

GET https://api.unified.to/hris/{connection_id}/employee?limit=100
Authorization: Bearer YOUR_API_KEY

Listing timeshifts for a date window (when the integration supports server-side date filtering):

GET https://api.unified.to/hris/{connection_id}/timeshift?start_gte=2026-01-01T00:00:00Z&end_lt=2026-02-01T00:00:00Z
Authorization: Bearer YOUR_API_KEY

Joining the data:

• payslip.user_id === employee.id
• timeshift.employee_user_id === employee.id

The same request works on every integration that supports the object; only the connection_id changes. Where an integration doesn't support it (BambooHR has no payslips, for example), the call returns 501.

What's intentionally not in the payroll model

What Unified.to deliberately doesn't do:

• No invented payroll history. Unified.to does not fabricate historical compensation from current-state fields. If an HR integration doesn't surface payslips, the integration returns HTTP 501 for that resource; the connection is still valid, but the feature isn't available for that vendor.
• No server-side aggregation. No totals, averages, or group-by endpoints. Aggregation is the application's responsibility.
• No currency normalization. Each record carries its own currency. Aggregating across multiple currencies requires explicit conversion logic in the application.
• No frequency normalization. Timeshift compensation may be hourly, daily, or one-time. Converting to comparable units is the application's responsibility.

These constraints are intentional. They preserve correctness and auditability — engineers can defend exactly where every payroll number came from.

What payroll integrations does Unified support?

Unified.to's HR & Directory API spans 711 integrations. Payroll objects (Payslip, Payroll, Paycode, Deduction, Benefit, BankAccount, Earning) are on a smaller set, and the fields each one returns vary: year-to-date totals and pay-run links, for example, come only from some payroll systems. Always check the Supported Integrations page for current per-integration feature support before committing to specific use cases.

As of 19 October 2026, payroll objects are available on these integrations:

• ADP Workforce Now: payslips, deductions, benefits, bank accounts, Earning
• Deel: payslips, pay runs, benefits, bank accounts
• Remote.com: payslips, pay runs, Earning
• UKG Pro HCM: payslips, deductions, benefits, bank accounts, Earning
• UKG Ready: deductions, benefits, bank accounts
• Workday: Earning; payslips through Workday (Legacy)
• Xero: payslips, Earning
• Check, Employment Hero Payroll, Paychex, Paycor, Paylocity, PayFit, Payworks and Rippling: payslips, and pay runs, pay codes, deductions or Earning depending on the integration

Paycom, Ceridian Dayforce, Trinet Zenefits, PrismHR, Sage HR, Iris HR, Humi and Readytech Zambion are available for employee data; check each one's Feature Support tab for payroll objects.

Benefits and deductions are also readable on HR integrations such as BambooHR and Personio; NetSuite returns payslips; and time-tracking integrations such as Deputy and Humanforce return timeshifts.

The full integration list is available at unified.to/hris.

For a deeper breakdown of the major payroll APIs and what each provides, see 15 payroll APIs to integrate with in 2026: ADP, Gusto, Paychex.

Why is payroll integration architecturally different from CRM or marketing integration?

Payroll has properties that CRM and marketing data don't share. These properties affect how integrations should be designed.

Pay runs are batch-driven, not event-driven

Pay runs happen on schedules — weekly, biweekly, semi-monthly, or monthly. A payslip exists because a pay run executed, not because someone clicked a button at 3:42 PM. The "real-time" framing that's central to CRM data ("show the salesperson the deal stage as it changes right now") doesn't apply the same way to payroll. Most payroll integrations are about reading historical pay artifacts at query time, not subscribing to sub-second event streams. On Unified.to, pay runs, pay codes and bank accounts send no change events; payslips do on some integrations.

Payroll data is highly sensitive

Payroll records contain SSN-equivalent identifiers, bank accounts, tax withholdings, compensation amounts, and deduction details. Architecture choices about data storage have outsized compliance implications:

• Integrations that cache payroll data keep a copy of your customers' payroll records in their own database
• Pass-through integrations send each request to the payroll system and keep no stored copy of customer payroll records (both are still subprocessors)
• The difference changes how much payroll data sits in a vendor's storage for SOC 2, GDPR and HIPAA reviews

Compliance requirements vary by jurisdiction

Payroll obligations differ across countries, states, and provinces. US payroll has tax withholding, FICA, and ACA reporting requirements. EU payroll has GDPR, country-specific tax models, and works council requirements. Canadian payroll has provincial tax variations. Global payroll integrations need to handle multiple jurisdictions per customer, often with separate underlying integrations per country.

Write operations have direct financial consequences

Writing to a payroll system can move real money. CRM write errors create data quality problems; payroll write errors create misissued paychecks, tax filing errors, and audit findings. Most B2B SaaS products integrating payroll do reads only and let the customer's payroll administrator handle pay runs. Build path: read first, write only when the use case requires it.

Schema variability is high

Different payroll systems encode the same concepts differently. ADP, Paychex and Workday represent earnings, deductions, and tax types in fundamentally different shapes. Unified.to's Payslip object maps these onto the same fields (gross_amount, net_amount, details[]), but vendor-specific custom deduction types and earnings codes still require either explicit handling or raw passthrough access.

What do teams build with payroll integration?

Labour-cost reporting, payroll-to-accounting reconciliation, audit trails, compensation analytics and employee pay apps, all from read-only payroll data.

Labour-cost analytics and reporting

Read payslips across an organization to compute labour cost by department, project, location, or time period. Combine with HRIS data (department, location) and timeshifts (hours worked) to get fully attributable labour cost.

Financial reconciliation between payroll and accounting

Write payroll run totals into accounting systems as journal entries, on accounting integrations that support journal writes. The payslip's gross_amount, net_amount, and deduction breakdown map to gross wages, net wages, and tax/benefit liability accounts respectively.

Audit trails and compliance reporting

Surface payroll history for audits, tax filings, and regulatory reporting. The architectural advantage of reading from documented payslip records (rather than reconstructed history) is defensibility: engineers can show exactly which pay run produced which numbers.

Compensation analytics and benchmarking

Aggregate compensation data across employees, departments, and time periods. Track compensation trends, raise patterns, and bonus distributions. The Payslip object's paid_at and start_at/end_at fields make point-in-time analysis defensible.

Employee financial wellness and self-service

Build applications that show employees their pay history, deductions, benefits enrolment, and time off balances. Combining Payslip, Deduction, Benefit, and Time Off data through a single API surface simplifies the integration footprint substantially.

For deeper coverage of the broader HR data surface, see our HRIS API integration guide.

What makes payroll integration operationally hard?

Several factors compound:

• Authentication variability. Rippling uses OAuth; Paychex and ADP Workforce Now use OAuth client credentials (ADP adds certificates); Workday (Legacy) uses an integration system user's username and password. Each integration needs its own credential lifecycle handling.
• Schema variability. Earnings codes, deduction types, tax categories, benefit structures all differ across vendors. Normalizing them while preserving vendor-specific data is non-trivial.
• Batch processing semantics. Pay runs are async batch operations. Submitting a pay run, polling for completion, and handling failures introduces async lifecycle work that real-time read APIs don't have.
• Rate limits and concurrency. Enterprise payroll systems (ADP, Workday) have tight rate limits and concurrency caps. Bulk operations need throttling.
• Compliance and security scope. Storing payroll data at rest expands compliance scope substantially. Pass-through architectures with no customer records at rest keep that copy out of the integration layer.
• Per-customer schema variation. Custom earnings codes, custom deduction types, and tenant-specific configurations vary across customers even within the same payroll vendor.
• Cross-team setup. Production payroll integrations require coordination across the customer's HR/payroll administrator, IT/security, and finance — setup is rarely "just wire it up."

For broader context on integration architecture, see our breakdown of ETL vs. iPaaS vs. unified API.

Direct vs. Unified — when to choose each

Build directly if

• You support exactly one payroll vendor and have no near-term plans to add another
• You need deep vendor-specific functionality (e.g., direct submission of complex pay runs in ADP, Workday-specific compensation flows)
• You have engineering capacity to maintain per-vendor authentication, schema mapping, and rate-limit handling
• Your customers tolerate longer per-vendor integration cycles

Use Unified.to if

• You support (or plan to support) multiple payroll vendors across customers
• You'd rather not build per-vendor authentication and normalization infrastructure
• You want consistent semantics across payroll, HRIS, and adjacent workforce data
• You don't want a third copy of payroll data in your integration vendor's storage (pass-through, no customer records at rest)

Best practices for payroll integration

• Read from documented payroll artifacts, not from inferred fields. Use Payslip and Timeshift records for historical analysis. Don't reconstruct payroll history from employee.compensation[] — that field has no effective-date semantics.
• Aggregate explicitly with currency awareness. Each Payslip carries its own currency. Aggregating across currencies requires explicit conversion logic.
• Plan for HTTP 501 responses. Not every HR integration supports every payroll object. A 501 means the integration doesn't surface that resource, but the connection itself is still valid.
• Treat payroll write operations cautiously. Reads are safe. Writes have financial and compliance consequences. Default to read-only unless the use case explicitly requires writes.
• Handle compliance scope at the architecture level. Storing payroll data at rest expands compliance scope substantially. Pass-through reads minimize it.
• Read pay runs on a schedule. Pay runs, pay codes and bank accounts send no change events; payslips do on some integrations, such as Remote.com and Xero.
• Copying payroll data into your own database? Database Sync (Grow, Pro and Scale) writes changes into MongoDB, MySQL, Postgres, MSSQL, MariaDB, Supabase or Snowflake only for objects with native or virtual webhooks, so it covers payslips on supported integrations but not pay runs or pay codes.

Frequently asked questions

Does Unified.to send events when payroll data changes?

On some objects. Reads always go to the payroll system at request time. Payslip events come from virtual webhooks on integrations such as Remote.com and Xero, which check at an interval you set, as often as every minute on paid plans; pay runs, pay codes and bank accounts send no events, so read them on a schedule after each pay date.

Does Unified.to store payroll data?

No customer records at rest. Each request goes to the source system, payroll payloads aren't stored, and logs hold operational metadata only; connection credentials and operational metadata are encrypted at rest. Unified.to is a subprocessor, with no stored copy of customer payroll records.

How do I start with payroll integration on Unified.to?

Unified.to's HR & Directory API reads payslips, pay runs, pay codes, deductions, benefits and bank accounts on supported payroll integrations, alongside employee and time data, across 711 HR & Directory integrations, with no customer records at rest. It's on every plan, from Grow ($750 a month), with a 30-day free trial on Grow and Pro.

Start a free trial or book a demo to see it work.