HR & Payroll CSV Data Prep: Import, Mask & Migrate (2026 Guide)

Quick Answer

The most common HR and payroll CSV import failures trace to three sources: encoding mismatches (Gusto rejects files that are not UTF-8 without BOM), column count mismatches (Workday EIB templates have a per-employer fixed column count — a 47-column template rejects a 44-column file with a row-level error), and header row handling (ADP processes the header row as an employee record, producing an employee-number error on what is actually the column label row). Fix encoding first, validate column count against your platform's current template, then remove the header row for ADP imports.

---

Not legal or compliance advice. GDPR, HIPAA, and payroll-specific regulations vary by jurisdiction and employer type. Consult qualified legal and compliance counsel before finalizing data handling procedures for HR and payroll data.

---

TL;DR: Payroll CSVs carry some of the most sensitive data in any organization — SSNs in Social Security Administration format (XXX-XX-XXXX), ABA routing numbers in 9-digit American Bankers Association standard, salary figures, bank account numbers, and earning codes that implicitly identify health conditions (STD leave, FMLA codes, disability pay differentials) and union membership. Four platforms dominate mid-market HRIS imports: ADP requires header row removal and case-sensitive earning codes ("REG" not "Regular"); Gusto requires UTF-8 encoding without BOM; Workday EIB requires exact column counts matching the employer-specific template; QuickBooks Payroll silently overwrites bank routing numbers with blanks when account fields are present but empty in the import file. Under GDPR, uploading a payroll CSV to a cloud-based processing tool creates an Article 28 processor relationship — regardless of whether the vendor markets itself as secure. Earning codes that implicitly identify health conditions may trigger Article 9 special-category obligations. Browser-local processing via Web Workers eliminates the processor relationship entirely: the file is handled by JavaScript threads that operate in browser memory with zero network transmission.

---

A Workday HRIS administrator imports a 2,400-employee payroll extract for a quarterly compensation review. The EIB template was configured during the 2023 implementation with 47 required columns. Since then, the payroll team added three columns to the standard export: a remote-work stipend field, a new benefit tier code, and a manager-approval flag. The import fails at row 23.

Row 23: Expected 47 columns, found 44

The administrator strips the three new columns and re-exports. The import fails again — the new benefit tier code was mapped to a column that existed in 2023 but was since renamed in the EIB template. The EIB does not detect column name mismatches. It maps by position. Position 31 in the file now contains the wrong data type for position 31 in the template.

Meanwhile, a payroll analyst at a different company runs a QuickBooks Payroll import to update direct deposit information for 180 employees. The import completes without any error message. Three payroll periods later, 23 employees report missing direct deposits. Investigation reveals that the import file contained blank values in the routing-number column for those employees. QuickBooks Payroll accepted the blank values and overwrote the existing routing numbers with empty strings — no warning, no rejected rows, no validation error surface anywhere in the interface.

These are the failure modes that cost payroll operations hours of investigation and, in the QuickBooks case, real payroll disruption. They happen because payroll import interfaces are designed around vendor data models, not around making import requirements transparent to the people preparing the files.

Platform import behaviors documented here reflect vendor documentation and community-reported patterns as of May 2026. Import templates, column requirements, and error messages change with platform updates. Always validate against your platform's current template before production imports.

---

Table of Contents

• What Payroll CSVs Actually Contain
• Why Uploading Payroll Data Creates Regulatory Exposure
• Platform Import Schemas: ADP, Gusto, Workday EIB, QuickBooks Payroll
• Payroll Import Error Taxonomy
• Pre-Import Prep Workflow
• Masking Sensitive Fields Before Import
• HRIS Migration Workflow
• Validation Before Submission
• Compliance Alignment
• Additional Resources
• FAQ

---

What Payroll CSVs Actually Contain

Payroll exports are not ordinary spreadsheets. They combine multiple categories of personally identifiable information in a single file — data that, individually, might be unremarkable, but in combination creates a comprehensive profile of every employee: their identity, location, earnings, banking relationships, and often their health history.

