Open a lead CSV without interpreting its fields as formulas

A person can type almost any text into a contact form. When you export that data to review calls, the text ends up in a spreadsheet. The CSV format does not declare that each cell is text: part of the behaviour is decided by the program that opens the file and its import options. This guide proposes a method for opening the export without any cell being executed or losing its format, with a harmless test to accept it.

Why a cell turns into a formula

The OWASP guide on CSV formula injection explains that spreadsheets treat a cell as a formula when it starts with an equals sign (=), plus (+), minus (-) or at sign (@), and also with a tab or carriage return; some locales also accept the full-width versions of those characters. It adds two warnings that matter here: filtering only the first character is not enough, because a separator or badly escaped quotes can open a new cell, and Excel may strip quotes or escape characters when saving and reopening, so a neutralised cell becomes active again (accessed 27/10/2026).

The risk is not only about security. Microsoft’s help on importing or exporting text or CSV files states that when you open a .csv directly, Excel interprets each column using the default settings, and gives the example of a column of numbers with leading zeros that must be converted to text to keep them. A postcode, an identifier or a phone number can change without warning.

Original, harmless control example

This phone number is fictional: do not use it to make contact. The test detects interpretation and format loss without building a dangerous payload: =1+1 only adds. Do not strip every leading sign as an automatic fix: you would change phone numbers and other legitimate data. Keep a restricted copy of the file as received and document every transformation of the reading copy.

Edge case: a comment such as Llamar mañana, "urgente" contains the separator and quotes. If the export does not quote and escape it properly, the row gains a column and the text after the comma starts a new cell: that is how a leading sign reaches a cell that looked safe. Before reviewing content, check that every row has the same number of columns as the header and that the comment appears whole in a single cell.

Acceptance procedure for the copy

1. Store the received file without opening it in a spreadsheet, in a location with restricted access, and note date, source and row count.
2. Prepare a fictional file with the five test cells and the same columns as the real export.
3. Import the test file with your application’s wizard and declare as text every free-text, phone, code and identifier column before loading data. In Excel, changing the extension to .txt forces the import wizard, according to Microsoft’s help.
4. Save the copy in the format the recipient will receive, close it and reopen it in their application and version.
5. If any cell shows a result, a number or a date, change the procedure before using real data.
6. Repeat the steps with the real export and share only the columns needed.

Sharing only what is needed is not a courtesy: the GDPR data minimisation principle requires personal data to be adequate, relevant and limited to the purpose. A call review rarely needs every contact’s full free-text comment.

Which method to use in each case

The neutralisation OWASP proposes, quoting every field, prepending a single quote and doubling internal quotes, is meant for human reading. For a system-to-system load, that extra character pollutes the data: there, validate the format with the guide to preparing a contacts CSV. If you can choose the exchange format, the guide to CSV or JSON compares how each keeps data types.

Exporting and opening are separate controls

Whether your call tracking tool, CallRail or another, produces a correct export does not certify how each cell is treated in your viewer: that control is yours, with any provider. The export answers for the content; opening answers for how it is interpreted. If you are exporting to keep data before closing an account, the guide on what to export before cancelling covers the content; here only the way it is opened is controlled.

Common mistakes and how to spot them

• Trusting the CSV quotes. Symptom: the test looks fine on opening and changes after saving and reopening. Check: always repeat the reopening step.
• Declaring only the comments column as text. Symptom: phone numbers lose the + or codes lose their zeros. Check: review every column in the test, not one.
• Working on the only original. Symptom: you cannot show what the export contained. Check: compare row count and date with the stored copy.
• Testing in your application and not the recipient’s. Symptom: the client sees results you do not. Check: ask them to open the fictional file before the real one.
• Stripping every leading sign. Symptom: phone numbers without prefix and altered negative references. Check: compare a sample with the original.

This review does not require buying CallRail: the product fits when you also need to capture and attribute calls. No real export has been tested here.

From the author's experience

In the lead and call exports I've reviewed, I'd test names and notes that start with formula characters first, along with phone numbers carrying a leading plus sign and long identifiers — those are the fields that most often end up interpreted as a calculation or lose their formatting on open. I'd protect phone numbers and identifiers from automatic conversion in particular, and keep dates with a defined format and time zone, always checking the import in the destination spreadsheet before trusting it.

The procedure I'd recommend to an operations team is to define an explicit import with text columns and documented formatting, rather than relying on a double-click when it isn't clear what transformation is being applied. If a client needs to open the file by double-clicking, I'd propose an XLSX with explicit cell types where that's viable, or a version prepared for safe reading in CSV, always keeping the original for technical exchange. I'd test the actual export from any contact center or call tracking tool before trusting its protection against dangerous cells, checking whether it adds escape characters that later show up as literal data when imported into another system. And of the possible errors, the one I'd check most carefully before loading a CRM or a dialer is the loss of prefixes, zeros and precision in identifiers; I wouldn't claim to know which is "most frequent" without consulting an actual incident log.

Sources and limitations

Documentary review: 27 October 2026. Content type: Documentation-based guide with original exercise.

Linked sources describe the terms and capabilities each provider publishes. Examples that use fictional data are labelled in the text.

Scope: Documentation reviewed on 16 October 2026. Examples are fictional and tests are proposed; CallsIQ has not performed product tests.

• CSV formula injectioncommunity.owasp.org
• importing or exporting text or CSV filessupport.microsoft.com

How to report a correction

Check current terms

Consider these options if they solve the problem described. Confirm features, limits and availability in your country.

CallRail for international clients: its phone-number documentation lists availability in the United States, Canada, the United Kingdom and Australia. Spain is not on that list. Consider this option if you manage phone operations in those markets, and confirm numbers, destinations and terms with the provider. Availability checked on 2 October 2026.

CallRailAffiliate link

The labelled commercial links may earn CallsIQ a commission or referral reward. Our commercial policy.