The Rejections page on the Trading party specific tab: the expanded PO 2 rule group shows the information icon next to its title because only one of its two rules is enabled, and the PO group below it is fully disabled and shown in grey text

Rejection Rules are conditional guardrails that automatically block documents from progressing through the approval workflow when they violate defined criteria. They form the third layer of Docupath's business rules system - operating after Instruction Builds (which guide extraction) and Transformations (which reshape data).

Rejection Rules are deterministic: if a condition evaluates to true, the document is rejected with a logged reason. They do not correct data or infer intent - they simply enforce compliance boundaries by preventing non-conforming documents from reaching approval.

Rejection Rules evaluate documents after AI extraction and after Transformation Rules have been applied. This means rejection conditions are evaluated against the final, transformed values - not the raw extraction output. If a rejection condition is triggered, the document is immediately moved to Rejected status with a required reason, and it exits the approval flow.

To create a rejection rule:

Once deleted, the rule no longer applies to documents processed under that scope.

A rejection rule group can be disabled without being deleted, either as a whole or one sub-rule at a time. Only enabled rules are evaluated when a document is processed; a disabled rule stays configured but is skipped entirely, so it cannot reject a document while it is off.

On the Rejections list:

The Title column is the first column in the list and can be sorted, so groups can be found by name before toggling them.

Each rule also carries its own switch on the create and edit screens, so a rule can be saved in a disabled state and switched on later once it has been reviewed. This is useful for staging a strict rejection rule before it starts blocking documents.

Switch changes take effect in the interface immediately and are saved after you stop toggling. If a save fails, the group reverts to its last saved state and an error message appears.

Rules created before this capability existed are enabled by default, so existing rejection behavior is unchanged until a rule is explicitly switched off.

When the AI generates a rejection rule, the output is composed of:

Users do not typically need to edit the generated rules manually, but they can be modified directly if needed.

Rejection Rules can be configured at multiple scopes. When multiple rules could apply, the most specific scope takes precedence:

Rejection Rules can reference supporting files (such as CSV lookup tables) to validate field values against approved lists. For example, a rule can reject documents where the cost centre is not found in an approved cost centre list. Supporting files are uploaded to the tenant instance separately and can be linked to a rule during creation by clicking the "Link Supporting File" link. Use the NOT_CONTAINS ("Does not contain") operator for this: it rejects or flags only when the field genuinely does not contain any value from the linked list, while its counterpart CONTAINS matches when the field does contain a listed value.

Rejection Rules are strictly deterministic - they evaluate conditions and either reject or pass the document. They do not modify data, infer corrections, or apply partial rejections. This predictability is a design choice that ensures rejection outcomes are auditable and unambiguous.

Each generated rule shows a short, automatically generated title in its header, next to its position number - for example, Rule 1 : PO Number is empty. The title is derived from the rule's own content, so you can identify a rule at a glance instead of reading it by position alone. It is separate from the Title you enter for the rule group as a whole.

A rejection rule's title is built from its first condition, read as a plain-language phrase (<Field> <operator> <value>) with the operator spelled out in words:

The IS_NULL and IS_NOT_NULL operators take no value, so their titles end at the operator (for example, PO Number is empty). A value that references a supporting-file column reads as column "<Column>", and field paths are shown as plain text (for example, Buyer Name).

When a rule has more than one condition, the title describes the first condition and appends +N more to stand for the rest. If the first condition cannot be phrased, the title falls back to the rule's rejection reason (which is required), so a title is normally always available. The header falls back to just the position number (with no title) only in the rare case of an incomplete rule with neither a usable condition nor a reason.

Note: a rule group simply refers to a single Rejection Rule, as a Rejection Rule can be composed of multiple sub-rules.