Why does {type} return "Opportunity" but {type.id} returns "Opprtnty"?

Because they are different things. {field} returns the display name, the human-readable string a user sees on the record. {field.id} returns the internal code, the machine token NetSuite stores. Both are correct, neither is a formatting of the other, and a literal written for one will never match the other.

The transaction type pair is the cleanest demonstration, because transaction types are stock NetSuite values rather than anything account-specific:

Formula(Text) = {type}       -> "Opportunity"      "Journal"
Formula(Text) = {type.id}    -> "Opprtnty"         "Journal"

Same row, same field, two different strings. Journal happens to be identical in both, which is exactly the kind of coincidence that lets a broken assumption survive testing.

There is no {field.name}

The third guess is the one that hurts:

Formula(Text) = {entity.name}   -> every row returns the string "ERROR: Field Not Found"

{field.name} does not exist on these fields. It does not raise an error either. The column fills with that literal string on every row while the search reports success, which is its own failure mode. So of the three spellings, two work and return different values, and the third returns text that looks like an error and is treated as data.

The two engines have opposite defaults

This is the part that costs real time.

{type.id} returning Opprtnty is exactly what SuiteQL's transaction.type column returns for the same field. SuiteQL gives you the code by default. A saved search formula gives you the label by default. The same logical field, opposite defaults, in two engines that people routinely move work between.

So a CASE statement, a filter list or a mapping table copied out of a SuiteQL query and pasted into a saved search formula compares codes against labels, matches nothing, and reports zero rows without complaining. Copied the other way, it does the same. The SuiteQL half of this is written up separately in why SuiteQL returns CustInvc instead of Invoice.

The defaults are the trap. Once you know which side you are on, both engines can give you either form.

Exports carry the display name

A CSV export from a saved search results page carries the display side. In a summary export grouped by transaction type, the type column read Bill, Invoice, Credit Memo and so on, not the codes VendBill, CustInvc, CustCred that SuiteQL returns for the same field.

That matters when a saved search export feeds a script or a warehouse load that was written against SuiteQL output. The two files describe the same rows and share no vocabulary in that column.

It is not only transaction type

The same split showed up on status. For {status}, the display value and the .id code differed in length on every row sampled, which rules out the comfortable theory that the code is an occasional alias for the display name. On both list fields tested they are genuinely separate tokens, not a quirk of one field.

The status values themselves are left out here, because status codes differ by record type and by account and a pair copied from one account is no use in another. The transaction type pair above makes the same point with values NetSuite ships to everybody.

How to tell if you are affected

Add both forms as columns and read them side by side:

Formula(Text) = {type}
Formula(Text) = {type.id}

If your criteria, your CASE branches or your downstream mapping use the values from one column while your formula emits the other, the search is silently selecting or bucketing nothing. The fast audit is to look for any hard-coded string in a formula that contains a space. No transaction type code in this run's output contains one, and many display names do.

Scope: one sandbox account on NetSuite 2026.1, Administrator role. The formula probes were built and run ad hoc through the SuiteScript search engine (nlapiCreateSearch / runSearch) without saving anything; the export observation is UI-driven, taken from the Export - CSV button on a saved search results page. Two field types were examined, a record-reference field and list fields.