Skip to main content

Custom Instructions and Business Logic

How to configure Docupath's business rules layer - the three-part system that governs how documents are interpreted, refined, and validated

Docupath provides three complementary systems that work together to manage how documents are processed, from initial extraction through final output. This "Read → Polish → Guardrail" mental model allows organizations to enforce consistent data handling across documents:

  • Instruction Builds (Read) teach the AI how to interpret, extract, and validate data

  • Transformation Rules (Polish) format and reshape data after extraction

  • Rejection Rules (Guardrail) block documents that violate compliance or business requirements

These systems operate at different scopes within an organization, and a fixed scope order decides the sequence they run in when more than one applies to the same document.

How It Works

The Read → Polish → Guardrail Flow

Read Phase (Instruction Builds)

Instruction Builds define natural language instructions that guide AI interpretation during document processing. Written in plain English, they are flexible and scalable. During the read phase, they can:

  • Teach the AI how to extract specific information from documents

  • Infer missing fields from context or related data

  • Split or merge line items intelligently

  • Apply language-specific or region-specific formatting

  • Validate extracted values against master data

  • Block approval and validation of a document whose extracted data does not satisfy a stated condition (a custom validation)

Polish Phase (Transformation Rules)

After the AI completes extraction, Transformation Rules run automatically. They manipulate extracted data using conditional logic to SET values, INCREASE, DECREASE, MULTIPLY, or DIVIDE numeric fields. Multiple conditions can be combined using AND/OR logic before actions execute.

Guardrail Phase (Rejection Rules)

Rejection Rules deterministically block documents when conditions are met. Unlike transformations that correct data, rejection rules apply hard stops - if a condition is true, the document is rejected with no automatic corrections.

Scope Precedence

All three operate within a scope hierarchy. When more than one applies to a document, they are evaluated in scope order, from most specific to most general:

  1. Trading party relationship specific (Party A + Party B for a specific relationship) - most specific

  2. Trading party specific (either Party A or Party B alone)

  3. Organization specific

  4. Country specific

  5. Global - least specific

Trading party scoping supports both one-party (single entity) and two-party (relationship-based) configurations, allowing granular control over instructions and rules for specific business partnerships.

Enabling and Disabling Rules or Instructions

All three types can be enabled or disabled without being deleted, and only enabled items are applied when a document is processed. A disabled item stays configured and can be switched back on at any time.

Each type groups its items the same way, so the controls behave consistently:

  • Instruction Builds list instruction groups. Each group holds the instructions for one scope, and every instruction inside it has its own switch

  • Transformations and Rejections list rule groups. Each group holds one or more rules, and every rule inside it has its own switch

In every case the group's row switch is on when at least one item in it is enabled, and turning the group off switches off everything inside it. Items are enabled by default, so nothing is skipped until it is explicitly switched off.

Because disabled items are skipped, switching one off can change what the remaining instructions and rules do. This is covered in Scope Precedence in Instructions and Rules.

Supported Configurations and Options

Instruction Builds

Instruction Scope Options:

  • Trading party specific (one-party or two-party relationships)

  • Organization specific

  • Country specific

  • Global

Capabilities:

  • Natural language instruction definition

  • Several separate instructions per scope, each individually enabled or disabled

  • Per-instruction AI refinement

  • Field inference and validation

  • Custom validations that block Approve and Validate, compiled onto the document at extraction

  • Intelligent line item handling (splitting/merging)

  • Language and region-specific formatting

  • Master data validation

Transformation Rules

Condition Operators:

  • = (equal)

  • < (less than)

  • <= (less than or equal)

  • != (not equal)

  • IS_NULL (field has no value)

  • IS_NOT_NULL (field has a value)

Action Operators:

  • SET - assign a specific value

  • INCREASE - increment a numeric field

  • DECREASE - decrement a numeric field

  • MULTIPLY - multiply a numeric field by a factor

  • DIVIDE - divide a numeric field by a factor

Logic Options:

  • AND - all conditions must evaluate to true

  • OR - at least one condition must evaluate to true

  • Note: AND and OR cannot be mixed within the same rule

