EigenForge AI Labs Talk to us

Blog

The invoice that was paid twice

Somewhere in this quarter's payables is an invoice that was paid twice, and another that was billed above the contracted rate. Sample-based audit will not find them. Reading every line will. Here is how the check works.

← All articles

2026-10-05 · EigenForge AI Labs

Ask a finance function how it knows invoices are correct and the honest answer is: sampling. A fraction of payments gets checked against contracts and receipts, chosen by size or by rotation, because checking every line of every invoice against every contracted rate is more work than the department has people. The rest goes through on trust and workflow.

The losses are not dramatic. Nobody steals a million. A supplier bills at last year's rate. A invoice arrives twice, once through the portal and once by email, and both are paid. A contract says a service is included; the invoice lists it anyway. Each one is small. Together they are a number the audit committee would prefer not to estimate.

Reading everything instead of some of it

The check itself is not exotic. Every invoice line is read against the contract that governs it — the rate, the inclusions, the caps — and against every other payment in the period, so that the same obligation arriving twice shows up as a pair, not as two lonely transactions. What makes it possible is that the reading happens where the records already sit: the ERP, the contract store, the payment run. Nothing is exported, reconciled in a spreadsheet, and argued about later.

What comes out is not a report of all invoices. It is an exception list — the short list of payments that need a human decision, each with the evidence attached: the contract clause, the matching pair, the rate that changed.

What the exception list looks like

A duplicate is rarely exact. The same supplier, the same amount, nine days apart, referenced to the same purchase order with one character different in the invoice number. A human checker skimming a thousand lines does not see it. A check that compares everything against everything sees it every time, and says precisely why it thinks so.

The same pass finds the rate drift — billed at 4 percent above the contracted schedule — and the included service billed anyway. Each lands on the exception list with the two documents side by side.

THE COMMON APPROACHChunk, embed, retrieve bysimilarity✕Parent–child relationships are lost✕Joins cannot be rebuilt from similarity✕The copy drifts from the source✕Fluent, confident, sometimes wrong✕Content leaves the boundary to be embeddedAN ONTOLOGY OVER LIVE DATAModel relationships, resolve,query✓Table relationships preserved, joins correct✓Answers generated from live records, never from a stale copy✓Every answer traces back to records✓Policy applied at query time, per user✓Runs against a local model — nothing leavesIs it answering from a copy of your data, or from your data?
Exhibit 01Every exception traces to the exact records that produced it.

Why finance trusts it

Because it is verifiable line by line. Every item on the exception list can be traced to the exact records that produced it, and any figure can be reconstructed as it stood on the day the run happened. The department's own audit trail is the evidence, not a vendor's summary of it.

And because the decision stays with the officer. The check finds and evidences; it does not claw anything back, write to the ERP, or accuse anyone. Recovery, dispute and supplier conversations remain human acts — which is exactly why this works as a first engagement, in government finance and in commercial payables alike.

use casepublic finance

Disagree with this?

These are written to be argued with. If you think this is wrong, we would rather hear it than not.

hello@eigenforgelabs.ai

Send opens your email client with the note already addressed to us — nothing is stored on this site, and the message goes from your own mailbox, so our reply lands in yours.