Template Rules in Process Templates

Status: 01.08.2026 • Reading time: ~8 minutes

Template Rules are a way to define business logic that runs during document processing. Once a document has been captured and fields contain values (from OCR, import, or mapping), rules can evaluate those values and react to them. This gives you a controlled layer between “data was captured” and “data is accepted”, so you can enforce consistency, detect exceptions early, and reduce manual corrections.

A rule typically has three ingredients: it looks at one value (or a value derived from other values), evaluates a condition, and—if the condition is met—triggers a response such as creating a remark or updating one or more fields.

Because rules can be executed in a defined order, you can build structured logic: normalize values first, compute derived values next, and validate the final result afterwards.

What you can do with Template Rules

Validate completeness and basic plausibility

Rules can ensure that the most important fields are present and reasonable. For example, you can detect missing invoice dates, missing vendor references, or totals that are zero when they should not be. This is often the first line of control: if the basics are missing, it does not make sense to proceed to more advanced checks.

Instead of blocking everything, you can choose the behavior that fits your workflow. Some customers mark missing essentials as errors (stop processing until fixed), while other checks may be warnings (allow processing but force review).

Validate formats and patterns (e.g., invoice numbers, IDs)

Many business fields must follow a structured format: invoice numbers, purchase order numbers, VAT IDs, IBANs, internal references. Rules can validate that a field conforms to the expected structure and raise a remark when it does not.

This is especially helpful when OCR reads characters incorrectly (O vs 0, I vs 1), or when suppliers use varying numbering schemes and you want to detect “unusual” values early.

Compare values for consistency

Rules can compare two values and evaluate whether they match or differ. This can be as simple as checking that two extracted references are aligned, or more business-oriented checks such as ensuring the currency matches the vendor’s expected currency.

A common approach is to compare an extracted value against another captured field, or against a value derived from master data. The goal is not to catch every small deviation, but to identify contradictions that indicate the document needs attention.

Perform numeric controls, including thresholds and tolerances

Numeric comparisons are one of the strongest features in real invoice processing. You can flag high amounts for manual approval, detect negative values where they should not occur, and highlight suspicious differences.

Where equality is required, tolerance is important because scanned documents often introduce minor deviations through rounding (especially with VAT). Instead of treating “118.99 vs 119.00” as a failure, you can allow a small deviation band and only raise an exception when the difference exceeds your defined tolerance.

This is also how typical financial integrity checks are expressed—such as verifying totals and taxes without creating too many false positives.

Validate totals such as Net / VAT / Gross

One of the most requested controls is ensuring totals add up correctly. A typical business rule is: Gross should equal Net plus VAT, possibly within a tolerance. When the relationship does not hold, you can raise a remark that explicitly asks for review.

These checks can be applied at header level (document totals) and—depending on your template structure—also at line level (e.g., line amount = quantity × unit price, or line totals sum to header totals). Even when you do not enforce strict blocking, this provides strong operational control and reduces posting errors.

Check master-data resolution (record existence)

A field can contain a value and still be wrong because it does not resolve to a valid record. Rules can detect this kind of issue by checking whether a corresponding master-data record exists. Typical examples include vendor/customer resolution, item numbers on lines, or other referenced entities.

This is one of the most important rule types because downstream enrichment depends on it. If a vendor record cannot be resolved, fields such as payment terms, approval logic, or posting setup might be unreliable. In that sense, “record exists” checks often act as gateways: if resolution fails, the document is marked for correction before it can proceed.

Use master data as part of the logic (enrichment and control)

Once a record is resolved, rules can use information from that record as input for further evaluation or to populate document fields. This enables vendor-specific logic and consistent behavior.

For instance, you might want to raise a remark when the vendor is blocked, apply the vendor’s default currency when the currency is missing, or use vendor payment terms to derive a due date. This reduces manual work and keeps document handling aligned with master data.

Derive and compute values

In many processes, the values you want to validate are not directly captured but can be derived. Rules can support calculated results, such as expected totals or differences. This helps you express controls like “compare captured gross against calculated gross” or “compute the delta and flag it when it exceeds tolerance”.

Calculated values are also useful for building consistent, explainable logic where validation does not depend on a single extracted field but on relationships between fields.

Handle dates and due-date logic

Date checks are a frequent requirement because date fields influence posting and payment processes. Rules can check for unrealistic dates (far in the future, or earlier than expected), enforce relationships (due date not earlier than invoice date), and derive dates from other values.

A classic example is due-date calculation based on payment terms. When due date is derived consistently, you reduce manual edits and avoid posting documents with incorrect payment dates.

What happens when a rule is met

Remarks: communicate clearly to the user

Remarks are the “human-facing” outcome of rules. They provide clear guidance: what was detected, why it matters, and what to do. Remarks can be informational, warnings, or errors depending on how strict the process should be.

Good remark text is specific and actionable. “Totals mismatch” is helpful; “rule failed” is not. The best rule sets feel like a checklist that automatically explains itself to the reviewer.

Field replacement: automatic corrections and standardization

Rules can also update fields automatically. This is appropriate when the change is safe and deterministic: normalizing number formats, filling defaults, copying values between fields, or applying values derived from master data.

Replacing values does not have to hide issues. Many customers combine both approaches: they normalize values automatically, but still create a remark when the document originally contained something suspicious. That way, the document becomes processable while still remaining transparent.

Typical outcomes customers implement

Customers commonly implement a rule set that delivers results like:

“Flag invoices when totals don’t add up (net + VAT vs gross), while allowing a small tolerance for rounding.”
“Raise warnings when invoice totals exceed approval thresholds.”
“Stop processing when a vendor cannot be resolved or when mandatory fields are missing.”
“Detect invalid formats for invoice numbers, VAT IDs, or IBANs.”
“Derive due dates based on invoice dates and payment terms so users don’t need to calculate them manually.”
“Normalize captured values so comparisons and posting behave consistently.”
“Apply vendor-specific controls, for example blocked vendors, currency mismatch, or missing references.”