Business Rule Use Cases

Written by Uday Kumar Updated

Access. Business Rules is available to three roles. SuperAdmin can build rules. ProcureToPay Manager and ProcureToPay Agent have read-only access. See the Roles and Access Reference.

Overview

Most manual coding work falls into one of six use cases. Recognizing which one fits your problem tells you which action type to reach for, and where that use case tends to go wrong.

Each use case below describes a class of manual work rather than a rule to copy exactly. Substitute the field names from your own tenant for the generic ones used here.

Choosing a use case

Start from the manual work you want to remove, rather than from the rule you think you need. Find the row that matches what your team does by hand today, and the use case and the action type follow from it.

Each use case has its own section after the table, covering how to express it as a rule and where it tends to go wrong.

Table 1. Which use case fits the problem

The manual work you are removing Use case Action type it uses
Coding every invoice from one supplier the same way Supplier defaults Set to
Typing the same descriptive text with a few details changed Composed text Set to, with @ field references
Setting field B whenever field A has a particular value Conditional default Set to, often with an ELSE clause
Retyping a header value onto every line, or the reverse Header and line alignment Copy from another field
Working out a figure with a calculator before entering it Derived amount Calculate As
Reading the document body for something not extracted as a field Keyword match Set to, on a keyword condition

Supplier defaults

This is the most common use case. A supplier’s invoices always belong to the same department, location, or cost center, and someone codes them by hand every time.

Expressed as a rule: test Vendor Name, then set the coding fields. Because In is multi-select, one rule can cover a group of suppliers that share a coding treatment rather than needing one rule per supplier.

The use case gets harder when the treatment varies by a second dimension, such as the same supplier coded differently for two legal entities. The IF clause then carries both conditions, and because conditions are AND-only, you need one rule per combination.

The trap here is the priority order. Supplier defaults are exactly the case where a configuration option may already be populating the field, and configuration options sit above business rules. If a supplier-default rule appears to do nothing, that is the first thing to check.

Composed text

Memo and description fields are often filled with a sentence that is mostly boilerplate and partly document-specific, written as a reference for whoever sees the entry in the system of record later.

Set to with @ field references handles this: static text carries the constant part, and each reference pulls a value off the document being processed. One rule replaces the typing on every invoice.

Two things are worth deciding before you build one:

  • Which fields are reliably populated. A reference to a field that is empty on some documents produces a sentence with a gap in it. Fields extracted from every invoice make better references than optional ones.
  • Whether the text is for people or for matching. Downstream systems that parse memo text are sensitive to format changes, so a composed value that something else reads should be treated as an interface rather than as prose.

Conditional default

A flag or a classification on the document implies a value in another field, and the implication is currently held in someone’s head.

The shape is a narrow IF and a narrow THEN: test the field that carries the signal, set the field that depends on it. A boolean tested with Equals, or a field tested with Exists, covers most of these.

ELSE is most useful in this use case. Take a document that either has a purchase order or does not, where each case implies a different value. One rule with a THEN and an ELSE is easier to read six months later than two rules whose conditions have to stay mutually exclusive, and it cannot be broken by someone disabling one half.

Header and line alignment

A value belongs on the header and is needed on every line, or a line value is needed at header level for reporting. Both directions are handled by Copy from another field.

The scope control decides the outcome:

  • Header to line, applying to everything: choose All Lines.
  • Header to line, applying only where a line condition matched: choose Same Line.
  • Line to header: the header holds one value, so where lines differ, which line wins is a question worth answering before you build the rule.

Type compatibility constrains this use case more than the others. A text target accepts any source, but every other target requires a source of the same type, and a dropdown target requires the same dropdown.

Derived amount

A figure is computed by hand from other figures on the invoice, such as a net amount after tax and freight, or a line total from quantity and price.

Calculate As replaces the calculator. It is available for amount targets only, which is the main limit on the use case.

Use parentheses whenever precedence could be misread. @{Total Amount} - @{Total Tax} / @{Quantity} divides before subtracting, which is rarely what was meant. Writing (@{Total Amount} - @{Total Tax}) / @{Quantity} removes the doubt, for the next reader as much as for the engine.

Formulas are validated as written, so a division by a literal zero is caught as you type. A division by a field that happens to be zero on one document is not, so prefer a denominator that is always populated, or condition the rule on that field existing.

The same choice matters for every field in the formula, not only the denominator. Where any referenced field is empty or non-numeric on a document, the rule does not run for it. Build derived amounts on fields the agent extracts from every invoice.

Keyword match

Keyword extraction is not switched on for every tenant. Your Auditoria contact can tell you whether it is available to you.

Sometimes the value you need is printed on the document but is not one of the extracted fields, such as a project reference, a site code, or a term that implies a particular treatment.

Keyword extraction matches against the document body instead of an extracted field, so a rule can act on something printed on the invoice that is not captured as a field.

Because Contains is case-insensitive and matches anywhere in the text, this use case is the easiest of the six to make too broad. A short or common string matches documents you did not intend. Prefer a distinctive string, and where a rule of this kind behaves unexpectedly, check the breadth of the match before the rest of the rule.

What these use cases have in common

  • Each rule does one recognizable thing. A rule combining three use cases is hard to name, and a rule that is hard to name is hard to review.
  • The conditions carry the logic; the name carries the intent. Name a rule after the outcome, not the requester or the ticket.
  • A rule that appears not to work is usually being overridden. Check the priority order before rebuilding the rule.
  • Rules built on optional fields are conditional in practice, whether or not you wrote a condition. An absent field means nothing to test or nothing to copy.

Results

You can match a piece of manual field work to one of the six rule shapes, or recognize that it is not rule-shaped and needs a different tool.

Related information