What Is Payroll Integration? A Complete Guide (2026)

April 28, 2026

Payroll integration is the process of connecting external applications to payroll systems (ADP, Gusto, Paychex, Paylocity, Workday, and others) to read and write payroll-related data — pay runs, payslips, deductions, benefits, time worked, and bank accounts. The architectural distinction worth understanding upfront: payroll data doesn't live in just 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-relevant data across the broader workforce data surface where it actually 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 directly.
• 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). Records join on Employee ID.
• Unified.to does not provide a separate Payroll API. Payroll integration is delivered through Unified's HR & Directory API, which spans 236 integrations including major payroll systems (ADP Workforce Now, Gusto, Paychex, Paylocity, Paycor, Paycom, PayFit, Workday, Rippling, Ceridian Dayforce, Deel, UKG Pro HCM, and others) plus HRIS, identity, and adjacent workforce data integrations.
• 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. Real-time event delivery doesn't apply the same way it does for CRM data — the integration is about reading recorded payroll artifacts, not subscribing to high-frequency 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 specific payroll system varies — ADP, Gusto, 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 — labor 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 canonical objects in a payroll integration are Employee, Payslip, Timeshift, Deduction, Benefit, BankAccount, and Time Off. They join on employee identifiers.

Payslip — pay-period snapshots

A payslip represents what was actually paid for a specific pay period. The verified Unified Payslip schema 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

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.

Benefit — company-wide benefit plans

A Benefit represents a benefit plan offered by the company (e.g., "401(k) Plan"). The Unified Benefit schema 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
• 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 Unified Deduction schema 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

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 Unified Bank Account schema 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

Note the routing number format is US-specific (9-digit). For non-US payroll integrations, bank account semantics may differ — confirm per-integration support.

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 surfaces 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.

This is why Unified consolidates payroll, HRIS, identity, and adjacent workforce data into a single HR & Directory category rather than fragmenting them into separate APIs.

What does payroll integration data actually look like?

Through Unified's HR & Directory API, payroll-relevant data is read using standard endpoints that follow the same pattern across all 236 HR & Directory integrations.

Listing payslips for an employee:

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

Listing employees:

GET https://api.unified.to/hris/employee/{connection_id}?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/timeshift/{connection_id}?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 endpoint structure works for ADP, Gusto, Workday, Paylocity, BambooHR, or any other supported integration — only the connection_id changes.

What's intentionally not in the payroll model

A few things worth knowing about what Unified deliberately doesn't do:

• No invented payroll history. Unified 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's HR & Directory API spans 236 integrations. Coverage for payroll-specific data (Payslip, Deduction, Benefit, BankAccount) varies meaningfully by integration — typical readable-field support across the integration set is in the 5-11 integration range per Payslip field, with rollout expanding over time. Always check the Supported Integrations page for current per-integration feature support before committing to specific use cases.

The unambiguously payroll-capable integrations within the 236 include:

• ADP Workforce Now — enterprise payroll. ADP publishes its developer documentation at the ADP Developer Portal for direct API integration.
• Gusto — SMB payroll, benefits, and HR infrastructure. Gusto's developer documentation covers their embedded payroll API.
• Paychex — SMB to enterprise payroll
• Paylocity — payroll and HR technology
• Paycor — payroll and workforce management
• Paycom — enterprise payroll and HR
• PayFit — European payroll automation
• Payworks — Canadian payroll
• Workday — enterprise HCM and payroll
• Rippling — combined HR, payroll, IT
• Ceridian Dayforce — enterprise payroll and workforce management
• Deel — global payroll and contractor payments
• Employment Hero Payroll — APAC SMB payroll
• UKG Pro HCM, UKG Ready — enterprise HCM
• Trinet Zenefits — SMB payroll and benefits
• PrismHR — PEO/ASO payroll infrastructure
• Sage HR — SMB and mid-market payroll
• Iris HR — UK payroll and HR
• Humi — Canadian SMB payroll
• Readytech Zambion — APAC payroll

Plus HR integrations that include payroll functionality (BambooHR, HiBob, Personio, FactorialHR, HeavenHR, Namely, PeopleHR, and others), and adjacent integrations where payroll-relevant data is referenced (QuickBooks, Xero, Sage Intacct, NetSuite, Brex, Ramp, Bill.com, identity integrations like Okta and Microsoft Entra ID, and time-tracking integrations like Deputy, Humanforce, and Harri).

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.

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 at rest become full sub-processors for that data
• Real-time pass-through integrations route requests live to the payroll system without storing customer payroll records
• The distinction affects SOC 2, GDPR, and HIPAA scope substantially

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, Gusto, and Workday represent earnings, deductions, and tax types in fundamentally different shapes. Unified's normalized Payslip object converges these onto consistent fields (gross_amount, net_amount, details[]), but vendor-specific custom deduction types and earnings codes still require either explicit handling or raw passthrough access.

Common payroll integration use cases

Labor cost analytics and reporting

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

