Rules reference
A rule is a set of conditions and a set of actions. When every condition matches, every action is applied. Rules run after extraction and before the invoice reaches a human queue, so they decide what a reviewer or approver is handed rather than what happens afterwards.
This page is the exact vocabulary. If you want to write your first one instead, start with your first coding rule.
Condition fields and their operators
Each field understands only the operators listed against it. The builder offers no others, and a rule that names a pairing outside this table is refused when you save it rather than stored and quietly never fired.
| Field | Operators | Matches against |
|---|---|---|
| Source email | is, contains | The full sender address, for example invoices@theircompany.com |
| Vendor | is, contains, is not mapped | The vendor name read off the invoice |
| Amount | is, is greater than, is less than | The invoice total, compared as a number |
| Keyword in document | contains | The subject line the invoice arrived under |
| Property alias | is, contains | The property hint read off the invoice, or the subject |
| Intake mailbox | is, contains | The intake address the mail arrived at, for example lakeshore@acme.inlet-ap.com |
Matching the intake mailbox
Intake mailbox is the receiving side of the conversation, where Source email is the sending side. It exists so that a mailbox you handed to one building's vendors can drive coding, and it is most useful with contains and the local part alone:
Intake mailbox contains "lakeshore@"
Written that way, the rule survives a change of intake subdomain, which writing out the full address does not.
You often do not need a rule at all. A mailbox created with a property already codes mail arriving there to that property when the invoice names nothing recognizable — see per-property mailboxes. Reach for a rule when the mailbox should also set a GL code, assign a reviewer, or apply to a subset of the mail arriving there.
Text comparisons are case-insensitive and ignore surrounding whitespace, so ACME Corp and acme corp are the same value.
Amount is compared as a number. A value that is not a number is refused on save, because a non-numeric amount compares as false against every operator — which produces a rule that looks correct in the list and never matches anything.
is not mapped takes no value. It is true when the invoice's vendor does not match a vendor in your workspace, which makes it the condition for "somebody new is billing us".
Why there is no domain field
To match a whole vendor domain, use Source email contains @theircompany.com.
Source email contains @theircompany.com
There is deliberately no separate domain field. The address already contains the domain, so a domain field would be a second field meaning almost the same thing, and every rule author would then have to guess which one they wanted. The leading @ is what makes the test exact: without it, theircompany.com would also match billing@nottheircompany.com.example.
The rule vocabulary is short on purpose. Every field and operator here has a matching branch in the evaluator, and nothing has a branch in the evaluator that is not here. A dropdown offering an operator the evaluator cannot execute is worse than a missing feature, because the rule saves cleanly and then does nothing at all.
How conditions combine
All conditions must match. There is no OR, and there is no nesting.
Where you want an OR, write two rules. This is more typing and it makes each rule readable on its own, which matters when somebody asks in six months why a particular invoice was coded the way it was.
Actions
| Action | What it does |
|---|---|
| Set coding | Writes a GL account onto the document, recorded as coming from a rule rather than from the page. An action with no account in it is ignored. |
| Assign reviewer | Assigns the document to a named member of your workspace. If the name matches nobody in the workspace, the document is left unassigned rather than handed to a stranger with a similar name. |
| Auto-approve | Moves the document to ready for approval without waiting on the confidence threshold. |
| Quarantine | Puts the document on a security hold and sends a notification naming the rule that did it. |
Auto-approval is opt-in and bounded by whatever conditions you set. A common first version is "a mapped vendor, under a small amount, from a known address" — narrow enough that you would have approved every one of them by hand anyway.
Every action is recorded in the audit trail with the rule that caused it, which is the part that makes auto-approval defensible rather than merely convenient.
Priority and ordering
Rules have a priority number and run in ascending order: 1 before 50, 50 before the default of 100. Rules that share a priority run oldest first.
Every rule that matches is applied, not only the first. Two rules that both set a GL account will both run, and the later one wins, so ordering is how you express "the general case, unless".
One action stops the sequence: quarantine. When a quarantine rule matches, no further rule is evaluated for that document. A document being held for a security reason should not also be coded, assigned and auto-approved on its way into the hold.
Each rule keeps a count of how many documents it has matched. A rule with a match count of zero after a busy month is usually a rule whose conditions are narrower than its author believed.
Disabling rather than deleting
A rule can be switched off and left in place. The match count and the audit history survive, which is worth more than a tidy list when you are working out what changed.
Who may write rules
Reading rules is open to everyone in the workspace. Creating, editing and deleting them is restricted to an Admin or a Controller Approver, and the API enforces that independently of what the interface shows. See roles and permissions.
The rules engine is part of a paid plan. On the free plan the rest of the pipeline runs normally — intake, extraction, review, approval and export all work — and rule writing is the thing you upgrade for.
Where to go next
- Your first coding rule — a worked example from a real invoice.
- Coding invoices — what the fields a rule writes actually mean.
- Invoice statuses — where a quarantine or an auto-approval leaves a document.
- Roles and permissions — who is allowed to change any of this.