Technology
Business Rules
Thresholds, policies and validation written as explicit rules, so decisions can be explained and changed.
The concept
Policy as configuration you can read
A written condition with an outcome. In PTAS AI products, rules decide approvals, holds and postings, and models supply the evidence.
Every finance team runs on rules, and most of them live in someone's head or a spreadsheet. Invoices above three lakh go to the finance controller. A price more than two percent above the PO is a variance. The same invoice number from the same vendor within a year is a duplicate. Input credit is not claimed on a blocked category. Automation that does not hold these rules explicitly holds them anyway, in code nobody reads or in a model's habits, and then nobody can say why a particular invoice was paid.
In the platform a rule is configuration with four parts: a condition, the threshold or list it reads, an outcome and an owner. Approval bands by entity and cost centre. Match tolerances by vendor or category. Duplicate checks on vendor, number, date and amount. Tax checks on GSTIN status and on the rate against the HSN code. Hold lists for new vendors and changed bank details. Agents and the workflow engine read the current version when they run, and every decision they make names the rule and the version that applied.
Rules are also where the line between model and policy is drawn. A model can say how likely it is that an invoice line belongs to PO-88214. Whether a match inside tolerance may proceed is the rule's call. Keeping that line explicit is what lets a CFO change policy without retraining anything, and lets an auditor read why a decision went the way it did without asking an engineer.
Where it sits
Between intelligence and action
PTAS AI workflows run as Perception, Intelligence, Orchestration, Action and Verification. Rules sit in the third stage, which puts one between every model output and every action.
In the products
The rules inside DocPro and FinSuite
DocPro rules decide whether a record is fit to hand over. FinSuite rules decide whether it may be approved, posted and paid.
DocPro
Validation rules
Totals recomputed from the lines, dates checked for order, GSTIN and PAN checked for format, required fields present. A failed rule holds the record with the rule named.
DocPro
Thresholds per field
The confidence a field needs before it may pass without review is a rule, set per field and document type and versioned like any other.
FinSuite
Duplicate checks
Same vendor and invoice number, or the same amount and date under a different number, checked against everything posted and in flight. A suspected duplicate is held with the earlier document linked.
FinSuite
Match tolerances
Price and quantity tolerances by vendor, category or entity. Inside tolerance the invoice proceeds; outside it, the variance goes to the exceptions queue with the amount.
FinSuite
GST and tax checks
GSTIN status, the rate charged against the HSN or SAC code, tax type against place of supply, and the categories you treat as blocked, checked line by line before approval.
FinSuite
Approval bands
Value bands by entity and cost centre name the approver. Delegation and cover are rules with a date range, and the decision records which band applied.
Worked example
The rules one invoice met, and the history of one of them
Five checks on a supplier invoice and the band that will route it, each citing its rule and version. Then that band's version history. Values are illustrative.
Invoice MC-2026-04871 against the rule set. Illustrative example
Every outcome cites a rule and a version, so the same question asked a year from now gets the same answer.
A model proposed, a rule decided
A model ranked the PO line as the likely match. The tolerance rule said the price was outside it.
The hold says why
Rule, version, row and amount are on the hold, so the analyst starts from the answer.
Routing waits its turn
The band is known, but approval is not requested until the variance is settled.
The band that will route this invoice, APR-01, has changed several times. Each change was a version with an author, an approver and a date it took effect, and one more is waiting for approval now. Invoices routed under earlier versions still say so on their records.
Approval band APR-01, version history. Illustrative example
An invoice approved in May 2026 was routed under v12, and its record still says so. Changing the rule did not rewrite the history.
Proposed and approved apart
The person who drafts a rule change cannot approve it.
Effective from a date
A change starts on its effective date and never applies backwards.
History stays readable
Superseded versions are kept, so any past decision can be checked against the rule it used.
Limits and controls
What rules cannot do
Rules only know what they are told. A policy nobody wrote down is not enforced, and the first weeks of a rollout usually surface a few, as items that no rule could place. Rules are also blunt at the edges. A two percent tolerance treats 2.1 percent the same as twenty, which is why a failed rule sends the item to a person with the amount in front of them instead of rejecting it outright.
And rules multiply. A rule set that grows one vendor exception at a time becomes as hard to read as the code it replaced. Each rule therefore has an owner and a review date, and a rule nobody can explain any more is retired through the same approval as any other change.
Change by role, approved by another
Who may propose a rule change and who may approve it are separate roles. A reviewer in a queue can change an item, and cannot change a rule from there.
Versioned, with an effective date
Every change creates a version with its author, approver and effective date. Earlier versions stay readable, and decisions cite the version they used.
Rules kept outside the model
Thresholds, bands and checks are configuration the agents read, never text inside a prompt. A model change cannot alter a rule, and a rule change needs no retraining.
Every outcome cited
Each pass, hold and route records the rule, the version and the inputs that produced it, queryable by audit afterwards.
The queue a failed rule sends work to is described under Human-in-the-Loop. How agents read rules at run time is under Agentic AI Architecture.
FAQ
Questions finance and audit teams ask about rules
Who can change a rule, and how is the change controlled?
Roles you assign. Typically a process owner proposes, a finance controller or CFO approves, and an administrator can see both but do neither. A change records its author, its approver, the reason given and an effective date, and the previous version stays readable. Reviewers working a queue can correct an item or decide on it, but they cannot touch the rule that held it. That separation is what keeps a rule a control.
Can we change a threshold or an approval band without a software release?
Yes. Bands, tolerances, thresholds, hold lists and routes are configuration, changed by the roles you have authorised and versioned as above. A new kind of rule is different: one that needs data the platform does not yet read, or a check against a system it is not yet connected to, is engineering work and goes through a release.
How do rules and AI models work together on the same decision?
The model supplies evidence and the rule decides what the evidence allows. A model reads the quantity and scores it; a threshold rule decides whether that score is enough to proceed. A model ranks the likely PO line; a tolerance rule decides whether the price difference is acceptable. A model can be retrained without anyone touching a rule, and policy can change without anyone touching a model.
Can rules differ by entity, vendor or category?
Yes. Bands, tolerances and checks can be set per entity, cost centre, vendor or category. Where more than one rule could apply to the same item, which one takes precedence is part of the configuration and is shown on the decision, so nobody has to work out afterwards which rule won.
Keep reading
Where the rules apply
Human-in-the-Loop
Where a failed rule sends an item, and what the reviewer there may decide.
Read more →Workflow Orchestration
The engine that reads the bands and routes each case to a person.
Read more →GST Compliance Automation
Tax checks line by line, run as a workflow before filing.
Read more →Accounts Payable Automation
Duplicate, match and approval rules inside the payables process.
Read more →Next step
Write your approval policy down once
Bring your approval matrix, your tolerances and the checks your team still runs by hand. We will turn them into versioned rules and show you where each one sits in the workflow.