The SSN format. The Social Security Administration issues SSNs in the format XXX-XX-XXXX: three digits, a hyphen, two digits, a hyphen, four digits. Payroll exports from different systems represent SSNs differently — some strip the hyphens (9-digit string), some include them, some partially mask the first five digits. Each representation requires different handling before import into platforms that validate SSN format.

The ABA routing number format. The American Bankers Association routing transit number is a 9-digit identifier assigned to financial institutions. Routing numbers do not contain hyphens in standard format. Payroll exports may include routing numbers with leading zeros — which Excel automatically strips if the column is not formatted as text. A routing number that was 021000021 becomes 21000021 (8 digits) after an Excel CSV round-trip, which fails platform validation.

The Article 9 trigger in earning codes. Under GDPR Article 9, processing data that reveals health conditions requires a higher legal basis than standard personal data. Earning codes that indicate paid leave for medical conditions — STD (short-term disability), FMLA (Family and Medical Leave Act leave), DISB (disability pay differential), or employer-specific health leave codes — implicitly reveal that an employee had a qualifying health condition during the period covered. When a payroll CSV contains these codes for EU-based employees or EU residents, the file may carry Article 9 special-category data even though the column is labeled "Earning Code" rather than "Health Status."

This distinction is not theoretical. A payroll CSV with only REG and OT earning codes carries different regulatory weight than one that includes STD and FMLA codes for the same employees. The Article 9 exposure exists at the row level — a single STD row for a single EU-resident employee in a 10,000-row file creates Art. 9 obligations for the entire file handling workflow.

A payroll CSV that also includes union dues deductions may carry Art. 9 data on trade union membership — another explicitly listed special category under Art. 9(1).

For a detailed GDPR compliance framework for HR and payroll data, including lawful basis analysis and data processing agreement requirements, see HR Payroll CSV GDPR Compliance.

---

Why Uploading Payroll Data Creates Regulatory Exposure

1. What cloud-based CSV tools do

Cloud-based CSV processing tools receive your uploaded file on a remote server. The file is stored — temporarily, in most cases, but the definition of "temporary" varies by vendor and by tier — in blob storage infrastructure, processed on compute capacity shared across multiple customers, logged for debugging and audit purposes, and accessible to vendor support personnel for troubleshooting. Backup snapshots may retain copies beyond the stated retention period.

This architecture is standard for cloud tools and is not a sign of bad intent. It is also structurally incompatible with payroll data privacy requirements, because it means the file left your organization's control the moment you uploaded it.

2. The specific regulatory risk

Uploading a payroll CSV to any cloud-based processing tool creates a GDPR Article 28 data processor relationship. The regulation does not distinguish between tools used for one-off cleanup and tools used for sustained processing — the upload is the trigger. Article 28 requires:

• A signed Data Processing Agreement with every processor that handles personal data on the controller's behalf
• Verification that the processor provides sufficient guarantees about technical and organizational security measures
• Controller liability for processor failures, regardless of whether the controller performed adequate due diligence

The McDonald's Poland precedent (UODO decision DKN.5130.4179.2020, 21 July 2025, €4,022,773 fine) established controller liability for inadequate processor due diligence. The controller used a processor that lacked adequate safeguards. The processor was compromised. The controller paid.

If the payroll file contains earning codes that implicitly reveal health conditions for EU-resident employees, Article 9 special-category protections layer on top of Art. 28 obligations — requiring an Art. 9(2) basis for the processing and elevating the security requirements for the processor.

3. How SplitForge processes payroll data

SplitForge Data Masking processes files using Web Worker threads running in your browser. Web Workers are JavaScript background threads that operate entirely in browser memory. They do not make network requests. Your payroll CSV is loaded via the browser File API — which reads the file from your local filesystem without any network transmission — passed to a Web Worker thread for processing, and exported via the browser Blob API to a local download.

