Fast Fix (2 Minutes)
If your Gusto payroll import just failed:
- "File encoding not supported. Please upload a UTF-8 encoded file" — your file is not UTF-8 without BOM. Open the file in SplitForge Format Checker or a UTF-8-capable text editor and re-export/save as UTF-8 without BOM. Do not use Excel's "CSV UTF-8" export option — it adds a BOM that Gusto rejects.
- Date fields failing validation — check for 00/00/0000 placeholder dates. Search the file for "00/00" and replace with either a valid date or remove the row. Also check for dates in the wrong format (Gusto expects YYYY-MM-DD in most configurations; MM/DD/YYYY in others — verify your Gusto tenant settings).
- Numeric field parse errors — search the file for "#REF!" (including the hash and exclamation mark). If present, the file passed through Excel and a formula broke. Open the original export source, not the Excel-edited version, and re-export directly to CSV.
- Column not found / missing required field — Gusto requires column header strings to match its expected names exactly. Pull the current expected header list from Gusto's import documentation for your specific import type and compare against your file's actual headers.
Quick Answer
The Gusto payroll import error "File encoding not supported. Please upload a UTF-8 encoded file" means your CSV is encoded as Windows-1252 (ANSI) or UTF-8 with BOM — both of which Gusto rejects. Files exported from Windows Excel default to one of these encodings. The fix is re-encoding the file as UTF-8 without BOM, which requires a tool that explicitly saves without the Byte Order Mark (BOM) that Windows Excel adds by default.
Not legal or compliance advice. Gusto import behavior described here reflects Gusto documentation and community-reported patterns as of May 2026. Confirm current requirements with Gusto's import documentation and your account configuration.
TL;DR: Gusto payroll imports fail for four main reasons: (1) encoding — Gusto requires UTF-8 without BOM, and Windows Excel exports produce UTF-8 with BOM or ANSI/Windows-1252, both of which are rejected with a clear error message; (2) date placeholders — 00/00/0000 and similar sentinel values used by legacy payroll systems to represent "no date set" fail Gusto's date parser with a validation error; (3) #REF! formula residue — when a payroll CSV is opened and edited in Excel and a formula's referenced cell is deleted, the formula renders as "#REF!" in the cell; if that cell is in a numeric column (hours, pay rate, salary), Gusto's numeric parser fails; (4) column header mismatches — Gusto validates column presence by matching header strings; case differences, underscores vs. spaces, or abbreviated vs. full column names all cause "missing required column" errors. SplitForge Format Checker detects encoding, date format issues, formula residues, and header validation without uploading your payroll file.
What Gusto's Error Messages Actually Mean
"File encoding not supported. Please upload a UTF-8 encoded file"
What Gusto means: The file is not encoded as UTF-8 without BOM.
What actually happened: Your file is encoded as Windows-1252 (ANSI) or UTF-8 with a Byte Order Mark (BOM). Both are rejected.
The BOM is a 3-byte sequence (EF BB BF) prepended to the file by some editors and export tools to mark the file as UTF-8. It is invisible in spreadsheet applications — your file "looks fine" when opened in Excel or Google Sheets. Gusto's import parser rejects files with a BOM because it detects the BOM bytes as unexpected content at the start of the file.
Where each encoding comes from:
| Export source | Typical encoding | Gusto accepts? |
|---|---|---|
| Windows Excel → "CSV" | Windows-1252 (ANSI) | No |
| Windows Excel → "CSV UTF-8 (with BOM)" | UTF-8 with BOM | No |
| Google Sheets → Download as CSV | UTF-8 without BOM | Yes |
| macOS Numbers → Export to CSV | UTF-8 without BOM | Yes |
| ADP Workforce Now export | Varies by configuration | Verify before import |
| Legacy HRIS systems | Often Windows-1252 | No — must re-encode |
The hidden character problem. Files with Windows-1252 encoding that contain non-ASCII characters — employee names with accented letters (Müller, García, Nguyen), addresses with special punctuation — will either fail the Gusto encoding check or, on systems that accept non-UTF-8 loosely, produce garbled characters in the employee record.
Fix: Re-encode the file as UTF-8 without BOM. SplitForge Format Checker detects file encoding on load and normalizes to UTF-8 without BOM on export — in your browser, no upload.
Before (fails Gusto — Windows-1252 ANSI encoding):
[File bytes start with Windows-1252 encoding — "Employee Name" column contains García,
encoded as 47 61 72 63 ED 61 in Windows-1252. Gusto rejects the file at upload.]
After (accepted by Gusto — UTF-8 without BOM):
[File bytes start without BOM — "Employee Name" column contains García,
encoded as 47 61 72 63 C3 AD 61 in UTF-8. Gusto parses correctly.]
Date Validation Failure — 00/00/0000 Placeholder
What Gusto means: A date field contains a value that is not a valid date.
What actually happened: The export from a legacy payroll system populated date fields with a sentinel value — 00/00/0000, 01/01/1900, or 12/31/9999 — to indicate that the field has no value set. These are not valid dates. Gusto's date parser rejects them.
Why this happens. Legacy payroll systems, including older versions of ADP, Kronos, and other HRIS platforms, use placeholder date values instead of null or empty cells to represent "not set." When these systems export to CSV, the placeholder values come along. 00/00/0000 is particularly common in systems that require a date to be present in the field definition even when no actual date exists for that record.
Other date failure patterns:
| Value in file | Reason for failure | Fix |
|---|---|---|
00/00/0000 | Not a valid calendar date | Replace with empty cell or correct date |
01/01/1900 | Excel's default "zero date" — often appears when a blank date is formatted as date in Excel | Replace with empty cell |
12/31/9999 | "Far future" sentinel used by some systems | Replace with empty cell or correct date |
2026/05/23 | Format mismatch — Gusto expects YYYY-MM-DD or MM/DD/YYYY per configuration | Normalize to expected format |
May 23, 2026 | Freeform date text — not parsed | Normalize to expected format |
Fix: Before import, search the file for all sentinel date values and replace them with either an empty cell (if the field is optional) or the correct date value (if it can be determined). Normalize all remaining date values to the format specified in your Gusto account configuration.
#REF! Breaking Numeric Parse
What Gusto means: A field expected to contain a numeric value (hours, pay rate, salary) contains non-numeric text.
What actually happened: The payroll CSV was opened in Excel after export, a cell reference was broken (a referenced column or row was deleted), and Excel rendered the broken formula as "#REF!" in the cell. When the file was re-saved as CSV, the "#REF!" text was written as the literal cell value. Gusto's numeric parser encounters "#REF!" in a field expecting a number and fails.
How formula residue gets into payroll CSVs:
- Payroll export is saved as CSV — no formulas present in a correctly exported CSV
- Analyst opens the CSV in Excel to "make a quick edit" — Excel opens the file as a worksheet
- Analyst deletes a column, reorders columns, or performs an edit that breaks a formula that was added during previous editing sessions
- Excel renders the broken formula reference as "#REF!" in the affected cells
- Analyst saves the file — Excel saves "#REF!" as the literal cell value in the CSV
- Gusto import encounters "#REF!" in the hours or pay-rate column and fails to parse it as a number
This failure is easy to miss. The "#REF!" string looks like it could be an import error message from a different system, or it may be present in only a few rows while the rest parse correctly. Gusto may report a generic "invalid value" error on those rows without specifying that the value was "#REF!".
Fix:
- Open the file in a text editor or CSV validator (not Excel) and search for the string "#REF!"
- If found, identify which rows are affected and which column contains the formula residue
- Do not fix by editing in Excel — this risks introducing additional formula residue
- Re-export from the original payroll source if possible, without the Excel round-trip
- If re-export is not possible, use a text editor to replace "#REF!" with the correct numeric value for each affected row
Before (Gusto parse failure):
EMP-10382,Johnson,Michael,80,#REF!,Bi-Weekly
After (correct):
EMP-10382,Johnson,Michael,80,32.50,Bi-Weekly
Column Header Mismatch — Required Column Not Found
What Gusto means: A column that Gusto requires for this import type is not present in the file.
What actually happened: The column exists in the file but Gusto cannot find it because the header string does not match what Gusto expects — different capitalization, underscores vs. spaces, abbreviated vs. full name, or a completely different label from a different system's export template.
Gusto locates required columns by matching the header row string against its expected column name list. "Employee_SSN" and "Employee SSN" are not equivalent. "SSN" and "Social Security Number" are not equivalent. "First Name" and "FirstName" are not equivalent.
Common Gusto required columns and typical naming mismatches:
| Gusto expects | File may contain | Match? |
|---|---|---|
First Name | first_name | No |
First Name | FirstName | No |
Last Name | last_name | No |
SSN | Social Security Number | No |
SSN | Employee SSN | No |
Pay Rate | pay_rate | No |
Pay Rate | Hourly Rate | No |
Pay Type | pay_type | No |
Fix: Pull the required column header list from Gusto's import documentation for your specific import type (new hire import, payroll update import, direct deposit update import — each has different required columns and header strings). Rename your file's column headers to match exactly.
Do not rename in Excel if avoidable — Excel may reformat column values when opening and re-saving the CSV. Use a text editor or a browser-based CSV tool to rename headers without touching cell values.
Gusto Import Error Cause/Fix Table
| Error or Failure | Root Cause | Fix |
|---|---|---|
File encoding not supported. Please upload a UTF-8 encoded file | File is UTF-8 with BOM or Windows-1252 (ANSI) | Re-encode as UTF-8 without BOM — not Excel's "CSV UTF-8" option |
| Date validation failure | Placeholder date (00/00/0000, 01/01/1900) or wrong format | Replace placeholders with empty cells; normalize date format |
| Numeric parse failure on hours/pay-rate column | "#REF!" formula residue from Excel round-trip | Search and replace "#REF!" values; re-export from source if possible |
| Missing required column | Header string does not match Gusto's expected label exactly | Match column headers character-for-character to Gusto's required names |
| Row parsed as single field | File is tab-delimited; Gusto expects comma-delimited | Confirm delimiter is comma; re-export with comma delimiter |
| SSN validation failure | Placeholder SSN (000-00-0000, PENDING) or hyphens stripped | Use valid SSN format XXX-XX-XXXX with hyphens; remove placeholders |
| Garbled employee names | Non-ASCII characters in Windows-1252 encoded file | Re-encode as UTF-8 without BOM to preserve accented characters |
| Pay frequency not accepted | Value ("Bi-Weekly", "Semi-Monthly") not matching Gusto's enumeration | Use accepted values: Weekly, Biweekly, Semimonthly, Monthly, Daily |
| Duplicate employee record | Employee SSN or ID already exists in Gusto | Check for existing records; use update import instead of new hire import |
Pre-Import Validation Checklist for Gusto
- File is encoded as UTF-8 without BOM (not Windows-1252 ANSI, not UTF-8 with BOM)
- All date fields contain valid calendar dates — no 00/00/0000, 01/01/1900, or 12/31/9999 placeholders
- All numeric fields (hours, pay rate, salary) contain numeric values — no #REF!, #VALUE!, #N/A strings
- Column headers match Gusto's expected strings exactly — case-sensitive, exact spacing
- File uses comma as delimiter (not tab, semicolon, or pipe)
- SSN/ITIN column contains valid formatted values (XXX-XX-XXXX with hyphens) — no placeholders
- Pay frequency values match Gusto's accepted enumeration (Biweekly, not Bi-Weekly)
- No blank header cells — every column has a label (blank headers cause column count errors)
- Required columns for this import type are all present
SplitForge Format Checker detects encoding, formula residue, date format inconsistencies, and header validation in your browser without uploading the payroll file.
The ANSI Legacy Export Problem
Legacy payroll systems — older ADP versions, Kronos, some older HRIS platforms — were designed before UTF-8 became the universal standard. Their default CSV export uses Windows-1252 (ANSI) encoding because that was the Windows standard at the time they were built. Updating the export encoding requires a configuration change that many organizations have never made, because the files "worked fine" when imported into other systems that accepted ANSI.
Gusto is stricter. It requires UTF-8 specifically.
This means every organization migrating from a legacy payroll system to Gusto faces the encoding issue on their first import — and often on every subsequent import until the source system's export encoding is reconfigured.
The pragmatic fix while the source system encoding is being updated: use a browser-based format normalizer to re-encode each export file to UTF-8 without BOM before import. This adds one step to the import workflow but is faster and safer than attempting to reconfigure a legacy HRIS export.
For the full encoding fix workflow including how to detect encoding before you upload and why Windows-1252 produces garbled characters on non-ASCII employee names, see ADP CSV Import Errors: Fix Bad Employee Number & Codes — the encoding detection approach is the same across both platforms.
For the full HR and payroll CSV data prep workflow covering all platforms, see the HR & Payroll CSV Data Prep Guide.
For the compliance framework around handling payroll CSVs without creating GDPR processor relationships, see HR Payroll CSV GDPR Compliance and Privacy-First Data Processing Guide.