Fifteen fraud signals before anyone approves. A match gate that blocks. Three checkpoints between approved and gone.
Nine stages. Three of them can stop the bill entirely.
It lands in the Inbox unread. No extraction, no coding, no record created. Deliberately inert until a person engages.
One click. AI pulls the header and line detail into a draft you can correct, park, or discard. The draft is yours until you submit it.
Typosquatted vendors, bank details changed just before invoicing, amounts shaved under an approval limit, same-day splits, anomalies against the vendor's own history.
Purchase order, goods receipt and invoice compared line by line. Service lines use two-way automatically, since nothing physical arrived.
By amount, department, project or category. Whoever keyed the bill cannot approve it. If an approver is on leave, their delegate inherits real authority — and it reverts on schedule.
With the variance, the fraud result and the match evidence already attached — not as a bare exception to go chase.
ACH, domestic wire, printed check or international SWIFT. Individually, never in a batch. A cancel window opens immediately.
Funds are drawn, then held. At the moment of execution the vendor's bank details are read again and compared to what was scheduled.
Released through a licensed money-mover — the funds never sit on our balance sheet. The bill is now immutable. Corrections from here are reversals, with amounts derived from the original.
Payment fraud rarely looks like fraud. It looks like a familiar vendor and a short note saying the bank details changed. PayCure screens deterministically — the same input gives the same result every time, and every flag traces to a named rule you can show an auditor.
Separation of duties is easy to write into a policy and hard to keep alive when someone's on leave. These are enforced in software — switchable, thresholdable, overridable with a written reason, but never bypassed quietly.
| Control | What it stops |
|---|---|
| Enter ≠ approve | Approving your own entry |
| Approve ≠ pay | Approving and releasing the payment |
| Onboard ≠ approve vendor | Creating a payee and activating it |
| Change ≠ verify bank | Changing bank details and confirming them |
| Issue ≠ reverse credit | Issuing a credit and reversing it unseen |
| + four more, each configurable | |
Paying fifty bills with one click is how a wrong amount leaves the building unnoticed. Bills are scheduled and released individually, so each amount is seen. Slightly more clicking; dramatically less exposure.
Why the last check matters. The gap between scheduling and execution is the most exposed window in AP. A vendor's bank details can change inside it — sometimes legitimately, sometimes not. Reading them again at execution closes that window entirely.
The quiet risk in most AP systems is the edit — a posted bill amended, a paid invoice voided and re-entered, and the record of what actually happened simply gone. Nothing looks wrong afterwards, which is the problem.
Why derived, not typed. A hand-keyed reversal can be keyed wrong, and a wrong reversal against a paid bill is among the hardest errors to find — both documents look individually reasonable. Deriving the figure removes the opportunity.
When the PO and the receipt are created in the same system, there is nothing to reconcile across tools — the match reads the same records the buyer and the warehouse wrote.