Use standard saved-search criteria to define the records included in a calculation, and summary criteria to select groups based on their calculated results. In NetSuite, those are different decisions. Filtering out small transactions before summing them can produce a different customer list from summing all eligible transactions and then applying a customer-level threshold.
Start with the business sentence, including its grouping and threshold. “Customers whose eligible monthly invoices total more than 10,000” is a group-level question. “Invoices greater than 10,000” is a transaction-level question. The two searches should not be expected to return the same result.
Population rules establish the eligible facts: transaction type, posting status where relevant, date or period, subsidiary and business exclusions. Apply them before deciding which customer, vendor, item or other group passes a threshold.
Group-selection rules use a defined summary operation such as Sum, Count, Average, Minimum or Maximum. The field and summary type used in summary criteria should match the corresponding summarized result. A count of lines answers a different question from a count of transactions or customers.
Write both layers in the specification. For example: include eligible invoices dated in the selected month, group by customer identity, sum the approved invoice amount and retain customers above the agreed threshold. Also state whether credit memos belong in the measure, because net sales and gross invoices are different populations.
A summary search inherits any errors in its detail rows. If an invoice amount repeats after a join, Sum can preserve the duplication. If several order lines share one order ID, a simple row count can overstate the number of orders.
Inspect a detailed diagnostic view before adding group thresholds. Confirm the identifiers, amount signs, currency basis and exclusions. Include records on both sides of the threshold, plus one exactly at it, so the distinction between greater than and greater than or equal to is visible.
Avoid grouping solely by display names where distinct records could share them. Use a supported identity for the grouping design and a readable label for presentation. A renamed customer should not unexpectedly become a second business identity in historical comparisons.
Assume an invoice-level population in one currency with no credits or additional adjustments. Customer A has two eligible invoices of 6,000 each. Customer B has one invoice of 11,000. Customer C has two invoices of 5,000 each.
The requirement is to show customers whose eligible invoice total is greater than 10,000. With all eligible invoices included, A totals 12,000 and B totals 11,000. Both pass. C totals exactly 10,000 and does not pass the strict greater-than rule.
If the author instead adds a standard criterion requiring each invoice amount to exceed 10,000, both of A's invoices disappear before aggregation. Only B remains. The selected customer total becomes 11,000 instead of the intended 23,000.
Changing the threshold to greater than or equal to 10,000 adds C and produces an intended selected total of 33,000. This is a business-rule change, not a rounding fix. The requester should approve the boundary explicitly.
| Business question | Standard population | Summary decision |
|---|---|---|
| Customers over a monthly sales threshold | Eligible sales documents for the month | Sum by customer exceeds threshold |
| Vendors with several overdue bills | Defined overdue bill population | Count by vendor reaches limit |
| Items with unusually high average discount | Eligible item sales and discount basis | Average or weighted measure exceeds policy |
| Groups containing any old exception | Eligible unresolved records | Oldest date passes the age boundary |
| Customers with both sales and returns | Clearly classified transaction population | Tested grouped conditions establish both categories |
The table is a design checklist, not a universal saved-search configuration. Weighted measures, multiple conditions and distinct counts can require additional modeling or another reporting route. Confirm that the selected interface supports the intended operation before promising one search will do everything.
The summary page shows summarized fields. Detailed fields can be inspected through supported drilldown, but the user needs to understand what that detail represents. A customer passing the total threshold can legitimately have many individual invoices below it.
Choose a drilldown that makes the arithmetic reproducible. Include the base identity, date, amount and the fields that explain eligibility. If the group total includes credits, the detail should expose them rather than presenting only positive documents.
Test subtotal and grand-total interpretation. The grand total of selected groups is not necessarily the total for all eligible records before the summary filter. Label the output so a manager does not mistake a high-value exception population for company-wide sales.
Where the summary is exported, verify whether the consumer receives grouped rows, detail rows or another output form. Do not infer export structure from the on-screen appearance alone.
NetSuite's custom KPI calculations do not support summary search filters in the same way as grouped saved-search results. A saved search using summary criteria can therefore produce a KPI value that differs from the saved-search result.
Do not resolve that mismatch by changing a correct business threshold until the KPI looks right. Determine whether the dashboard needs a different supported search design or another presentation. Preserve the original grouped measure for the users who rely on it.
For a KPI handoff, write down the desired unit: number of qualifying customers, total value of their invoices, or proportion of the whole population. These are three different measures even when they originate from the same exception definition.
The dashboard owner should approve the final implementation using a known sample. A title that matches the search title is not evidence that the two calculations are identical.
Summary filters using multi-select related records or related multi-select fields have a documented duplication limitation. If the design depends on that combination, retain a specific test and assess alternatives rather than claiming that grouping automatically resolves it.
A related-record filter can also narrow the detail population in a way the requester did not intend. For example, filtering to one child status before calculating a customer total means the total represents only that status. Decide whether the requirement concerns all eligible customer activity or only the selected related subset.
Keep every exclusion explainable in business terms. If an analyst cannot say why a detail row belongs in the group, the summary threshold is being applied to an unstable definition.
Save a compact acceptance pack with the population criteria, group identity, summary operation, threshold operator and expected qualifying groups. Include a below-threshold case, exact-threshold case, above-threshold case and a group with multiple smaller contributing records.
Repeat the pack after changes to joins, formulas, date ranges or downstream dashboards. Check both qualifying identities and their amounts. Two offsetting classification errors can leave the grand total unchanged while selecting the wrong customers.
For account-specific summary behavior, bring that proof pack to CuriousRubik's NetSuite support services. It gives the reviewer a precise outcome to validate without relying on a screenshot of an unexplained total.
Use it when the threshold applies to a calculated group, such as total eligible invoices per customer. Standard criteria should first define which underlying records contribute to that group.
A standard amount filter may have removed them before aggregation. If the requirement concerns the customer's combined amount, retain all eligible invoices and apply the approved threshold to the grouped sum.
Do not assume so. Custom KPI calculations do not support summary search filters in the same way as grouped results. Validate the desired dashboard measure separately and choose a supported design.
Only if the search definition actually represents all company sales. A summary threshold usually selects a subset of groups. Its grand total represents that selected population and should be labeled accordingly.
Include a group that qualifies only because several individually small records add up to the threshold. Add exact-boundary, below-boundary and above-boundary groups to prove both the aggregation and comparison operator.