Numbers or identifiers changed in the CSV
Inspect the saved value and compare it with the original before changing precision or number formatting.
- Text became a date (General imports)
- An item-defined cost contains currency formatting (Item records)
- The journal reports Rounding Error (Journal entries)
- The journal's debits and credits do not balance (Journal entries, Single Journal Entry import, Intercompany journal entries)
- A value was saved in exponent notation (General imports)
- The bill amount is not valid numeric text (Vendor bills)
Text became a date
Message looks like
Oracle does not publish one exact wording for this case. Match it by the situation described below.
What it means
The saved value no longer matches the source, a spreadsheet symptom: text such as a part number was silently converted to a date or a number.
Import context: General imports.
Check this first
Compare the saved CSV value with the original export before changing anything in NetSuite.
Show the steps
Check the number that was actually saved
- Open the saved CSV as text and locate the affected value.
- Compare it with the original export when one is available. Compare numeric values precisely, not just the displayed number of decimals.
- Check whether the column is an amount, quantity, rate, or identifier. Identifiers must keep their original characters, including leading zeros.
- Match number formatting to the import's decimal settings. Check currency symbols, grouping separators, and exponent notation where relevant.
- Restore lost digits from the original source. Adding decimal places to a rounded value does not recover them.
- Inspect the final CSV after saving it again.
Excel can export the value as displayed when saving CSV. That makes the saved file the final check, even when the formula bar previously showed more precision. Microsoft CSV export guidance
For quantities, compare the same units and the same stock balance. For amounts, identify which field owns the calculation before changing a number. Do not balance a journal or inventory adjustment by inserting an arbitrary difference. Keep debit, credit, rate, quantity, and precision findings separate.
Documentation checked September 16, 2026.
An item-defined cost contains currency formatting
Message looks like
You have entered an Invalid Field Value for [CostEstimate]
What it means
The item defined cost was rejected even though the number is right, usually because the value carries a currency symbol the field does not accept.
Import context: Item records.
Check this first
Remove currency symbols from the cost column and set the field's currency format to none on the mapping page.
Show the steps
Steps for this error
- Remove currency symbols from the cost column. The field stores the amount without a symbol.
- On the Field Mapping page, open the Item Defined Cost field’s format options and set Currency with Symbol to None.
- Retry one item.
Documentation checked September 16, 2026.
The journal reports Rounding Error
Message looks like
Rounding Error xx.xx
What it means
The journal's debits and credits stop matching after rounding, usually hidden extra decimals from the original export or 0.00 values entered on the opposite side of lines.
Import context: Journal entries.
Check this first
Check line amounts for extra decimal places and correct them at the source rather than adding a balancing line.
Show the steps
Steps for this error
- Total one journal using the complete saved decimal values for Debit and Credit.
- Remove unintended zero values from the opposite amount column and inspect spreadsheet rounding.
- Correct the source amounts and retry the whole journal; do not add an unexplained balancing line.
Documentation checked September 16, 2026.
The journal's debits and credits do not balance
Check each journal separately. If the amounts already balance, check which lines reach NetSuite, then try the documented line-order workaround.
Message looks like
The amounts in a journal entry must balance.
What it means
NetSuite is trying to save a journal whose debit and credit totals do not match. The numbers may be wrong, or the import may not be bringing the expected lines together.
A balanced total for the whole CSV is not enough when the file contains several journals. Each journal must balance on its own.
For example, one journal with debits of 110 and credits of 100 and another with debits of 90 and credits of 100 are both unbalanced. The combined 200 on each side does not make either journal valid.
Import context: Journal entries, including the Single Journal Entry import. Intercompany and advanced intercompany journals have their own requirements; the standard-journal line-order workaround is not an established fix for them.
Check this first
Take one failed journal and compare its debit and credit totals using the values saved in the CSV. Check that every line belongs to the intended journal and that both amount columns are mapped correctly.
Show the steps
Check one journal and its imported lines
- Identify the lines for one journal. For a file containing several journals, use the same identifier and mapping that the import uses to group them. Check for missing or inconsistent identifiers.
- Total that journal's debits and credits separately. Include every intended line and inspect the full saved amounts, not just rounded spreadsheet displays.
- On Field Mapping, confirm that Debit maps to the journal line's Debit field and Credit maps to its Credit field. Check that a mapping default is not supplying a different amount.
- Inspect the saved CSV for missing amounts, shifted columns, or values that the spreadsheet total treated as text. Compare suspect values with the source before changing them.
- Check for missing lines, duplicated lines, and spreadsheet total rows. Keep calculation rows outside the import data.
- If the amounts, grouping, and mappings check out, try the line-order steps below on a copy of the failed journal.
For imports containing several journals, Oracle documents transaction identifiers on every row. The dedicated Single Journal Entry import handles one journal, so do not add a multi-journal identifier requirement to that workflow. Journal CSV structure
The amounts balance, but NetSuite still rejects the journal
SuiteAnswers Answer 70365 describes a case where the values are valid and the journal balances, but the order of the debit and credit lines causes the import to fail. Its suggested workaround is to keep each side together.
- Make a copy of the failed journal's import data.
- Move complete rows so the debit lines come first, followed by the credit lines, within that journal.
- Keep every account, amount, memo, and other field attached to its original line. Do not sort the Debit or Credit column by itself.
- Recheck the totals and save the CSV.
- Retry that journal and check the import result.
For example, a journal arranged as debit 60, credit 100, debit 40 can be rearranged as follows without changing an amount:
| Journal identifier | Account | Debit | Credit |
|---|---|---|---|
| JE-EXAMPLE-01 | Expense A | 60 | |
| JE-EXAMPLE-01 | Expense B | 40 | |
| JE-EXAMPLE-01 | Accrual account | 100 |
The names and identifier above are illustrative. Use your actual account references and mapping. For a batch, keep each journal's rows together; do not move all debit rows in the entire file ahead of all credit rows.
This is a workaround for an otherwise balanced file. Reordering cannot fix unequal totals or an incorrect mapping. Do not change amounts or add a balancing line just to make the error disappear.
If you are updating an existing journal
Check how the imported lines will affect the saved journal. Oracle documents that journal line imports using Update append lines unless the sublist is replaced. The resulting journal must balance; do not assume that a CSV line will replace a particular existing line.
Replacing the sublist requires the complete intended set of lines and a deliberate review of the replacement settings. It is not a routine fix for this error. Oracle also notes that updating a journal applied as a payment can remove that payment application. The Single Journal Entry Import Assistant does not support updates. Journal update behavior
If that looks right
Keep the failed journal, its complete error, and the import mapping together for review. If an error also identifies a script, investigate what that script changes before the journal is saved. The balance message alone does not identify a script as the cause.
Intercompany and advanced intercompany journals
For an intercompany or advanced intercompany journal, use the requirements for that journal type. Do not assume that the standard-journal line-order workaround explains its failure.
Still stuck?
We can help compare the journal, the CSV, and the import mapping to find where the two sides stop matching.
Read Oracle's supporting guidance
The line-order workaround comes from user-supplied SuiteAnswers Answer 70365 (last updated 06/01/2026; NetSuite 2026.1). No authenticated SuiteAnswers page was accessed. The public Oracle pages support the balance, grouping, numeric-value and update checks, not the line-order workaround. No client CSV was examined and no import was run for this addition.
- Journal balance requirement
- Journal Entry CSV Files
- Using Journal Entry Import for Updates
- Journal Entry Import Errors
Documentation checked September 16, 2026.
A value was saved in exponent notation
Message looks like
Oracle does not publish one exact wording for this case. Match it by the situation described below.
What it means
A long number was saved in exponent notation, such as 1.23E+15, so the identifier no longer matches anything.
Import context: General imports.
Check this first
Format the column as text and compare the saved value with the original before importing again.
Show the steps
Steps for this error
- Open the saved CSV in a text editor and find the value written in exponent notation.
- Restore the original identifier or number from its source and preserve it as text before saving.
- Reopen the CSV to confirm the literal value, then retry one row.
Documentation checked September 16, 2026.
The bill amount is not valid numeric text
Message looks like
You have entered an invalid field value for the following field: amount
What it means
The amount is not plain numeric text: a thousands separator or a currency symbol is riding along in the column.
Import context: Vendor bills.
Check this first
Strip separators and symbols so the Amount column holds bare numbers only.
Show the steps
Steps for this error
- Check the Amount column for thousands separators or currency symbols.
- Save plain numbers and retry one bill.
Documentation checked September 16, 2026.
Related errors
- Check saved numeric values
- Check record grouping and file links
- The journal's debits and credits do not balance (Journal entries, Single Journal Entry import, Intercompany journal entries)
- The journal reports Rounding Error (Journal entries)
- A totals row asks for Account (Journal entries)
Book a free 30-minute look at your import error
Bring the error and your file to a screen share and I will dig into it live. Thirty minutes is usually enough to find what is wrong and tell you what fixing it takes. Sometimes that settles it on the call; when it does not, you leave with a straight answer instead of a mystery. No cost and no obligation.
An import that keeps failing is often the first visible sign of a larger setup problem. Most of my client work starts exactly here: somebody mid-import, a file that will not load, and nobody on their side to email. If a migration or implementation sits behind this error, that is the work I do every week.