A duplicate vendor record is a second entry in the vendor master for a supplier that already has one, under a variant of its name, address or tax ID. Each record carries its own open bills and payment history, so one invoice can clear twice, once through each record. Duplicate vendor payments of this kind start in master data.
Rever leaves your vendor master as it is. Its connections are read-only, and its agents look for the effects of a second record before money leaves: Spend Guard screens bills and payments for the same item under different identifiers, Matcher compares vendor identity and payment references field by field, and Sentinel checks changes to vendor master and bank details. Your team decides each case in the Inbox.
Where the second record comes from
A vendor master collects duplicates through ordinary work. A supplier changes its trading name after an acquisition, and someone in purchasing creates a new record instead of editing the old one. A new remittance address arrives, and AP sets the vendor up again. An acquired company's vendors come across in an import, and the suppliers the two companies shared now exist twice. Small format differences hide the overlap from a casual search: "Acme Inc" against "ACME, Inc.", a tax ID with a hyphen against one without, a street abbreviation against the full word.
The second record causes harm at the invoice. A supplier emails a PDF and mails a paper copy, or resends an unpaid bill with a new date. AP keys one copy against each record. A typical ERP warns about a duplicate bill when the same vendor sends the same invoice number twice, and a second vendor record defeats that check, because the system sees two vendors. An approver signs both bills, both enter a payment run, and the supplier receives the money twice.
A duplicate payment is a payment made more than once for the same obligation. Preventing duplicate payments across the whole AP process, from invoice entry to the payment run, is a topic of its own, and the vendor record is one of its causes.
Duplicate records carry a second risk. A record with different bank details gives a fraudster a place to send money, whether someone creates a fake "new" vendor or changes the bank account on a dormant one. Verifying a vendor bank-detail change is its own procedure, and the last control below covers the part that belongs to the vendor master.
Controls on the vendor master
Vendor master hygiene comes down to a few habits, each owned by a named person:
- Search before you create. Require a search on legal name, tax ID and bank account before anyone adds a vendor, and record the result.
- Separate the duties. The person who creates or edits a vendor record should not be the person who enters bills or releases payments to that vendor.
- Require the identifying fields. A record without a tax ID or a legal name is hard to compare with anything, so make those fields mandatory.
- Review on a schedule. Pull near-duplicate names, shared tax IDs, shared bank accounts and dormant records, then merge or deactivate them while keeping the payment history.
- Verify bank-detail changes away from the request. Call the vendor on a number already on file, and ignore any contact details that came with the change.
Each control depends on someone running it, and a scheduled review finds a new duplicate at the next cycle, after any payment it caused.
Duplicate vendor payments: what Spend Guard checks before payment
Spend Guard detects exact and near duplicates across budgets, purchase orders, bills, claims and payments, including different identifiers for the same economic item. Two vendor records billing the same service period is the case that matters here. Spend Guard also separates a valid recurring charge, a partial invoice or an instalment from an unintended duplicate, so a monthly subscription does not trip the check.
Matcher supplies the field-level comparison behind each duplicate finding. It matches vendor legal identity, entity, contractual identifiers and payment references, and it refers protected bank-master differences to Sentinel. The comparison shows your AP lead why two records look like one supplier, with each difference cited.
Spend Guard aims to stop the payment before the run. It proposes a hold, a cancellation or a credit request with the support attached. A hold needs Inbox approval before it is recorded in Rever, and your team applies it in the payment run. After your team acts, Spend Guard verifies that the cancellation, credit or refund took effect in the source. The accounts payable capability shows where this sits in the payment run.
Sentinel and the changed bank account
Sentinel compares party, address, bank and other master details across the original documents, recent documents and the master change history, and it checks authorisation through a route independent of the changed details. For a bank-detail change, Sentinel "prepares an independent human callback using a previously trusted contact and known-good details, and never relies on contact details supplied with the change." Sentinel also reviews activity on dormant or new parties as a risk indicator.
Each Sentinel finding states whether the concern is suspected, supported or disproved. Indicators alone do not establish fraud, and no setting lets an agent place a payment hold on its own. Continuous controls monitoring covers the wider watch that Sentinel, Steward and Auditor keep over approvals and system health.
For records already paid, the zero-day scan applies the relevant reconciliations, verifications and controls to the in-scope population of your connected records, and duplicate payments are among the checks Spend Guard runs.
