10 Things to Check Before Importing a CSV Into Salesforce

Importing a CSV into Salesforce can look deceptively simple.

Choose a file. Map the fields. Start the import.

But a successful import only tells you that Salesforce accepted the data.

It does not tell you that the data was correct.

Duplicates can still be duplicates. Wrong identifiers can still point to the wrong records. Suspicious values can still make it through. Missing information can still create incomplete contacts, leads, or accounts.

That is why some of the most important work happens before the import begins.

Here are 10 things worth checking first.

1. Know exactly what Salesforce objects you are importing

Before cleaning anything, establish where the data is supposed to go.

Are you importing:

• Leads?
• Contacts?
• Accounts?
• Opportunities?
• A custom object?
• Several related objects?

This matters because different Salesforce objects have different fields, relationships, required values, and business meaning.

A column that makes sense for a Contact may not belong on an Account.

A customer identifier may need to map differently depending on whether the file is creating new records or updating existing ones.

Do not begin with:

“Here is our CSV.”

Begin with:

“What does each row represent, and where should it live in Salesforce?”

That decision affects every check that follows.

2. Check required fields before mapping

A file can contain hundreds of columns and still be missing the few fields that actually matter.

Review which values are required by:

• Salesforce,
• your organization's Salesforce configuration,
• validation rules,
• and your internal business process.

Common examples might include:

• name
• company
• email
• owner
• status
• account identifier
• lifecycle or pipeline information

Do not look only for completely blank rows.

Look for records where an important field is missing while the rest of the row appears complete.

Those partial records are easy to overlook.

3. Investigate duplicate records

Duplicate checking should happen before the records become CRM records.

But do not define a duplicate as only an identical row.

The same person or company may appear twice with slightly different information.

Examples:

• same email, different name
• same phone number, different contact
• same account ID, different company name
• similar company names with different formatting
• duplicate customers with one newer and one older record

Automatically deleting one of them may be wrong.

The real question is:

Do these records represent the same business entity?

That requires investigation.

Salesforce can help manage duplicates, but preventing unnecessary duplicates from entering the system in the first place is cleaner than creating them and resolving them afterward.

4. Validate identifiers carefully

Identifiers are particularly dangerous because they often look correct even when they are not.

Review fields such as:

• Salesforce record IDs
• external IDs
• customer IDs
• account numbers
• contact identifiers
• legacy-system keys

Look for:

• missing IDs
• repeated IDs that should be unique
• one ID attached to multiple entities
• malformed IDs
• leading zeros lost during spreadsheet editing
• identifiers accidentally converted into numbers or scientific notation

If you are updating or upserting existing Salesforce records, a broken identifier can affect the wrong record.

Treat identifiers as keys, not ordinary spreadsheet values.

5. Standardize dates

Date problems can be surprisingly difficult to notice.

Consider:

08/11/2026

Does that mean August 11 or November 8?

Now imagine the same file also contains:

2026-08-11

and:

11-Aug-2026

Even if every value is individually understandable, inconsistent formats increase ambiguity and mapping risk.

Check:

• date format
• timestamps
• time zones where relevant
• impossible dates
• dates outside the expected business period
• blanks in fields that logically require a date

Do not standardize blindly.

A strange date may be a formatting problem, or it may reveal a deeper problem with the record.

6. Check field types and value limits

A CSV does not inherently know what a Salesforce field expects.

The file may contain text where Salesforce expects a number.

A value may be longer than the destination field allows.

A picklist may contain a value that does not belong to the accepted set.

A numeric column may contain:

• currency symbols
• commas
• spaces
• text
• unexpected negatives
• malformed decimals

A Boolean field may contain several competing representations:

• Yes
• Y
• TRUE
• 1

Preparing the file means checking whether the actual values match the meaning and constraints of the destination fields.

7. Normalize categorical values

CRM data often becomes messy because one concept is represented several different ways.

For example:

• Active
• active
• ACTIVE
• Current
• Actve

Or:

• Closed Won
• Closed-Won
• Won
• Complete

Humans may understand these as equivalent.

Reporting systems often do not.

Review fields such as:

• lead status
• lifecycle stage
• source
• account type
• country
• owner
• pipeline
• industry
• customer category

Decide what the accepted value set should be before importing the records.

Otherwise the import may succeed while reporting becomes fragmented.

8. Inspect the CSV structure itself

Sometimes the problem is not the data inside a field.

It is the structure of the file.

Check for:

• duplicate column headers
• blank headers
• unexpected empty columns
• shifted values
• accidental extra header rows
• completely empty rows
• inconsistent delimiters
• broken quoting
• unexpected encoding problems
• columns that no longer match the intended Salesforce mapping

A file can look fine when opened in a spreadsheet application while still containing structural problems that become visible during import.

Before mapping fields, verify that the CSV itself is stable.

9. Look for suspicious records that Salesforce may still accept

This is one of the most important checks.

Some bad data is technically valid.

Imagine a file where most deal values are between $1,000 and $50,000.

One row contains:

$9,999,999

Salesforce may have no reason to reject it.

That does not mean the value is correct.

The same applies to:

• unusual quantities
• impossible ages
• extreme transaction values
• strange dates
• unusually long phone numbers
• unexpected countries
• rare status combinations
• unusually incomplete records

This is the distinction between import validation and data investigation.

A system can accept a value that a human should still review.

Import validity is not the same thing as data validity.

10. Check relationships between fields

Some of the most important problems are invisible when each column is inspected independently.

Examples:

• Country = United States, but phone code = +44
• Status = Closed, but Close Date is empty
• Account ID refers to one company while Account Name contains another
• Lead status indicates conversion while required conversion information is missing
• Customer type conflicts with another classification field

Each individual value may look valid.

The combination is what makes the record suspicious.

This is why serious pre-import review eventually becomes more than formatting.

You are investigating relationships within the data.

Run a small test before the full import

Even after preparing the file, avoid treating the first import as an all-or-nothing operation.

A smaller controlled import can help confirm:

• field mappings
• formats
• ownership
• object selection
• expected values
• relationships
• downstream behavior

Inspect the result before moving the entire dataset.

A clean test import can expose assumptions that were difficult to see inside the CSV alone.

Salesforce can accept a record that your business should reject

This is the broader lesson.

Salesforce needs to determine whether a record can enter the system.

Your team needs to determine whether the record should be trusted.

Those are different questions.

A technically valid record can still contain:

• a duplicate customer
• an incorrect amount
• a suspicious identifier
• conflicting information
• missing context
• an operational mistake

That is why data preparation should not stop at formatting.

Where Auditere fits

Auditere is not a CRM and does not replace Salesforce.

It is an investigation layer for structured business data.

Before or around CRM import workflows, Auditere can help teams surface and review problems such as:

• missing information
• duplicate records
• suspicious values
• conflicting data
• structural inconsistencies
• records that require human judgment

Instead of building an investigation process manually from formulas, filters, helper columns, and scattered notes, the goal is to give teams a dedicated place to work through data-quality issues.

The workflow becomes:

Detect → Review → Resolve → Verify

Then the reviewed data can continue into Salesforce or whatever business system comes next.

Final thought

A green “import completed” message is not a data-quality certificate.

It only tells you that the import completed.

Before moving a business-critical CSV into Salesforce, investigate the data itself.

The problems that are easiest to fix are usually the ones that have not spread into the rest of your systems yet.

If your team spends too much time manually checking CSVs before Salesforce import, explore Auditere.

Auditere helps investigate structured data before it becomes a bigger business problem.

Related reads: How to clean a CSV before CRM import · Finding bad data in Excel · Audit before you import

Auditere is live for beta. Start your free trial or view pricing.