It is the same invoice. It has a different reference.
A duplicate payment almost never looks like one. The vendor chases an unpaid bill and emails the invoice again with a new number on it. A PDF gets keyed on Tuesday by the person covering, and again on Thursday by the person who owns the account. A credit is issued against one copy and the other one is still sitting in the run. By the time it is caught, the money has left, and getting it back is a phone call to a vendor who has no reason to hurry.
Flags a matching vendor, amount, and invoice-number pattern before the payment executes. Nothing pays automatically -- you decide.
What you get with duplicate detection
A payables ledger where every bill carries its vendor, its reference, its amount and its link back to the purchase order it came from, and where nothing is paid without a payment being registered against it. Vendor records hold the banking details, the payment terms and the payable account, and count the supplier invoices and purchase orders already against that partner. The AP dashboard is the journal view with live bills-to-pay counters on it.
Where duplicate detection comes from
All of it is Odoo Community, no module to add, no tier to reach, no extra per-user fee, and the deployment is yours. NetSuite bills the same payables stack as a module and a per-seat renewal; in Odoo the ledger is already included, and that difference is the product.
One thing is genuinely absent, and it is the thing that creates the problem this page is about. Stock Community has no document capture: no OCR model, no extraction field on a bill, nothing that reads a PDF. Every bill is keyed by a person or arrives through the email alias as an attachment that stays an attachment. Two people keying the same invoice produce two records with different references, and nothing in the ledger has ever seen the document that would tell them apart. There is also no alerting layer to lean on: the dashboard is a set of counters, with no configurable KPI or alert screen behind it.
What the agent adds to duplicate detection
Your team stops reading the payment run line by line to find the one bill that is already paid. The agent reads the whole run before it executes and looks for the near-duplicate, the same vendor, the same amount, a reference that is close rather than identical, which is the shape the real ones take. Then it does the part that matters: it checks whether it is a true duplicate or a legitimate repeat charge, because a monthly retainer billed at the same amount by the same vendor looks identical to a double-key and must not be held. What it cannot resolve it escalates, the two records side by side, and holds the payment until a person answers. It flags and holds, it never releases or cancels a payment on its own.
This is a real recorded demo run, not a claim of production use at a customer -- Del AI has completed no migrations for a customer yet.
What is a duplicate payment in accounts payable?
A duplicate payment is a second payment made against an obligation that has already been settled, the same invoice paid twice, or the same underlying charge paid once through an invoice and once through a statement, a card, or a second invoice the vendor issued for it. It is distinct from an overpayment, where the amount is wrong on a single transaction, because in a duplicate every individual transaction is correct in isolation and only the pair is wrong. That is what makes it hard to catch after the fact: nothing in the ledger is out of balance, no account is misstated, and the only evidence is that two records describe one event.
Why does an exact-match duplicate check miss most duplicates?
Because the duplicates that survive into a payment run are the ones that are not exact. A check keyed on vendor, invoice number and amount together will catch the same record entered twice with the same reference, which is the case a careful team rarely produces. What it will not catch is a vendor re-issuing a chased invoice under a new number, the same document keyed by two people who transcribed the reference differently, an invoice entered once against the vendor's head office and once against a subsidiary record, or the same charge arriving once as an invoice and once on a statement. In each of those the amount and the vendor agree and the reference does not, so exact matching reports a clean run. The check that finds them has to treat near-agreement as a signal and then decide whether it is a duplicate or a coincidence, which is a judgement rather than a comparison.
What should an AP agent do when it finds a possible duplicate payment?
It should hold the payment and show both records, rather than either paying or deleting. Both automatic outcomes are wrong for the same reason: a possible duplicate is genuinely ambiguous, and the ambiguity is the useful information. A recurring charge from a subscription vendor is identical to a double-key on every field a machine can see, and cancelling it holds up a service; a genuine duplicate paid because the run could not be delayed is money that leaves the business and comes back only if a vendor chooses to return it. The behaviour worth having is narrow: name the two records, name the fields that agree and the field that does not, say which of the two is already paid or scheduled, and stop until someone decides. Speed is the wrong objective on exactly the transactions that most need a person. Oracle sells the opposite emphasis on NetSuite's accounts payable page, where purchase order matching exists to "avoid overpayments or duplicate payments and reduce the risk of invoice fraud". Matching against a purchase order does prevent one family of duplicates, the ones that arrive against a known order. It has nothing to say about the invoice that never had an order behind it, which is where most indirect spend lives.
Can you recover a duplicate payment after it has left?
Sometimes, and the difficulty is commercial rather than technical. Once the money has gone, recovery depends on the vendor agreeing that it was overpaid and either returning the funds or issuing a credit note to be applied against future invoices, which is a negotiation with a counterparty who is holding the money and is under no operational pressure to move quickly. Credits are the common outcome, and a credit is only worth its face value if there is future spend with that vendor to apply it to; against a supplier you have stopped using, it is worth considerably less. This asymmetry is the practical case for catching duplicates before a payment run rather than in a reconciliation afterwards: the pre-payment check costs a person a minute, and the post-payment recovery costs a relationship and an uncertain amount of time.