ADP CSV Import Errors: Fix Bad Employee Number & Codes

Fast Fix (2 Minutes)

If your ADP Workforce Now import just failed and you need a fix now:

1. "Bad employee number in row X" — ADP processed your header row as an employee record. Open the file, delete row 1 (the header row), save as CSV, re-import.
2. Earning code rejected — earning codes in ADP are case-sensitive strings registered in your company's ADP configuration. Open your ADP admin panel, pull the earning code list, verify the exact string your file is using matches character for character. Common mismatch: file uses "VAC", configuration expects "VACATION".
3. File rejected at upload — check the filename for spaces and special characters. Rename to alphanumeric with hyphens or underscores only (e.g., payroll-import-2026-05-23.csv).
4. Import succeeded but data landed in wrong fields — columns shifted. ADP maps by position. Check whether columns were added, removed, or reordered in the export since the import template was last configured.

---

Quick Answer

The most common ADP Workforce Now CSV import error — "Bad employee number in row 14" — is not caused by a bad employee number. It is caused by the header row not being removed before upload. ADP processes every row in the import file as an employee record; the header row's column labels are read as employee data, and "Employee_Number" (or whatever the header label is) fails ADP's employee number format check. The fix is to delete the header row before import.

---

Not legal or compliance advice. ADP import configurations vary by employer. Behavior described here reflects ADP Workforce Now documentation and community-reported patterns as of May 2026. Confirm specifics against your ADP company configuration.

---

TL;DR: ADP Workforce Now CSV imports fail for four main reasons: (1) the header row is included and processed as an employee record, producing "Bad employee number" errors; (2) earning code strings in the file do not match the exact case-sensitive strings in your ADP company configuration — the standard short codes (REG, OT, VAC) may not be what your employer configured; (3) filenames with spaces or special characters are rejected at the upload stage before row processing begins; (4) columns are mapped positionally, so adding, removing, or reordering export columns shifts all fields downstream of the change without producing an error — it silently loads incorrect data into wrong fields. All four are diagnosable with a file inspection before upload. SplitForge Format Checker validates file structure, encoding, column counts, and header presence without uploading your file.

---

What ADP's Error Messages Actually Mean

ADP Workforce Now import error messages describe the symptom at the data level, not the root cause in the file. This section translates the most common messages.

"Bad employee number in row 14"

What ADP means: Row 14 contains a value in the employee number field that does not match ADP's expected format.

What actually happened: Row 14 is your header row. ADP does not auto-detect or skip header rows. It processes every row in the file as an employee record. The value in the employee number column of row 14 is "Employee_Number" (or "EmpID" or whatever your export uses as a header label). That string fails ADP's employee number format validation.

The row number in the error varies: if your export has blank rows above the header, or metadata rows before the data begins, the header may not be row 1. ADP counts from the beginning of the file. Whatever row the header is on — that is the row number that appears in the error.

Fix: Open the CSV file. Identify the header row. Delete it. Save the file. Re-import.

Before (fails):
Employee_Number,Last_Name,First_Name,SSN,Earning_Code,Hours,Rate
103842,Johnson,Michael,547-82-3901,REG,80,32.50

After (correct):
103842,Johnson,Michael,547-82-3901,REG,80,32.50

If your ADP import configuration specifically requires a header row (some custom ADP setups do), verify with your ADP administrator whether the header should be present and what format it expects. Standard ADP Workforce Now payroll imports do not require a header row.

---

Earning Code Not Recognized

What ADP means: The value in the earning code column does not match any earning code registered in your ADP company configuration.

What actually happened: ADP earning codes are employer-specific, case-sensitive, exact strings. There is no universal ADP earning code standard that applies across all employers. Common abbreviated codes (REG, OT, VAC, SIC) are used by some employers; full-word codes (REGULAR, OVERTIME, VACATION, SICK) are used by others; custom employer-defined codes (PTO, FLEX, COMP, SHIFT) are used by others still.

When a payroll export uses abbreviated codes and the ADP configuration expects full-word codes — or vice versa — the import either rejects affected rows or, depending on ADP configuration, maps the unrecognized code to a default earning type.