No payroll data crosses a network boundary at any point in this workflow. No processor relationship is created under GDPR Art. 28. No DPA is required for the processing step.

4. The verifiable claim

Open your browser DevTools (F12) and navigate to the Network tab. Load SplitForge Data Masking. Drop a payroll CSV file. Watch the Network tab during the entire processing cycle.

You will see zero POST requests to any external domain during file processing. The requests that appear are for page assets only — JavaScript, CSS, fonts — not data uploads.

To confirm there is no server dependency: turn off Wi-Fi or disconnect your network connection after the page finishes loading, then process the file. The masking operation completes and the export downloads correctly, because the processing runs in your browser, not on a server.

For the complete privacy-first data processing framework across HIPAA, GDPR, and SOC 2, see our privacy-first data processing guide.

---

Platform Import Schemas: ADP, Gusto, Workday EIB, QuickBooks Payroll

Each platform makes different structural assumptions about how CSV import files will be formatted. These assumptions are incompletely documented and the error messages that result from format violations range from specific to completely opaque.

ADP Workforce Now

Header row behavior. ADP Workforce Now CSV imports process every row in the file as an employee record — including the header row. When you export a payroll file from your source system and upload it directly to ADP without removing the header row, ADP attempts to parse the column label row as employee data.

The error produced by this:

Bad employee number in row 14

The "employee number" in row 14 is the string "Employee_Number" — the column header. ADP does not auto-detect or skip header rows. The row count in the error message may vary depending on whether blank rows precede the header in the export.

Earning code case sensitivity. ADP earning codes are case-sensitive exact strings registered in your company's ADP earning code configuration. "REG" and "Regular" are not equivalent. "reg" will not match "REG". The import will either reject the row or silently assign the unrecognized code to a default earning type, depending on your ADP configuration.

Common standard ADP earning codes in their required format:

Custom earning codes are employer-specific. Always pull the current earning code list from your ADP company configuration before preparing an import file. A code list from a previous employer's ADP environment may not map correctly in a different company configuration.

Positional column mapping. ADP imports map columns by position, not by header name. Adding a column to the export or reordering columns shifts all fields downstream of the change. A column added at position 5 in a 20-column template causes columns 6 through 20 to be read as the wrong fields. The import may not error — it may silently load incorrect data into the wrong fields.

Multi-company imports. ADP supports multi-company environments where a single import file contains employees from multiple company codes. The company code column must be present and correctly formatted when using this mode. A common error: exporting from a single-company context and uploading to a multi-company ADP configuration without including the company code column.

---

Gusto

Encoding requirement. Gusto requires UTF-8 encoding without a Byte Order Mark (BOM). Files exported from Windows Excel are frequently saved as UTF-8 with BOM (the Windows Excel default when choosing CSV UTF-8 format) or as Windows-1252 (ANSI) encoding when saved as generic CSV. Both produce this error on Gusto upload:

File encoding not supported. Please upload a UTF-8 encoded file

The error message does not identify which encoding was detected — only that it was not the expected UTF-8-without-BOM. Files exported from Google Sheets default to UTF-8 without BOM and typically do not trigger this error. Files exported from macOS Numbers also default to UTF-8 without BOM.

The BOM is a 3-byte sequence (EF BB BF) prepended to the file by some editors and export tools to mark the encoding. It is invisible in most text editors and spreadsheet applications, which is why this encoding issue catches people off guard — the file "looks fine" but Gusto rejects it.

Delimiter expectations. Gusto expects comma-delimited CSV. Tab-delimited exports from payroll systems that use TSV as their default produce silent misalignment rather than an error: Gusto reads the entire row as a single field containing the raw tab-separated string. The import may appear to succeed while creating malformed employee records.

