Salesforce import error

Error converting value to correct data type

Something in your file is text where Salesforce wants a date, a number, or a boolean. Here is how to find the column, and the exact format each field type will accept.

Last updated 14 July 2026 6 min read

Error converting value to correct data type: Failed to parse date: 1999-01-01T23:01:01+01:00

The short answer: the loader could not turn one of your cells into the type the field holds. It is nearly always a date in a format Salesforce does not recognize, a number carrying a currency symbol or a thousands separator, an Excel serial number where a date should be, or a blank-looking cell that actually contains a space. Reformat the offending column — dates as yyyy-MM-dd, numbers as bare digits with a period as the decimal point — and reload. No tool required.

Where the error comes from

The message is thrown before Salesforce looks at your data as a record. No validation rules, no required fields, no triggers. A converter took the string in your cell, tried to make a date, a number, or a boolean out of it, and gave up. In Data Loader's case that converter is its own internal parser, which is stricter about formatting than the API it feeds — which is why a value the REST API would happily accept can still fail here. The fix is always in the file.

The rest of the message names the culprit. Error converting value to correct data type: Failed to parse date: … is a date problem; the same error ending in Boolean is a checkbox problem. A number that will not parse is worth knowing about too, though Data Loader reports it as a separate error — <field>: invalid number: <value>. It is the same class of problem with the same class of fix, so both are covered below.

Dates: the format Salesforce actually accepts

The API stores a Date field as yyyy-MM-dd and a Date/Time field as ISO 8601 — yyyy-MM-ddTHH:mm:ss.SSSZ or yyyy-MM-ddTHH:mm:ss.SSS+/-HH:mm. Time zone offsets are not supported on plain Date values.

Data Loader is more forgiving, but only along a fixed list: yyyy-MM-dd, yyyyMMdd, MM/dd/yyyy, yyyy-MM-dd HH:mm:ss, MM/dd/yyyy HH:mm:ss and yyyy-MM-dd'T'HH:mm:ss.SSS'Z', among others. Outside that list is a parse failure.

Two traps sit inside this. Data Loader's parser rejects the colon in a time zone offset even though the SOAP and Bulk APIs accept it: 1999-01-01T23:01:01+01:00 fails, while 1999-01-01T23:01:01+0100 and 1999-01-01T23:01:01GMT+01:00 pass. And dd/MM/yyyy is only understood when you tick Use European date format in Data Loader's settings — the option exists to support dd/MM/yyyy and dd/MM/yyyy HH:mm:ss. With it off, 03/12/2026 is read as March 12th.

The Data Import Wizard differs again: it reads dates in the format of the locale of the user running the import. The same file, imported by a colleague elsewhere, can be read differently.

Date format table

What your file contains	Why it fails	What to write instead
`3 Mar 2026`, `03-Mar-26`, `Mar 3, 2026`	Not on the accepted format list. Month names are never parsed.	`2026-03-03`
`03/12/2026` meaning 3 December	Read as 12 March unless European date format is on. No error — a wrong date.	`2026-12-03`
`46084`	An Excel date serial number — this one is 3 March 2026. It is a number, not a date.	Format the cell as a date in Excel, then export as `yyyy-MM-dd`
`2026-03-03T09:00:00+01:00`	Data Loader cannot parse the colon in the offset.	`2026-03-03T09:00:00+0100` or `2026-03-03T09:00:00GMT+01:00`
`2026-03-03 09:00`	Seconds are missing from a supported pattern.	`2026-03-03 09:00:00`
`09:00` or `9:00 AM` in a Time field	Data Loader wants milliseconds and the trailing `Z`. It answers with a different error: `value not of required type`.	`09:00:00.000Z`
`2026-03-03` in a Date/Time field	Loads, but at midnight — and then shifts by your time zone.	Supply the time, or read why the date lands a day early.

A parse failure at least stops the record. The worse outcome is the silent one: an ambiguous 03/12/2026 that loads cleanly on the wrong day. If your dates parsed but look wrong, see Salesforce import date off by one day.

Numbers: strip everything that is not a digit

A Number, Currency, or Percent field wants a bare number, not a formatted one.

Currency symbols. $1200 is a string. The field holds the amount; the currency is set by the record's currency code, not by a symbol in the cell. Remove $, £, € and any trailing USD.
Thousands separators. 1,200,000 is rejected — Salesforce's own guidance on the invalid number error is to remove the commas and untick Use 1000 Separator in Excel's Format Cells dialog. Write 1200000.
Percent signs and accounting notation. A Percent field takes 15, not 15%. (500) is not a negative number; -500 is.
Text in a number column. N/A, TBD, - and unknown all fail. Leave the cell genuinely empty instead.

The decimal comma, which is worse than it looks

In much of Europe 1,5 means one and a half. Salesforce expects a period: 1.5. This mismatch has two failure modes, and the loud one is the lucky one. If the comma reaches the API, the value is rejected as an invalid number. But in a comma-delimited CSV, an unquoted 1,5 is not one field — it is two. Every column to its right shifts by one, which is how you get Row is larger than header, or an amount sitting quietly in the wrong field. Fix the decimal separator at the source, or keep the file as .xlsx and use a tool that reads the workbook directly instead of a re-delimited CSV.

Checkboxes and booleans

