What does "An nlobjSearchColumn contains an invalid column summary type" mean on a formula column?

It means you have put Sum or Average on a Formula(Text) column. The message names the offending pair at the end, so the fix is usually visible in the error itself.

SSS_INVALID_SRCH_COLUMN_SUM
An nlobjSearchColumn contains an invalid column summary type, or is not in proper syntax: formulatext: SUM.

The Average variant is identical apart from the last token:

SSS_INVALID_SRCH_COLUMN_SUM
An nlobjSearchColumn contains an invalid column summary type, or is not in proper syntax: formulatext: AVG.

Read the part after the colon as <column type>: <summary type>. That pair is the whole diagnosis.

Minimal reproduction

Two formula columns, each run under all six summary types on the same transaction search. Twelve combinations, ten of which run.

                Formula(Text)   Formula(Numeric)
Group           accepted        accepted
Sum             REJECTED        accepted
Count           accepted        accepted
Minimum         accepted        accepted
Maximum         accepted        accepted
Average         REJECTED        accepted

The two rejections are correct. You cannot add up strings, and both come back as an error object with the code above rather than as a result set with something odd in it.

The fix

Decide which half of the pair is wrong.

If the value is genuinely numeric and you typed it into the wrong kind of column, change the column type to Formula(Numeric) and leave the summary alone. All six summary types are accepted there.

If the value is genuinely text, change the summary to Group or Count, keeping in mind that Count on a text formula returns the number of distinct strings the formula produces and not a number of rows.

If what you were actually trying to do was count rows, neither column belongs in the search: use a Formula(Numeric) column containing 1 with summary Sum.

The combination that should have been rejected and was not

Minimum and Maximum on a Formula(Text) column are accepted, and they return a lexicographic result. With this formula in the column:

CASE WHEN {quantity} > 0 THEN 'pos' ELSE 'other' END

Minimum returned other and Maximum returned pos. Not the smallest or largest quantity, not the most or least common bucket. Alphabetical order, o before p, computed over strings.

That is legitimate SQL and it is a loaded gun in a report. Maximum of a text status column returns whichever status sorts last alphabetically, which has no business meaning whatsoever and looks exactly like a real answer. Sum and Average at least fail loudly. Min and Max on text fail silently, which makes them the more expensive of the two behaviours by a wide margin.

Neither carries a warning, and nothing in the name of the summary type distinguishes the ones that are meaningful for a text formula from the ones that merely execute.

How to tell if you are affected

Two different checks, because the two problems have opposite symptoms.

The rejection is loud, so you already know about it: the search does not run, and the error names the pair.

The lexicographic one is silent, so it has to be hunted. Go through your saved searches for Formula(Text) columns with a Minimum or Maximum summary, and for each one ask what the alphabetically last value of that expression is. If the answer is not the value the column claims to report, the column has been quietly wrong since it was built. The same check applies to plain text fields under Min or Max, though this run only exercised formula columns.

Scope: one sandbox account on NetSuite 2026.1, Administrator role, transaction record type. All twelve combinations were built and run ad hoc through the SuiteScript search engine (nlapiCreateSearch / runSearch) with nothing saved. Two formula column types were tried, Text and Numeric, against the six summary types listed above; Formula(Date), Formula(Currency) and Formula(Percent) columns were not put through the same grid, so this page says nothing about what they accept.