The useful question is not simply whether a value looks numeric. It is whether the destination might interpret the text differently from its intended meaning. Three implementation choices keep that uncertainty visible.

Keep the evidence as text

The parser in preflight.js keeps parsed field values as strings. For example, 000042 and 12345678901234567890 are synthetic identifiers, not customer records. Converting them to numbers before checking them would undermine the evidence the checker needs: the leading zeros and exact sequence of digits.

Here, “preserve” means retaining the parsed field text, not reproducing the original CSV bytes. CSV quoting is decoded during parsing. Each finding includes the original parsed value, a logical record number, the record’s starting line, and the selected column. Those two location numbers matter because a quoted field can contain a newline: one record need not occupy one physical line.

The checks can use a trimmed copy for comparison while reporting the untrimmed field value. Outside whitespace becomes a finding, rather than a silent correction. The parser also rejects malformed quoting and records with unexpected field counts instead of trying to guess the missing structure.

Share the rules across two interfaces

The browser interface in app.js and the command-line interface in cli.js both call the same audit function. The core module exposes it through a browser global or CommonJS, keeping the checking rules in one place.

This is a small architectural choice with a practical benefit: changing a rule does not require separately reimplementing it for two interfaces. The wrappers handle different jobs. The browser gathers column selections and displays findings; the command line reads a file and produces a JSON report. Sharing the engine reduces opportunities for drift, although it does not by itself prove that both wrappers behave correctly.

Ask for meaning instead of inventing a repair

Consider the synthetic amount 1,234, quoted when it appears in a comma-delimited CSV. With the decimal convention unknown, the engine checks dot-decimal and comma-decimal interpretations. When both fit but imply different values, it flags ambiguity.

The next step is to confirm the source convention. The checker does not choose a locale from one cell, rewrite the amount, or recover digits already lost upstream. Users select which columns represent IDs or amounts; header-name suggestions are only a starting point.

The repository’s test/preflight.test.js makes these boundaries inspectable through synthetic cases for leading zeros, long IDs, quoted multiline fields, ambiguous amounts, and malformed input.

The result is deliberately a review report, not a cleaned CSV. It checks selected columns against listed heuristics. A report with no findings is not approval to import, and a downloaded report may contain original values that need care before sharing.

Project: CSV Import Preflight.

Chris

For quantities, you may want a consistent decimal symbol. For an identifier, every character can matter. Before converting a batch, write down what must stay exactly the same.

Three separators, three different jobs

Keep the original file unchanged. A field delimiter separates columns; a decimal symbol separates the whole and fractional parts of a value; a thousands separator groups digits. Agree on each separately.

For example, 1.234,50;002,00 contains two fields when the delimiter is a semicolon. With a decimal comma and grouping dot, the first value becomes 1234.50. Under the same rules, the second becomes 002.00: its leading zeros are retained.

In comma-delimited CSV, a field containing a comma needs quoting: "1,234". The informational RFC 4180 describes CSV quoting and escaping, not the business meaning of a number. The semicolon example uses a different delimiter.

If one column contains both decimal conventions, confirm a rule for the affected records. A plausible-looking result is not enough.

Make preservation visible

These are the first three amount changes from my synthetic test. The rule was explicit: semicolon delimiter, decimal comma, grouping dot. The converter treats data as strings, so it does not pass identifiers through floating-point arithmetic.

The first record ID was 100000000000000000001. It remained exactly the same in the output.

The tested batch contained 25,000 data records across two files. All 75,000 data cells were checked against expected strings, and all 21-digit IDs were retained. This is a synthetic demonstration, not a customer case study.

Preservation in the CSV does not control how another application opens it. Import settings still matter.

Try the tools you already have

Microsoft documents how automatic conversion can remove leading zeros and truncate numeric precision after 15 significant digits. A long identifier should be imported as text. Setting it to text after digits have been lost will not restore them.

1. Start from the untouched source file.
2. Use Data → From Text/CSV, then open the transformation editor.
3. Set identifier columns to Text before numeric conversion. Check the delimiter and the locale used for amount columns.
4. Preview representative records before loading the result.

These steps are adapted from Microsoft's import guidance. Menu names vary by version. These are documentation-based instructions; I have not tested every Excel edition.

OpenRefine is another option for inspecting and editing tabular data. For a small one-off job, an existing tool may already give you a result you can verify.

Some findings should stop an export

In the companion review example, an unresolved value prevents the whole batch from producing a processed CSV or delivery ZIP. Proposed changes remain visible in the diagnostic log; they are not a completed delivery.

• Count the records. Explain any difference between input and output.
• Compare exact strings. Inspect long IDs, leading zeros, signs and fractional zeros.
• Review exceptions. Mixed separators, unexpected text and malformed groups need a decision.
• Agree on duplicates. An identical row can be a valid repeated transaction. This workflow flags exact repeated source rows by default; removal requires an agreed rule.

Format checks cannot establish whether a value is commercially correct. Confirm the intended interpretation against a trusted source before using the output.

Inspect the actual demonstration

The complete demonstration pack contains synthetic inputs, processed outputs for the passing batch, full change logs, and reports from both actual test runs. The unresolved review batch deliberately has no processed output.

You can also read the passing-batch report and review-required report separately. The PDFs contain limited previews; the JSONL files contain the full logs. Open raw CSV and JSONL in a text editor first so a spreadsheet does not silently reinterpret the values.

This article is adapted from my original Filework Notes guide. I run Filework Notes; that page also describes an optional paid service for a defined numeric CSV batch. The guide, reports and demonstration pack are free to inspect, with no signup required.