Cross-Validation Rules Creating New Rules
Overview
Cross-Validation Rules let you enforce your company's accounting policies at the point of transaction entry. This article walks through creating a new rule and explains each part of the rule record — Main Information, Filters, and Requirements — along with the transaction types that are not currently supported.
Watch the video below for a walkthrough on how to create a Cross-Validation Rule end to end.
To create Cross-Validation Rules, a user needs to fill out the three aspects of each rule: Main Information, Filters, and Requirements. Each of these is explained below.
Main Information
This section explains how the rule should behave. Below is an explanation of each field.
| Field | Description | Example |
| Name | The name you want to give the CVR. | Marketing Spend |
| Transaction Type | The NetSuite Transaction Types that you want the rule to apply to. For a list of unsupported transaction types, please see the end of this article. | Journal, Vendor Bill, Invoice |
| Status | If the rule is in effect or not. | Active |
| Action | The two options are Prevent or Detect. If Prevent is selected, then Cross-Validation Rules will prevent a transaction from posting by throwing an error when a user tries to save it. The values you entered are retained on the transaction when the save is blocked, so you can correct the flagged field and save again without rebuilding the transaction from scratch. If Detect is selected, then Cross-Validation Rules will allow the transaction to post, log the transaction in a report of violating transactions, and display a warning on the transaction after it is saved. | Prevent |
| Description | A description of the rule. | This rule will prevent a Vendor Bill with the Department: Marketing if the Vendor is not one of our marketing-related suppliers. |
| Error Message | This is the message that a user will see when the CVR prevents or detects a rule violation. The Name of the rule will be appended at the end of the Error Message with a hyperlink to the CVR. The Error Message is optional. If you leave it blank, Cross-Validation Rules generates a default message from the rule's fields and conditions — stated in plain language using field labels and condition names — so the user still sees a readable explanation of what the rule requires. | You cannot post a Vendor Bill with the Department: Marketing to that Vendor because they are not marketing related. |
Filters
A Cross-Validation Rule can have as many filters as a company needs. When a CVR has more than one filter, a transaction must meet all the filters to be evaluated; if a transaction only meets some of the filters on a CVR then it will not be evaluated for the CVR requirements. CVR filters have three fields: Field, Operator, and Value.
| Field | Description | Example |
| Field | This is the transaction field that the filter Operator and Value will relate to. | User, Account, Amount, Department |
| Operator | This is the method by which the Value is considered on the specific Field. | Equal, Not Equal, Includes, Any of, Greater Than |
| Value | This is the Value that the Field must match or not match to qualify for the filter. | John Smith, 1000 Checking, $1000 |
Requirements
Cross-Validation Rule Requirements are what the user is trying to enforce or prevent on a transaction. When a user tries to create a transaction, the Cross-Validation Rule script will first evaluate if it meets any CVR filters. If the CVR finds that the transaction does qualify for certain filters, then the transaction will be evaluated against the CVR requirements. If the transaction passes the requirement, it will be allowed to post; if it fails then it will fail to post or be added to the Cross-Validation Rule Report. CVR Requirements have the following fields: Field, Enforcement Direction, Operator, Value, Require All, & Apply to Filtered Lines Only.
| Field | Description | Example |
| Field | The transaction field you want the CVR to evaluate. | Amount, Account Type, Role, Custom Segment |
| Enforcement Direction | This is whether the value on the transaction must be or cannot be a specific value based on the CVR. | Must Be or Cannot Be |
| Operator | This is the method by which the Value is considered on the specific Field. | Equal, Not Equal, Includes, Any of, Greater Than |
| Value | This is the Value that the Field must be or cannot be to pass the requirement. | $-10000, AP Clerk, Cost of Goods Sold |
| Require All | When Require All is on, the transaction must pass through all the requirements to post. When Require All is off, the transaction must pass through at least one requirement to post. | Requirements: -Entity must be Amazon -Activity Code must be D Require All On: Must have Amazon AND D. Require All Off: Must have Amazon OR D. |
| Apply to Filtered Lines Only | When enabled, requirements will only be evaluated against lines that match the line-level filters. For debit requirements, all debit lines are checked. For credit requirements, all credit lines are checked. | Filter: Account equals Accounts Payable Requirement: Entity cannot be Empty Enabled: Only the Accounts Payable line must have the Entity filled out. Not Enabled: All lines on the transaction must have the Entity filled out. Please note that Tax Lines that are automatically created by NetSuite cannot be evaluated by Cross-Validation Rules. |
Account Hierarchy Operators
The Account, Account (Debit), and Account (Credit) fields support two operators that match an account by its position in your chart of accounts rather than by an exact ID: equal or subaccount of and not equal or subaccount of. These are available on both Filters and Requirements (Must Be and Cannot Be), and on any custom field that is sourced from Account.
The operator's Value is a multi-select of parent accounts. Select one parent for a single subtree, or several to match under any of them.
| Operator | A line's account matches when... |
| equal or subaccount of | The account is one of the selected accounts, or any account beneath a selected account in the hierarchy, at any depth. |
| not equal or subaccount of | The account is neither a selected account nor beneath any selected account. Consistent with other negative operators, a line with no account also satisfies this operator. |
The parent account is included, and new subaccounts are covered automatically.
The selected parent account itself is part of the match set, not just its children — NetSuite allows posting directly to a header account. Descendants are resolved each time a transaction is validated, so a subaccount created after the rule is saved is matched without editing the rule.
For example, a Filter of Account (Debit) equal or subaccount of 6000 Operating Expenses evaluates every transaction that debits 6000 or any account beneath it, including accounts added later. Pairing this with a Requirement keeps a whole branch of the chart of accounts under one policy without maintaining an account list.
Unsupported Transaction Types
The following transaction types are not currently supported by CVR.
- Customer Deposit (coming soon)
- Commission
- Bin Worksheet
- Intercompany Transfer Order
- Inventory Adjustment
- Inventory Cost Revaluation
- Inventory Transfer
- Inventory Worksheet
- Item Receipt
- Item Fulfillment
- Estimate
- Transfer Order
- Assembly Build
- Assembly Unbuild
- Work Order
- Work Order Close
- Work Order Completion
- Work Order Issue
- FX Reval
- Tax Liability Payment Legacy
- Deposit Application
- Transfer
- Vendor Prepayment Application
- Netting Settlement
- Custom Transaction NTA Alloc Journal
- Cash Refund
- Vendor Return Authorization
- Return Authorization
