Keep long digit IDs as text in CSV to Excel
Stop Excel from shortening order, ledger and tracking identifiers past fifteen significant digits.
Quick answer. Keep long digit identifiers as Text. Excel cannot store more than fifteen significant digits exactly; widening a column will not restore a shortened token.
Try a file with a known result
Original synthetic teaching data; no customer records. Download the small sample, then load it into the matching tool. Your own files remain in your browser.
Settings for this example
Load long-ids.csv in CSV to Excel with Comma and a header. Leave ledger_ref and tracking_id on Text. As a negative test, try Number on ledger_ref and confirm unsafe values block download.
Expected results to compare
- The preview has 3 data records and 4 columns.
- The nineteen-digit and seventeen-digit tokens match the file from first digit to last.
- Number on ledger_ref blocks the 19-digit value and the zero-padded value, counts the 15-digit ledger as 1 numeric cell, and still blocks download. Number on tracking_id blocks all three rows for more than 15 significant digits.
Synthetic IDs only. Already-shortened exponent strings are covered in the scientific-notation guide.
Open the matching tool →Long digit IDs are not safe Excel numbers
Order IDs, tracking numbers, ledger references and bank-like teaching tokens often exceed fifteen significant digits. Excel’s numeric type cannot store every digit exactly; the grid may show scientific notation and permanently drop the tail. This page focuses on long identifiers that look like integers. For exponent strings already containing E, use the companion scientific notation guide.
record_id,ledger_ref,tracking_id,note R-01,1000000000000001234,12345678901234567,nineteen and seventeen digits R-02,100000000000000,9876543210987654,fifteen and sixteen digits R-03,0004411223344556677,4411223344556677,leading zeros on a long token
All values are synthetic teaching data. They are not account numbers or government identifiers. The third row also carries leading zeros so you can see two injuries at once: padding loss and precision loss.
Download /samples/long-ids.csv, or load “Long digit IDs” from the tool sample pack. After Preview, preflight flags 16+ digit tokens and leading zeros. Those rows are a warning to keep Text, not a conversion of the values.
Before and after: formula bar versus the grid
Opened as General, a typical grid shows something like:
record_id ledger_ref tracking_id note R-01 1.00000E+18 1.23457E+16 nineteen and seventeen digits R-02 100000000000000 9.87654E+15 fifteen and sixteen digits R-03 4.41122E+15 4411223344556677 leading zeros on a long token
The start of the number looks familiar; the tail is gone. Widening the column or applying 0 decimal places does not grow digits back. A text-preserving XLSX keeps the source characters, including the nineteen-digit ledger_ref and the zero-padded third-row token.
| Token | Digits | Number export |
|---|---|---|
1000000000000001234 | 19 | Blocked — more than 15 significant digits |
12345678901234567 | 17 | Blocked — more than 15 significant digits |
9876543210987654 | 16 | Blocked — more than 15 significant digits |
100000000000000 | 15 | Accepted as a number, still an identifier — keep Text |
0004411223344556677 | 19 with zeros | Blocked — leading zeros would be lost |
Fifteen significant digits is the conservative ceiling this tool uses, matching Excel’s documented numeric precision limit. Passing that check does not mean the field is a quantity. 100000000000000 would be a legal Number cell and still the wrong type for a ledger reference.
Preserve the full token
- Use the original CSV from the order or warehouse system, not a workbook that already rounded the ID.
- Load it in CSV to Excel with Comma and a header, or load the long-ids sample pack entry.
- Preview. Compare ledger_ref and tracking_id from the first digit to the last, not only the first screenful.
- Keep identifier columns on Text. If you mark Number, values longer than fifteen significant digits block the download in this tool—that block is intentional.
- Download XLSX. The file name uses a
-convertedsuffix so it does not replace the source CSV. Re-open and check the formula bar on the nineteen-digit value.
Step-by-step troubleshooting
- Preview already shows 1.23E+16. The CSV stored an exponent string. This tool will keep that string as text; it cannot expand it back into digits. Re-export. See scientific notation.
- Number on ledger_ref blocks download. Read the numeric error list: it names the source record and the reason (leading zeros or more than 15 significant digits). Switch the column to Text.
- Barcode scan does not match the spreadsheet. Compare the full token, not a rounded display. If the CSV still has every digit, convert with Text. If the CSV already lost the tail, only the source system can restore it.
- Some rows are 15 digits and some are 17. Keep the whole column as Text. Do not mark Number “for the short rows.”
- The ID also has leading zeros. That is two numeric injuries. Keep Text; see Keep leading zeros.
Why widening the column is not enough
Column width only helps values that are still stored completely. A float that already rounded the seventeenth digit will not grow those digits back when you stretch the column. A display format with zero decimals shows a rounded integer of the stored float, not the original token. Treat any ID that must match a barcode scan or payment reference as text from the first import.
TableMender defaults to Text and refuses unsafe Number exports for over-long digit strings. It cannot expand an ID that an earlier workbook already shortened.
Honest limits
The tool does not validate check digits, IBAN structure, or carrier tracking formats. It does not pad to a guessed width. It does not claim that every destination database can store a 19-digit integer; it only claims that the XLSX text cell will contain the same characters as the CSV field. CSV export still has no column types: the receiving spreadsheet can convert the file again unless you import as text.
Edge cases
Fifteen-digit tokens can still display in scientific notation in a narrow Excel column even when precision remains. Prefer Text whenever the field is an identifier. Mixed columns that contain both quantities and long IDs should stay Text, or be split before conversion. Matching tool: CSV to Excel.
FAQ grounded in the converter
Why block Number instead of rounding? Silent rounding is how these IDs die. The block names the record so you can keep Text.
Does two-decimal display help? No. Two-decimal format is for amounts you explicitly mark as Number. It does not store extra integer digits.
What if the ID has letters? Letter-number tokens are already unsafe as Number and fail the plain-decimal check. SKU-style codes are covered in SKU codes.
Number export on long-ids.csv
Load long-ids.csv in CSV to Excel with Comma and a header. The preview has 3 data records and 4 columns. The header is source record 1. Set one identifier column to Number and read the list. The status line can count a numeric cell and still block the download. Reset the column to Text before you download.
| Column set to Number | What the list shows |
|---|---|
| ledger_ref | Source record 2, 1000000000000001234: More than 15 significant digits. Source record 4, 0004411223344556677: Leading zeros would be lost. Source record 3, 100000000000000, is counted as 1 numeric cell and is still an identifier. 2 values need attention. Download stays blocked. |
| tracking_id | Source records 2, 3 and 4: More than 15 significant digits. The tokens are 17, 16 and 16 digits and do not start with zero, so this is the precision guard. 0 numeric cells. |
The 15-digit ledger is inside the same column as a 19-digit token and a zero-padded token. Marking the column Number because one cell would pass still blocks the file. Keep the whole column on Text.
What preflight counts on long-ids.csv
After Preview, the identifier row warns: leading zeros in column 2 (1 cell, the padded ledger on R-03) and 16+ digit tokens in columns 2 and 3 (5 cells). The 15-digit ledger is not in that 16+ list. The how-to link is this page. The file contains no exponent text, so the link does not open the scientific notation guide. If your CSV already stores 1.23457E+16, that guide is the right page, and this sample will not grow the missing digits back.
The formula-like row stays clear. There is no fully blank data record and no exact whole-row duplicate. A clear duplicate check does not make a 19-digit token safe as an Excel number.
Sources:
Examples are original teaching data. Tool-specific behavior describes this version of TableMender; software interfaces can vary by version.