Use case: mergers and acquisitions

Payroll consolidation after a merger or acquisition

When an acquired company’s employees move onto the acquirer’s payroll, every person and pay code has to land correctly. SmartCompaire compares the legacy payroll with the target payroll employee by employee, so your team can sign off post-merger payroll integration testing on recorded evidence rather than spot checks.

Request a demo See all features

Why payroll consolidation in M&A is hard to test

A consolidation rarely starts from a clean slate. The acquired company has its own payroll system, employee numbers and pay code catalogue, often across several entities, countries and pay cycles to bring across before cut-over.

Parallel runs are the usual answer: pay the same people in both systems and compare the results. The hard part is the comparison.

Employee numbers change. One legacy pay code may become two in the new system, or the other way around. A pay code that exists on only one side is easy to miss in a spreadsheet lookup.

SmartCompaire handles the comparison. You load what each system produced and how employees and pay codes correspond; it shows the differences, labeled by your status rules, for your team to review, explain or raise as a defect.

How post-merger payroll integration testing works

Each comparison lives in a project with one source system and one target system. A typical M&A setup looks like this.

  1. Create a project per entity and cycle

    Record the name, comparison type (payroll or time), country, cycle, and source and target systems. The acquired company’s payroll is the source and the acquirer’s is the target. Two acquired entities going onto one target become two projects.

  2. Map old employee numbers to new ones

    Pair each source employee number with its target number. Each number can be mapped once in either direction, and duplicates in an imported file are rejected with their row number. Leading zeros are kept, and employees in the pay data with no mapping yet are listed.

  3. Map the two pay code catalogues

    Each mapping links a source pay code to a target pay code under a Bucket (such as Earnings or Taxes) and a Bucket code type, with optional tax authority codes. Where two legacy codes become one new code, both are summed and compared with it as a total.

  4. Load pay data from both payrolls

    Upload exports from each system as .xlsx, .xls or .csv files, type rows in, or paste them from a spreadsheet. Files up to 100 MB are accepted by default, large ones are imported in the background, and rejected rows in an imported file are reported with their spreadsheet row number and a plain reason (the first 100 on screen, up to 100,000 in a downloadable CSV).

  5. Check readiness, then run the comparison

    The readiness check shows how many pay rows will match a mapping and lists the largest unmatched pay codes (up to 25) with the reason, before anything runs. The run itself keeps rows found on only one side, so a pay code missing from either system appears as a result instead of being dropped.

    Learn more

  6. Review, explain and track to resolution

    Rows with a threshold for their Bucket and code type are graded against it and labeled by your status rules; rows without one are counted as having no threshold. Reviewers record overrides and comments, link rows to defects or to known and accepted differences, and rerun as fixes land.

Built for the details of an M&A consolidation

New employee numbers

Acquired employees usually get new IDs. The employee mapping carries the old-to-new pairing, so nobody matches people by name.

Different pay code catalogues

Mappings that share a source or target code are grouped, so many-to-one and one-to-many changes are compared as totals, not false differences.

Several entities and countries

Run one project per entity, country or cycle. The dashboard filters by country, cycle, comparison type and workflow status.

Repeated parallel runs

Every run is kept. A fixed mapping applies on the next run without re-uploading, and each run stores the thresholds and rules in force at the time.

Tolerances per bucket

Organization default thresholds per Bucket and code type are copied into each new project, then adjusted for that entity.

Defect tracking and reporting across the integration

Differences found during consolidation need an owner and an outcome, recorded next to the result rows.

  • Defects. Record a description, cycle, bucket, EE group, defect type, priority (Low to Critical), assignee, due date and status from Open through Resolved, Closed, Rejected or Deferred.
  • Known and accepted differences (KD/AD). Document expected differences, such as a deliberate pay code change, with a justification link and approval status. Result rows are linked one by one.
  • Row-level review. Set a status, status override, linked defect, linked KD/AD record and a comment of up to 4,000 characters on any result row.
  • Analytics. Outcomes by bucket, code type, employee or pay code, a bucket-by-status matrix, the over-threshold trend across runs, and defect counts by status, priority or assignee.
  • Reports for the steering group. Generate Dashboard, Comparison, Analytics, Defect, KD/AD and Executive Summary reports as PDF or Excel, for one project, one run or all active projects at once.Learn more

Access for both companies’ teams and outside consultants

An organization has four roles: viewer, member, admin and owner. Owners can grant or remove individual permissions per person, and no one can give a role higher than their own. Viewers can follow results without changing them.

Access is set per organization, not per project: every member can see every project in the organization. If one company’s payroll must stay hidden from the other company’s team, keep them in separate organizations.

Consultants can belong to several organizations and switch between them. Organizations are kept apart by database row-level security, though platform operator staff can access organizations for support; each switch is written to the audit log.

Hirra, the in-app assistant

Hirra answers questions about a project with the asking user’s own permissions. It is in beta and can make mistakes, so check figures that matter.

  • Project status and workflow help. Ask what is wrong with an entity’s project for a summary of setup, unmatched codes and the latest run. Hirra can also raise defects, record KD/AD items and queue reports.Learn more
  • Where the data goes. Questions and the data Hirra reads, which can include pay rows, are sent through the SmartCompaire backend to OpenRouter and its model providers; no zero-retention option is set. If you turn on the optional avatar, its spoken replies go from your browser to HeyGen.Learn more

What to plan for

A few things are worth knowing before you design the test plan.

  • Data arrives as files. There are no live connections to payroll systems. Exports from systems such as SAP, Workday, Oracle or ADP are loaded as spreadsheets or CSV files.Learn more
  • One cycle per project. All pay data in a project is added up per employee and pay code, so several periods in one project are compared as one total. Use a project per cycle to compare period by period.
  • Amounts are graded. Thresholds are absolute amounts, not percentages. Number (hours or units) and Rate differences are recorded but not graded, and MTD, QTD and YTD figures are stored but not compared.
  • Country is a label. Every project uses the same comparison logic. There are no country- or tax-regime-specific calculations.
  • It finds differences; it does not fix them. SmartCompaire records and grades differences. Corrections are made in your payroll systems, then confirmed in the next run.

Frequently asked questions

Can we test two acquired companies onto the same target payroll?

Yes. Create one project per acquired company or entity, each with its own source system and the shared target system. Reports can cover all active projects together.

Do employee numbers have to match between the two payrolls?

No. The employee mapping pairs each source employee number with its target number. Employees found in the pay data without a mapping are listed so you can complete it before running.

How do we handle differences we expect after the merger?

Record them as known or accepted differences (KD/AD) with a justification link and approval status, then link the affected result rows. Linking is manual, row by row; it does not suppress differences in later runs automatically.

Does SmartCompaire connect directly to our payroll systems?

No. Pay data and mappings are loaded from files, typed in, or pasted. Nothing is written back to either payroll system.

Parallel testing guide

What a payroll parallel test is, a step-by-step method and checklist, the mistakes that create false variances, and how to read the results.

System upgrades

Test a payroll upgrade, cloud move or new vendor by comparing old and new pay results by employee and pay code, and keep every run in the project’s history.

Integrations

SmartCompaire compares exported files from any payroll or time system, using templates and mappings rather than live connectors.

Hirra assistant

Hirra, the in-app AI payroll assistant, answers questions about your projects and runs using only the data your role can see.

Security

Tenant isolation, roles, sign-in, encryption, audit logging and where AI requests go, including what is not covered.

See SmartCompaire on your own payroll data

Bring a source and a target extract from your parallel run; we will walk through the comparison with you.

Request a demo