A duplicate payment costs about four times the invoice to recover

An invoice arrives in the AP email box on the 3rd. The vendor emails it again on the 11th because nobody confirmed receipt. It also appears on their month-end statement, which somebody at a property forwards on the 28th.

Three submissions, one obligation. If two clear, you have paid twice, and getting one back is harder than not paying it was.

Five ways the same invoice arrives twice

Vendor resubmission. The most common. A vendor with no visibility into your process re-sends after a week of silence. Entirely reasonable behavior on their part.

Multiple intake channels. The invoice emailed to AP and also handed to the property manager, who uploads it. Two paths, two records, and neither channel knows about the other.

Statement forwarding. A vendor statement listing open invoices gets forwarded and processed as though it were an invoice. This one creates duplicates that do not look like duplicates, because the document type is different.

Slightly altered invoice number. INV-4471 and 4471, or the same number with a different prefix after the vendor changed systems. Exact-match duplicate checks miss all of these.

Reprocessing after a correction. An invoice rejected for a coding error, corrected, resubmitted, and the original never actually cancelled.

Notice that only the first is about the vendor. The other four are about your intake having more than one door and no shared memory across them.

The recovery cost is the part people underestimate

Paying twice is an accounting error. Recovering it is a collections effort against your own vendor.

What it involves: identifying the duplicate, which frequently happens weeks later during a reconciliation. Contacting the vendor. Waiting for them to confirm. Then either receiving a refund, which requires the vendor to have the cash and the willingness, or accepting a credit memo against future invoices, which means carrying the balance until you buy enough from them to absorb it.

Staff time across that arc, plus the reconciliation time to find it, plus the accounting entries to correct it, runs to several multiples of the invoice's original processing cost. Somewhere around four times is a reasonable planning assumption, and it is worse for a small invoice because the fixed effort does not scale down.

Detection has to be fuzzy or it catches almost nothing

An exact match on vendor plus invoice number plus amount catches the honest resubmission and nothing else.

The checks that catch the rest:

Vendor plus amount plus date proximity, ignoring the invoice number entirely. Two invoices from the same vendor for the same amount within a few days are worth a look even with different numbers.

Normalized invoice number. Strip prefixes, leading zeros, and punctuation before comparing, so INV-04471 and 4471 collide.

Vendor plus amount across a wider window for recurring vendors, which needs care because a landscaper legitimately bills the same amount monthly. Same amount, same vendor, same month is a duplicate. Same amount, same vendor, consecutive months is a contract.

Document type filtering before any of this, so a statement never enters the invoice pipeline in the first place. Separating W-9s, insurance certificates, statements, and delivery notes out at intake removes the entire statement-forwarding category.

BillRoute does duplicate detection before approval, and non-invoice document filtering that routes statements and certificates to a Not accepted queue rather than into the invoice flow. Both matter and the second one prevents a class of duplicate the first would have to catch later.

One intake channel is the structural fix

Detection is a control. Single intake is prevention.

If invoices can arrive by email, by upload from a property, and through a vendor portal, then three records can exist for one obligation and each channel has to trust a shared duplicate check. That works and it is strictly harder than having one door.

The version that reduces duplicates most is a vendor-facing path where the vendor can see that their invoice was received and what its status is. A vendor who can check does not re-send, which removes the largest single cause rather than detecting it.

Three-way match catches a different failure and misses this one

Worth distinguishing, because these get conflated.

Duplicate detection asks whether you have seen this invoice before.

Three-way match asks whether this invoice corresponds to a purchase order and a receipt of goods. It catches an invoice for something you never ordered or never received, which is a different failure from paying the same thing twice.

An invoice can be a perfect three-way match and still be a duplicate, if the first copy also matched. So the PO-backed population needs both checks, and a system that treats matching as sufficient will pay some invoices twice.

What we do and where the boundary is

Duplicate detection before approval, non-invoice document filtering, and a Not accepted queue for both. Validation against the supplier master and the property chart of accounts, so a mismatch surfaces as a specific named error rather than as a rejection.

Where it stops:

We do not recover a duplicate payment that already went out. Once funds have moved, that is a conversation with your vendor and there is no software step for it.

We do not detect duplicates across systems we do not see. An invoice paid outside BillRoute, on a card or by a property-level check, is invisible to the check.

We do not decide whether two similar invoices are actually the same obligation. Detection flags candidates and a person confirms, because a recurring monthly charge and a duplicate look identical to a rule.

Run the backward pass

Take twelve months of paid invoices. Group by vendor and amount. Look at every group with two or more entries within the same calendar month.

The list will be shorter than you fear and longer than zero, and everything on it is money you can ask for back.

How many groups came up?