Invoice risk score: how the 0-100 scoring works

A controller with 300 invoices per month cannot look at all 300 at the same level. The operational question is not “is this invoice correct?”. It is “where do I look first?”.

The risk score answers that. It turns scattered signals into a 0-100 number and sorts the queue. This article explains how it works in ininvoice and why it is auditor-defensible.

What an invoice risk score is

A risk score is an aggregator. It takes objective signals about the invoice, applies a weighting logic and returns a value on a fixed scale. In ininvoice, 0 to 100.

• 0-25 (green): clean invoice. No relevant signals. Candidate for auto-approval per policy.
• 26-60 (amber): one or more active signals. Human review before approval.
• 61-100 (red): multiple signals or one very strong one. Not approved without explicit justification.

The score does not decide payment. It sorts. When 50 invoices come in on Monday, the 80+ are looked at first; the score 10s are approved in batch.

Ranked factors that make up the score

The score combines seven factors, ordered here by approximate relative weight. Exact weights are internal product and are recalibrated with usage data, but the order is stable.

1. Potential duplicate. Another invoice from the same supplier with similar amount and concept in a recent window. The most expensive signal: a duplicate paid twice is direct loss.
2. Price or quantity variance out of tolerance. Line-by-line cross-check against the PO, 2% or EUR 1.50 OR mode. Details in price variance calculation.
3. New or unvalidated supplier. First invoice from a tax ID that was not in the master, or recent setup without enough history.
4. Amount outside historical range. Invoice that deviates from the average amount this supplier has invoiced in prior months.
5. No linked PO. Cannot be cross-checked against a formal PO. It blocks three-way matching and raises risk even if the rest is normal.
6. Inconsistent date. Invoice date earlier than the PO, outside the legal window or header different from signed metadata.
7. Altered payment details. IBAN, tax ID or address different from the last payment. The classic impersonation fraud signal.

How each factor is weighted

• Factors with direct financial impact (duplicate, altered payment data) weigh more than context ones (new supplier, no PO).
• They combine in a non-purely-additive way. Two signals pointing to the same risk do not double the weight.
• The score saturates at the top. Above 80 routing is the same; not artificially inflated.
• Weights are recalibrated with feedback. Repeated false positives on a signal lower its weight in next models.

Mental rule: one strong signal alone raises the score, several weak ones together also do.

Three examples: score 12, score 47 and score 88

Invoice A — score 12 (green)

Signal	State
Supplier	Recurring, 14 prior invoices
Linked PO	Yes, formal PO
Price/quantity variance	Zero on all lines
Amount (EUR 1,245)	Within historical range
Duplicate	No
Payment data	IBAN matches last payment

Score 12. Goes to auto-approval if the client policy allows. The controller doesn’t look at it in detail.

Invoice B — score 47 (amber)

Signal	State
Supplier	Recurring
Linked PO	Yes
Price variance	+4.2% on one line (out of tolerance)
Amount (EUR 3,850)	Within historical range
Duplicate	No
Payment data	IBAN matches

Score 47. One actionable active signal. The system routes the exception to the responsible buyer. The invoice is not approved until justification or supplier correction.

Invoice C — score 88 (red)

Signal	State
Supplier	New, first invoice
Linked PO	No
Price/quantity variance	Not applicable (no PO)
Amount (EUR 12,400)	No history to compare
Duplicate	No
Payment data	Foreign IBAN, newly registered email domain

Score 88. Three red factors: new supplier, no PO, atypical payment data. The invoice goes to the top of the queue. The controller calls via a verified channel, not via the received email. It is the pattern described in supplier invoice fraud.

The score as a human queue prioritiser

The score does not replace human judgement. It assigns attention. Industry data (Ardent Partners, IOFM) puts the AP queue at 40-80 invoices/day per person. Without a score, order is FIFO; with a score, by risk.

• Green (0-25): batch one-click approval. 60-80% of volume.
• Amber (26-60): the bulk of review time. Most real exceptions live here.
• Red (61-100): 5-10% of volume, captures almost all financial risk.

Score and fraud detection

Several score factors are classic fraud signals: altered payment data, recent email domain, new supplier with high amount. The combination is the statistical pattern of BEC (business email compromise).

The score is not a fraud detector on its own, but it systematically raises invoices with a suspicious profile. A team that looks at scores 80+ first reviews de facto almost every fraud attempt that arrives via email. Patterns and countermeasures in how to detect invoice fraud.

Why an automated score is auditor-defensible

• Declared rule. The seven factors and their logic are documented. The auditor can read the model and mentally reproduce the result.
• Full audit trail. Each invoice stores the values of the seven factors, the score, the human decision and the justification. Reproducible months later.
• Human override always available. The score suggests; the human decides. Approving an 88 or rejecting a 12 requires written justification.

That triad — declared rule, traceability, override — sets a defensible score apart from a black box the auditor rejects. Compatible with COSO and with GDPR art. 22 as long as there is meaningful human intervention.

How to improve your queue’s average score

• Formalise POs for recurring suppliers. Without a PO, factor 5 is always active. With a PO, factors 2 and 4 usually come out clean.
• Validate suppliers before the first invoice. Tax ID, IBAN and tax data verified. After 3-4 invoices the “new supplier” factor disappears.
• Clean line descriptions. Better invoice/PO match = lower false variance.
• Confirm IBAN changes via a verified channel. A call to the master’s phone, not email. Kills the “altered payment data” signal.

Integration with the approval flow

• Automatic routing: <25 to exception-based approval, 26-60 to buyer or owner, 61+ to a second approver.
• SLA per band: greens in hours, reds can wait days if they require a supplier call. That way the average SLA isn’t hurt.
• Feedback loop: every human decision is stored and used to recalibrate weights.

End-to-end flow at touchless accounts payable, document cross-check at three-way matching, reconciliation at invoice and delivery note reconciliation.

FAQ

Does the score replace the human approver?

No. It suggests priority and level of review. Final approval is always human, with traceable justification when departing from the score.

Why 0-100 and not binary suspicious/not suspicious?

Risk is continuous. Score 35 and score 70 demand different attention levels; putting them in the same bucket wastes time.

What if we have little invoice history?

The factors that don’t depend on history (variance, no PO, date, payment data) work from day 1. Those that do (historical range, new supplier) gain precision after 2-3 months.

Can sensitivity be adjusted per client?

Yes. Band thresholds are configurable.

Is it GDPR-compliant if it affects payments?

Yes, because the final decision is human and reversible (GDPR art. 22). The score is decision support, not terminal automated decision.

Can I see why an invoice has score X?

Yes. The interface shows the seven factors with their value and how they contribute to the total. Required for defensibility.

How do I know there is no bias against certain suppliers?

Signals are objective (amounts, dates, IBAN, presence of PO). No proxy identity variables. The audit trail lets you review the score distribution per supplier.

Three things to remember

1. The score is a prioritiser, not a decider. It sorts the queue; the human approver still owns it.
2. It combines seven objective signals ranked by financial impact. Duplicate and payment data weigh more.
3. It is auditor-defensible thanks to declared rule, audit trail and human override. Not a black box.

If you want to see it on your queue, try ininvoice. Check the pricing and features.

Related content

• Touchless accounts payable
• Three-way matching
• Invoice and delivery note reconciliation
• Price variance invoice vs PO
• Supplier invoice fraud
• How to detect duplicate invoices