Validate an ADP payroll migration with a parallel run

ADP migration validation from exported files

How an ADP parallel test runs in SmartCompaire

One project holds one comparison. Its four data steps (employee mapping, paycode mapping, source pay data and target pay data) each accept a file upload, typed entry or pasted rows. Then you check readiness, run and review.

1. Create the project

   Name it, choose a payroll comparison, and record the country, cycle, and source and target systems. Your organization’s default thresholds are copied in and can be edited.

2. Map employees

   Pair each source employee number with its target number. Each number can be mapped once in either direction; duplicates are rejected with their row number.

3. Map pay codes

   Map each ADP earnings, deduction and tax code to its counterpart, with a Bucket and Bucket code type such as Earnings/Gross.

4. Load source and target pay data

   Upload both pay registers using the 15-column template. Only the PayCode column is required on each row.

   Learn more

5. Check readiness and run

   The readiness check shows how many rows will match a mapping and lists unmatched pay codes with the reason. The run compares every employee and mapping group in the background.

6. Review and sign off

   Filter results, set statuses and overrides, link rows to defects or known and acceptable differences (KD/AD), and generate PDF or Excel reports.

   Learn more

Mapping ADP earnings and deduction codes

Pay code mapping is where most of an ADP migration’s design decisions show up, including codes that do not line up one to one.

• Many codes to one. When two source codes map to one target code, or the reverse, the mappings are grouped and each side is summed, so a consolidated code is not reported as a false difference.
• Tax authority in the key. Mapping keys join tax authority and pay code on each side, so the same code under two authorities stays separate. A blank tax authority matches the code under any authority. An optional override pay code replaces the target tax authority in the key.
• No guessing on ambiguous rows. If a pay row has no tax authority and its pay code is mapped more than once, the row is left unmatched rather than assigned to one of the mappings.
• Fix mappings without reloading. Each run re-matches pay rows against the current mappings. Correct a mapping after the upload and the next run picks it up.

Preparing ADP exports for import

The import accepts common spreadsheet quirks and tells you exactly which rows it could not use.

• File types. Upload .xlsx, .xls or .csv. Only the first worksheet is read. Headers must be the template’s column names (a system ID prefix is fine); without a PayCode column the import stops and names what is missing.
• Headers and IDs. Header matching ignores case, spaces and punctuation. Leading zeros in employee IDs are kept, so 0012345 stays 0012345, as long as the export keeps them as text (CSV, or a text-formatted Excel column).
• Amounts and dates. Dollar signs, thousands commas and accounting negatives such as (12.00) are accepted. Dates can be Excel serials or formats such as YYYY-MM-DD and MM/DD/YYYY.
• Exact decimals. Amounts are stored as exact decimals: 4 places for money, 6 for rates.
• Large registers. Files up to 100 MB can be uploaded by default. Every file is imported in the background, 5,000 rows per batch, with progress tracking and a cancel option. Files over 2 MB skip the in-browser preview.
• Row-level rejections. Each rejected row is reported with its spreadsheet row number and a plain reason. A downloadable CSV holds the original cells for up to 100,000 rejected rows.

Common pitfalls in ADP payroll parallel testing

These issues most often make a parallel run look worse, or better, than it is.

Grading differences and tracking them to sign-off

• Thresholds per bucket. Set an absolute amount, not a percentage, for each Bucket and Bucket code type pair. A row passes when the absolute difference is at or under it.
• Status rules. Label each row, such as Matched, Within Threshold or Over Threshold, using rules your organization can add to or adjust.
• Defects and KD/AD records. Raise a defect with priority, assignee and due date, or record a KD/AD with a link to its justification, and link result rows to either.
• Repeatable runs. Each run keeps the thresholds and status rules in force at the time, and a trend chart shows over-threshold counts by run.
• Help from Hirra. The in-app assistant, in beta, can summarize a project, list its largest unmatched pay codes and suggest next steps, within what your role can see.Learn more

What to know before you start

Frequently asked questions