You tested 60 invoices. The duplicates were in the other 48,140.

What comes back

Not a score and not a dashboard. A finding you can put in a file.

Coverage

Every invoice in the period is tested, with the count for each control shown next to its denominator — including the controls that returned nothing.

Evidence

Each finding carries the fields that matched, a plain-English reason, and a trace to the rule and the ruleset version that raised it.

Precision

Shown with its denominator. You see what was confirmed, out of what was raised, rather than a confidence percentage with nothing behind it.

Your rules

The seventeen checks we ship are a starting point, not the product. You can add your own — a threshold your controller argues about, a supplier pattern only your team knows — and tighten or retire ours.

Writing one

In plain English. You describe what you are trying to catch, an assistant turns it into the rule that will run, and it shows you the transactions that rule would have caught before anything changes — nothing it does lands without you approving it. What you end up deploying is a rule you can read, not a model's opinion you have to take on faith. Which is what makes the next line matter.

Refusals

Before a ruleset goes live you can replay it over your already-adjudicated alerts. If it would suppress a finding an analyst confirmed, the deploy is blocked. Going ahead anyway takes a written reason, and that override — who, when, and why — is what lands in the change log.

What it looks for

Duplicate payment first, because it is the one we have gone deepest on and the one whose name makes it sound easy. It is not a string match on an invoice number. Here are five ways a duplicate walks past a conventional AP check, and what catches each one anyway.

A second vendor record

The same supplier sits twice in your master — a legacy row, an acquisition, a tax ID re-keyed by someone in a hurry — and the second bill goes in under the other record. A check that looks for duplicates within a vendor never sees the sibling. The catch is expanding to the master vendor first, so both records are one supplier before anything is compared.

Inside a recurring stream

A supplier that legitimately bills the same amount every month bills it twice in one month. Logic that treats a recurring vendor as expected waves it through, and the eleven honest siblings are the camouflage. The catch is clearing the earlier periods and raising only the same-period double.

The attachment disagrees with the keying

What was typed into the system and what the PDF actually says are not the same text. Compare only the keyed lines and the two invoices look unrelated. The matcher compares the union of the keyed entry and the document text on both sides, so the pair still meets.

A second company code

The same document is submitted to a different entity's AP instance — an acquired subsidiary still running its own system, which has never seen the original and holds no PO linkage. Per-instance dedup is blind to this by construction, not by oversight, which is why it is the shape that survives longest. The catch is screening on tax ID across entities.

Tax-inclusive against tax-exclusive

The same gross amount presented with the net and tax split differently. Matching on subtotals misses it; reading the gross with a swapped composition recognises the classic re-billing twin.

And one it should not raise

An invoice fully reversed by a credit note and then re-submitted is not exposure, however much it looks like a duplicate. Detection consults the settlement layer and returns it resolved — the vendor ledger is the arbiter. Handing you a finding you have to disprove is a cost, not a catch.

And the other twelve families, because one check is not a product. Seventeen in total, grouped the way a control owner would group them rather than the way the engine does.

Duplicates — four

The same invoice twice. The same purchase settled twice, whether both times as an invoice, both on a corporate card, or once each way. The same vendor sitting twice in your master. The same item ordered on two purchase orders.

Buying around the process — five

Spend with no purchase order behind it. A purchase order raised after the invoice it is supposed to authorise. A burst of requisitions from one requester that each sit under their approval limit and together do not. A payment that traces back to an invoice nobody approved. An expense claim for something you already have a procurement route for.

The three-way match — three

Quantity billed against quantity ordered and quantity received. An invoice with no goods receipt or service entry behind it — or one entered on the invoice date, which is its own kind of answer. An invoice billing above the purchase orders it draws on, with no surcharge or blanket clause to explain it.

Price and terms — three

A line priced well outside the history for that item. A unit price above what the purchase order says. Payment terms that have drifted from the contracted ones.

Vendor hygiene — two

A transaction against a supplier you blocked or deactivated. A high-value invoice from a supplier with no tax ID on file.

Which of these can run at all is a question about your data, not about us. Invoices and a supplier list support a few of them; purchase orders, receipts, requisitions, contracts and payments each switch on more. Send us invoices alone and four of the seventeen return anything useful — and one of the other thirteen would fire on every row you sent, which is noise wearing a finding's clothes. So we tell you which four ran, and hold the rest back rather than returning thirteen empty controls and letting that read as a clean bill of health.

What it costs, and what it replaces

You already pay a recovery firm a percentage of what they find. Run this over the same period first.

Pricing

A flat annual fee, banded on transaction volume. Never a share of what we find — a revenue share turns a control into an attribution argument.

Recovery firms

Charge 20–40% of recoveries, on contingency, over two to four years of history. Testing the same period first costs you nothing to check.

Seats

The auditor seat is free, permanently. Internal audit should not be paying for a control it may later have to test.

Where we are

Stated plainly, because you are going to ask and because the answer is checkable.

SOC 2

Type I in progress. We will not imply otherwise, and we are happy to start on a departmental or P-Card scope while it completes.

Your data

Nothing is required to see the product. The walkthrough runs on a tenant we built and seeded — we wrote those records, and the engine raised most of what you see from them. A handful of cases are placed by hand, including the two that arrive already adjudicated, because a queue in which nothing has been decided cannot show you what deciding looks like. If you are judging the detection rather than the workflow, those are the ones to discount, and we will point at them.

Who built it

Three of us. Two founded a duplicate-payment detection company that an enterprise spend platform acquired; the third was the data scientist on the product it became. Between us we have started and led AI teams, done the data science, and spent years inside procurement and the ERP tables this reads from — the same invoice, supplier and approval records, from the other side. This is the second time these three people have built duplicate-payment detection over enterprise spend, and the first one is still running at that platform's customers.

In development

Related-party detection over an entity graph — suppliers connected to an employee who approved their requisitions. Not shipped, not counted here.