Required field minimums. Gusto payroll imports require at minimum: legal first name, legal last name, and either SSN or ITIN. Employee records that include SSN placeholders — strings like "PENDING", "TBD", or "000-00-0000" — will fail SSN format validation or create records with invalid SSN values that surface as errors during year-end W-2 processing.

Phone number formatting. Gusto validates phone number format. Domestic US numbers must be 10-digit strings without country code prefix. Numbers formatted as "+1-555-867-5309" or "(555) 867-5309" may fail validation depending on Gusto version. Normalize to 10-digit format (5558675309 or 555-867-5309) before import.

---

Workday EIB (Enterprise Interface Builder)

Template-locked column counts. Workday EIB templates are configured during HRIS implementation and specify an exact number of required columns. The column count is fixed to the template version. When the payroll export adds columns after the EIB template was configured, the column count in the export no longer matches. The error is explicit:

Row 23: Expected 47 columns, found 44

This error identifies the row and the expected vs. actual counts but does not identify which columns are missing. The count mismatch could mean three columns were added to the export (making it 50 instead of 47, shown as "found 50"), or three columns that the template requires are absent from the export (shown as "found 44").

Positional mapping with name-blindness. Workday EIB maps columns by position. Column name changes in the export do not cause errors — they cause silent data misrouting. If the EIB template expects column 31 to be "Department_Code" but the export has "Cost_Center_Code" at position 31 (with an identical value format), the import will succeed and map cost center codes to the department field without producing a warning.

This positional blindness is why adding a column in the middle of an export is more damaging than adding one at the end. A column added at position 15 in a 47-column export shifts columns 16 through 47 by one position, causing 32 fields to be loaded into the wrong EIB slots.

Date format strictness. EIB requires dates in the format specified during template configuration. ISO 8601 (YYYY-MM-DD) is common but not universal — some templates were configured for MM/DD/YYYY during implementation. Mixed date formats (some rows YYYY-MM-DD, others MM/DD/YYYY) cause row-level rejections on the affected rows. The error does not always identify which column the date format mismatch occurred in.

Two-pass validation with batch error reporting. EIB performs a validation pass before committing any records. If validation finds errors, it returns a batch error report identifying all failing rows before any records are written. A 2,400-row file with 30 validation errors produces a report of all 30 errors — which is useful for bulk correction but means you must fix all issues and re-import the full file before any records are committed.

EIB integration IDs. Workday uses Integration IDs — Workday-internal identifiers — for cross-referencing. When importing data that references other Workday objects (departments, cost centers, job profiles), the referenced values must be EIB-compatible integration IDs, not display names or external system identifiers. A department exported from ADP as "Finance - West" may need to be "DEPT-FW-0042" in Workday's EIB format.

---

QuickBooks Payroll

Silent bank routing number overwrite. QuickBooks Payroll direct deposit imports do not validate that routing number and account number fields are non-empty before writing. If the import file contains blank values in those columns, QuickBooks writes the blank values over the existing direct deposit information in the employee record — without an error message, a warning, or a rejected-row flag. The import completes with a success status. The banking data is gone.

This is the failure that does not surface until payroll processing, when the missing routing number causes direct deposit failures for affected employees.

Missing column error. When the import file is missing columns that QuickBooks requires, the error is:

The file is missing required columns: Employee SSN, Pay Frequency

The column names in the CSV header must match QuickBooks Payroll's expected strings exactly — case-sensitive, with identical spacing. "Employee SSN" and "employee_ssn" are not equivalent. "Employee SSN" and "EmployeeSSN" are not equivalent. Obtain the required column name list from QuickBooks Payroll's import documentation for your version before preparing the file.

Pay frequency enumeration. QuickBooks Payroll accepts a fixed set of values in the Pay Frequency column. Valid values as of 2026: "Weekly", "Biweekly", "Semimonthly", "Monthly", "Daily". Values exported from other systems using different terminology — "Bi-Weekly", "Semi-Monthly", "Every Two Weeks", "2x Monthly" — produce validation failures. Normalize pay frequency values to the QuickBooks enumeration before import.

