Book a Free Consultation
Back to blog
SuiteQLRelease NotesSuiteScript2026.2

NetSuite 2026.2: The SuiteQL Default Sort Change That May Already Be Affecting Your Queries

August 2, 2026 · 7 min read

Need help with this in your NetSuite account?

If your SuiteQL queries against transaction records started returning results in a different order after the 2026.2 update, this is why.

NetSuite changed the default sort order for transaction queries in 2026.2. Queries that previously returned results sorted by tranDisplayName now return results sorted by tranDate. Any query that does not include an explicit ORDER BY clause is subject to this change.

Running SuiteScript or integrations that query NetSuite transactions and not certain whether your queries are affected? SuitePacific reviews SuiteScript implementations and can identify queries that need explicit sort order before they cause issues in your live environment. Contact us.

What changed

In previous releases, a SuiteQL query against the transaction table without an ORDER BY clause would return results ordered by tranDisplayName by default. The tranDisplayName field is a display-formatted string that combines the record type and document number, for example "Invoice #1042" or "Bill #0318."

In 2026.2, the default sort order changed to tranDate. Queries without an explicit ORDER BY now return results ordered by the transaction date instead.

This is not a change to the SuiteQL language itself. It is a change to the underlying default behavior when no sort is specified.

Why this matters

A query that returns results in a different order is a silent change. There is no error, no warning, and no indication in the query itself that anything has changed. The query runs successfully; the results just come back in a different sequence.

This creates problems in several common patterns:

Scripts that process transactions in sequence

If a scheduled script or Map/Reduce script queries transactions and processes them in the order returned, the processing sequence has changed. A script that was previously processing invoices in document-number order is now processing them in date order. Depending on what the script does, this can produce different outputs, different cumulative totals, or different record linkages.

Reports and exports that assumed a stable order

If a SuiteScript export, RESTlet response, or integration feed relies on SuiteQL to retrieve transaction data and sends it downstream without an explicit sort, the downstream system is now receiving records in a different order. This can cause mismatches with systems that expect a specific sequence.

Pagination in paged queries

If a query uses OFFSET and FETCH NEXT for pagination without an explicit ORDER BY, the page boundaries are no longer stable. Records can shift between pages as the default sort changes, which means a paged query may skip records or return duplicates across pages.

Before 2026.2 Default sort: tranDisplayName tranDisplayName tranDate Bill #0318 2026-06-14 Invoice #1001 2026-05-02 Invoice #1042 2026-07-01 Invoice #1099 2026-04-18 Journal #0044 2026-07-15 Alphabetical by display name After 2026.2 Default sort: tranDate tranDisplayName tranDate Invoice #1099 2026-04-18 Invoice #1001 2026-05-02 Bill #0318 2026-06-14 Invoice #1042 2026-07-01 Journal #0044 2026-07-15 Chronological by transaction date
Same query, same records, different order. Without ORDER BY, the result sequence changed in 2026.2.

How to identify affected queries

Any SuiteQL query that meets all three of these criteria is potentially affected:

  1. It queries the transaction table or a table that joins to transaction
  2. It does not include an ORDER BY clause
  3. The script, integration, or report that uses it depends on the order of results in any way

Dependency on result order is not always obvious. A script that iterates through results and writes each one to a log is order-dependent. A script that sums values is not. Review each query in context, not just in isolation.

Where to look:

  • Scheduled scripts that process transaction records
  • Map/Reduce scripts that use SuiteQL in the getInputData phase
  • RESTlets that query and return transaction data
  • Integrations that call the NetSuite REST API using SuiteQL
  • SuiteAnalytics Workbook queries that feed into external systems

Search your codebase for FROM transaction and FROM transactionLine as a starting point. Any query that uses these tables without ORDER BY is a candidate for review.

The fix

Add an explicit ORDER BY clause to every SuiteQL query that operates on transaction data. This removes the dependency on default sort behavior and makes the query deterministic regardless of how the default changes in future releases.

Before (relies on default sort):

SELECT id, tranId, tranDate, tranDisplayName, amount
FROM transaction
WHERE type = 'Invoice'
AND tranDate >= '2026-07-01'

After (explicit sort):

SELECT id, tranId, tranDate, tranDisplayName, amount
FROM transaction
WHERE type = 'Invoice'
AND tranDate >= '2026-07-01'
ORDER BY tranDate ASC

Choose the sort column that matches the intent of the query. If the script was designed to process transactions in chronological order, use ORDER BY tranDate ASC. If it was designed to process them in document-number order, use ORDER BY tranId ASC. If it is used for display purposes and the previous alphabetical order was intentional, ORDER BY tranDisplayName ASC restores it explicitly.

For paged queries, an explicit sort is especially important:

SELECT id, tranId, tranDate
FROM transaction
WHERE type = 'VendBill'
ORDER BY tranDate ASC
OFFSET 0 FETCH NEXT 1000 ROWS ONLY

Without ORDER BY on a paged query, different pages may return overlapping or skipped records if the underlying default sort shifts between requests.

Frequently asked questions

Does this affect all SuiteQL queries or only transaction queries? The change specifically affects the default sort behavior for transaction record queries. Non-transaction queries may have their own default sort behavior. Regardless of record type, adding explicit ORDER BY to any query that depends on result order is the correct practice.

My query has been running without ORDER BY for years. Is it definitely affected? If your query hits transaction records and the order of results matters, yes. The order may have changed silently in 2026.2. The safest action is to add an explicit ORDER BY and verify the results match your expectations.

Does this affect the N/search module as well? No. The change applies to SuiteQL queries using the N/query module, the REST API, and SuiteAnalytics Workbook. The N/search module uses a different query mechanism and is not affected by this specific change.

Where is this documented? The SuiteQL behavior change is included in the NetSuite 2026.2 release notes. Review the SuiteQL section of the release notes for the complete details.

How SuitePacific can help

Auditing SuiteScript implementations for implicit sort dependencies, particularly across scheduled and Map/Reduce scripts that process large transaction volumes, is the kind of technical review that prevents production issues before they appear.

If your NetSuite account recently upgraded to 2026.2 and you want to verify that your SuiteQL queries are not affected by this change, contact SuitePacific. We can review your scripts and identify any queries that need an explicit sort order added.

Have a NetSuite challenge like this?

We work with post-go-live NetSuite accounts every day. Tell us what you're working on.