Use case · Fraud & Risk
Catch the duplicate invoice before it is paid.
Procapy checks every invoice and expense claim as it arrives: duplicates, mismatches between the receipt and the claim, unverified vendors, claims that look personal, and patterns that only appear across many submissions. ProcAI does the reading. Your team looks only at what it flags.
The problems
Sound familiar?
The same invoice gets paid twice, and nobody notices for months.
The vendor emailed it in March and posted it in April. One copy says INV-1043, the other says 1043. Two people keyed it, two approvers signed it, and the duplicate is discovered when the vendor sends a credit note out of courtesy, or does not.
A vendor that looks real, and is not.
The vendor was created on Tuesday. The first invoice arrived on Wednesday. The bank details were “updated” by email on Thursday. Each step passed through a different person, and none of them saw the other two.
The receipt says 180,000. The claim says 810,000.
A taxi fare rounded up, a dinner claimed twice, a single purchase split into two claims to stay under the approval threshold. Small enough individually that no one checks, frequent enough to add up.
Dinner with a client, at a table for one, on a Saturday.
Groceries coded as office supplies, a family hotel stay attached to a conference, fuel on a week with no travel. The approver has forty claims to clear and no way to tell which one deserves a question.
Controls that depend on someone happening to remember.
The check exists in the policy document. Whether it happens depends on who is on shift, how busy they are and whether the vendor name rings a bell. That is not a control. It is a hope.
Your new use case with Procapy
What fraud & risk looks like once Procapy runs it.
Duplicate detection on every submission.
Every incoming invoice and claim is matched on vendor, amount, invoice number and date against everything already in the system, across entities and across expenses and AP. Near-duplicates are caught too: the same amount with a reformatted invoice number, or the same receipt image submitted by two people. The match is shown to the approver with the original alongside.
The receipt is read and compared to the claim.
ProcAI extracts merchant, date, amount, currency and tax from the receipt image and compares each to what the employee typed. A mismatch is flagged on the line before the approver sees it. The receipt image and the claimed values are kept together, permanently.
Vendor onboarding that verifies before it trusts.
New vendors require a tax registration, ownership details and bank account evidence before they can be invoiced against. Procapy checks for near-identical vendor names and bank accounts already in the master, and any change to bank details triggers a separate approval, by a different person from the one who made the change.
Three-way match for invoices against a purchase order.
Invoice quantity and price are matched to the PO and to the goods receipt within tolerances you set. An invoice with no PO, or one that exceeds the PO, routes to a different, stricter approval chain rather than the default one.
Pattern checks across many claims, not one at a time.
ProcAI looks for claims split to stay under thresholds, repeated round-number amounts, the same merchant across consecutive days, weekend and out-of-hours spend, and frequency that deviates from the employee’s own history. The single claim looks fine. The pattern does not.
Personal-versus-business signals, surfaced to the approver.
Meals require attendees and a purpose, with per-head caps. Travel claims are checked against the trip dates and destination on the request. Category rules flag merchants that rarely have a business reason. The approver sees the signal next to the approve button, and the question gets asked.
Segregation of duties that the system enforces.
The person who creates a vendor cannot approve its invoices. The requester cannot approve their own claim. The person who approves a payment cannot release it. These are configuration rules, checked at setup, not reminders in a policy document.
Risk scoring that decides where attention goes.
Each transaction carries a risk score built from the checks above. Low-risk items flow through the standard chain. Flagged items are held in an exceptions queue for individual review, separated from bulk approvals, so a busy approver cannot wave them through with everything else.
Every override recorded with its reason.
A flag can be overridden, but only with a written justification, and the override is stored on the transaction with the name of the person who made it. The exception becomes evidence rather than a gap.
Controls at the payment stage, not only at approval.
Before a payment file is generated, the bank account on each payment is checked against the verified vendor master. A payment to an account that changed since the invoice was approved is held until the change has been approved. Payment release requires dual authorisation.
Reporting that shows the control is working.
Flag rates by type, exceptions by department and entity, overrides by approver, and repeat patterns by employee or vendor, over any period. Your audit committee gets evidence that the checks ran, not a description of what they were meant to do.
See what ProcAI flags in your own data.
Bring a month of expense claims and vendor invoices to a 30-minute session and we will run them through the duplicate, mismatch and policy checks live.