CSV Export Problems: Why Exports Go Stale

A trade association with 1,840 members keeps its membership list in one system and everything else in email. On a Tuesday afternoon in March, the membership secretary exported the list to a CSV and sent it to six colleagues: the events lead planning the summer conference, two regional coordinators, the treasurer, the newsletter editor, and a volunteer building a printed directory. By the end of the following month there were nine versions in circulation and no reliable way to say which was right.

Nobody misbehaved. The events lead added a column for dietary requirements. The treasurer filtered out lapsed members and saved the result over the original. A coordinator corrected two addresses in her copy. The volunteer saved his as members_FINAL_v2.csv, which is how these things are named. Meanwhile the membership system carried on: eleven members joined, four resigned, and nineteen changed a contact detail.

A CSV export is a snapshot of one moment. It is right when it is generated and drifts from the source from that point on, and because each recipient keeps their own copy, one export becomes a set of files that quietly disagree about the same list. That makes CSV a sound way to move data between systems and a poor way to keep a group of people looking at the same numbers.

What is inside a CSV export

A CSV file is plain text: one line per record, values separated by commas, usually with a header row naming the columns. That simplicity is the whole point and the whole limitation. The values survive the export. Everything around them does not.

Formulas do not survive; only the numbers they produced at the moment of export. Formatting does not survive, which is why phone numbers lose their leading zero and dates arrive as 03/04/2026 with no indication of whether that is March or April. Relationships do not survive: if a member record was linked to three event bookings, the CSV holds a flattened mess or nothing at all. Nor do validation rules, so nothing stops a recipient typing n/a into a date column.

Most consequentially, the file carries no record of when it was made or by whom. A CSV opened in six months looks exactly like one opened six minutes after it was written.

CSV export problems begin the moment the file leaves the system

Inside the system, a record has one home. Change a member's email address and everyone sees the new address, because there is only one record to look at.

The export ends that arrangement. From the moment the file is written to disk it is connected to nothing. The source system does not know it exists, cannot notify it of a change, and will not stop the recipient using it.

This is the point most teams miss. They treat the export as a view of the data. It is not a view; it is a copy. A view updates; a copy does not, and it does not tell you it has not. Teams that keep hitting this end up looking at how to keep business data in one place rather than distributing copies of it, because the distribution is where the trouble starts.

Why an export starts ageing at the point of download

The rate of ageing depends on how quickly the underlying list changes, and for most business data that is faster than people assume.

Thirty-four changes a month across the association's 1,840 records is under two per cent, which sounds negligible. After four weeks the export is around 98 per cent accurate. After three months roughly one record in twenty is wrong. After a year, close to a quarter of it is wrong or missing.

The problem is not the percentage but that the wrong records are invisible. A member whose email has bounced does not appear as an error in the CSV; the address sits there looking like all the others. Someone posting 1,840 conference invitations from a nine-month-old export will get 400 or so back, and will discover it only after the postage is paid.

Emailing an export creates a copy nobody can update

An attachment is a one-way street. Once the file is in someone else's inbox, the sender has no route back to it. If a mistake surfaces ten minutes later, the only remedy is a second email saying ignore the first one, which works for some recipients and not others.

There is a more persistent problem underneath. When a recipient spots an error and fixes it in their copy, the correction stays with them. The coordinator who corrected two addresses did real work that never reached the membership system. The next export reproduces the same two errors, she corrects them again, and this continues for years without anyone noticing.

Corrections made in a copy do not travel back. Over time the copies collectively know more about the members than the source system does, and none of that knowledge sits anywhere useful.

Six people, six copies of the same export

Divergence begins immediately and accelerates, because each recipient adapts the file to their own purpose.

By June the six copies looked like this. The events lead's had two extra columns and 1,840 rows. The treasurer's had 1,602 rows, lapsed members removed, and was the one quoted in a committee paper. One coordinator's held corrected addresses; the other's had a sort that had silently broken the row alignment on a column. The newsletter editor was working from a copy of the treasurer's file, so his mailing list was missing 238 paid-up members. The volunteer's directory had gone to print.

When the committee asked how many members the association had, three numbers came back in the same week: 1,840, 1,602, and 1,851. All three were defensible, and all three came from the same original export. This is the moment someone asks which version is current? and finds there is no answer, only a set of files with different modification dates.

How often an export has to be regenerated to stay useful

If exporting is the only option, the regeneration interval is worth calculating rather than guessing. Two numbers give it: the rate at which records change, and the error rate you can live with.

Divide the tolerance by the monthly change rate. The association changes about 1.8 per cent of records a month, so a two per cent tolerance for a mailing means regenerating monthly. For invoicing, where the tolerance is closer to zero, no interval is short enough and the export is the wrong instrument.

In practice the rule holds badly, because regeneration is a task somebody has to remember. The association exported for the conference in March and next exported in November. The eight months between were not a decision; they were the absence of one. Any process depending on someone recalling to refresh a file will fail during a busy quarter, which is when the data matters most.

How to tell whether people are working from an old export

The signals are recognisable once you know to look for them.

Two colleagues quote different totals for the same list in the same meeting. Post comes back marked addressee unknown for people who moved months ago. A customer who cancelled in the spring receives a renewal notice. Filenames appear with dates, initials, or the word final in them. Somebody asks you to send me the latest one — the phrase is the tell, because it concedes that the copy they hold is not the latest and that they cannot tell how far behind it is.

A quick audit settles it. Ask the four or five people who use the list for the modification date on their file and its number of rows. If the dates span more than a fortnight, or the row counts differ, that group has been deciding from different versions of the same list for some time.

What replaces the export when the list has to stay current

The alternative is not a better file. It is not sending a file at all — giving people an address instead, so that everyone who opens it sees the list as it stands at that moment.

That is what the association did. The same membership spreadsheet became a searchable directory published from the CSV, with one link shared among the committee, the coordinators, and the volunteers. The events lead's dietary column became a field on the record rather than a private addition to a private file. The treasurer's filter became a saved view of the same data instead of a separate 1,602-row document. When a coordinator corrects an address now, everybody has it, including the person printing the directory.

The change is smaller than it sounds. Nothing about the underlying columns changed; the file that used to be attached to an email became a working application with its own address. The wider case for replacing spreadsheets with something shareable covers the operational side, and the same argument plays out when a customer spreadsheet is asked to behave like a real system of record.

What CSV is still the right tool for

None of this makes CSV a bad format. It is an excellent one, used for what it is good at.

It is the right tool for moving data between systems: an accounting package to a payroll provider, a shop to a bookkeeping tool. It is right for a deliberate archive — the membership list as it stood on 31 December, kept precisely because it will never change. It is right for one-off analysis, for handing data to someone with no access to your systems, and for backups, which are supposed to be frozen.

The distinction is between transport and residence. CSV is a lorry, not a warehouse. It moves data very well, and the trouble starts when people begin living out of the back of it.

So the question is not whether to stop exporting, but which of your exports are transport and which have quietly become residence. Look at the files that leave your business on a repeating schedule, and the ones people ask for by name. Those are the lists that need an address rather than another attachment — and once they have one, the version question stops being asked, because there is only one version to ask about.