Your Excel formulas vanished in the CSV. Here is exactly what a save discards.

You spent an afternoon building a model, saved it as CSV to send to someone, opened the CSV to check, and every formula is gone. Nothing malfunctioned. CSV is a text format for one table of values, and a workbook is not that.

What follows is a full accounting of what a Save As CSV discards, why each loss happens, and which ones you should actually care about. Some of them are worth mourning. Several are improvements.

Loss: formulas become their results

Cause. A cell containing =SUM(B2:B100) writes 4213.5 to the CSV. The expression lives in the workbook's XML; the CSV gets the last computed value. There is no syntax in CSV for an expression, so there is nowhere to put it.

Consequence. The file is now a snapshot. If the underlying numbers change, nothing recalculates, because there is no calculation any more. That is exactly what you want for a report you are archiving and exactly wrong for a template you expect someone to fill in.

Fix. Decide which of the two you are producing. If it is a snapshot of results, CSV is the right choice and the loss is intentional. If the recipient needs the logic, send XLSX. If the recipient needs to run the logic on new data every month, neither is right: the calculation should live in a pipeline that re-runs, not in a file that someone re-opens.

Fix it: rebuild the calculation as a pipeline you can re-run on next month's file →

Loss: every sheet but the active one

Cause. CSV holds one table. A workbook with a Data tab, a Lookup tab and a Summary tab has three, and Save As writes whichever one was in front when you hit save.

This is the loss that produces the most confused emails, because the CSV is not empty and not obviously wrong. It is just a different sheet from the one the recipient expected, usually the summary rather than the data.

Fix. Export each sheet you need as its own CSV, and name the files after the sheets. If the sheets are related through lookups, that relationship also does not survive, so you will need to re-join them on the other side. Our Excel to CSV converter shows you the sheet list and lets you pick, rather than silently taking whichever one Excel considered active.

Fix it: pick the sheet you want and convert just that one →

Loss: formatting, including number formats

Cause. Bold, fills, borders, column widths, conditional formatting, freeze panes: none of it exists in CSV. That is fine and mostly nobody misses it.

Number formats are the interesting case, because they change what gets written.

The first two are improvements. A number without a currency symbol or a percent sign is easier for every downstream tool to handle, and the symbol was never data. The third is a trap: the date is written in the display format, which means an ambiguous format in the cell produces an ambiguous date in the file. The fourth is real damage that happened before the export, and the CSV faithfully records it.

Fix it: format date columns as ISO in the sheet before you export →

Loss: charts, comments, validation, named ranges

Cause. All of these are workbook features with no textual representation. Charts are drawings bound to ranges. Comments are annotations attached to cells. Data validation is a rule, not a value. Named ranges are references. None of them are rows and columns.

Consequence. The one that actually costs people is data validation. A column that was constrained to a dropdown of five values in the workbook is a free text column in the CSV, and the next person to fill it in will type whatever they like. If that file comes back to you, expect Yes, yes, Y and TRUE in the same column.

Fix. Validate on the way back in rather than trusting the way out. A profiler that lists distinct values per column finds the four spellings of yes in about two seconds, which is faster than any amount of instruction in an email.

Fix it: profile the returned file and see every distinct value per column →

Loss: error cells and merged cells, in their own special ways

Error values. A formula showing #N/A, #REF! or #DIV/0! writes that literal text into the CSV. So a numeric column can arrive with #N/A scattered through it, which forces the whole column to be read as text and makes every sum fail. Clean errors up before exporting, or wrap the formulas in IFERROR.

Merged cells. A merged cell writes its value into the first position and empty strings into the rest. That produces the very recognizable shape where a category name appears once and then five blank rows follow, which most people read as missing data. It is not missing; it is a layout that was never tabular.

The repair is a forward fill: every blank takes the value above it. In SQL that is a window function.

SELECT LAST_VALUE(NULLIF(TRIM(region), '') IGNORE NULLS)
         OVER (ORDER BY row_num
               ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS region,
       product, revenue
FROM data;

The IGNORE NULLS is the part that makes it work, and the NULLIF around TRIM is what turns an empty string into a real NULL so the fill sees it.

Fix it: fill missing values down the column in one operation →

Check what is really in the file

After any workbook to CSV export, do a three-point comparison against the original. It takes a minute and catches almost everything in this guide.

• Row count. Does the CSV have the same number of data rows as the sheet? A merged header block or a filtered view can change this.
• Column count. Trailing columns that were formatted but empty sometimes come along as extra empty fields.
• One total. Sum a numeric column in both places. If they disagree, either an error value became text, or a formula was showing a stale result at save time.

That last check is the one I would never skip. It catches the whole class of problems where the CSV looks structurally perfect and is arithmetically wrong.

Fix it: diff the workbook against the exported file by key column →