Where this engagement started
A regional PE fund processing invoices across a portfolio of operating companies wanted to stop
hand-keying invoice data into the accounting system. That part was straightforward: invoice extraction
is a solved problem.
The harder problem was the trust layer. Vendor banking details quietly drift over time. Sometimes
legitimately, when a vendor moves banks or updates account details. Sometimes maliciously, when a bad
actor changes the banking details on a real invoice and intercepts the payment. AP teams do not always
notice the change. Finance often finds out months later, in a forensic review, after the money has moved.
Most invoice-automation systems skip this check. They extract faster, but they do not verify. Faster
extraction without verification is faster fraud risk. The brief was to build invoice parsing with the
trust layer baked in, so a vendor-banking-detail change cannot slide into a payment file unnoticed.
What the system actually does: the dual-rail check
Every invoice that lands in the inbox is parsed and structured. Then it runs through two parallel checks
before any payment is built.
The vendor-master rail. Every invoice is checked against the master record of every
vendor the business has paid before. The system does not just look up the vendor name. It compares the
banking details on the new invoice against the banking details on the master record. If the bank account
number, the bank name, or the SWIFT code has changed, the payment is held. A human reviewer gets an
auto-context email with the variance highlighted: "Vendor banking details on this invoice do not match
the master record. Review before release." No payment moves until a human signs off.
The duplicate rail. Every invoice is also checked against the live ledger of every
invoice already processed. The system catches both exact duplicates, like the same invoice number paid
twice, and suspicious duplicates, like the same invoice number with slightly different banking details.
Both rails must pass before the invoice is queued for payment.
The invoice only reaches the payment file once both rails are clean.
When something fails: the audit trail
The failure path is not an exception; it is part of the workflow. When either rail catches a problem, the
system emails the finance team with the variance highlighted, the original invoice attached, and a
context block describing why the check held it. The reviewer makes the call: pay, hold for vendor
confirmation, or escalate.
Every processed invoice has a traceable record. Every payment file is built only after verified
invoices, never bulk-released. An auditor reviewing the system can trace any payment back to the parsed
invoice, the verification result, and the reviewer who signed off.
What this looks like for your AP
Sound familiar? Your AP team hand-keys invoices. You have found a banking-detail variance in a forensic
review. Auditors ask for a vendor-master verification trail and you cannot produce one. The dual-rail
invoice path is what closes the gap.
The first call tells you whether the architecture above fits your AP volume, where the riskiest exposure
points are, and what the first 60 days would cost.
