Last reviewed: 10 October 2026. Product details reflect this review date. Availability and behavior can vary by account, role and release.
Editorial ink illustration: A colleague compares an item with an invoice and a record on screen.
A saved search can return the right transactions and still produce the wrong answer. The problem often begins when the author expects one row per invoice but the results contain several rows for the same invoice. Counting those rows overstates the invoice count. Adding a repeated invoice total can overstate the amount.
Before choosing columns, finish this sentence: “One result row represents…” The answer might be one invoice, one item line, or another carefully defined unit. This level of detail is sometimes called the grain of the search. You do not need database terminology to use the idea; you need to know what you are counting.
This lesson uses one fictional invoice to make that decision visible. It also explains the Main Line filter’s limits, including the important Journal Entry exception. The examples are simplified teaching models, not promised output from every transaction search.
“How much did we invoice?” and “Which items did we invoice?” can require different result shapes.
An invoice-level review might need an invoice identifier, customer, transaction date, status, and an appropriate invoice-level amount. An item analysis needs the item and a measure associated with that line. Adding item detail to an invoice-level report changes the information you are asking the search to return.
Write the intended use beside the question. A credit controller checking ten unpaid invoices needs different evidence from a sales analyst comparing quantities across items. Even when both begin with invoices, their dates, status filters, amount fields, and level of detail may differ.
A useful starting definition is specific: “One row per invoice in the agreed period, with no joined contact detail.” This is much easier to test than “sales report.” It also makes later additions easier to assess. If someone requests three contact names on each invoice, the team can discuss the effect on row count before changing the search.
For supported transaction searches, Main Line distinguishes transaction-header information from line detail. Setting Main Line to Yes returns the main-line view and excludes item-line detail. Setting it to No returns line-level information; some header information can still appear on those rows.
This is an important control, but it is not a universal duplicate-removal switch. Added joins can introduce their own one-to-many relationships. Line-level work can also require explicit decisions about tax, shipping, accounting detail, and other rows relevant to the selected transaction type and fields.
Journal Entry is an exception. The Main Line filter does not work as described when the transaction type is set to Journal Entry. Do not apply an invoice search recipe to journals and assume the result has the same meaning. Design and reconcile a journal search separately around its accounting lines and the question you need to answer.
For this lesson, keep the test to invoices. Agree with the search owner how the account’s available fields and criteria will isolate the intended invoice or item rows.
Imagine invoice INV-001 has two item lines:
The example deliberately excludes tax, shipping, discounts, credits, and joined-record detail. It uses one currency and no conversion. Those boundaries make the arithmetic easy to inspect.
An invoice-level view represents INV-001 once, with a total of 150. A correctly scoped item-line view represents its two item amounts, 90 and 60. Both can answer useful questions. The first contains one invoice-level result. The second contains two item-line results for the same invoice.
Now imagine a poorly designed export repeats the header total of 150 beside each item. Adding that column produces 300. Nothing about the customer transaction doubled. The report added the same invoice-level measure twice because it was displayed at a finer level of detail.
The correct lesson is not to delete the second row. That row may hold valid item information. Choose a measure that belongs at the result’s level of detail, or use an invoice-level result when that is the question.
A saved search preserves reusable criteria and result definitions. Before making it broadly useful, make it demonstrably correct for a known sample.
Use an authorized training account or an approved read-only investigation. Select one known invoice. Add only the fields needed to identify it and verify the amount or quantity you intend to measure. Apply the Main Line approach appropriate to the intended view, remembering the transaction-type boundary.
Compare the result with the invoice itself. Confirm the identifier, expected number of rows, and the arithmetic. Only then expand the date range or add more customers. This gives you a working reference when a later change creates an unexpected total.
Name the search so its purpose is understandable. “Invoice item amounts for monthly product review” communicates more than “Invoice Report New 2.” Keep a short definition of its scope with the team’s reporting instructions. A colleague should be able to tell what is included without reverse-engineering every criterion.
Related records can enrich a search, but they can also change its shape. Consider a transaction linked to a business that has multiple contacts. If the chosen join returns several matching contact records, one transaction may appear beside each of them. A header-level intention does not remove the need to check that relationship.
After adding a joined field, rerun the same known sample. Compare the row count before and after. Ask whether each new row represents a genuine additional business fact or repeats a measure you planned to sum.
Avoid using grouping merely to make unexpected rows disappear. Grouping can produce a tidy result while preserving an inflated sum. First explain why the rows exist. Then choose the correct detail, filter, measure, or aggregation for the business question.
If your analysis needs more complex relationships, the dataset lesson for SuiteAnalytics Workbook extends the same reasoning to workbook views. Changing tools does not remove the need to understand the underlying rows.
Once the rows are correct, review the boundaries of the population. A transaction-date question may differ from a record-created-date question. A search for open invoices may differ from one for all invoices issued during the month. Neither definition is automatically wrong, but the title and user expectation must match the chosen definition.
Amounts also need a stated currency basis. Do not add values from different currencies simply because they occupy one column. If currency conversion or consolidation is part of the report, identify the method with the finance owner and reconcile a representative example.
A missing invoice calls for a different investigation from a duplicated invoice. Check the record type, period, status, subsidiary or other scope restrictions, and the active role’s access. Change one condition at a time in an appropriate test copy. Removing all criteria can expose unnecessary data and leaves you with little explanation of which condition caused the gap.
Search creation, sharing, and record visibility are related but separate permissions. Public or audience-based sharing options require the appropriate Publish Search permission. Readers still need the relevant record-type permissions. Settings such as Run Unrestricted can change how role restrictions apply, so review those settings and test the intended audience’s actual results. Do not make a search public as a shortcut for resolving an individual’s missing access.
Test the intended reader’s experience using an approved role-based process. Check whether that reader can see the expected records and whether sensitive columns are appropriate for the audience. The roles and permissions review guide helps structure that review.
When a search becomes slow, preserve the known-good sample and investigate the expensive additions systematically. The NetSuite performance investigation guide offers a wider diagnostic method. CuriousRubik’s NetSuite training services can help teams practice these checks using their approved reporting scenarios.
If the total is doubled, inspect repeated measures and joins before changing the underlying invoices. If the row count is unexpectedly high, identify what each row adds. If the amount is correct but the invoice count is wrong, review whether you counted detail rows. If two users get different results, compare their access and search context before blaming the saved definition.
For each problem, retain one small example with an expected answer. Record the search definition change that you tested and the observed result. That evidence is more useful than a screenshot of a large total with no explanation of its inputs.
Before relying on the search, confirm:
A trustworthy search is one whose rows you can explain. Once that foundation is sound, totals and charts become much easier to defend.