Rule Scope Options:

  • Trading party specific

  • Organization specific

  • Country specific

  • Global

Data Sources:

  • CSV lookup tables (maximum 100,000 rows, 10 columns per table)

Rejection Rules

Condition Operators:

  • Same as Transformation Rules: =, <, <=, !=, IS_NULL, IS_NOT_NULL

Logic Options:

  • AND - all conditions must be true for rejection

  • OR - document is rejected if any condition is true

  • Note: AND and OR cannot be mixed within the same rule

Rule Scope Options:

  • Trading party specific

  • Organization specific

  • Country specific

  • Global

Data Sources:

  • CSV reference files for validation (e.g., approved cost centers, authorized vendors)

Common Use Cases:

  • Missing required fields (e.g., missing PO number)

  • Test data detection

  • Master data validation (cost center, supplier, account codes)

  • Business rule violations (e.g., non-positive totals)

Other Technical Specifications

System Constraints

Rule Management Limits:

  • Maximum rule groups per organization: 100

  • Maximum rules per rule group: 500

  • Maximum rule groups per tenant: 1,000

  • Maximum instructions per organization: 100

  • Maximum instructions per country: 100

  • Maximum global instructions: 100

Data Handling:

  • Condition nesting: cannot mix AND and OR operators in single rule

Access Control:

  • Instruction Builds, Transformations and Rejections each open on four tabs: Organization, Trading Party, Country and Global

  • Admins work on all four tabs

  • Managers work on the Organization and Trading Party tabs. The Country and Global tabs are not available to a Manager

  • A custom role can be granted read and write per tab, except that Country and Global can be granted view access but never write, because only admins change that configuration

  • Actions a role does not allow are greyed out with the tooltip "You don't have permission to perform this action", so a read-only user can still see the rules that apply to their documents

  • All changes are audit-logged

  • Scope precedence is automatically enforced

Processing Order

  1. Document enters system

  2. Instruction Builds guide AI extraction (Read phase)

  3. Transformation Rules applied to extracted data (Polish phase)

  4. Rejection Rules evaluated against the transformed values; document blocked if any condition is met (Guardrail phase)

  5. Processed document exported with transformed data

Integration Points

External Data Sources

Transformation Rules and Rejection Rules can reference CSV files for:

  • Lookup tables for value mapping

  • Master data validation (cost centers, vendors, account codes)

  • Reference lists for compliance checks

Audit and Compliance

All rule changes are audit-logged, tracking:

  • Who created or modified the rule

  • When the change occurred

  • What was changed

  • The scope level affected

Organization Hierarchy

Rules respect your organization structure:

  • Tenant-wide limits keep the total number of rule groups manageable

  • Organization specific rules run ahead of global ones, so both can apply to the same document

  • Trading party specific rules carry business logic that applies to one partner or one partner relationship

Notes

Rule Logic Constraints

  • No mixed AND/OR logic - Single rules cannot combine AND and OR operators. Workaround: create separate rules or use rule groups

  • No automatic correction in Rejection Rules - Documents rejected by guardrails are blocked entirely; transformation-style fixes are not applied during rejection

  • Scope precedence is automatic - the scope order is fixed and cannot be overridden. For how overlapping items combine once they are in that order, see Scope Precedence in Instructions and Rules

CSV Data Constraints

  • Row limits - a CSV file holds up to 100,000 rows, so a larger reference set has to be narrowed down before it is uploaded

  • Column limits - a CSV file holds up to 10 columns, so include only the columns your rules actually use

Performance Considerations

  • Large rule sets - Organizations with many rule groups or rules in each group may experience slower evaluation times

  • CSV lookup performance - Large reference files (approaching 100,000 rows) may impact processing speed

Scope-Related Edge Cases

  • Multiple Trading Party matches - If both Party A-specific and Party B-specific rules exist for the same field, the one-party rules are evaluated in order of precedence, Party A before Party B

  • Country specific items - Instruction Builds, Transformations and Rejections each have a Country tab, so country scope is available in all three

  • Empty scope intersections - If a two-party rule is defined but only one party is known during processing, the rule does not apply

Related Articles
Did this answer your question?