Contractor vs. employee distinction. QuickBooks Payroll imports are separate for W-2 employees and 1099 contractors. A file that mixes employee and contractor records will produce errors on records that do not match the expected type for the selected import template. Separate contractor records into a distinct file before import.

---

Payroll Import Error Taxonomy

Reference this table when diagnosing a payroll import failure. Errors are organized by verbatim error string where the platform produces a consistent message, or by failure pattern where the platform produces no error.

---

Pre-Import Prep Workflow

Preparing a payroll CSV for platform import is a sequential process. Skipping steps produces the specific failure modes documented in the error taxonomy above. All steps below can be completed without uploading the file to any server.

Step 1: Encoding check and normalization

Before anything else, identify the file encoding. A payroll CSV exported from Windows Excel is frequently Windows-1252 (ANSI) or UTF-8 with BOM — both will cause failures on Gusto imports and unpredictable behavior on platforms that accept non-UTF-8 silently.

Check encoding by loading the file into a browser-based tool that detects encoding before processing. SplitForge Data Cleaner detects file encoding on load and normalizes to UTF-8 without BOM during export — entirely in your browser, no upload.

If encoding conversion is required, normalize to UTF-8 without BOM as the default for all payroll CSV workflows. This is safe for all four platforms covered here.

Step 2: Leading zero protection

Before modifying anything in the file, check financial and identifier columns for leading zero loss. Routing numbers, SSNs with leading zeros in the area number (rare but valid), ZIP codes, and employee ID numbers with leading zeros all lose their leading zeros when Excel opens a CSV and interprets numeric columns as numbers.

A 9-digit routing number 021000021 becomes 21000021 (8 digits) after Excel processes it. An SSN with area number 009 becomes 9-XX-XXXX. Re-pad affected columns to their correct widths before any further processing.

Step 3: Column count and structure validation

Compare your file's column structure against the target platform's import template:

For ADP: Confirm the header row will be removed before upload. Verify earning codes in the earning code column match your company ADP configuration's exact code strings.

For Gusto: Verify required columns are present with exact header label matches. Check that SSN/ITIN values are not placeholders.

For Workday EIB: Count the columns in your export. Compare against the EIB template's expected count. Open the EIB template in Workday and verify that column positions match between your export and the template. If any columns were added, reordered, or renamed in the export since the EIB template was last updated, resolve the mismatch before proceeding.

For QuickBooks Payroll: Verify column header strings match QuickBooks expected labels exactly. Verify pay frequency values match the accepted enumeration.

Step 4: Blank value audit for financial fields

For any import that includes bank routing numbers, account numbers, or direct deposit information: run a blank-value check across every financial column in the file before upload.

QuickBooks Payroll will overwrite existing banking data with blank values without warning. A single blank routing-number cell in a 500-row direct deposit update can cause 1 employee's direct deposit to fail with no visible error at import time.

Flag every row where routing-number, account-number, or similar financial columns are blank. Resolve by populating from a source record or removing the row from the import if the employee is not intended to be part of the update.

Step 5: Date format normalization

Identify the date format required by your target platform's current import template. Normalize all date columns in the file to that format. Common patterns for each platform:

• ADP: MM/DD/YYYY in most standard templates
• Gusto: YYYY-MM-DD
• Workday EIB: Format configured at template creation — check template specification
• QuickBooks Payroll: MM/DD/YYYY

Mixed formats within a single column (some rows YYYY-MM-DD, others MM/DD/YYYY) produce row-level rejections on EIB and QuickBooks Payroll. Normalize the entire column consistently.

Step 6: Sensitive field masking before distribution

If the prepared file will be shared with anyone before import — for review, for IT staging, for approval sign-off — mask sensitive fields before sharing. See the masking workflow below.

---

Masking Sensitive Fields Before Import

