Practical guide

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

  1. The preview has 3 data records and 4 columns.
  2. The nineteen-digit and seventeen-digit tokens match the file from first digit to last.
  3. 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.

What this converter accepts as Number on the teaching file
TokenDigitsNumber export
100000000000000123419Blocked — more than 15 significant digits
1234567890123456717Blocked — more than 15 significant digits
987654321098765416Blocked — more than 15 significant digits
10000000000000015Accepted as a number, still an identifier — keep Text
000441122334455667719 with zerosBlocked — 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

  1. Use the original CSV from the order or warehouse system, not a workbook that already rounded the ID.
  2. Load it in CSV to Excel with Comma and a header, or load the long-ids sample pack entry.
  3. Preview. Compare ledger_ref and tracking_id from the first digit to the last, not only the first screenful.
  4. 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.
  5. Download XLSX. The file name uses a -converted suffix so it does not replace the source CSV. Re-open and check the formula bar on the nineteen-digit value.

Keep long IDs as text →

Step-by-step troubleshooting

  1. 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.
  2. 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.
  3. 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.
  4. Some rows are 15 digits and some are 17. Keep the whole column as Text. Do not mark Number “for the short rows.”
  5. 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.

ledger_ref and tracking_id set to Number
Column set to NumberWhat the list shows
ledger_refSource 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_idSource 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.

← All guides