Three questions before approving a CSV export
A CSV export can preserve its row count while changing the values you meant to keep. Before deciding that an import worked, separate three questions: which record is this, what text changed, and what behavior still needs checking?
This article was drafted with AI assistance for Workflow Fieldnotes, an Editorial Desk Media publication. The examples are fictional; they illustrate a comparison method, not a tested result from a particular software product.
Consider this small original file:
record_id,external_id,start_date,note
r-41,0017,04/05/2026
r-42,0018,04/06/2026,
After an imaginary import and export, it becomes:
record_id,external_id,start_date,note
r-41,17,2026-05-04,
r-42,0018,04/06/2026,
There are still two data rows. That count conceals three changes in r-41.
1. Which column establishes identity?
For this exercise, record_id is the declared unique key. It lets us compare the r-41 row before and after without relying on position or a person's name. Row order can change without changing identity.
The key is an input to the comparison, not something the tool should invent. First check that it exists and has one nonempty value per row. If r-41 appears twice, deciding which copy matches the original would require information this file does not provide. Record the ambiguity before proceeding.
Choosing external_id as the key changes the interpretation. The exact strings 0017 and 17 are different keys. An exact-key comparison would see a removed key and an added key; it cannot conclude that both refer to the same record. That is why the identity choice belongs in the acceptance notes.
2. What changed before we interpret it?
With record_id as the key, the expected findings are:
| Field in r-41 | Original | Exported | Observation |
|---|---|---|---|
| external_id | 0017 | 17 | Leading zeros disappeared. |
| start_date | 04/05/2026 | 2026-05-04 | The text changed; the original date convention is not established here. |
| note | No fourth field | Explicit empty fourth field | Missing became empty. |
The last distinction is intentional. The first original row has only three fields; the exported row has a trailing comma that supplies an empty fourth field. A strict fixed-width CSV consumer may reject the short row altogether. A comparison dialect that preserves short rows can instead expose the absence explicitly. Document which behavior you are using.
Do not normalize the date merely to make the report green. The strings might represent the same intended date, or the import might have chosen the wrong convention. Ask for the declared date format and business meaning before approving a transformation. Likewise, an identifier may look numeric without being a quantity.
3. What does the report actually approve?
For the displayed pair, expect one changed row and three changed values, with no added or removed rows or headers. The r-42 row is unchanged. Write those expectations down before running a comparator; an unexpected result should prompt investigation, not an edit to the expectation.
An acceptance note can be short: “Compared by record_id. Row r-41 changed in three fields. Identifier and date interpretations remain unresolved; no repair applied.” Add who owns the decision and the original/export filenames. Keep both files untouched.
Even a zero-difference report would cover the exported representation only. It would not demonstrate that a welcome automation stayed paused, a consent setting survived, or an application interpreted a date correctly.
For additional fictional pairs and a local comparison interface, use the Workflow Fieldnotes CSV comparison guide. Its method makes delimiter choice, exact keys, short rows, and missing-versus-empty behavior explicit.
Technical source: RFC 4180 documents a common comma-separated format, including quoting and consistent field counts. It is informational, not a universal promise about CSV importers. The short-row distinction above is an explicitly chosen comparison behavior, not a claim that RFC 4180 requires accepting short rows.