Payroll workflows commonly require distributing the import file before it reaches the production system: for manager review of compensation changes, for IT verification of the HRIS migration mapping, for compliance sign-off on the data handling procedure. When an unmasked payroll file is shared for these purposes, every recipient gains access to SSNs, routing numbers, salary data, and earning codes for every employee in the file.

Masking replaces sensitive values with format-preserving substitutes. The structure and format of the data are preserved; the real values are not.

What to mask for staging and review workflows:

Why format-preserving masking matters for payroll imports. Many HRIS import validators check field format — not just presence. A masked SSN that retains the XXX-XX-XXXX hyphen structure passes SSN format validation on platforms that check structure. A masked SSN that replaces the value with "REDACTED" or "XXX" fails format validation. Format-preserving masking lets you prepare a masked version of the import file that can be passed through the same pre-import validation checks as the real file — confirming that the file structure is import-ready before you substitute back the real values for the production run.

Masking workflow with Data Masking:

1. Load the payroll CSV into SplitForge Data Masking — no upload, processed in your browser
2. Select the SSN column and apply format-preserving mask (XXX-XX-XXXX format retained in output)
3. Select routing number column and apply format-preserving mask (9-digit format retained)
4. Select account number column and apply format-preserving mask
5. Optionally remove or suppress salary columns for review-copy exports
6. Export the masked file for distribution

The original file is never modified. The masked export is a separate file. The masking operation runs in a Web Worker thread — no data leaves your device.

Maintaining the production-masked separation. Keep a strict naming convention to distinguish masked files from production files. A common pattern: payroll-q3-import-MASKED-review.csv vs. payroll-q3-import-PRODUCTION.csv. Never submit a masked file to a live HRIS import. Format-preserving masked SSNs will not match existing employee records by SSN, and masked routing numbers will corrupt direct deposit data.

---

HRIS Migration Workflow

HRIS migrations move the employee record of truth from one platform to another — typically triggered by a vendor switch, an acquisition, or a significant expansion of the HR tech stack. The migration involves exporting from the source system, transforming the data to match the target system schema, and importing into the target. The transformation step is where most data quality issues originate and where sensitive data is most at risk of unnecessary exposure.

Phase 1: Source system export

Before exporting, document what you need from the source system versus what the source system will give you. Most HRIS platforms export everything configured in the system — all active fields, all custom fields, all historical values, all system-internal columns. A full export from a mature ADP environment can easily contain 60 or more columns, many of which represent ADP-internal data that has no equivalent in the target system.

Common source export issues that compound during migration:

• Custom field pollution. Source exports include every custom field ever added to the HRIS configuration — including deprecated fields that were populated years ago and never cleaned up. Fields like "Legacy_System_ID", "Migration_Notes_2019", "Contractor_Temp_Flag_Q2" appear in the export and must be evaluated before import.
• Terminated and test records. Source exports typically include all employees — active, terminated, leave of absence, and test accounts created during system setup. Most HRIS imports are designed for active employees only. Terminated records in a new system import can create data integrity issues and billing complications on headcount-based contracts.
• Inconsistent historical data. Long-running HRIS systems accumulate data entered under multiple administrators with different formatting conventions. Address formats, phone number representations, date formats, and department naming conventions may be inconsistent across the employee population. A migration is an opportunity to normalize these — but it requires explicit remediation, not just a CSV transform.

Phase 2: Schema mapping

Build a column-by-column mapping from source schema to target schema before touching any data. The mapping document should record:

• Source column name → Target column name (or "no equivalent — remove")
• Source value format → Target expected format (e.g., "YYYY-MM-DD" → "MM/DD/YYYY")
• Source enumeration values → Target enumeration values (e.g., "Bi-Weekly" → "Biweekly")
• Columns required in target that do not exist in source (must be populated from another source, defaulted, or confirmed to be blank-safe in target)
• Columns in source that must be excluded from target import (custom fields, internal IDs, deprecated flags)