Financial reconciliation between payroll and accounting

Feed payroll run totals into accounting systems as journal entries. 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 enrollment, and time off balances. Combining Payslip, Deduction, Benefit, and Time Off data through a single API surface simplifies the integration footprint substantially.

Contractor payment automation

For products supporting global contractor payments (Deel, Remote, Rippling), the integration handles tax compliance and payment routing across jurisdictions through the payroll integration layer.

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. Some payroll systems use OAuth (Gusto, Rippling); some use API keys (Paychex); some use enterprise authentication patterns specific to large vendors (ADP, Workday). 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 data stored at rest minimize this.
• 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 if

• You support (or plan to support) multiple payroll vendors across customers
• You want time-to-first-customer measured in minutes, not weeks
• You'd rather not build per-vendor authentication and normalization infrastructure
• You want consistent semantics across payroll, HRIS, and adjacent workforce data
• You want to keep payroll data out of your application's compliance scope (pass-through architecture, no payroll data stored 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.
• Don't assume real-time event delivery for payroll runs. Payroll is batch-driven; the integration should poll for change detection on pay runs rather than expecting native webhooks.

Frequently asked questions

What is payroll integration?

Payroll integration is the connection between an external application and a payroll system, enabling programmatic access to payroll and compensation 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 directly.

Which payroll systems can be integrated through Unified?

Unified's HR & Directory API spans 236 integrations including major payroll systems: ADP Workforce Now, Gusto, Paychex, Paylocity, Paycor, Paycom, PayFit, Payworks, Workday, Rippling, Ceridian Dayforce, Deel, UKG Pro HCM, UKG Ready, Trinet Zenefits, PrismHR, Sage HR, Iris HR, Humi, Employment Hero Payroll, and many others. The full list is at unified.to/hris.

Does Unified have a separate Payroll API?

No. Payroll integration is delivered through Unified's HR & Directory API. This is intentional — payroll data spans more than just the payroll system (HRIS, identity, time tracking, accounting all carry payroll-relevant data), and consolidating these into a single API surface reduces integration footprint substantially.

How does payroll integration differ from HRIS integration?

Payroll integration focuses on pay runs, compensation, withholdings, deductions, and payments. HRIS integration focuses on the broader employee identity and lifecycle: employees, positions, groups, locations, time off, time tracking. They overlap substantially — a payslip references an employee (HRIS data), and time worked feeds payroll calculations. Most B2B SaaS products integrating payroll need to read across both HRIS and payroll, which is why Unified consolidates them into a single API category.

What's the difference between Payslip and Employee compensation?

Payslip records are point-in-time snapshots of what was actually paid for a pay period — they have start_at, end_at, paid_at, gross_amount, and net_amount fields. Employee.compensation[] represents current-state compensation only, with no effective-date semantics. For historical payroll analysis, use Payslip records. For current compensation, use the Employee record.

Are payroll updates real-time?

Reads are real-time pass-through — every request hits the source payroll system live, with no cached replica. But payroll itself is batch-driven by nature: pay runs happen on weekly, biweekly, or monthly schedules. The "real-time" framing is about data freshness on read, not about subscribing to high-frequency change events. Change detection on payroll records uses virtual webhooks (polling-based) where event delivery is needed.

Does Unified store payroll data?

No. The HR & Directory API is real-time pass-through — every request is routed live to the source system. Payroll payloads are not stored at rest. Payroll data is not written to logs. This minimizes the compliance scope for SOC 2, GDPR, and HIPAA — the integration vendor isn't a sub-processor for the payroll data itself.

How do I handle payroll data across multiple currencies?

Each Payslip carries its own currency field. Unified does not normalize across currencies — aggregating compensation across multiple currencies requires explicit conversion logic in the application. The same applies to Timeshift compensation, which carries currency and frequency (HOUR, DAY, ONE_TIME).

What if a payroll integration doesn't support a feature I need?

If an integration doesn't surface a particular payroll object (Payslip, Deduction, etc.), Unified returns HTTP 501 Not Implemented. The connection itself is still valid — only the unsupported feature isn't available. The Feature Support tab in the Unified app shows per-integration capability for each object.

Final thoughts

Payroll integration is a category that benefits substantially from a unified architecture. The data is sensitive, the schemas vary, the compliance requirements are jurisdiction-specific, and the data itself spans more than just the payroll system. For B2B SaaS products supporting payroll-related features across multiple customers, building each integration directly means repeating the per-vendor authentication, schema normalization, rate-limit handling, and compliance work for every payroll system the product supports.

Unified.to consolidates payroll integration into the HR & Directory API alongside 235 other workforce data sources — covering ADP, Gusto, Paychex, Workday, Rippling, Ceridian Dayforce, Deel, UKG, and more, plus HRIS and identity integrations — through a single normalized schema with consistent semantics, raw passthrough for vendor-specific fields, and pass-through architecture that keeps customer payroll data out of compliance scope.

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