A customer number is not a quantity. It may contain only digits, but nobody needs to add two customer numbers together. That distinction is easy to preserve inside an application and surprisingly easy to lose when someone downloads its data.
Consider a fictional membership business with the account reference 004817. An operator exports a customer list, opens it in a spreadsheet and sees 4817. The name still looks right. The row is still there. Yet the reference no longer matches the one used by another system.
For a SaaS product, the choice between CSV and Excel export should follow the recipient's next task. CSV suits documented data exchange and simple tables. An XLSX workbook lets the product specify cell types and provide a more deliberate spreadsheet experience. Either format needs an explicit definition of the values it carries; neither makes the export correct by itself.
The useful product question is therefore more specific than which download button to add: what must survive when this file leaves the app?
Look at the value, then the cell
Our fictional record has an account reference, a membership fee, a renewal date and a customer-written note. Those four fields deserve different treatment.
The reference should remain text, including its leading zeros. The fee is an amount that may need arithmetic, accompanied by an unambiguous currency. The renewal date describes a calendar date, rather than a moment that should shift when someone changes time zones. The note is customer content, which must remain content even when it resembles a spreadsheet instruction.
Sending all four through the same generic conversion can make the file look tidy while changing its meaning. Treating every field as text avoids some conversions, but makes ordinary calculations less convenient. Treating everything that resembles a number as numeric causes a different set of problems. The exporter needs a small field specification, not a universal guess.
That specification can be brief. Explain what each column means, whether it can be empty, how dates and amounts are represented, and which identifiers must be read literally. A receiving developer should not have to infer the rule from a handful of sample rows.
Two formats, two useful jobs
CSV for another application. Start with stable columns, clear value conventions and correct parsing when a documented table feeds another system.
XLSX for spreadsheet work. Start with deliberate cell types, readable labels and a useful layout when a person will open and work with the file.
A package for a complete account. Explain relationships and included material when the task involves related records and files. One table may be insufficient.
These are starting points, not a rule that every product must ship three export options. A small application may serve its customers well with one well-documented CSV. Another may need a workbook because people routinely download lists for manual planning. Discover the real task before committing to extra formats and support work.
CSV is plain tabular text. It does not carry a workbook's cell-type settings, column widths or multiple worksheets. A receiving program decides how to interpret its fields. That simplicity helps integration, while leaving more responsibility with the import process.
The Informational RFC 4180 description of CSV covers conventions such as quoted fields and escaping quotation marks. Those conventions keep a comma inside a note from becoming a new column. They do not tell a spreadsheet that a digit-only account reference is text. Correct quoting and correct interpretation are separate requirements.
XLSX gives the exporter room to express the intended spreadsheet structure. A team can write identifiers as text cells, amounts as numeric cells and explanations on a separate sheet. It also takes more work to generate and maintain that experience. A beautifully formatted workbook with the wrong underlying cell values is still wrong.
Why adding the zeros back is an unreliable repair
Microsoft documents Excel's automatic conversions, including removal of leading zeros and a maximum numeric precision of 15 significant digits. Its guidance describes importing identifier columns as text. Automatic Data Conversions controls are available in specified versions, including Microsoft 365 and Excel 2024; the customer's version and settings matter.
For product teams, the implication is to preserve identifiers before the receiving software interprets them. A custom display format can make a short number appear padded. It cannot establish which missing characters belonged to the original reference, and it cannot recover digits already lost to numeric precision.
Avoid asking support to repair an altered export by eyeballing it. Compare it with a fresh authoritative source and regenerate or re-import using the agreed types. If someone has edited and saved the file, establish which copy still contains the original values before making further changes.
There is also a difference between a number's value and its display. A fee can be a genuine numeric amount even when the recipient changes the visible decimal places. An account reference is a label whose characters matter. Decide based on the field's business meaning, rather than the fact that both happen to contain digits.
A customer note must stay a note
Spreadsheet programs can interpret certain text as formulas. This matters when an export contains names, descriptions, notes or other untrusted input. A file generated by your trusted application can still contain text supplied by somebody else.
OWASP's CSV injection guidance explains this risk and warns that there is no universal sanitization strategy suitable for all spreadsheet applications and downstream consumers. Some measures used for spreadsheet viewing change the underlying text, which can affect later programmatic imports. Saving and reopening a file can also change the behavior of suggested escapes.
That creates a design decision: a file intended for human spreadsheet use may need different handling from a file promised as a literal data interchange. Specify how each mode represents untrusted text and have the engineering team review it against the supported receiving applications. Do not quietly alter customer content and continue describing the output as an exact copy.
For XLSX, explicitly writing untrusted content as string cells is part of the design. It still deserves verification in the workbook library and applications you support. Renaming a file or choosing a different extension does not establish safe handling.
Give each download an understandable promise
A useful interface might offer Spreadsheet workbook and CSV for import, with one sentence explaining the purpose of each. Those labels are proposed product copy, not features claimed for a Lesscode product.
The workbook could prioritize human use: text identifiers, numeric amounts, descriptive headings and a visible explanation of date and currency conventions. The CSV could prioritize a documented schema: stable column names, a declared encoding, consistent representations and import instructions. If their values differ because of a protective transformation, disclose that difference clearly.
Keep shared scope consistent. A user should not select one format and unexpectedly receive a different set of customers. Show whether the download includes selected rows, the current filtered result or the whole authorized dataset. Explain intentional omissions rather than hiding them behind a successful download message.
Both options need the same access discipline. Generate only data the requester is entitled to export, protect any stored download and avoid treating possession of a predictable file address as permission. Formatting decisions should not create a route around ordinary account boundaries.
If customers use the file in a recurring integration, treat changes to its columns and meanings as a product change. A harmless-looking label update can break a receiving script. A new export version, migration note or agreed transition can be more useful than silently replacing the old structure. Lesscode's SaaS data migration guide explores the related work of preserving usable records when systems change.
The acceptance conversation happens outside the app
Ask a prospective development partner to show a small synthetic export in the receiving tool your customer actually uses. Include a zero-prefixed reference, an identifier longer than 15 digits, an ordinary amount, a calendar date, non-English text and a multiline note. Include harmless formula-like text to review literal handling in a controlled setting. These are recommended scenarios; no export tests were performed for this article.
Then have the intended operator complete a normal task. Can they match the account reference to another system? Can they total the amount without repairing its type? Can they distinguish an empty field from an actual zero? Does saving the working copy preserve the fields they will hand back?
Keep the original sample values beside the result. A screenshot of a readable grid proves very little about the saved data. Record the supported application and version, the import route and any necessary settings. A product that requires an import step should teach that step at the download, where it helps.
When scoping custom SaaS and AI software, bring the receiving workflow into the brief. An example file and a description of what the customer does next give the team a concrete delivery target. The export is ready when that next task works with the intended values intact.
Cover: AI-generated conceptual editorial illustration. This article was prepared with AI assistance and checked against the linked sources.