Workday migrations deserve special attention on Integration IDs. Workday uses internal integration identifiers for cross-object references — departments, job profiles, cost centers, locations. These IDs are assigned during Workday tenant configuration and do not exist in the source ADP or Gusto system. The migration mapping must resolve all cross-references to Workday Integration IDs before the import file is ready.

Phase 3: Staged import and validation

Never run a full production migration as a first attempt. HRIS platforms provide test environments or import validation modes specifically for migration use. The staged process:

1. Run a validation-only import of 50-100 representative records (include edge cases: terminated employees to verify they are filtered, employees with STD earning codes, employees with foreign-format phone numbers)
2. Review the validation report for errors and warnings
3. Resolve all errors in the full file
4. Run a full validation-only import of the complete employee population
5. Review the complete validation report — resolve all remaining errors
6. Confirm cutover timing and run production import

Production imports for HRIS migrations should happen during a controlled maintenance window with a rollback plan. If the import produces unexpected results in the new system, you need a documented path back to the source system while the issues are diagnosed.

Sensitive data during the migration process. The migration workflow involves the full unmasked payroll file passing through the hands of multiple teams — the HR team preparing the export, the IT team building the transformation, the vendor consultant validating the import. Each handoff is a potential exposure point. Establish data handling procedures before starting: who receives the file, in what format, how it is transmitted, and when it is destroyed. Consider whether masked files can substitute for unmasked ones at any step in the transformation process where real SSNs or routing numbers are not required for the transformation logic itself.

---

Validation Before Submission

Validation is a distinct step from preparation. Preparation fixes known issues. Validation confirms that fixes worked and identifies issues that were not anticipated during preparation.

For HRIS imports, validation should happen at two levels: a local check of the file before uploading it to the platform, and then the platform's own validation mode (where available) before committing records.

Pre-submission local validation checklist:

• Column count matches target platform import template exactly
• All column headers match expected strings (case-sensitive, exact spacing)
• No blank values in required fields: SSN, Pay Frequency, Employee ID
• No blank values in routing number or account number columns (if direct deposit data is present)
• Earning codes match platform-specific accepted strings exactly
• Date formats are consistent across all rows and match the target platform expected format
• SSNs are in XXX-XX-XXXX format with hyphens; no stripped hyphens, no leading-zero loss
• ABA routing numbers are 9 digits; no leading-zero loss from Excel auto-formatting
• Employee IDs are present and non-blank for all rows
• No duplicate employee IDs (unless the platform supports multiple earning records per employee in a single import)
• Header row is present or absent as required (ADP requires header removal; most platforms require header presence)
• File encoding is UTF-8 without BOM (required for Gusto; safe default for all platforms)
• Pay frequency values match the target platform's accepted enumeration strings
• No placeholder SSN values (000-00-0000, PENDING, TBD, APPLIED)

Migration-specific additional checks:

• Active employees only (unless target is configured to accept terminated records)
• Custom source fields removed
• Cross-object references (department codes, job profile codes) resolved to target system identifiers
• Earning code values mapped from source enumeration to target enumeration
• All date columns normalized to target expected format

Platform validation modes:

Most HRIS platforms provide a dry-run or validation-only mode. Use it:

• Workday EIB: EIB performs a validation pass before committing by default; monitor the background job status for the validation report
• ADP: ADP Workforce Now provides an import preview before final submission
• QuickBooks Payroll: Use the import preview to review what will be written before confirming — particularly important for direct deposit imports given the silent overwrite behavior

---

Compliance Alignment

Not legal or compliance advice. Validate all workflows with qualified legal and compliance counsel.

Payroll data occupies a distinct compliance position from other sensitive datasets: it is required for employment, making complete elimination of processing impractical, but it contains categories of information that trigger multiple overlapping regulatory frameworks.

GDPR

For organizations with EU-resident employees or EU residents on the payroll, GDPR applies to every step of payroll CSV handling:

