Guide

Import Excel to Salesforce without converting to CSV

Every import guide opens with 'first save your spreadsheet as CSV'. That single step is where most import data gets quietly corrupted. Here is what it breaks, and how to avoid it.

Last updated 14 July 2026 6 min read

The short answer: if you must produce a CSV, do these four things before you save. Format your ID, ZIP and phone columns as Text (not General) so Excel stops treating them as numbers. Rewrite every date as yyyy-MM-dd. Use File → Save As → CSV UTF-8 (Comma delimited), not plain CSV (Comma delimited). Then open the saved file in a text editor and look at it — that is the file Salesforce will read, and it is the only way to see what Excel actually wrote.

Why the conversion step exists at all

Because Salesforce's own tools do not read Excel. Data Loader "reads, extracts, and loads data from comma-separated values (CSV) files or from a database connection", and Salesforce's help documentation states plainly that Microsoft Excel files (XLS or XLSX) are not directly supported by its import tools. The Data Import Wizard takes a CSV too. So the guides are not wrong — with those tools, you have no choice.

The problem is that Excel's CSV export is not a neutral dump of your data. It writes what the cells display, in your machine's locale, in your machine's default encoding. Four of those defaults are actively hostile to a Salesforce load.

What the conversion breaks

What you see	Why it happens	How to avoid it
A long numeric key exports as `1.23457E+17`	Excel stores numbers as IEEE-754 doubles and keeps only 15 significant digits; anything longer is displayed in scientific notation, and the CSV gets the displayed text.	Format the column as Text before the values are entered or pasted.
An 18-digit external key comes back ending in `000`	Same 15-digit ceiling. Digits past the fifteenth are replaced with zeros — silently, with no warning and no error.	Text-formatted column, or re-export the key from the source system as a string. (Salesforce's own record Ids are alphanumeric, so they usually survive this; numeric ERP keys, order numbers and SKUs do not.)
`02134` becomes `2134`	Excel reads it as a number, and numbers have no leading zeros. Salesforce's own docs note that "both Excel and Google Spreadsheet will remove leading zeros after saving the file" unless the column is formatted first.	Text-formatted column. Affects ZIP codes, phone numbers, account numbers, cost centres.
`03/04/2026` loads as the wrong month	Excel writes the date in the display format, which follows the machine locale — day-first in the UK, month-first in the US. The file is ambiguous, and something downstream has to guess.	Write dates as `yyyy-MM-dd`. That is the format the Bulk API expects for a `date` field, and it cannot be misread.
`Ambrosetti` arrives as `AmbrosettiÂ`, `Müller` as `MÃ¼ller`	Salesforce's docs are explicit: "When using Microsoft Excel to save a CSV file, its encoding is automatically set using machine-specific ANSI encoding and not UTF-8." The Bulk API requires UTF-8.	Save as CSV UTF-8, or re-encode the saved file in a text editor.
Semicolons instead of commas between fields	Excel's CSV delimiter follows the Windows list separator, which is a semicolon in most European locales. The file is a CSV in name only.	Change the list separator in regional settings, or find-and-replace the delimiter after saving.
A description field shunts every later column one to the right	The value contains a comma or a line break. Correct CSV requires it to be wrapped in double quotes, and an embedded double quote must itself be doubled. Not every writer and reader agrees.	Strip line breaks from free-text columns, and check the saved file, not the spreadsheet.
Hundreds of empty records get created	Rows that only ever held formatting are still inside the sheet's used range. They export as empty lines, and an insert obligingly creates a record for each one.	Select and delete the rows below your data — delete the rows, not just their contents.
Only one sheet made it into the file	Every CSV save option in Excel "saves only the active sheet". Your lookup tab is not in the export.	Export each sheet separately, or use a tool that reads the workbook.

Surviving the CSV route

If Data Loader or the Data Import Wizard is what you have, this is the order that works. Do it once, properly, and keep the cleaned file as your template.

Fix the column types first. Select the ID, ZIP, phone and reference columns and set them to Text. Re-paste the values afterwards. Reformatting a column that already shows 1.23457E+17 does not bring the lost digits back — the truncation happened when the value went in.
Rewrite dates as yyyy-MM-dd. The Bulk API documents yyyy-MM-dd for a date field and yyyy-MM-ddTHH:mm:ss.SSSZ (or with a +/-HH:mm offset) for a dateTime. If your dates are landing a day early or late, that is usually a timezone problem rather than a format one — see dates shifting by one day.
Delete the empty rows and columns below and to the right of your data.
Save as CSV UTF-8 (Comma delimited), not plain CSV. This is the only save option that reliably preserves accents and non-Latin characters.
Watch out for the byte order mark. CSV UTF-8 writes a BOM, and Salesforce documents that Data Loader (v28 and later) rejects BOM-prefixed files with Invalid CSV file format. Please select a different file. Error getting header row from the CSV file. If you hit that, re-save the file as UTF-8 without a BOM in a text editor such as Notepad++.
Open the .csv in a text editor before you load it. Not in Excel — Excel will re-parse it and hide the very damage you are looking for. Check one long ID, one ZIP code, one date, one accented name.

That checklist works with no tooling beyond Excel and Notepad. It is also six manual steps that have to be repeated correctly on every file, by every person, forever, and step one is unrecoverable if you get it wrong.

The better route: never convert at all

Most of that table has one root cause — an intermediate text format that throws away the types your spreadsheet already knew. An .xlsx file stores a date as a date and a number as a number. Nothing forces you to flatten that into ambiguous text before Salesforce sees it, except the tools.

The 15-digit truncation is the exception, and it is worth being clear about: that damage happens inside Excel, the moment a long number lands in a General column. It is already in the .xlsx. No reader — ours or anyone's — can put the digits back. That one you fix at the source, with a Text-formatted column. Everything else in the table disappears when the conversion does.

INQUA reads .xlsx, .xlsm, .csv and .txt natively, so the conversion never happens. Cells are read as the values the workbook actually stores — a date cell arrives as a date rather than as whatever your locale would have printed, a text-formatted key keeps every character, and a formula cell arrives as its cached result. For CSVs it detects the encoding (UTF-8, UTF-16 with either byte order, and Windows-1252 for the BOM-less ANSI files Excel's plain CSV save produces) instead of assuming one. All-blank rows are dropped so they cannot become phantom records. Legacy .xls is the one exception: re-save it as .xlsx once, and you are done.

From there you map columns, apply per-column transformations if the source values need translating, and preview every row with its Salesforce type applied — so a value that will not convert is flagged as a type-conversion error in the preview grid, not in a Salesforce failure log an hour later. The output is either a typed .xlsx workbook written onto your own load template — which needs no Salesforce connection at all — or a Bulk API 2.0 insert or External-Id upsert, confirmed twice. It never deletes and never updates by record Id.

What this does not fix

Being honest about the boundary: reading the file correctly removes a whole class of self-inflicted errors, and none of the others. No client-side tool can know that your org has a validation rule requiring a close date in the future, a required field enforced by page layout, a duplicate rule, or a trigger that rejects the record. Those are decided by your org's automation at write time, and the only way to find them is to write. Nor can any reader recover a number Excel already truncated before you uploaded the file. What you can do is make sure the rows that reach the org are not carrying shifted dates, stripped zeros, or mojibake in the company name — damage the file format added, rather than damage your data ever had.

If you are choosing between tools rather than fixing one file, the Data Import Wizard's limits are the usual reason people end up here, and the import error reference covers what Salesforce tells you when a row is rejected.

Frequently asked

Can Salesforce import an Excel file directly?

Not with its own tools. Data Loader reads CSV files or a database connection, the Data Import Wizard takes a CSV, and Salesforce's help documentation states that Excel files (XLS or XLSX) are not directly supported by its import tools. Third-party tools can read XLSX natively; if you are using Salesforce's built-in tools you have to export a CSV first.

Why does Excel turn my ID into 1.23457E+17?

Excel treats the value as a number, and it stores only 15 significant digits. Anything longer is displayed in scientific notation, and the CSV export writes what the cell displays. Formatting the column as Text afterwards does not restore the lost digits — the truncation happened when the value was entered. Format the column as Text first, then paste.

Which Save As option should I use for a Salesforce CSV?

CSV UTF-8 (Comma delimited), not plain CSV (Comma delimited). Salesforce's documentation notes that Excel saves plain CSV using machine-specific ANSI encoding rather than UTF-8, which is what mangles accented characters. Be aware that the UTF-8 option writes a byte order mark, which Data Loader v28 and later reject with an 'Invalid CSV file format' error — strip the BOM in a text editor if you hit that.

How should dates be formatted in the file?

Use yyyy-MM-dd for a date field. The Bulk API documents that format explicitly, and unlike 03/04/2026 it cannot be read as the wrong month. For dateTime fields the documented format is yyyy-MM-ddTHH:mm:ss.SSS with either a Z or a +/-HH:mm offset. Leaving Excel to write the date in your machine's locale format is how ambiguity gets into the file.

Why did my import create hundreds of empty records?

Rows that once held formatting stay inside the sheet's used range even after you clear their contents. They export as empty lines in the CSV, and an insert creates a record for each one. Select those rows and delete the rows themselves, not just their values, before exporting.

My CSV is separated by semicolons. Why?

Excel's CSV delimiter follows the Windows list separator, which is a semicolon in most European locales. The file is a valid CSV in name only as far as a comma-expecting reader is concerned. Change the list separator in regional settings, or replace the delimiter after saving.

Does skipping the CSV step prevent all import errors?

No. It removes the errors the conversion itself creates — truncated IDs, stripped leading zeros, locale-shifted dates, broken encodings, phantom blank rows. It cannot prevent failures decided by your org at write time: required fields, validation rules, duplicate rules, and triggers or Flows. Those are only discoverable by attempting the write.