A CSV import checklist that catches errors before upload
Check CSV mappings, identifiers, dates, untrusted text, test batches, rejected rows, and final reconciliation before changing business records.
A CSV import can look simple because the file opens neatly in a spreadsheet. The destination system still has to interpret every identifier, date, amount, blank, and relationship correctly. A successful upload message may only mean that the file was accepted; it may not mean that the right records were updated or that no unwanted actions were triggered.
The useful approach is to treat an import as a controlled change. Preserve the original, define the intended result, validate a working copy, test a representative batch, and reconcile the destination afterward. This can be done with modest tools and a clear checklist rather than a complicated integration project.
This guide is an original operating checklist for business owners and administrators. It includes a hypothetical service-contact import and explains when to stop. Exact limits and behaviors vary by destination, so use the current official documentation for the system you actually operate.
Define the intended change before preparing the file
Write one sentence describing what the import should do. For example: update service contact phone numbers for existing customer references without creating customers, changing communication preferences, or sending messages. That sentence establishes a boundary against which you can inspect the import settings.
Decide whether the operation creates records, updates records, or does both. Identify the field that connects each incoming row to an existing record. If the destination cannot reliably distinguish those actions, reduce the scope or choose another supported method rather than assuming it will infer your intention.
Name the business owner, operator, reviewer, and recovery decision-maker. For a small team, one person may fill several roles, but a second check is helpful when the changes are difficult to reverse. Keep the intended result with the file so somebody reviewing it later can understand why the import happened.
Read the destination’s actual import requirements
Check supported encoding, delimiter, maximum size, required columns, accepted date formats, and how the system handles empty values. Confirm whether an empty field clears an existing value, leaves it unchanged, or causes a validation error. Those behaviors have very different consequences.
Check how updates are matched and what happens when the matching value is absent or repeated. Find out whether the import can trigger welcome emails, automation rules, assignment changes, or notifications. Turning a list of contacts into a series of outbound messages should never be an accidental side effect.
The RFC 4180 description of CSV documents common formatting conventions. It does not mean every business application accepts the same dialect or applies the same update behavior. Use it as background for understanding the file, then verify the destination’s current requirements. Do not rely on an old import template without checking whether the fields and rules still apply.
Preserve an original and create a controlled working copy
Store the unmodified export in an approved restricted location. Record its source, extraction date, scope, and row count. Work on a separate copy with an identifiable version. Avoid editing the only copy and losing the ability to explain a transformation.
Keep a short transformation log: renamed a column, removed an out-of-scope row, converted a documented date format, or corrected a confirmed invalid value. The log should explain the reason and approver where a business decision was involved. Do not silently invent missing values to make validation pass.
Limit the file to information needed for the import. A complete customer export may include sensitive fields that the destination does not need. Removing unnecessary columns reduces both mapping mistakes and the exposure created by extra copies. The customer data sharing checklist provides a broader way to assess whether information should move between systems at all.
Map columns by meaning rather than similar names
Create a mapping table with source column, destination field, meaning, transformation, and empty-value behavior. Two fields called account may represent different things: a customer identifier in one tool and an accounting category in another.
Use the small-business data dictionary to resolve those meanings before importing. Dates should identify a particular event, amounts should identify currency and basis, and status values should have defined entry conditions. A matching column label is not enough evidence.
| Incoming column | Destination intention | Check before upload |
|---|---|---|
| customer_reference | Find an existing customer | Unique, preserved as text, no missing values |
| service_phone | Update the service contact number | Country information and permitted format understood |
| service_contact_name | Update the named service contact | Correct person and appropriate source |
| effective_date | Explain when the update applies | Unambiguous date interpretation |
| marketing_status | Outside this import’s scope | Exclude instead of mapping casually |
If a source field has no appropriate destination, stop and decide whether it should be omitted or whether the process needs a new approved field. Do not hide it in a general notes field simply to avoid losing a column.
Protect identifiers, dates, and international values
Treat identifiers as identifiers, even when they contain only digits. Leading zeros can distinguish valid references, and a long reference can be damaged if a spreadsheet interprets it as a number. Inspect the actual exported text rather than trusting how a cell appears on screen.
Use an unambiguous date representation accepted by the destination. A value such as 03/04 can mean different days depending on the locale. Do not infer the intended interpretation from your own computer settings. Ask the source owner when the meaning is uncertain.
Check names with accents, non-Latin characters, apostrophes, and punctuation. Confirm that the selected encoding preserves them. Inspect decimal separators, currency codes, phone country codes, and multiline addresses where relevant. A worldwide customer list should not be forced into one country’s assumptions merely because the operator’s spreadsheet defaults to that country.
Validate structure before reviewing business content
Check that the file contains the expected header and a consistent number of fields per record. Quoted commas, quotation marks, and line breaks can affect how a parser interprets rows. Opening the file successfully in one program does not establish that the destination will parse it the same way.
Then validate required values, allowed statuses, identifier uniqueness, and relationships to existing records. Distinguish a formatting problem from a business question. A missing customer reference may require investigation; filling it with zero is not a valid repair unless zero is a documented legitimate reference.
The W3C CSV on the Web primer describes how metadata can express column types and constraints that raw CSV does not carry by itself. You can apply the basic idea with a readable validation checklist even if you do not implement a technical metadata standard. The rules need to be explicit somewhere outside the operator’s memory.
Inspect untrusted text without executing it
Customer-provided text can contain values that spreadsheet software interprets as formulas. OWASP’s CSV injection guidance describes this risk when untrusted content is opened in spreadsheet applications. Treat the file as data and use an approved inspection method that does not execute unexpected formulas or active content.
Do not run a formula supplied in a customer field to see what it does. Ask the technical owner how the destination and review tools handle such values. Protection may require different treatment for a machine import and a human-readable spreadsheet export; a change that makes one use safer may alter the actual data expected by another.
Record the chosen handling rule and keep the original securely. This is particularly important when a business exports support messages, names, or other user-entered text. The reviewer should be able to inspect suspicious content without granting that content authority to run actions.
Test a representative batch with clear stop conditions
Choose a small sample containing ordinary rows and edge cases: an accented name, a leading-zero reference, an optional blank, an existing record with a different value, and a record that should fail validation. Use a sandbox or supported preview mode when available; otherwise, design a limited reversible production test with appropriate approval.
Write the expected outcome for each row before importing. Confirm that invalid rows are rejected as expected and that a rejected row does not partially change another record. Do not assume the operation is all-or-nothing unless the product explicitly supports that behavior.
Stop if the system creates unexpected records, clears unrelated fields, sends unplanned messages, or reports errors whose effects are unclear. Do not repeatedly rerun the same file in the hope that the error disappears. A retry can duplicate records or external actions if the import is not designed to recognize previously processed rows.
A hypothetical service-contact import
Imagine a maintenance business updating the service phone numbers for thirty existing customer locations. The operator maps customer_reference to the destination’s stable location identifier and excludes billing and marketing fields. A five-row test includes one reference with a leading zero and one unknown reference.
The preview shows that the spreadsheet’s saved copy removed the leading zero. The operator stops before upload, returns to the preserved original, and prepares the reference column using the destination’s supported text format. The unknown reference remains an exception for the operations owner rather than becoming a new customer automatically.
After the corrected test, the reviewer checks the actual destination records and confirms that only the intended phone fields changed. The team then processes the remaining approved rows. This is a hypothetical example, not a claim that a particular import tool has been tested. Its lesson is that a small, deliberately varied test can expose a problem a clean-looking first row would miss.
Reconcile accepted, rejected, and unchanged rows
After the import, reconcile the submitted row count with created, updated, unchanged, and rejected outcomes. Use the destination’s actual definitions because some tools count processed rows differently. Save the result report with the mapping and working-file version.
Inspect a meaningful sample of changed records and every unresolved exception. Check related processes: a customer search, a support lookup, or the next scheduled export. The import is complete when the business can use the intended result, not merely when the progress bar reaches the end.
If the outcome is wrong, follow the planned recovery route. Restoring a pre-import snapshot may overwrite legitimate work created afterward, so recovery needs an explicit decision. The business audit trail guide helps record what changed, which batch caused it, and how corrections were authorized without retaining unnecessary copies of sensitive values.
Give rejected rows their own resolution path
A rejected row is still business work. Put it in an exception register with its original reference, rejection reason, responsible owner, and next action. Keep technical errors distinct from missing business decisions. Invalid encoding may be an operator correction; an uncertain customer identity may require the customer-record owner.
Do not reimport the entire original file merely to process a few repaired rows. Determine which rows were already accepted, whether the destination recognizes repeated submissions, and how the corrected batch will be identified. If the tool reports only a general failure without reliable row outcomes, investigate before retrying.
Tell downstream users when the imported dataset is incomplete. For example, a support team should know that several locations still retain their previous phone details. A partial import should not be described as a finished refresh. Once exceptions are resolved, reconcile the combined outcome of the original and corrected batches so the business has one explanation of the final state. Keep the exception record’s access restricted to the information needed for resolution.
Review the file again after its final save
Validation is only useful if it applies to the exact file that will be uploaded. A final spreadsheet save can change delimiters, quoting, encoding, or displayed values depending on the application’s settings. Keep the reviewed working version identifiable and inspect the final exported file through the approved method before selecting it in the destination.
Record the filename and a batch reference that will appear in the import log. Where appropriate, a technical operator can also record a file checksum to distinguish two files with the same name. The checksum identifies a particular file’s contents; it does not prove that those contents are correct or authorized.
Avoid editing the file between final approval and upload. If a correction is needed, create a new identifiable version and repeat the relevant checks. This is especially important when one person prepares the file and another uploads it later. The second person should be able to confirm that the selected file is the reviewed one without relying on a message saying use the latest copy. A small amount of version discipline prevents a sound mapping and validation process from being undermined at the final step.
Turn a successful import into a repeatable procedure
Keep the approved mapping, validation rules, sample cases, stop conditions, and reconciliation steps. Record the destination version or documentation check date when product behavior matters. A future operator should be able to distinguish a reusable rule from a one-time correction.
For recurring imports, monitor why rows fail and whether the source can prevent those failures. Track unexpected creations, missing match keys, rejected rows, and time spent resolving exceptions. These observations are more useful than measuring upload speed alone.
Start the next import by reviewing its purpose again. A file that was safe for phone updates may be unsafe for permission changes or financial records. Reuse the disciplined process, not an assumption that every CSV operation is equivalent. The aim is a controlled, explainable change whose results the business has actually checked.
Sources and editorial method
Checked October 15, 2026. Primary references: RFC 4180, W3C CSV on the Web primer, and OWASP CSV Injection. These support limited points about formatting, metadata, and spreadsheet interpretation of untrusted values. The checklist, mapping table, pilot design, and maintenance-business example are original guidance. The example is hypothetical; no destination-specific import or live integration has been tested for this article.
