NetSuite 2026.2: The SuiteQL Default Sort Change That May Already Be Affecting Your Queries
Need help with this in your NetSuite account?
SuiteQL is NetSuite's SQL-based query language that provides direct, structured access to the NetSuite data model, used in saved searches, REST API queries, and SuiteScript integrations. Without an explicit ORDER BY clause, SuiteQL results are returned in an implementation-defined order that can change between platform releases.
If your SuiteQL queries against transaction records started returning results in a different order after the 2026.2 update, this is why.
Quick answer
NetSuite changed the default sort order for SuiteQL queries against transaction records in 2026.2. Queries that previously returned results sorted by tranDisplayName when no ORDER BY clause was specified now return results sorted by tranDate. Any SuiteQL query or integration that relied on the previous implicit ordering without an explicit ORDER BY will receive results in a different sequence after the update. The practical impact affects reports, exports, and integrations that expected a document-number sort and compare results across periods. Queries that already include an explicit ORDER BY clause are not affected. Organizations running SuiteScript, scheduled integrations, or custom reports that query the transaction table should audit for queries without an explicit ORDER BY before 2026.2 reaches Production, particularly for any output used in reconciliation workflows or compared against prior-period data. The affected execution paths include query.runSuiteQL() and query.runSuiteQLPaged() in SuiteScript 2.x, and the REST API endpoint at /services/rest/query/v1/suiteql.
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 the SuiteQL Default Sort in NetSuite 2026.2?
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 Does the SuiteQL Sort Change Matter?
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.
How Do You Identify SuiteQL Queries Affected by This Change?
Any SuiteQL query that meets all three of these criteria is potentially affected:
- It queries the
transactiontable or a table that joins totransaction - It does not include an
ORDER BYclause - 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
getInputDataphase - 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.
What Is the Fix for the SuiteQL Sort Change?
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 ASCChoose 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 ONLYWithout 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 Can SuitePacific Help With the SuiteQL Sort Change?
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.
For help identifying and updating affected SuiteQL queries in your scripts, see SuitePacific's NetSuite SuiteScript development service.
More From the Blog
How to Switch from NetSuite ACS to a Managed Support Firm
Already decided to leave ACS? This guide covers the transition: auditing your current contract, documenting your account, timing the handoff, finding a replacement, and what to expect in the first 30 days with a managed support firm.
NetSuite ACS Tiers Explained: What Advise, Monitor, Optimize, and Architect Actually Cover
A tier-by-tier breakdown of NetSuite Advanced Customer Support: what each ACS tier includes in practice, what none of them cover, who each tier is designed for, and when upgrading a tier solves a problem versus when the issue is ACS scope.
Have a NetSuite challenge like this?
We work with post-go-live NetSuite accounts every day. Tell us what you're working on.