CSV export problems: what the file leaves behind
Most CSV export problems have one of two causes. A CSV holds values and nothing else, so the program that opens it has to guess what each value means. And an export is a copy, so it starts to differ from its source as soon as it is written. The first cause turns ZIP codes into shorter numbers and March into April. The second leaves people mailing, calling and quoting totals from a list that has moved on.
What survives in a CSV and what doesn't
RFC 4180 is the 2005 memo that documents the common CSV format. It describes a plain text file: one record per line, fields separated by commas, and an optional header line naming the fields. It also records that no formal specification existed, "which allows for a wide variety of interpretations of CSV files." Most import surprises start there.
The values come through an export. Almost everything around them stays behind:
- Formulas. Only the value each formula showed at export arrives, as if someone had typed it in.
- Formatting. Microsoft's note on file formats says that if you save a workbook in any text format, "all formatting is lost."
- Other tabs. Excel's CSV options save only the active sheet, so an Orders tab beside it stays in the workbook.
- Links between records. A customer with five orders becomes one row with no orders, or five rows that repeat the customer.
- Rules. Dropdowns and validation don't travel, so nothing stops someone typing "TBC" into a date column.
- Provenance. Nothing inside the file says which system produced it, who ran the export or when.
Six rows that break an import
Every name, row and figure in the Sierra Bloom example below is sample data invented for this guide. Sierra Bloom Supply, a made-up garden wholesaler in Sacramento, California, exports its customer list from its order system as customers.csv. Six lines of that file, as plain text:
customer_id,name,zip,first_order,credit_limit
00417,"Rivera, Hale & Co.",95814,2026-01-19,5000
00418,José Núñez Landscaping,93721,2026-02-11,4000
00419,Beacon Hill Florist,02108,2026-02-23,2500
00420,Oak & Ivy Gardens,95616,03/04/2026,1800
00421,Chen Wei Nursery,95678,2026-03-09,"12,500"
00422,Marlow Tree Care,95630,2026-03-15,
Each row carries one trap:
| Row | In the file | What can go wrong | Check after import |
|---|---|---|---|
| 00417 | A name with a comma, in quotes | RFC 4180 says such a field should sit in double quotes. A tool that splits on every comma sees six fields and shifts the rest one column right | The ZIP reads 95814 |
| 00418 | Accented letters | Microsoft says a UTF-8 CSV opens normally in Excel if it was saved with a byte order mark, and otherwise points to importing it through Get Data on the Data tab. Opened directly without one, the accents can come out as stray symbols | A search for Núñez finds the record |
| 00419 | ZIP 02108, ID 00419 | Excel removes leading zeros, so they become 2108 and 419 | Five-digit ZIP, ID unchanged |
| 00420 | 03/04/2026 among year-first dates |
Month first, it is March 4. Day first, April 3. The file doesn't say which | The date matches the order system |
| 00421 | "12,500" |
Kept as text, it can drop out of totals. Split at the comma, it becomes 12 and 500 | The six limits total 25,800, not 13,300 |
| 00422 | An empty credit limit | An import may store 0, which reads as "no credit" instead of "not set" | Empty or flagged, not 0 |
Two more to watch for: Excel keeps 15 significant digits, so a 16-digit card number or tracking reference loses its last digit to a zero, and a code such as 12/2 can turn into 2-Dec.
Excel makes the zero, date and long-number changes as it opens the file. Open a CSV directly in Excel and it reads each column using its current default data format settings, not anything written in the file. If someone then saves it as CSV again, the shortened ZIPs are what gets saved, and formatting the column afterward won't restore the zeros. To keep values intact, use Data > From Text/CSV and set the ID, ZIP and reference columns to Text before loading.
How fast an export goes stale
Staleness needs no mistake at all. Suppose Sierra Bloom's full list holds 2,000 customers and about 40 records change in a typical month: a new buyer, a moved warehouse, a closed account. That is 2% a month. If different records change each month, the export ages like this:
| Age of the export | Records changed since (sample) | Share out of date |
|---|---|---|
| One month | about 40 | 2% |
| Three months | about 120 | 6% |
| Twelve months | about 480 | 24% |
Some records change twice, so the real share runs a little lower. The bigger point is that you can't see it. A row for a closed account looks identical to a live one.
Copies drift apart as well as behind
Send the export to three people and it becomes three files. Sales adds a Last called column. Accounts deletes inactive customers and saves over the file, leaving 1,730 rows. The warehouse corrects two delivery ZIPs in its own copy. None of these changes reaches the order system, so the next export repeats the two wrong ZIPs. Ask the three copies how many customers Sierra Bloom has and you get 2,000 twice and 1,730 once, all defensible. Only the warehouse copy has the right ZIPs, and only the sales copy knows who was called.
How often to regenerate an export
If a file is the only option, work out the interval instead of guessing. Divide the error rate the task can tolerate by the share of the list that changes each month. The result is the maximum age in months.
| What the export is for | Error you can accept | Monthly change | Regenerate at least every |
|---|---|---|---|
| Seasonal catalog mailing | 5% | 2% | 2.5 months |
| Sales call list | 2% | 2% | 1 month |
| Credit limits used to approve orders | 0% | 2% | No interval works |
The last row matters most. When a wrong value costs money or a customer's trust, no refresh schedule is short enough, and the list has to be read where it is maintained. For the rest, put the export date and purpose in the file name, such as customers_2026-09-30_catalog.csv, so an old copy announces its age.
Signs people are working from old exports
Watch for file names carrying "final", "v2" or someone's initials, and for requests to "send the latest one". Other signs are two reports with different customer counts for the same week, mail returned from addresses customers updated long ago, and statements sent to closed accounts. To confirm it, run a short audit:
- Collect each user's file name, modified date and row count.
- Compare header rows for added or missing columns.
- Search every copy for three records you know changed recently in the source.
- Total one numeric column, such as credit limit, in each copy and in the source.
If the dates span more than your regeneration interval, or the counts and totals differ, people are working from different lists.
Before you import a CSV anywhere
Keep an untouched copy of the export, and note where it came from, when it was made and what each column means. Import a small sample of your own file first, with one row for each trap above, and run the checks from the table. Then import the same file a second time. Existing records should update by customer_id, not appear twice, so decide that rule before the second import.
When the list has to stay current
For a list several people read and correct, stop sending files. Give them one address where the list is kept, so the warehouse's ZIP fix is the version sales sees.
In Exepad, upload the cleaned file with a short brief on the CSV to App page. The page hands both to Studio, where you create the first version and review it before publishing. Write the brief around the traps you found:
A customer list for a garden wholesaler, from customers.csv. customer_id is the unique key and keeps its leading zeros. zip is five-digit text. first_order is a date; any written with slashes are month first. An empty credit_limit means "not set". Sales reps sign in to look customers up and add notes, but cannot change credit limits. Accounts staff can.
If the building assistant in Studio suggests field types, check its choices for customer_id, zip and first_order yourself. Test the access you describe for each collection as well: sign in as a sales rep and try to edit a credit limit.
The upload is a snapshot, not a live connection to the order system. Choose how later changes arrive: people edit in the app, or you re-import deliberately with the customer_id rule you tested. A list people sign in to and edit is an app with data: any plan builds and previews it, and putting it live needs a paid plan. See what each plan includes.
If the accountant still wants a file at year end, you can export your app's data. Look through the export before handing it over, and date it.
What CSV is still right for
CSV remains the right tool when a frozen copy is the point:
- Moving data between systems, such as web shop orders into bookkeeping software.
- A dated archive, like the list as it stood on December 31.
- One-off analysis that nobody else depends on.
- Data for someone with no access to your systems.
- Backups, which are meant to stay frozen.
Trouble starts when a file meant to carry data becomes the place people keep it. The exports you send on a schedule, and the ones people ask for by name, are the lists that need a home.
Where to take the list next
For looking customers up, try a searchable directory built from a CSV. For follow-ups, see CSV to CRM. For totals and charts, start with a CSV dashboard. If the list began in a workbook, the Excel walkthrough with a column-mapping plan covers formulas and tabs. For copies spread across tools, see keeping business data in one place.
When the six-row test passes on your own file, bring the cleaned CSV into Studio.


