Finance, procurement and accounts payable teams

Hold the invoice that does not match its order, and pay the rest

A supplier's invoice arrives for more than the purchase order, on a contract whose rate changed last quarter. It is one of four hundred this week.

Request a working session The product that runs it: Operations, Finance & Back Office

Read the journey; a working session shows it running.

Seen by the customer · Finance workbench

From the record, not a run: what would reach them, on Finance workbench.

The case

Annotated from the record

What happened

A supplier's invoice arrives for more than the purchase order, on a contract whose rate changed last quarter.

A supplier's invoice arrives for more than the purchase order, on a contract whose rate changed last quarter. It is one of four hundred this week.

What it reads

The invoice, the purchase order and the delivery record
Contract obligations and rate history
The supplier's invoicing history
Approval authority for the amount

Checks before anything is sent

Purchase-order match, contract obligation, duplicate and approval-authority checks pass.

Every option considered, including doing nothing

Release to payment, where the order, the contract and the history agreeConsidered
Hold with the anomaly's reasons for the ownerConsidered
Refuse a duplicateConsidered
No action until the contract's rate is confirmedConsidered

Doing nothing is one of the outcomes, and it is recorded with its reason. The options are the record's own; a run decides between them.

Evidence record

Preview

Reference: The reference of the saved run.
Decision: One of the options, including no action, with the reason.
Checks: Purchase-order match, contract obligation, duplicate and approval-authority checks pass.
Evidence kept: Invoice
purchase order
contract terms
anomaly reasons
owner's decision
payment record
The measures: Overpayments prevented, against invoices held that were correct.
Connection: Written on every record: the systems the run read, and the sample it ran on.

The shape of the record, with no values. A reference appears only after a run is saved.

The improvement, and how it is measured

Hypothesis

An invoice checked against its order and contract is paid once and correctly; one checked against nothing is paid as it arrives.

Modelled

The mechanism that could produce the result, stated; the figure is measured in the pilot.

Observed

Measured in a pilot’s validate stage, on your systems, against a comparison agreed first.

The result, the mechanism, the measurement, and the record’s five answers

Desired result

Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails

Mechanism

Ingest → qualify → score → apply limits/consent → assign control → execute approved action → capture delivery and business outcome → monitor/retrain

Measurement

Randomised holdout where feasible; intent-to-treat primary view; pre-declared denominator; guardrails for complaints, margin and opt-out

Measured on: Eligible population; treatment rate; conversion; incremental revenue; ARPU; churn; contact rate; margin; opt-out; decision latency

01
Desired result
The result wanted.
Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails
02
Mechanism
The mechanism that could produce it.
Ingest → qualify → score → apply limits/consent → assign control → execute approved action → capture delivery and business outcome → monitor/retrain
03
Evidence required
The records kept to show it.
Decision log; eligibility snapshot; price/order response; delivery receipt; control assignment; revenue/outcome ledger
04
Costs and risks
The cost, and the ways it can go wrong.
Costs: Setup fee + annual product subscription; optional managed execution fee; optional verified-outcome fee with agreed baseline
If it fails: Fail closed on eligibility/consent/price; queue retryable events; do not duplicate orders; route exception to campaign operations
05
Measurement approach
The measure that shows it helped.
Randomised holdout where feasible; intent-to-treat primary view; pre-declared denominator; guardrails for complaints, margin and opt-out
Measured on: Eligible population; treatment rate; conversion; incremental revenue; ARPU; churn; contact rate; margin; opt-out; decision latency

Measured in the pilot's validate stage, on your systems, with the comparison agreed first. Every line above is the record's own design intent.

The business side

The change: Overpayments prevented, against invoices held that were correct.
Running cost: Setup fee + annual product subscription; optional managed execution fee; optional verified-outcome fee with agreed baseline
What evidence supports it: Invoice, purchase order, contract terms, anomaly reasons, owner's decision and payment record.

The journey in detail

Step by step, from both sides

Step	What the customer experiences	What the operator does
The momentThe moment that started it.	A supplier's invoice arrives for more than the purchase order, on a contract whose rate changed last quarter.	Reads the invoice, the purchase order and the delivery record, contract obligations and rate history, the supplier's invoicing history, approval authority for the amount.
The decisionThe decision to be made.	The customer's screen is unchanged.	Flags the invoice against the purchase order, the contract's obligations and the supplier's history, and routes it for human follow-up or clears it.
The safeguardsThe conditions that stop it.	Still unchanged: the action waits until every check has passed.	Purchase-order match, contract obligation, duplicate and approval-authority checks pass.
The actionThe action that reaches the customer.	Hold the invoice with its reasons for the owner, or release it to payment through the finance system. Reaches them on Finance workbench.	Recommends. The system that holds the right confirms, charges or provisions.
When it goes wrongThe failure, and the recovery.	The contract's rate change was agreed by email and never entered, so a correct invoice is held and the supplier stops deliveries.	The hold names the rate it compared against, the owner attaches the agreed change, the contract record is corrected, and the invoice is released with the correction logged.
The resultThe change it made.	What changed for them is what is counted; nothing else is claimed.	Overpayments prevented, against invoices held that were correct.
The proofThe proof anyone can check.	Can be answered for, later, from the record.	Invoice, purchase order, contract terms, anomaly reasons, owner's decision and payment record.

Operator systems remain authoritative. HeuriTel reads these to propose an action; it does not decide on their behalf.

The failure, and the recovery

What goes wrong

The contract's rate change was agreed by email and never entered, so a correct invoice is held and the supplier stops deliveries.

What happens then

The hold names the rate it compared against, the owner attaches the agreed change, the contract record is corrected, and the invoice is released with the correction logged.

The products in this journey

Runs the decision
Operations, Finance & Back Office
Finance forecasting, procurement and vendor analytics, invoice and purchase-order checks, workforce planning and employee, HR and IT service assistants each choose from approved actions including no action and are measured against the outcome.
Contributes
Revenue Assurance & Reconciliation
the same discipline applied to revenue rather than to spend
Contributes
AI Operations & Governance
the providers and controls behind the finance assistants
The definition it demonstratesHeuriTel Invoice Anomaly Detection
Results it movesReduce avoidable service cost

Available to see today

Read the journey; a working session shows it running.

Request a working session