Why does my saved search formula column say "ERROR: Field Not Found" instead of a value?

Because the search succeeded. A field token in a Results formula failed to resolve, and instead of raising anything NetSuite put the literal 22-character string ERROR: Field Not Found in the column, on every row, as its value. It is data, not an exception.

Nothing else in the search reports a problem. No exception is thrown, the search reports success, and nothing in its status, row count or execution indicates a failure.

Minimal reproduction

Put an unresolvable token in a Results formula. Any token that does not resolve will do, including a deliberate nonsense one:

Results column, Formula(Text) = {zzznosuchrootfield}

The search runs. Every row comes back populated with:

ERROR: Field Not Found

Now the part that makes this dangerous rather than merely annoying. The same token in a numeric column behaves the same way:

Formula(Numeric) = {zzznosuchrootfield}                 -> ERROR: Field Not Found
Formula(Numeric) = NVL({zzznosuchrootfield},0) + 100    -> ERROR: Field Not Found
Formula(Numeric) = {zzznosuchrootfield}   [Sum]         -> ERROR: Field Not Found
Formula(Numeric) = 1                      [Sum]         -> a number, control behaves normally

A Formula(Numeric) column returning text. Not zero, not null, not an exception. And it survives aggregation: the SUM total of that column is itself the string, so a report whose bottom line should be a number has a sentence in it instead.

NVL does not rescue it

The second line above is the one people get wrong. NVL(...,0) protects against a null value, and there is no null here. The field name never resolves, so the whole expression is replaced by the error string before the arithmetic is even considered. The + 100 never happens. Anyone reasoning "I wrapped it in NVL, so at worst I get 0" is protected against a different problem from the one they have.

Where it actually costs you

The result set looks fine on screen, so the damage lands downstream. A CSV export, a scheduled email, or a SuiteScript reading that column receives text where it expects a number. In a spreadsheet the cell reads ERROR: Field Not Found, and a SUM() over that column silently skips it and produces a total that is too low, with no #VALUE! anywhere to warn the person reading it.

The Criteria side would have caught it

The same typo in a Criteria formula is rejected instantly and loudly, with INVALID_FORMULA_FIELD and a message telling you a field is unrecognised. Same expression, same search, opposite behaviour depending on which box you typed it into.

The cost asymmetry is measurable. In this run the criteria rejection came back in roughly a quarter of a second, because the search was refused at parse time and never executed. The valid criteria searches took a second or two. The results-formula versions took four to five seconds each: a full scan, paid in full, ending in bad data.

So there is a usable trick here. Before you trust a Results formula, paste the same expression into a Criteria formula once and see whether NetSuite accepts it. The Criteria side is the only one of the two that validates field names, and using it as a spellchecker costs you one cheap search.

It only reaches so far. The Criteria dropdown offers three formula types, Date, Numeric and Text, where Results offers seven. A Formula(Currency), Formula(Percent), Formula(Date/Time) or Formula(HTML) expression has no Criteria equivalent to paste into, so retype it as Formula(Text) for the check and put it back afterwards.

How to tell if you are affected

Scan the output, not the screen. Export the search to CSV and search the file for the string ERROR. It is a clean test because the string is exact, it is 22 characters, and a healthy formula column never contains it. Do the same on any column your scripts or spreadsheets read from a scheduled search.

If you find it, the fix is the token, not the formula logic. In this run the tokens that failed were plausible-looking join paths, and the string is emitted identically for a deliberate nonsense field and for a nearly-correct one, so the output will not tell you which of the two you have.

Scope: one sandbox account on NetSuite 2026.1, Administrator role. These searches were built and run ad hoc through the SuiteScript search engine (nlapiCreateSearch / runSearch), without saving anything, so what is described here is the behaviour of the search engine itself rather than of the saved search form.