Real scenario: An employer's ADP configuration was set up using full-word earning codes (VACATION, OVERTIME, SICK) during implementation. The payroll analyst preparing the import file uses abbreviated codes from a prior employer's ADP template (VAC, OT, SIC). ADP does not recognize "VAC" in a configuration where the registered code is "VACATION". The rows with "VAC" are rejected or silently misrouted.

Fix:

1. Pull the earning code list from your ADP company configuration (ADP admin → Company Setup → Earning Codes)
2. Compare the exact strings in your file against the configuration list
3. Replace all non-matching codes with the configuration-exact strings

Common mismatches:

The case-sensitivity rule: "REG" and "reg" are not equivalent in ADP. Whatever case the configuration uses — uppercase, mixed, lowercase — the import file must match exactly.

---

File Rejected at Upload (Before Row Processing)

What ADP means: The file did not pass ADP's initial upload validation before row-level processing began.

What actually happened: ADP Workforce Now's import interface validates the file at the point of upload. Common causes of pre-processing rejection:

• Filename contains spaces or special characters. Filenames with characters like spaces, commas, parentheses, or slashes may cause upload rejection depending on ADP version and browser behavior.
• File extension is incorrect. ADP expects .csv files. Files exported from Excel as .xlsx or saved with a .txt extension are rejected.
• File size exceeds the import limit. ADP has per-import file size limits that vary by ADP product tier. Very large payroll exports may need to be split into multiple files.

Fix: Rename the file to use only alphanumeric characters, hyphens, and underscores. Verify the extension is .csv. If the file exceeds size limits, split it into multiple batches and import sequentially.

Good filename: payroll-import-2026-05-23.csv

Problematic filenames: Payroll Import (Q2 2026).csv, payroll import 5/23/26.csv, Q2 payroll & benefits.csv

---

Correct Import — Data Lands in Wrong Fields

What ADP means: Nothing. ADP may report a successful import.

What actually happened: ADP maps import columns by position, not by column header name. If you added, removed, or reordered columns in the export since the ADP import template was last configured, the positional mapping shifted. Column 8 in the file is now mapped to whatever ADP expects at position 8 — which may be a different field than column 8 was before the reorder.

This is the most dangerous ADP import failure because it produces no error message. The import succeeds, and incorrect data is loaded into the wrong fields.

Example: An export template originally had 20 columns. A new "Remote Work Stipend" column was added at position 5. Columns 5 through 20 in the old template now map to positions 6 through 21 in ADP's expected schema. Every field from the old position 5 onward is now one position off. Pay rates land in the hours field. Employee IDs land in the last name field.

Fix:

1. Before any import, compare the column count and order in your export against the ADP import template
2. If columns were added, removed, or reordered, update the ADP import template mapping or revert the export to the original column structure
3. Run a test import with a single-row file and verify every field landed in the correct ADP field before importing the full dataset

---

ADP Import Error Cause/Fix Table

---

Pre-Import Validation Checklist

Run this before every ADP Workforce Now import:

• Header row removed from the file
• All earning code strings match your ADP company configuration exactly (case-sensitive)
• Filename uses only alphanumeric characters, hyphens, and underscores; extension is .csv
• Column count matches the ADP import template — no added, removed, or reordered columns
• Date format is consistent and matches ADP's expected format (MM/DD/YYYY in most configurations)
• No duplicate employee IDs in the file
• For multi-company imports: company code column is present and values match ADP company codes
• For update imports: employee IDs in the file match ADP's internal employee number format

SplitForge Format Checker validates file structure, encoding, column counts, date format consistency, and duplicate detection without uploading your payroll file.

---

Privacy Note: Validating ADP Files Without Upload

ADP payroll files contain SSNs, ABA routing numbers, salary data, and earning codes that may identify health conditions. Running these files through an online validation or cleaning tool before import creates a GDPR Article 28 processor relationship and transmits payroll data to infrastructure outside your control.

For the complete analysis of why uploading payroll files creates compliance exposure, see Never Upload a Payroll CSV to an Online Tool. SplitForge Format Checker validates file structure in your browser — no data is uploaded.

For the GDPR Article 28 framework specific to HR and payroll data, see HR Payroll CSV GDPR Compliance.

For the full HR and payroll CSV data prep workflow — encoding, masking, migration, and compliance — see the HR & Payroll CSV Data Prep Guide.

For the complete privacy-first processing framework, see Privacy-First Data Processing Guide.

---

FAQ