Business Rules
Business rules validate and normalize the values your project extracts. A validation rule checks a value and raises an error or warning in the Transaction Viewer; a normalization rule rewrites a value into a canonical form (dates, currencies, casing, codes). Rules are how you turn "the model extracted something" into "the data is correct, consistent, and enriched".
You can create rules three ways, from lowest to highest effort:
- Presets (low-code): pick a configurable template and fill in a short form or a visual builder. The code is generated for you and the rule stays editable in the Rule Editor.
- Catalog Lookup (structured): match extracted fields against a reference table (vendors, purchase orders, budget codes) without writing code. See Catalog Lookup Rule.
- Custom code: write JavaScript directly against the scripting API for logic the presets cannot express. See Custom (Script) Rules.
You do not have to build rules by hand at all: the Copilot can create rules for you. Describe what you want ("flag invoices whose line items don't sum to the total", "match each line item against the purchase-order catalog") and it configures the right preset or writes the code, saving it to your draft for review.
Rule levels
Every rule runs at one of three levels, which determines what data it sees:
| Level | Sees | Typical use |
|---|---|---|
| Field | One field value | Format checks, value normalization |
| Document | All fields in one document | Cross-field checks (line items sum to total), catalog lookups |
| Transaction | All documents in a transaction | Cross-document checks (passport matches application) |
Rule types
| Type | When it runs | Purpose |
|---|---|---|
| Normalization | During the Extract step, and on field edits in the Transaction Viewer | Rewrite values to a canonical form |
| Validation | At the Validate step, and on field edits in the Transaction Viewer | Check values and raise errors or warnings |
Field edits in the Viewer re-run only the affected rules (incremental validation), so a reviewer sees results update as they type without a full re-run.
Rule properties
These are set in the rule dialog and handled by the engine, not embedded in the rule's code:
| Property | Default | Description |
|---|---|---|
| Enabled | On | When off, the rule is skipped entirely. |
| Severity | Error | When set to Warning, every error the rule raises is downgraded to a warning after it runs. |
| Confirm fields on success | On | When on, the fields a passing validation rule engaged are auto-confirmed (treated as reviewed). |
| Weight | None | Display ordering only: higher-weight results appear first in the validation panel. |
The severity override is one-directional and applied after the rule runs: Warning turns this rule's errors into warnings, but it never turns warnings into errors. If a rule intentionally mixes errors and warnings, setting it to Warning collapses that distinction (both become warnings); leave it at Error and choose per-condition in code instead.
Preset reference
Presets are grouped by the level they run at. Names below are the labels shown in the "Add Rule" dialog. Anything a preset generates is plain JavaScript you can switch to custom code later.
Field-level presets
| Preset | Type | What it does |
|---|---|---|
| Can't Be Empty | Validation | Requires a non-empty value (whitespace counts as empty). |
| Conditionally Can't Be Empty | Validation | Requires a field only when another field holds a given value. |
| Choice Field Validation | Validation | Checks Choice selections; can require a selection and disallow multiples. |
| Format Validation by Regex | Validation | Validates the value against a regular expression. |
| Allowed Values List | Validation | Requires the value to be one of a predefined list. |
| Number Range | Validation | Requires a number within a min/max range. |
| Date Range | Validation | Requires a date within a relative window from today. |
| Default Value | Normalization | Fills a default when the field is empty. |
| Case Normalization | Normalization | Converts to lower, upper, or title case. |
| Code Normalization | Normalization | Cleans alphanumeric codes (Tax ID, VAT, IBAN, BIC/SWIFT, card numbers). |
| Auto-Replace | Normalization | Applies an ordered list of text replacements. |
| Date Normalization | Normalization | Reformats dates to a chosen component order and separator. |
| Number Normalization | Normalization | Standardizes thousands/decimal separators and decimal places. |
| Currency Code Normalization | Normalization | Maps currency values to ISO 4217 codes (USD, EUR, GBP). |
| Country Code Normalization | Normalization | Maps country names to ISO 3166-1 codes. |
| Populate Field From Metadata | Normalization | Sets the field from a transaction/document metadata key. |
| Validate Field Against Metadata | Validation | Compares the field to a metadata key (exact or fuzzy). |
Document-level presets
| Preset | Type | What it does |
|---|---|---|
| Catalog Lookup | Validation | Matches extracted fields against a reference catalog; can run per line item and pull data back. |
| Compare Fields | Validation | Requires fields, table columns, and constants to match within a document. |
| Cross-Field Date Validation | Validation | Requires one date on or before another, with swap suggestions. |
| Arithmetic Validation | Validation | Checks arithmetic relationships (sum fields, aggregate table columns). |
| Validate Fields Against Metadata | Validation | Compares several fields to metadata keys, each with its own mode. |
| Populate Fields From Metadata | Normalization | Fills many fields from metadata in one rule. |
| Conditional Auto-Replace | Normalization | Text replacements on a field, gated by a run condition. |
Transaction-level presets
| Preset | Type | What it does |
|---|---|---|
| Compare Fields | Validation | Requires fields and table columns to match across document types. |
| Transaction Integrity Check | Validation | Checks document types, counts, page counts, and conditional requirements. |
The metadata-driven presets (Populate/Validate Field(s) From/Against Metadata) compare extracted values against reference data you carry on transaction.metadata or document.metadata. They are the no-code path to the metadata helpers documented in Custom (Script) Rules. Submit reference values (expected vendor, policy flags) alongside the document at upload time, and the rule compares against them.
Wherever a rule asks for a metadata key, the box suggests the keys your project actually uses: those your recent transactions carry, and those your import connectors write (an email connector contributes Subject, From, Received and the rest). You can still type any key by hand. The same suggestions appear in classification conditions and in workflow If/Switch conditions that test a metadata value, and when adding a metadata column.
Where to go next
- Catalog Lookup Rule: match documents against reference tables (vendors, purchase orders), including per line item.
- Custom (Script) Rules: the full JavaScript scripting API, examples for every level, and the sandbox/security model.