The controls that catch a bad invoice before it is paid

Stories about fraud tend toward the dramatic. In a payables department the exposure is usually quieter: the same invoice arriving twice from two addresses, a vendor whose remittance details changed last week, an invoice emailed by someone who has never invoiced for that vendor before.

None of these is hard to spot once someone looks. The difficulty is looking at every invoice, every week, while also closing the month.

Patterns worth watching

Duplicates and near-duplicates

The same invoice entered twice, or resubmitted with a slightly different number or date. Sometimes it is an honest re-send; sometimes it is not. Either way it should not be paid twice.

New and changed vendors

A first payment to a vendor nobody has dealt with before, or a payment shortly after a vendor’s details were edited, deserves a second look. So do two vendor records whose names are nearly the same.

One person on both sides

When the person who enters an invoice can also approve it, or who changes a vendor can also pay it, a single mistake or a single bad actor goes unchecked.

Lookalike invoices

A convincing PDF from an unfamiliar sender, carrying a vendor’s name and new payment details. With Ingrid and tools like it now reading invoices, there is a newer variant: text hidden in the document, written to instruct the software rather than the reader.

Unusual journals

Manual journals to the bank account, journals posted at odd hours, and large round-number entries are not wrong in themselves, but they are where a controller would look first.

Where software does the looking

In Ingrid Payables, several of these checks run on every invoice as it comes in, before anyone is asked to approve it:

• Duplicate detection. Exact repeats are refused. The same invoice number with a different total needs a person to confirm it is a separate invoice.
• Sender checks. Mail from unknown senders is held for a person to allow or block, and is not read by Ingrid until then.
• Tampering and phishing warnings. Ingrid warns on hidden text in a PDF, instructions aimed at Ingrid, and a sender who does not usually invoice for that vendor.
• Over-invoicing. An invoice that totals more than its purchase order has left to invoice is held instead of posting.
• Segregation of duties. A submitter cannot approve their own invoice, and dual approval cannot be cleared by one person through a delegation.
• Anomaly alerts. Unusual amounts for a vendor, vendor spikes, near-duplicate vendor names and invoices for inactive vendors surface on the dashboard.

Ingrid Alert looks across the books as a whole. It reads Spire read-only through the Ingrid connector and runs eight control checks:

Each check can be switched on or off, the thresholds for what counts as unusual live in the company’s own settings, and each flagged item is marked reviewed with a reason, or reopened later.

Why a person still decides

Most flags turn out to be innocent: a vendor who really did change banks, a large journal that really was the year-end accrual. A system that rejected them on its own would be switched off within a month. So Ingrid’s checks ask rather than decide, apart from the few cases that are never right, such as paying the identical invoice twice.

What matters afterwards is the record. In Payables every change is kept with who, when and a before-and-after view, and the audit records of approvals, postings and Ingrid’s steps cannot be edited or deleted; the system refuses it. When the auditors ask why a flagged invoice was paid, the answer is already written down.

A short checklist

1. Confirm any change to a vendor’s banking details by calling a number you already had, not one in the email.
2. Keep entering and approving with different people, and require a second approver above a threshold you choose.
3. Review new vendors before their first payment, not after.
4. Read the week’s flags before the payment run, and record why each one was cleared.
5. Revisit the thresholds each quarter, so the flags stay few enough to read.