Use NetSuite's Main Line search criterion to choose the transaction row population before calculating a total. A transaction-level question usually starts with main-line results; an item-level question needs transaction lines and explicit treatment of other line types. Confirm the result with identifiable transactions before adding joins or summary formulas.
The important exception is journal entries: the Main Line filter does not work for transaction searches whose type is Journal Entry. A financial search containing journals therefore needs its own accounting-line validation. A single Main Line rule is not a universal recipe for every transaction type.
Write the required grain in the search description. Examples include one row per invoice, one row per invoice item line, or one row per posting account impact. These populations can share a document number while answering different questions.
An invoice count should count invoices. A product-sales analysis should retain the relevant item lines. An account reconciliation needs the posting population approved by finance. Begin with that decision rather than changing Main Line until a displayed total happens to look familiar.
Keep an internal transaction identifier in the investigation output. Document numbers are useful to readers, but they are insufficient as universal unique keys. At line level, also retain a supported line identifier and establish what makes it unique within the selected search. A repeated item can legitimately appear on two different lines of the same order.
With Main Line set to Yes, a basic transaction search returns transaction-level rows and omits item detail. With No, it returns line rows, which can still contain information from the transaction header. Without the criterion, both populations may appear.
A repeated header attribute is often harmless. A repeated header amount becomes dangerous when someone sums it as though it belongs independently to every line. Label the amount basis and inspect the result values rather than assuming that any column named Amount is suitable for the chosen grain.
The distinction between Account and Account (Main) also matters. The main account on an invoice can be receivables, while its item lines point to different accounts. Choosing a convenient account column without understanding that distinction can change the apparent purpose of the search.
| Reporting question | Starting population | Evidence to retain |
|---|---|---|
| How many invoices were issued | Transaction rows for the chosen invoice type | Distinct transaction IDs and a known invoice list |
| Which products were sold | Eligible item lines | Transaction and line identity, item and quantity |
| Which amount belongs to an account | Defined posting population | Account, debit or credit basis and GL comparison |
| Which journal lines need review | Separately validated journal population | Journal identity, account lines and balanced entry evidence |
| Which orders have multiple fulfillments | Order or line population with controlled related records | Before-and-after join counts |
This is a design aid. It does not specify an account's complete criteria. Tax, shipping, cost-of-goods-sold, discount and other special lines need decisions appropriate to the measure and enabled features.
For example, excluding tax may be correct for a net-sales measure but wrong for a receivable total. Save the reason for every exclusion so another analyst does not reuse a product-sales search as a customer-balance report.
Consider two simplified invoices in one currency, with no tax, shipping, discounts or additional posting complications. Invoice A contains item lines of 120 and 80, totaling 200. Invoice B contains one item line of 150. The intended invoice total is 350.
The transaction view should identify two invoices with a combined value of 350. The eligible item-line view should identify three lines, also totaling 350 under these deliberately simple assumptions. If an analyst sums a hypothetical mixed output containing both the two header totals and three line amounts, the result becomes 700.
Now suppose Invoice A also has tax of 20. Its receivable amount becomes 220 while its net item sales remain 200. A 20 difference between the appropriate header and item populations is then explainable. Forcing the two views to match by changing filters would destroy the distinction the reader needs.
The example demonstrates an expected-result method, not an executed account test. Actual amount signs and included rows must be checked for the relevant transaction and search fields.
First copy the definition through an approved development process so the live consumer is protected. Restrict the diagnostic search to a small list of known transactions. Include at least one multi-line document and one legitimate exception.
Remove related-record fields from the diagnostic copy and inspect the native transaction population. Add identifiers, type, Main Line indication where available, account, item and the exact measure being investigated. Establish the expected row count manually from the source records.
Next add special-line criteria one at a time. Record which identities and amounts each criterion removes. This provides evidence that an exclusion is intentional rather than a workaround that hides an unexplained difference.
Only then restore related-record fields. A sales-team, payment, fulfillment or other one-to-many join can expand the output even when the initial transaction grain was correct. Main Line is not a general deduplication control for every joined relationship.
Where journals are needed, identify their role in the report. An invoice-sales analysis and an account-movement analysis may require different treatment. Finance should decide whether journals belong in the metric before the search author selects criteria.
Use a known journal with more than two lines, and a second example involving any relevant book or subsidiary complexity. Confirm the accounts, posting amounts and unique identities. Do not expect a Main Line toggle to turn a journal into a single financial row.
If separate searches are combined downstream, define how their populations remain disjoint. A journal total and an invoice total should not overlap through an overly broad second search. Retain the transaction type in the combined evidence so that unexpected additions remain visible.
A search may supply a dashboard, email, spreadsheet or integration. Confirm whether the consumer expects one transaction or one line per row. A correct change from header to detail can still break a process that assumes unique transaction IDs.
Review summary settings after the detail population is accepted. Grouping repeated rows does not necessarily repair repeated money: a Sum can preserve the overstatement, while a Maximum can hide legitimate variation. Select the aggregation only after the measure's grain is established.
Record the intended user role, subsidiary restrictions and currency basis with the test result. These details make a later comparison reproducible. Bring the smallest failing transaction sample to CuriousRubik's NetSuite support services when account-specific search behavior needs investigation.
It defines the transaction-level starting population for supported transaction searches. Related-record joins can still affect the output. Validate distinct transaction IDs after adding joined fields instead of treating Main Line as a universal duplicate-removal setting.
Line results can include header information alongside their own fields. That is useful for context, but repeated header amounts must not be summed as independent line measures. Confirm the meaning of the specific amount column.
No. It does not work when the transaction search type is Journal Entry. Establish and test the required journal-accounting population separately, including its accounts, posting amounts and relevant book context.
No. Their treatment depends on the question. A net item-sales measure may exclude them, while an invoice balance may require them. Document the measure and prove the exclusions against known transactions.
Only if the grouping and aggregation correctly represent the underlying measure. Grouping can conceal repeated rows while a Sum still repeats money. Diagnose row grain and joins before choosing a summary operation.