NetSuite Saved Searches vs. SuiteQL vs. Reports: Which Approach Do You Need?
A practical decision guide for live NetSuite accounts choosing the right tool for custom reporting and dashboards.
Building custom reports in NetSuite and hitting limits? Tell us what your account needs to show.
NetSuite-Certified · Post-go-live specialist · Sandbox-first development · Month-to-month
Quick answer
NetSuite provides three distinct reporting approaches, each suited to different needs. Standard reports are pre-built financial statements such as Trial Balance, Income Statement, Balance Sheet, AR Aging, and AP Aging. They require no configuration but offer limited customization and no custom columns beyond standard filters. Saved searches are the primary tool for custom operational reporting in NetSuite. They require no code, support formula columns, filters, joins across related record types, and can be embedded as dashboard portlets. They cover the large majority of custom reporting requirements in live accounts. SuiteQL is a SQL-like query language that provides full join flexibility and complex calculations across multiple tables. It is required when saved search join depth limits are reached, such as when a WIP report must join projects, transactions, budgets, and invoices simultaneously. SuiteQL requires a developer to write and maintain. Most construction companies need saved searches for day-to-day dashboards and SuiteQL for complex financial reports.
How do the three approaches compare?
The right tool depends on the complexity of joins required, whether a developer is available to maintain code, and how the output will be consumed.
| Capability | Standard Reports | Saved Search | SuiteQL |
|---|---|---|---|
| Setup method | Pre-built, no config | UI-based, no code | Developer-written SQL |
| Custom columns/formulas | None beyond filters | Yes, formula columns | Full calculation control |
| Dashboard embedding | No | Yes, as portlets | Via Suitelet or portlet |
| Workflow conditions | No | Yes | No |
| Multi-table joins | Limited | Join depth limited | Full join flexibility |
| Real-time updates | Yes | Yes | Yes |
| Developer required | No | No | Yes |
| Edition availability | All editions | All editions | All editions |
| Maintenance burden | None | Low | Higher (code ownership) |
When should you use a saved search?
Saved searches handle the vast majority of custom reporting needs in a live NetSuite account without any code. They are the right starting point for nearly every operational report.
Operational dashboards
Portlets showing open purchase orders, vendor bills by project, subcontractor payment status, or job cost summaries. Saved searches update in real time and embed directly on role-based dashboards without developer involvement.
Custom record lists
Any list view that needs custom filters, formula columns, or sorting by derived values. Project status lists, lien waiver tracking, or equipment utilization summaries are all practical saved search use cases.
Workflow conditions
SuiteFlow workflows can reference saved searches to evaluate record conditions and route approvals. This is a key capability that SuiteQL cannot replicate; workflows require saved searches for their filter criteria.
When does a report require SuiteQL?
SuiteQL becomes necessary when saved search join depth limits are hit or when the report requires calculations that span multiple unrelated tables. It requires developer involvement to write and maintain.
WIP reports and complex financial schedules
A WIP schedule joins the project record, budget records, all posted transaction types, and invoice history simultaneously. The join depth and cross-table calculation requirements exceed what saved searches support.
Production variance and cost code analysis
Multi-category, multi-project analysis comparing budget to actual across cost codes requires joining transaction lines to budget lines at a level of granularity that saved searches cannot handle cleanly.
When saved search join limits are reached
NetSuite enforces limits on the number of record joins in a saved search. When a report requires more joins than the platform allows, a SuiteQL query is the correct solution.
When are standard reports the right choice?
Standard reports are appropriate for standard financial statements only: Trial Balance, Income Statement, Balance Sheet, AR Aging, AP Aging, and similar pre-built outputs. They require no setup and produce reliable standard output for month-end accounting review.
They are not useful for operational reporting, industry-specific analysis, or any report that requires joining data across record types not covered by the pre-built template. For those needs, saved searches or SuiteQL are the correct tools.
Related reading
- NetSuite WIP report for construction covers the full build for a WIP schedule using saved searches and SuiteQL.
- NetSuite SuiteScript development covers the broader SuiteScript and SuiteQL development work SuitePacific does.
- NetSuite support for construction companies covers the full construction practice including reporting, billing, and job costing.
Frequently Asked Questions
What is the difference between a saved search and a SuiteQL query in NetSuite?
A saved search is a UI-based reporting tool that requires no code. It supports custom filters, formula columns, summary rows, and joins across related record types. SuiteQL is a SQL-like query language that offers full join flexibility and complex calculations but requires a developer to write and maintain. Saved searches cover the large majority of custom reporting needs; SuiteQL is the right tool when join depth limits are reached or when complex multi-table calculations are required.
Can a saved search be used as a dashboard portlet in NetSuite?
Yes. Saved searches can be embedded as portlets on NetSuite role-based dashboards. This allows project managers, finance teams, and executives to see live operational data without navigating to the report each time. Portlets update in real time as new transactions post.
When does a NetSuite report require SuiteQL instead of a saved search?
SuiteQL is required when a report needs joins across more tables than the saved search join depth limit allows. WIP reports, production variance schedules, and complex job cost analyses that join project records, transaction lines, budget records, and invoice history simultaneously typically require SuiteQL. In practice, most operational reports work with saved searches; SuiteQL becomes necessary for complex financial or project accounting reports.
What are NetSuite standard reports and when should I use them?
Standard reports are pre-built financial statements included in all NetSuite editions: Trial Balance, Income Statement, Balance Sheet, AR Aging, AP Aging, and similar. They require no configuration and produce standard accounting output. They are appropriate for standard financial statements but offer limited customization. For any operational, industry-specific, or custom reporting requirement, saved searches or SuiteQL are the correct tools.
Can SuiteQL queries be embedded in a NetSuite dashboard?
SuiteQL results can be surfaced in a dashboard through a custom Suitelet or a saved search wrapper that calls the query. They cannot be embedded directly as dashboard portlets the way a saved search can. For most operational dashboards, saved searches remain the simpler and more maintainable approach.
What kind of custom reporting does SuitePacific build for construction companies?
SuitePacific builds WIP schedules, job cost dashboards, budget vs. actual reports by cost code, and project manager portlets for construction companies already live on NetSuite. This includes both saved search-based reports for day-to-day operational visibility and SuiteQL-based reports for complex financial calculations like WIP, earned value, and over/under billing. Plans start at $799 per month.
Need a custom report built in NetSuite?
Tell us what data the report needs to show and how your account currently tracks costs. We will assess whether a saved search or SuiteQL query is the right approach and how long the build takes.