Why does my Formula (Numeric) column return 39 decimal places?

Because Formula (Numeric) does not round. It hands back the raw Oracle NUMBER exactly as the division produced it, and that raw value is what lands in a CSV export or in a SuiteScript variable. There is no display precision applied on the way out.

Minimal reproduction

Put the constant 1/3 in a Results column, once as Formula (Numeric) and once as Formula (Currency):

expression 1/3
  Formula (Numeric)  -> .333333333333333333333333333333333333333
  Formula (Currency) -> .333

Thirty-nine threes.

Because the expression is a constant, the account's data plays no part in either result.

Formula (Currency) is not the fix

This is the part that costs people an afternoon. The obvious move on seeing 39 digits is to switch the column to Formula (Currency) and assume it gives two decimal places. It does not do that reliably.

expression 1/3        Formula (Currency) -> .333
expression 0.98765    Formula (Currency) -> .988
expression -1234.5    Formula (Currency) -> -1234.50

Two expressions rounded to three decimal places, and .98765 rounded up rather than truncating. A third, -1234.5, came back padded to two. Read together, Currency looks like it rounds to at most three places while padding up to a minimum of two, but all three readings came from the same account within minutes of each other, so the honest description is inconsistent formatting rather than a stable rule. Do not build a report on it and do not tell a finance user that a Currency column gives them cents.

No thousands separators anywhere

1234567.891 stays 1234567.891 under Formula (Numeric) and under Formula (Currency) alike. No grouping, at any magnitude tested. If a column needs to read as money for a human, the formula field type will not do that for you either.

The fix

Round in the expression and stop caring what the field type does:

ROUND({amountpaid} / {amount}, 2)

Then the precision is fixed before the field type ever sees it, and Currency's inconsistency stops mattering. This is the recommendation the run itself records, but the run measured the three field types, not the workaround, so ROUND here rests on it being ordinary Oracle arithmetic in the same expression slot rather than on a probe.

The reason to fix it in the expression rather than in the consumer is the export. A Numeric column carrying 39 decimal places reaches a CSV with all of them, and reaches a script variable the same way. Anything that parses, compares or writes that value back is dealing with the full precision whether or not the screen made it look otherwise.

The third type does something else entirely

Formula (Percent) is not a formatting variant of these two. It multiplies the value by 100 and appends a literal %, so an expression that already computes a percentage comes out a hundred times too large. That has its own page in this section.

How to tell if you are affected

Add a Formula (Numeric) column with 1/3 in it to any saved search you already have and look at the result. If it prints a long tail of threes, you have the behaviour described here, which as of this run is simply what the field type does.

Then check where your numbers go. A column that only ever gets read on screen is a cosmetic annoyance. A column exported to CSV, consumed by a scheduled script, or compared against a figure from another system is a correctness problem, because equality checks against a value with 39 decimal places do not go the way anybody expects.

Scope: one sandbox account on NetSuite 2026.1, Administrator role. The searches were built and run ad hoc through the SuiteScript search engine, nlapiCreateSearch and runSearch, without saving anything. Every value quoted above is arithmetic on constants, so none of it depends on the data in that account, but it is one version of NetSuite and four expressions, and the Currency behaviour in particular was inconsistent across those four.