A practical preflight before your next CSV import
In this article
A successful file upload tells you that a system received something. It does not tell you whether the right records reached the right fields. Before an import, separate three questions: can the table be read, do its values mean what you think, and does it satisfy the destination's requirements? This preflight is a suggested working method for small CSV and TSV handoffs, using Rowlane where its checks fit. It is not a claim that any particular import service accepts the resulting file.
Start with the destination
Obtain the receiving system's current template or field specification before editing the export. Record required headers, allowed values, identifier rules, date formats, and whether a blank cell clears an existing value. These decisions cannot be inferred reliably from a filename. If documentation is unavailable, ask the system owner for a small accepted example and an explanation of its fields.
Write down the intended scope as well: which records belong in this import, which period they cover, and whether the operation creates, updates, or replaces records. A technically consistent table can still contain the wrong population. Keeping scope beside the file makes that problem easier to spot before a transformation hides its origin.
Check the table's structure
Load an untouched copy into Data quality check. Review the header and record preview before interpreting the findings. CSV quoting allows a field to contain commas and line breaks; counting visible text lines is therefore not always a record count. RFC 4180 documents these quoting conventions. If the preview has one unexpected column, confirm the delimiter rather than starting to split or replace text.
Investigate uneven rows, empty headers, and repeated headers individually. A repeated header makes a later instruction such as “validate status” ambiguous. Fix the export or document a deliberate rename before proceeding. Keep the original available so a proposed repair can be compared against the source rather than accepted because the warning disappeared.
Profile meaning before cleaning
Inspect representative fields with Value frequency or Column statistics. Look for unexpected category spellings, missing identifiers, and numeric ranges that conflict with the documented unit. A range is an observation, not a business rule. A negative amount might be a refund; deleting it simply because it looks unusual would change the meaning of the table.
For an invented example, suppose a status column contains ready, Ready, and paused. Those values demonstrate a question about case, not evidence that capitalization is wrong. Ask whether the destination distinguishes the two ready labels. If it does not, an explicit value mapping can document the decision more clearly than an unexplained global case conversion.
Apply narrow transformations
Choose the smallest change that answers a confirmed requirement. Trim a selected text field when surrounding spaces are unwanted; preserve exact identifiers when spaces or case are meaningful. Rowlane treats source values as text, but an exported file can still be interpreted differently by the next application. Inspect the exported result in the intended import workflow.
Keep a short transformation record: selected columns, matching rules, excluded rows, and output filename. Avoid changing several unrelated properties in one undocumented pass. If a total or identifier count changes unexpectedly, you need to know which decision caused it. A smaller sequence of named steps is easier to explain than a single final file labelled clean.
Validate against explicit rules
Use Import validator for the field rules it supports, such as required values, uniqueness, a basic email shape, or a finite numeric range. Repeat checks for other relevant columns. A shape check cannot confirm that an address exists, and a unique column does not prove that every identifier refers to the intended entity.
Review rejected and accepted examples together. For a numeric field, include a known allowed boundary and a known disallowed value in a separate synthetic test table. This checks whether your chosen settings express the requirement you wrote down. It does not replace the destination's own validation, which may include relationships or rules absent from a browser tool.
Reconcile the export
Compare source and output record counts, selected identifiers, and any relevant totals. Explain every intentional exclusion. If two rows were removed as duplicates, retain the removed-record output and the rule used to choose the survivor. Reconciliation is most useful when it shows what changed and why, rather than merely reporting that the final number looks plausible.
Reopen the saved file through a controlled text import and check leading zeros, non-ASCII characters, quoted notes, and date strings. Test a small accepted subset in a sandbox if the destination provides one. Review its feedback before submitting the full file. Do not turn a successful sandbox upload into a claim about fields or records that were never exercised.
Make the handoff reviewable
Send the output with its scope, field expectations, transformation record, and unresolved questions. Identify who must approve uncertain values before import. W3C's tabular data model distinguishes cell text from interpreted values and metadata; documenting meaning is a separate task from producing delimited text.
Keep the original and the reviewed output distinguishable. The useful outcome is a file another person can inspect and a set of decisions they can reproduce, not an assertion that every possible problem has been eliminated. That makes the next import easier to assess and the next correction easier to trace.