Data Loader accepts a generous set of boolean values, case-insensitively: yes, y, true, on, 1 for true, and no, n, false, off, 0 for false. It accepts nothing else — Yes please fails, and a checkbox column holding Active or Closed is not a checkbox column at all.

The nastiest version: a cell containing a single space. It looks empty, an empty cell loads fine, and a space throws the conversion error. If a boolean column fails on rows that look blank, trim the column before you do anything else.

Excel, quietly rewriting your file

Many of these errors are made by the spreadsheet, not the source system. Excel infers a type from what a cell looks like, then re-renders it on save:

A date in a General cell is a serial number underneath, and a CSV export can emit 45718 instead of the date you saw.
An ID or postcode with leading zeros loses them.
A long number is exported in scientific notation as 1.2E+15.
A minus sign that arrived by copy-paste from Word, a PDF, or a web page can be an en dash (–500) rather than a hyphen, and stops being a number.

Set each column's format explicitly — Text for IDs, a custom yyyy-mm-dd for dates — before saving, then reopen the exported CSV in a plain text editor. What Excel displays is not what Excel saves.

A repeatable fix, per column

Read the failing value in the results file, not just the message.
Check the target field's type in Setup, Object Manager, Fields and Relationships. A Currency field and a Text field take completely different input.
Normalize the whole column in one pass. Do not fix only the rows in the error log — a second bad format is usually sitting behind the first.
Trim every column. Whitespace is the most common invisible cause.
Reload, and expect a new class of error to surface. Type errors mask missing required fields and restricted picklist rejections behind them.

Catching conversion errors before the load

Every fix above works with Excel and a text editor. The cost is the loop: load, read the failures, fix, reload, discover the next format the file got wrong. The way out is to type-check the file against the target fields before writing anything.

That is what INQUA does. It reads your .xlsx or .csv directly, types every cell against the target field, and previews per-cell errors — a date it cannot parse or a number it cannot read is flagged in the row where it lives, before a single record is written. A Parse date (exact format) transformation converts a known source format such as dd/MM/yyyy into a real date; Find & replace strips separators; common currency symbols in Number fields are accepted rather than rejected. A review scan checks every selected row for conversion issues before writing, and the Salesforce upload is refused outright while any cell error remains.

Be clear about the limits: type checking is not org simulation. It cannot tell you in advance that a validation rule, a required field, a duplicate rule, or a Flow will reject a row — those live in your org and only fire on write. What it removes is this class of error, where the data never reached the record.

It also works with no Salesforce connection: point it at your own load template and it writes a typed .xlsx workbook back onto that template. If a CSV round-trip mangled your dates in the first place, see importing Excel to Salesforce without CSV — or the full list of Salesforce import errors when the next message is a different one.

Frequently asked

What does 'error converting value to correct data type' mean?

A cell in your file could not be converted into the type the target field holds. The loader tried to build a date, a number, or a boolean from your text and failed. It happens before Salesforce evaluates the record, so validation rules, required fields, and triggers are not involved — the fix is always in the file's formatting.

What date format does Salesforce accept on import?

The API stores dates as yyyy-MM-dd and date/times as ISO 8601, for example 2026-03-03T09:00:00.000Z. Data Loader also accepts yyyyMMdd, MM/dd/yyyy, yyyy-MM-dd HH:mm:ss and MM/dd/yyyy HH:mm:ss, among a fixed list. Anything else, including month names like 3 Mar 2026, is a parse failure. yyyy-MM-dd is the safest choice everywhere.

Why does my dd/MM/yyyy date fail or load on the wrong day?

Data Loader reads MM/dd/yyyy by default. Its Settings screen has a 'Use European date format' option, which exists to support dd/MM/yyyy and dd/MM/yyyy HH:mm:ss. With it off, 03/12/2026 is read as March 12th and loads without any error. The Data Import Wizard instead uses the locale of the user running the import.

Why is 1999-01-01T23:01:01+01:00 rejected when it is valid ISO 8601?

Data Loader has its own internal date parser, and it cannot handle the colon inside a time zone offset — even though the SOAP and Bulk APIs accept that form. Salesforce's guidance is to write the offset without the colon, as 1999-01-01T23:01:01+0100, or to use the GMT prefix form 1999-01-01T23:01:01GMT+01:00. Both parse correctly.

Can I import a currency value like $1,200,000?

No. A Currency or Number field takes a bare number: 1200000. Salesforce's guidance on the related 'invalid number' error is to remove thousands separators from the file and untick 'Use 1000 Separator' in Excel's Format Cells dialog. The currency itself comes from the record's currency code, not from a symbol in the cell.

What values can I put in a checkbox column?

Data Loader accepts yes, y, true, on and 1 for true, and no, n, false, off and 0 for false, case-insensitively. Anything else fails. A cell containing only a space is a known cause of this error — it looks blank but throws a conversion failure where a genuinely empty cell would have loaded.

Why do the numbers in my file turn into 46084 or 1.2E+15?

Excel is rewriting them. Dates are stored internally as serial numbers counted from 1899-12-30, so 3 March 2026 in a General-formatted cell can export as 46084. Long numeric IDs are exported in scientific notation. Set the column's number format explicitly — Text for IDs, a custom yyyy-mm-dd for dates — before saving, and check the exported file in a text editor.