Tensor LabsTENSORLABS

You paid that invoice twice

Probabilistic record linkage across invoices, purchase orders, and receipts catches the duplicate payments that single-document AP checks cannot see.

July 27, 20264 min read4 sectionsBy Ahmed Abdullah
A close-up of a messy stack of orange papers and files

Three invoices, each paid twice

Two numbers refused to agree at quarter close. The ERP said the company had paid a logistics vendor 214,000 dollars. The vendor's own statement of account said 196,000. Finance assumed the vendor's books were behind, until the vendor sent the ledger and the awkward truth surfaced: the extra 18,000 was not missing from their side. It was duplicated on ours. Three invoices, each paid twice.

None of the duplicates looked like duplicates. One arrived first as a PDF attachment and again three weeks later through the vendor portal, with a new invoice number, because the vendor's system reissues numbers on resend. One was a scanned copy with a handwritten note that shifted the OCR just enough. One was the same charge split across two smaller invoices after a dispute, alongside the original that was never voided. The AP automation, which the company was proud of, had processed all of them flawlessly. Each document, read alone, was perfectly valid. That was the whole problem: every check the system ran was a single-document check.

Your AP pipeline reads every invoice correctly and still pays some of them twice, because reading was never the hard part. Matching is.

What duplicate payments actually cost

Duplicate payments are a quiet, well-measured leak. Audit firms that recover them for a living report typical findings of 0.1 to 0.5 percent of AP spend, which sounds small until you put your own number through it: a company paying 40 million a year through AP is leaking somewhere between 40,000 and 200,000, every year, to nobody's benefit. No fraudster, no breach, no villain. Just documents that describe the same obligation without resembling each other.

The classic control, exact match on vendor plus invoice number plus amount, catches the duplicate that arrives as a literal copy. It is blind to every variant that matters: reissued numbers, OCR drift, split invoices, currency-converted resubmissions, a vendor that exists twice in the master file under two spellings. The duplicates that survive are, by construction, the ones that look least like duplicates.

Match the obligation, not the document

The method is cross-document record linkage, the same discipline that deduplicates patient records and merges customer identities, pointed at the payables stream. Instead of asking "have I seen this invoice before," the system links every invoice to its purchase order and its goods-receipt or delivery confirmation, the classic three-way match, and then goes one step further: it asks, probabilistically, whether this obligation already exists in any form.

That means fuzzy vendor resolution first, because two vendor-master entries with one transposed word are the root of a remarkable share of duplicates. Then similarity scoring across the extracted fields: amounts within tolerance bands rather than exact, dates within plausible resend windows, line items compared as sets so a split invoice still sums against its sibling. Each candidate pair gets a match score. High-confidence duplicates block automatically; the ambiguous middle goes to a human queue with both documents side by side and the evidence highlighted, a thirty-second decision instead of a forensic project. We built this layer for our own document pipelines after watching single-document validation wave through a resend with a fresh invoice number.

(The three-way match is decades old. What changed is that extraction got good enough to feed it: the match logic is only as strong as the fields coming off the scans, which is why the linkage layer and the extraction layer have to be engineered together, not bolted.)

Tolerances are where the judgment lives. Too tight and the queue floods with false pairs; too loose and the split-invoice trick walks through. Setting them per vendor, per amount band, from your own history of confirmed duplicates is a calibration exercise, not a config default.

The number worth knowing before any software

The company with the 18,000-dollar quarter ran the linkage retroactively across two years of paid invoices. Confirmed duplicates: 340,000 dollars, of which about 260,000 proved recoverable through vendor credits. Recovered money from documents everyone had already read.

TensorLabs builds this matching layer on top of whatever AP extraction you already run. If you have never once found a duplicate payment, that is not evidence you have none; single-document checks cannot see them by design. Tell us your annual AP volume and we will put a defensible range on what your history is hiding.