Article 6 — Lawful basis: Processing employee personal data requires a lawful basis. Employment contracts (Art. 6(1)(b)) and legal obligations (Art. 6(1)(c)) typically provide the basis for core payroll processing. Ad-hoc processing — sharing the payroll file with a third-party tool for cleanup, or distributing it to managers for review — requires its own lawful basis analysis.

Article 9 — Special categories: Earning codes that implicitly reveal health conditions (STD, FMLA, disability codes) or trade union membership (union dues) trigger Art. 9 obligations for the rows containing those codes. The entire file is affected if it contains any Art. 9 data, because the file cannot be split at the row level once it is uploaded to a processing tool.

Article 28 — Processor relationships: Any upload to a third-party tool creates a processor relationship requiring a DPA. Browser-local processing (no upload) avoids creating a processor relationship for the cleaning and masking step, though processors used elsewhere in the payroll workflow (the HRIS platform itself, the payroll provider) still require DPAs.

Article 5(1)(c) — Data minimization: Files distributed for review, approval, or IT staging should contain only the fields necessary for that specific step. A manager reviewing compensation increases does not need the routing numbers column. Remove columns that are not needed for the specific recipient's task before sharing.

HIPAA

HIPAA covers Protected Health Information from covered entities. Healthcare employers processing payroll for clinical staff may have earning codes that intersect with PHI — for example, an STD code tied to a medical leave event that is also documented in the employee health record. Payroll teams at covered entities should confirm with the privacy officer whether payroll earning codes require PHI-level handling for their specific configuration.

For organizations processing payroll data for clinical staff and needing to understand browser-local PHI handling, see HIPAA-Safe CSV Cleaning.

SOC 2

SOC 2 Type II audits examine vendor management and data handling controls. Using a cloud-based tool for payroll CSV manipulation — even for a one-time cleanup — introduces a new vendor into the data supply chain. Browser-local processing tools that do not receive the uploaded data do not qualify as vendors in the SOC 2 vendor management sense, because no data is transferred to them.

State and local regulations

Several US states impose payroll data privacy requirements that go beyond federal obligations:

• California CCPA/CPRA applies to employee data in California; payroll data is in scope
• Illinois BIPA covers biometric time-tracking data if your payroll export includes biometric time records
• New York SHIELD Act covers SSNs and account numbers as defined private information

Confirm state-specific requirements for every jurisdiction where the organization employs workers before finalizing payroll data handling procedures.

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

---

Additional Resources

Regulatory and standards documentation:

• GDPR Article 28 — Processor obligations — Data Processing Agreement requirements and controller liability for processor failures
• GDPR Article 9 — Special categories of personal data — Conditions for processing health data, trade union membership, and other special categories
• IRS Publication 15 — Employer Tax Guide — Federal payroll tax withholding requirements and SSN handling obligations
• Social Security Administration — Employer Handbook — SSN verification, format standards, and reporting requirements
• California CCPA — Employee data guidance — CCPA application to employee records and payroll data
• USDOL FMLA regulations, 29 CFR Part 825 — FMLA leave requirements, record-keeping, and confidentiality obligations for medical information in leave records

Related SplitForge guides:

• HR Payroll CSV GDPR Compliance — GDPR Article 28 and Article 9 obligations specific to HR and payroll data handling
• Privacy-First Data Processing Guide — complete framework for HIPAA, GDPR, and SOC 2 compliant CSV data processing
• HIPAA-Safe CSV Cleaning — browser-local PHI handling workflow applicable to healthcare employer payroll data
• Client-Side CSV Processing Explained — technical architecture of Web Worker processing: how data is handled in browser memory without server transmission
• Data Privacy CSV Checklist — field-by-field classification and handling guidance for SSNs, account numbers, health codes, and other sensitive data types
• Never Upload Client Data to CSV Processing Sites — vendor storage risks, multi-tenant exposure, and data retention policy analysis for cloud-based CSV tools

---

FAQ