Use case: compliance and configuration changes
A new tax rule, union agreement or benefit deduction should change some pay codes for some employees, and nothing else. SmartCompaire compares the payroll results before and after the change, employee by employee and pay code by pay code, so payroll compliance testing covers every employee and pay code in the exports you load, rather than a sample of payslips. Your team still decides which differences are correct.
Configuration changes are routine in payroll: a tax table update, a negotiated rate increase in a union agreement, a new benefit plan or a revised deduction. Each one is meant to move specific amounts. The risk is the side effect you did not plan for, such as a deduction that now calculates on the wrong base, or a pay code that stopped appearing for one group of employees.
Spot-checking a few payslips confirms the intended change. It does not show what else moved. To validate payroll changes properly, you need every employee and every pay code from the run before the change, set against the same population after it, with each difference either explained or raised as a defect.
Each comparison lives in a project with a source and a target. For a change test, the source is the payroll result before the change and the target is the result after it. Both can come from the same payroll system.
Record a project name, the comparison type (payroll or time), country, cycle name, and the source and target systems.
When both runs come from the same system, employee numbers usually map to themselves. Leading zeros are kept, so 0012345 stays 0012345. Pay codes are mapped under a Bucket (such as Earnings, Deductions or Taxes) and a Bucket code type, with optional tax authority codes on each side. Every mapping pairs a source pay code with a target pay code, so a code renamed by the change is mapped from its old code to its new one. A code with no counterpart before the change appears as a "No paycode mapping" row with its amount, ungraded, for review.
Upload an export from each run as an .xlsx, .xls or .csv file, type rows in, or paste them from a spreadsheet. The pay data template carries tax authority code, pay code, number, rate and amount for each employee. Every row a file import rejects comes back with its spreadsheet row number and a plain reason; pastes of more than 500 rows are imported the same way.
The readiness check shows how many source and target pay rows will match a mapping and lists unmatched pay codes with the reason. It uses the same matching rules as the run, so a missing mapping for a new code shows up here first.
The run keeps rows found on only one side. A pay code that appears after the change but not before, or that disappeared, becomes a result row instead of being dropped. Each row records the source amount, target amount and difference, plus differences in number and rate. Where an employee has several rates for one pay code, the row compares the highest rate on each side.
Learn moreReviewers set a status override and comment on each row, link expected differences to a known or acceptable difference (KD/AD) record, and raise defects for the rest. Imports add to existing data, so after a configuration fix an admin replaces the target pay data with the new results (or you start a new project for the retest), and you run again; every run is kept.
A change test only works if the expected movement is easy to tell apart from the unexpected. These controls decide how each row is graded.
A threshold is an absolute amount set per Bucket and Bucket code type pair. A row passes when its difference is within that amount. Organization defaults are copied into each new project and can be edited there or pasted in from Excel.
Status rules label each row by comparing its difference with the threshold or a fixed number. Organizations can add their own rules and override or switch off the platform defaults.
Each run stores a copy of the thresholds and status rules in force when it ran. Tightening a threshold later does not rewrite earlier results, so each run still shows how it was graded at the time.
A KD/AD record holds a description, a link to a justification document, an assignee, dates and a status such as Approved. Approved is a status a reviewer sets, not a signed or audited approval. Result rows whose difference is the intended effect of the change can be linked to it.
A defect records the Bucket, Bucket code type, defect type, priority, assignee, due date, status and resolution comments. Result rows can reference the defect, so the defect and the rows that show it stay together.
Analytics shows outcomes by Bucket, Bucket code type, employee or pay code, and an over-threshold trend across runs. You can see whether each configuration fix reduced the number of over-threshold rows.
SmartCompaire keeps these records for each project.
SmartCompaire compares results. It does not contain tax tables or the terms of any union agreement, and it does not judge whether a calculation complies with a regulation. Country is a label on the project, and every project uses the same comparison logic. Your team decides which differences are correct.
Amounts are added up per employee and pay code across all pay data in a project. If you need to test several pay periods or check dates separately, create a project for each.
Only the amount difference is graded against thresholds. Number and rate differences, such as a changed hourly rate, are recorded on each row but not graded, and MTD, QTD and YTD amounts are imported but not compared.
Thresholds are absolute amounts, not percentages. Linking rows to a KD/AD record is done row by row, and a KD/AD record does not carry over to later runs on its own. SmartCompaire does not write corrections back to your payroll system; fixes are made there and tested again.
Not on its own. SmartCompaire has no tax tables or country-specific rules. It shows exactly which employees and pay codes changed between the run before and the run after, and by how much, so your payroll and tax specialists can confirm the intended effect and investigate everything else.
Yes. A project records a source and a target, and for a change test they can be the same system before and after the configuration change. You still provide employee and pay code mappings; when the numbers and codes are unchanged, each one maps to itself.
No. Each run stores a copy of the thresholds and status rules in force when it ran. Edits apply to the next run.
The comparison records differences in amount, number and rate for each row, but only the amount difference is graded against thresholds. A rate increase therefore shows up through the amount it produces, and the rate difference is visible on the row for review. Where an employee has several rates for one pay code, such as retro pay or a mid-period increase, the row compares the highest rate on each side.
A result row holds its current status, override, linked records and comment, along with the time it was last updated. It does not keep a per-field change history. Run history, import history, defects and KD/AD records are kept separately for each project.
Bring a source and a target extract from your parallel run; we will walk through the comparison with you.
Request a demo