Before you import a spreadsheet, preview what will change

By Noe Guerrero III

Before a spreadsheet import changes records in your business app, ask to see what it will add, update, leave unchanged, or reject. A useful preview explains those decisions before you approve them. An upload progress bar only tells you part of the story.

This matters when you're moving a parts list, customer directory, or job history into custom software. “Import CSV” sounds like a small feature. The rules behind that button deserve a real conversation.

Check the columns and the actual values

CSV means comma-separated values. Start by matching each source column to the right field in the app. Show a sample value beside the mapping so someone can spot a supplier code accidentally being assigned to an internal ID.

Then check how the values are interpreted. If your product code is 00127, a preview showing 127 needs attention. Microsoft's guidance on leading zeros explains how Excel can convert numeric text and remove those zeros, and how importing columns as Text can preserve them. Don't assume a code survived just because the file opens.

Test a description containing a comma, too. The CSV format described in RFC 4180 supports commas and line breaks inside quoted fields. Ask the developer to verify the exporter and importer agree on the format; one product description shouldn't become several fields.

If the original export already lost information, changing the app's display won't recover it. Compare the preview with a known correct source record.

Agree on what counts as the same record

Imagine a hypothetical repair shop in McAllen importing a single supplier's parts list. For this example, the agreed match is the supplier's unique product code. A product name is descriptive text, not the matching rule.

Decide what happens in these separate situations:

• The code isn't in the app yet.

• The code already exists, but its description changed.

• The same code appears twice within the uploaded file.

• A required code is missing.

Don't quietly pick the first or last duplicate unless that's an intentional, documented rule. Also decide what a blank cell means during an update: keep the old value, clear it, or reject the entry. Those choices can produce very different records from the same file.

Make the preview explain each change

For the repair-shop example, a small preview could look like this. These are proposed outcomes for a test file, not results from a real client system.

Ask for totals you can reconcile with the entries, including unchanged and rejected records. A sample of the first few records is useful, but the full file still needs validation. Make every proposed update inspectable before approval.

If someone edits an existing product after the preview was generated, require the app to check again before applying an outdated plan. The developer should define how those changes are detected and presented.

Decide what happens when part of the file fails

Will one rejected record stop the whole import, or will valid records be applied while the rejected ones wait? Either approach needs clear wording and a result you can inspect.

Different tools make different distinctions. HubSpot's import-error documentation separates cases where records aren't imported from cases where records import with errors in particular properties. For your own app, ask what “completed” means and which fields actually changed.

Keep the original file and a receipt showing the outcome, the time, and which entries need correction. For a partial import, make sure the correction process won't accidentally repeat the successful work.

Test the button twice before accepting the feature

Give the developer a small, agreed test file containing a new record, a changed record, a duplicate, and a missing identifier. Check the preview against the actual saved result. Then test what happens if the import completes but the user doesn't receive the confirmation and tries again. The second attempt should follow the agreed rule rather than create an unexplained second set of records.

Our offline app planning guide goes deeper into retries and conflicting changes. For an import feature, keep the acceptance decision simple: can your team explain what will change, approve it, and verify what actually happened? Our software development services can help turn those rules into a clear build brief.