SpendYou may know it as accounts payable

Pre-approval policy compliance check

Check each item against your written spend policy before it reaches the approver, and attach the findings so the approver sees them.

What to expect: ideas for what could change, what you need first, and how to test whether it helps. Nothing here is a measured result.

Impact: High
Ease: Medium
Prep: Some

Indicative rating based on the workflow described. Your readiness and implementation effort may differ.

Evidence status: Editorial / indicative assessment

What it does

Each item is tested against rules written from your spend policy before it goes for approval. Typical tests cover the PO requirement, contract terms, split invoices just under a threshold and restricted categories.

The findings are attached to the item. The approver reads them and still makes the decision.

Why it may help

Approvers check policy from memory, one item at a time.

Approvers see one item at a time and rarely have the policy, the contract and the PO open in front of them. Breaches can come to light only after the money is out.
Running the same written rules on every item before approval may surface more exceptions while there is still time to act.
The controller and the approvers would see it first, as a short list of findings beside each item.

Where it starts, where it stops

Starts at: An item is ready to go to an approver.
Ends at: The findings are attached and the item goes on for approval.
Left out on purpose: The approval decision itself
Writing or changing the policy
Payment release

One way it could run, and where people stay in

Illustrative workflow

This is an illustrative improvement approach, not a final solution design. The workflow, level of automation, integrations, and review requirements will depend on your existing tools, available capabilities, data quality, company policies, and team needs. Confirm these during discovery and a controlled pilot before implementation.

Today, by hand

The approver reads the invoice and relies on memory and judgement for policy.
Contract terms and thresholds are looked up only when something seems off.
Breaches are found later, in a review or audit.

If you adopt it

The controller turns the written policy into specific, testable rules.
Each item is checked against the current rules before approval.
Findings are attached to the item.
The approver reads the findings and decides.
The controller reviews items that were flagged and approved, each month.

Checks that remain: Your approval routing and the approver remain responsible for the decision. Checks outside the written rules still depend on people.

When a field is uncertain: The check only covers what has been written down. A clean result means no rule fired, which is different from the item being compliant. Say so on the screen the approver sees.

Work it may add: Findings add something to read for the approver. Compare that with the time spent finding problems later.

Who does what

What AI does

Tests each item against the current rules
Writes a plain statement of what each finding means
Attaches the findings to the item

What your system checks

Applies only rules the policy owner has approved
Keeps the rule version used for each item
Retains check results with the item

Finance team

Read the findings and decide on each item
Ask for more information when a finding is unclear
Record why a flagged item was approved

Process owner

Writes and approves the rules, and keeps them in line with the policy
Reviews flagged but approved items each month
Updates the rules when the policy changes and records the version

The system does not approve, reject or reroute an item, and it does not change a rule on its own.

What it could move, and how you would check

Of the five measures below, this use case may help two. These are expected effects to test against your own baseline, not measured results. The last column says how to check each one.

Possible effect on each of the five process facts
Fact	Expected effect	Why
Process steps	Depends on workflow design	Findings add something to read, but may remove separate lookups of contracts and thresholds.How to check it in a pilot: Compare approver minutes per item with and without findings.
Cycle time	Depends on workflow design	Approvers may decide faster with the findings in front of them, or slower if findings raise more questions.How to check it in a pilot: Measure time from ready for approval to decision.
Exception loops	Possible downstream benefit	Catching exceptions before approval may mean fewer items reopened after payment.How to check it in a pilot: Count items reopened or corrected after approval.
First-time-right rate	Potential direct benefit	More items may reach approval already within policy, or with the exception clearly noted.How to check it in a pilot: Compare policy exceptions found before approval with breaches found after.
Cost per invoice	Not directly addressed	This use case aims at control. Time spent on findings may add to the cost of each item.How to check it in a pilot: Compare handling time per item, including finding review, before and after, and note any avoided loss separately.

What you need first

Ease of getting started: Medium. The tools exist. Some of the setup work is yours.

Written spend policy and approval matrix
Contract terms for key suppliers held centrally
Approval routing already in place
Approver remains responsible for the decision
Policy rules versioned and approved by the controller

Evidence to keep

The rule set with versions and the approval of each change
Check results kept with each item
A selection of approvals reviewed against the findings
A list of policy points with no rule, and what was decided about them
Flagged but approved items and the reasons recorded

What can go wrong, and how a pilot would show it

A policy point has no rule, and a clean result gives a false sense of coverage.
Rules go out of date after the policy changes and nobody updates them.
Approvers rely on the check and stop reading the item.
A rule is written too loosely or too tightly, and findings are wrong either way.
Contract terms are missing for some suppliers, so those checks cannot run.

Your next step

Take your written spend policy and mark each point that could be tested on an invoice. Count the points you could not turn into a rule. That list shows what the check will and will not cover. Keep the check advisory during the pilot. Approvers decide as they do today.

The pilot steps are under "See how to test it" in the Ways to start panel. Paid support is optional: use Get implementation support if you want help.

How to test whether it improves the work

Effort by stage

Pilot:: Write the rules from the policy, run them over the previous quarter, and compare with what a person would flag, using a starter set of about 100 items as a discovery exercise. Mostly controller time.
Production:: Connect the check to your ERP or AP system and approval routing, and agree where findings are shown. Effort depends on how your policy and contract data are held.
Ongoing:: Keep the rules in step with the policy, review flagged but approved items, and add rules for gaps found.

What to measure, before and after

Rules against policy:: Check each rule against the policy text with the policy owner, and list policy points with no rule.
Same items, both ways:: Compare the findings with what a person finds reading the same items against the policy.
Exceptions found:: Policy exceptions found before approval, and breaches found afterwards.
False flags:: Findings that turn out to be wrong, and the time approvers spend on them.
Approver behaviour:: Whether approvers still read the item, or only the findings.
Starter set:: About 100 items is enough to learn from, not enough to prove the rules are ready for live use.

What we assumed when rating how easy this is

A written spend policy and approval matrix exist.
Contract terms for key suppliers are held in one place.
Approval routing is already in place.
The policy owner has time to write and maintain the rules.