Version upgrade
Pay codes and employee numbers often stay the same, so most mappings are one to one. The comparison shows where changed calculation logic in the new release produces different amounts.
Use cases · System upgrades
Prove the new payroll system pays the same as the old one
A version upgrade, a move to the cloud or a switch to a new payroll vendor all end with the same question: does the new system pay every employee what the old one did? SmartCompaire handles payroll system upgrade testing by comparing the pay results both systems export, employee by employee and code by code.
What payroll system upgrade testing has to prove
Whatever kind of change it is, sign-off depends on evidence that gross pay, deductions, taxes and net pay agree between the current system and the new one, or that every difference has been explained. Sampling a few employees by hand doesn’t give you that. A full comparison does.
SmartCompaire runs that comparison from files. There is no live connection to any payroll system: source and target pay results come in as spreadsheet or CSV exports, typed rows, or rows pasted from a spreadsheet. If both systems can export pay results, you can compare them, whether the target is a new release of the same product or a different vendor.
SmartCompaire never writes anything back to either system. It finds, grades and records differences. Your team decides what to fix and where.
Three kinds of change, one comparison
The method is the same for each. What changes is how much mapping work the project needs.
Cloud move
Moving from an on-premises installation to a hosted version of the same product can still change codes, tax setup or employee numbering. Mapping tables record each of those decisions in one place.
New payroll vendor
A re-implementation on a different platform usually means new employee numbers and a redesigned code structure. Employee and pay code mappings bridge the two, including codes that are split or combined.
Learn moreHow a payroll implementation test runs
One project holds one comparison. After you create it, the mapping and pay data steps each accept a file upload, typed entry or pasted rows. The last two steps run and review the comparison.
Create the project
Record the name, comparison type (payroll or time), country, cycle, and the source and target systems. The organization’s default thresholds are copied in and can be edited for this project.
Map employees
Pair each source employee number with its target number. Each number can be mapped only once in either direction, and leading zeros are kept, so 0012345 stays 0012345. The step also lists employees who appear in the pay data but have no mapping yet.
Map pay codes
Map each old code to its new counterpart and assign it to a Bucket and Bucket code type, such as Earnings/Gross or Taxes/Employee. Tax authority codes are optional.
Load source and target pay data
Upload both pay registers in the 15-column template. Only PayCode is required for a row to import, but rows without an Employee # are left out of the comparison. Rejected rows are reported with their spreadsheet row number and a plain reason.
Learn moreCheck readiness, then run
The readiness check shows how many rows will match a mapping and lists unmatched pay codes with the reason. The run then compares every employee and mapping group in the background.
Review, explain and report
Filter the results, set statuses and overrides, link rows to defects or to known and acceptable differences (KD/AD), and generate PDF or Excel reports.
Learn more
Built for repeated test cycles
Implementations rarely pass on the first parallel run. SmartCompaire is designed around fixing and rerunning.
- Run as often as you need. A project can be run many times, and every run stays in its history with its counts and who started it.
- Fix a mapping without re-uploading. Each run re-matches pay rows against the current mappings, so a corrected mapping takes effect on the next run.
- Past results stay put. Each run stores a copy of the thresholds and status rules in force at the time. Editing them later doesn’t change earlier results.
- See whether it’s getting better. The variance trend chart shows over-threshold counts per run, oldest first, for the most recent 12 runs.
- Add or replace data. Imports add to existing rows by default, and a run totals every row in the project, so re-importing the same or an updated export doubles its amounts. To load a corrected export or the next test cycle, an admin replaces the dataset (or clears it first), or you set up a new project for that cycle. An import that fails partway writes nothing.
What the comparison catches
- Amount differences. For each employee and mapping group, a run records the source amount, target amount and difference, and grades the difference against an absolute threshold set per Bucket and Bucket code type.
- Codes paid on one side only. A mapped pay code with pay in only one system shows up as a result row instead of being dropped, so a deduction the new system no longer takes is visible and graded. A code with no counterpart at all can’t be mapped, so its rows appear as No paycode mapping rather than being graded.
- Restructured codes. When two old codes map to one new code, they are summed and compared as a total. Mappings that share a source or target key are grouped the same way.
- Gaps in setup. Rows that can’t be paired are labelled No employee mapping or No paycode mapping, and each run counts them, so incomplete mappings don’t hide as matches. The exception is pay rows with no Employee #, which are left out of the run.
- Number and Rate changes. Differences in Number and Rate are recorded alongside Amount. Only the Amount difference is graded against thresholds.
From differences to sign-off
Some differences are bugs in the new configuration. Others are expected, such as a deliberate change in how the new system rounds or calculates. Reviewers can link each result row to a defect, with a priority, assignee, due date and status, or to a KD/AD record that holds the justification and a link to the supporting document. Linking is manual, row by row.
Analytics groups outcomes by bucket, code type, employee or pay code, with counts and total variance. For sign-off, six report types are available as PDF or Excel, including a Comparison report with up to the 500 largest over-threshold rows and an Executive Summary written in prose.
Roles keep the work controlled. Importing data and starting a run are separate permissions, bulk status changes need the admin-level bulk update permission, and viewers can read results but can’t save edits.
Upgrading a time system
Time projects use the same file layout and comparison logic as payroll. Hours or units go in the Number column. Number differences are recorded but not checked against thresholds, so grading applies to the Amount column. There are no rules specific to time and attendance, such as shifts or overtime.
Frequently asked questions
Does SmartCompaire connect directly to our old or new payroll system?
No. All data comes in as uploaded spreadsheet or CSV files, typed rows, or pasted rows. The server accepts .xlsx, .xlsm, .xls, .ods and .csv, reads the first worksheet, and has a default upload limit of 100 MB.
Can we compare several pay periods in one project?
A project adds up all of its pay data per employee and pay code, so several periods or check dates in one project are combined into a single total. To check each period on its own, set up one project per period.
Are MTD, QTD and YTD balances compared?
They are imported and stored with the pay data, but they are not compared. The comparison grades the Amount column.
Can thresholds be percentages?
No. Thresholds are absolute amounts set per Bucket and Bucket code type. A row passes when the absolute difference is at or below its threshold, and a row with no threshold gets no pass or fail grade.
How do I confirm a fix after an upgrade test finds a difference?
Make the fix in the payroll system itself: SmartCompaire finds, grades and records differences but never writes corrections back. Then re-export, have an admin replace the pay data, and rerun; the next run shows whether the fix worked.
Related
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