Cross-Validation Rules Examples
Cross-Validation Rule Examples
Every company maintains accounting controls that are documented in spreadsheets, email reminders, and month-end review checklists. Cross-Validation Rules move those controls into NetSuite, catching errors at the point of entry rather than during close.
The examples below illustrate common ways companies use Cross-Validation Rules to enforce accounting policies, maintain data integrity, and reduce manual review cycles. Specific accounts, segments, and thresholds will differ by environment, but the control patterns these examples demonstrate can be adapted to most NetSuite configurations.
For foundational information on how Filters and Requirements work, refer to the Cross-Validation Rules Overview article before working through these examples.
1. Require Segments on All Revenue Transactions
When any revenue account (Account Type = Income) appears on a transaction, require that Department, Class, and any applicable Custom Segment fields are populated on the relevant lines.
This can be taken further by requiring specific field values depending on context. For example, if the account is Services Revenue, the rule can require that the transaction be coded to the Services Department, the Accessories or Hardware Class, and Custom Segment ABC.
Why it's helpful: Ensures complete tracking by business unit and segment for accurate P&L reporting. Finance teams can run departmental performance reports with confidence that revenue is properly attributed, and missing segment data is caught at entry rather than corrected after the fact.
Example configuration:
- Filter: Account Type (Line) | Equal | Income
- Requirement: Department | Cannot Be | Empty
- Requirement: Class | Cannot Be | Empty
2. Block AP Account Transactions Without Vendor
Prevent posting of any transaction that includes an Accounts Payable account unless a Vendor is specified on the transaction header.
Why it's helpful: Eliminates orphaned AP balances that cannot be matched to vendor statements and prevents cash application errors. This rule catches manual journal entries that should have been processed as vendor bills, maintaining the integrity of the AP subledger.
Example configuration:
- Filter: Account | Any Of | [Accounts Payable accounts]
- Requirement: Entity | Must Be | Not Empty
3. Require Journal with Depreciation Expense to Credit Accumulated Depreciation
When any depreciation expense account is debited on a Journal Entry, require a corresponding credit to the related accumulated depreciation account. Multiple GL accounts can be selected to cover all applicable depreciation expense accounts.
Why it's helpful: Enforces proper fixed asset accounting by preventing depreciation from posting to the wrong contra-asset or P&L account. This control ensures the balance sheet relationship between asset accounts and accumulated depreciation remains accurate and audit-ready.
Example configuration:
- Filter: Account Debit (Line) | Any Of | [Depreciation Expense accounts]
- Requirement: Account Credit (Line) | Must Be | Equal | [Accumulated Depreciation account]
4. Restrict Direct Posting to Control Accounts
Block users from posting transactions directly to control accounts — such as AR Summary, AP Summary, or Inventory Asset — unless they hold the Controller or Administrator role.
Why it's helpful: Protects subledger integrity by ensuring transactions flow through the correct transaction types (invoices for AR, bills for AP) rather than manual journal entries. When control accounts are updated only through system-generated postings, subledger reconciliations are significantly simplified.
Example configuration:
- Filter: Account | Any Of | [Control accounts]
- Requirement: Role | Must Be | Any Of | Controller, Administrator
5. Require Project for Operating Expense Above Threshold
When an operating expense account has a line amount exceeding $5,000, require that a Project or Customer is specified on that line.
Why it's helpful: Ensures significant expenses are traceable to specific initiatives or clients without creating friction on routine, low-value transactions. Finance teams gain visibility into where large expenditures are allocated while keeping standard expense entry efficient.
Example configuration:
- Filter: Account Type | Equal | Expense
- Filter: Amount | Greater Than | 5000
- Requirement: Project | Cannot Be | Empty
6. Require Class on All Transactions for Multi-Entity Reporting
When a transaction involves subsidiaries in specific countries or regions — identified through a custom field — require that Class is populated on every transaction line.
Why it's helpful: Supports matrix reporting requirements where financials must be analyzed by both legal entity (subsidiary) and business line (class). Missing class values on multi-entity transactions create gaps in management reporting that are difficult to correct retroactively.
Example configuration:
- Filter: Subsidiary | Any Of | [Applicable subsidiaries]
- Requirement: Class | Cannot Be | Empty
7. Block Negative Line Amounts on Vendor Bills
Prevent vendor bills from being saved if any expense line contains a negative amount. Users must create a Vendor Credit instead.
Why it's helpful: Enforces correct transaction type usage, which keeps AP aging accurate and prevents vendor payment runs from selecting incorrect records. Vendor Credits flow through the system differently than negative bill lines, particularly for 1099 reporting and vendor statement reconciliation.
Example configuration:
- Transaction Type: Vendor Bill
- Requirement: Amount | Cannot Be | Less Than | 0
8. Require Both Subsidiaries on Intercompany Transactions
For transactions involving intercompany receivable or payable accounts, require that one of the approved Intercompany Representing Vendors or Customers is populated on the transaction.
Why it's helpful: Prevents unbalanced intercompany eliminations during consolidation and ensures every intercompany transaction has a clearly identified counterparty. This eliminates ambiguity around which subsidiary an intercompany balance belongs to when performing close procedures.
Example configuration:
- Filter: Account | Any Of | [Intercompany receivable/payable accounts]
- Requirement: Entity | Must Be | Any Of | [Approved intercompany vendors or customers]
9. Require Entity on COGS Transactions
When any cost of goods sold account (Account Type = Cost of Goods Sold) appears on a transaction, require that an Entity is populated on each COGS line.
Why it's helpful: Ensures every COGS entry is traceable to a specific vendor, employee, or other counterparty, preventing unattributed cost entries that obscure margin analysis. The most common application is requiring a Vendor on COGS lines to confirm that costs are tied to a supplier relationship, making it easier to reconcile cost activity against purchase orders and vendor statements.
Example configuration:
- Filter: Account Type (Line) | Equal | Cost of Goods Sold
- Requirement: Entity | Cannot Be | Empty
10. Prevent Invoicing Restricted Customers
Prevent invoices from being saved when the customer on the transaction matches a defined list of restricted customers — such as accounts on credit hold, accounts with disputed balances, or accounts pending contract execution.
Why it's helpful: Reduces revenue recognition risk and billing errors by enforcing a review gate before an invoice reaches a customer who should not be billed. Rather than relying on individual team members to identify restricted accounts, the rule enforces the control automatically at save time. Consider using the Detect action if the goal is to flag exceptions for review rather than block invoicing entirely.
Example configuration:
- Transaction Type: Invoice
- Requirement: Entity | Cannot Be | Any Of | [Restricted customer list]
