“But Oracle Would Have Caught That”: Oracle Duplicate Invoice Myths
A while back I wrote about the myths around SAP’s duplicate invoice check. The reaction I get in Oracle shops is exactly the same. When we run AP.guru against an Oracle Payables environment and show them the duplicate payments we found, someone always says: “But Oracle checks for that. How did these get through?”
Oracle does check. But like every ERP, what it actually catches depends entirely on how it’s configured, and the defaults leave real gaps. Here’s how it works, and where it doesn’t.
What Oracle actually checks
In Oracle Fusion Cloud Payables, the duplicate check is governed by Invoice Options, which are set per invoice business unit. When the check finds a match during validation, it applies a Duplicate Invoice Hold: the invoice parks there until someone deals with it.
Out of the box, that check leans heavily on the supplier + invoice number. Oracle also offers a stronger, multi-attribute check, matching on the combination of supplier, invoice type, amount, currency, and date, but you have to turn it on. Both behaviors are described in Oracle’s own documentation. And once you understand those two facts, the gaps write themselves.
Myth 1: “It checks across our whole company”
Invoice Options are configured per business unit. So the duplicate check runs within a business unit: an invoice entered in one BU is not compared against invoices in another. For shared-service or multi-entity organizations, that’s real exposure: the same invoice can be paid in two business units, and each check sees nothing wrong. It’s common enough that Oracle’s own community forums have long-running threads asking how to check across business units. If you run more than one BU, this is the first place to look.
Myth 2: “It’ll catch a re-keyed invoice”
By default, the check is invoice-number-centric within a supplier. Change the invoice number by a single character, such as a trailing “A”, a “-1”, or a dropped leading zero, and Oracle treats it as a brand-new invoice.
To catch the same supplier, amount, currency, and date under a different invoice number, you have to enable Oracle’s enhanced multi-attribute check. It’s a standard lookup: Lookup Type ADD_DUPLICATE_INV_CHECK with code DUPLICATE_INVOICE_CHECK. Turn it on and Oracle evaluates the whole combination across every invoice from that supplier, not just the number. It’s genuinely useful. In my experience, most shops have never enabled it.
Myth 3: “A duplicate simply can’t be paid”
This is the one that surprises people most. Oracle applies a hold, not a hard block. A Duplicate Invoice Hold parks the invoice during validation, but holds get released. Worse, Oracle will automatically release the duplicate hold if the duplicate conditions no longer apply. So if someone edits a field enough to break the match, the hold clears itself.
A hold is a speed bump, not a wall. And under volume pressure, speed bumps get driven over.
Myth 4: “Currency doesn’t matter”
The enhanced check keys on currency alongside amount and date. For a single-currency operation that’s fine. For a multi-currency operating company, the same invoice processed under two currency codes may not be seen as a match. It’s a narrow gap, but for global organizations it adds up, and it’s the same gap that exists in SAP.
And don’t forget the payment run
Even if your invoice-entry controls are perfect, disbursement is a separate step. Payment Process Requests have their own grouping and selection rules. If those aren’t configured to group or block identical items before payment, a duplicate can still slip through at pay time. Entry controls and payment controls are two different fences: you need both.
Where to look in your Oracle system
In Fusion Cloud:
- Setup and Maintenance → Manage Invoice Options (for each business unit): confirm the duplicate-check matching parameters and that Enable duplicate invoice hold during validation is on.
- Setup and Maintenance → Manage Standard Lookups: check whether Lookup Type
ADD_DUPLICATE_INV_CHECK(codeDUPLICATE_INVOICE_CHECK) exists and is enabled: that’s the switch for multi-attribute matching. - Manage Payment Process Profiles / PPR grouping rules: your last line of defense at disbursement.
Running on-premise E-Business Suite instead? The mechanics differ, but the same idea holds: duplicate checking is supplier- and site-driven, and just as dependent on how it’s set up.
The bottom line
Oracle’s duplicate check is a floor, not a guarantee. It runs within a business unit, leans on the invoice number unless you enable the multi-attribute check, keys on currency, and applies a hold that can be released. None of that means Oracle is broken. It means the control does exactly what it’s configured to do, and most organizations have never looked closely at how theirs is set. Same lesson as SAP: know your configuration, or the “impossible” duplicates aren’t impossible at all.
Source: Oracle Help Center, Guidelines for Invoice Options and finding duplicate invoices beyond the invoice number.
Want to know what’s getting through in your Oracle environment? Start a no-cost Proof of Value. We only get paid a percentage of what we recover.
Karl has spent 25+ years in AP auditing and analytics, helping finance teams recover lost value and understand their payables. He writes about what he’s actually seen in the field. Read his story →