Every AP team has a duplicate-invoice check. Most of them are weaker than they look.
The typical check asks one question: have we seen this invoice number before? If yes, flag it. That catches the obvious re-sends, but it misses the more expensive failure — and it gives suppliers an answer that's often wrong.
The reason is simple. "Is this a duplicate?" and "has this already been paid?" are different questions, and the difference is exactly where double-payments happen.
A duplicate is not one thing
When a supplier resends an invoice, that invoice can be in one of several states inside Oracle Fusion Cloud ERP:
- Not yet processed — it's sitting in the queue, mid-extraction or awaiting approval.
- Validated and scheduled — it's been approved and is queued for the next payment run.
- Already paid — it cleared, and remittance has been sent.
A check that only matches invoice numbers collapses all three into "duplicate, flagged." But the right action is different for each — and getting it wrong is what causes the costly mistakes.
The worst case: an invoice that's already paid comes back in, your number-only check doesn't recognize it as paid, and it slips into the workflow as if it were new. Now you're one approval away from paying it twice. Recovering an overpayment from a supplier is slow, awkward work — and in healthcare, where the same supplier might bill hundreds of times a month, it's not rare.
The fix: read live payment status, not just the invoice number
The durable answer is to check the invoice against Fusion's live payment records, not just your own history of invoice numbers. Oracle Fusion's AP Invoices REST data already carries the fields you need on an existing invoice:
- Payment status — paid, partially paid, not paid, or cancelled.
- Payment date — when the most recent payment cleared.
- Paid amount — how much has been paid to date.
- Currency — so the figures you quote back are unambiguous.
The key insight is that you don't need to build any of this. Fusion already knows whether an invoice was paid; the job of the AP layer is to query that status at the moment of duplicate detection and branch on it — rather than treating "we've seen this number" as the end of the investigation.
That's a small change in where you look, and a large change in what you can safely automate.
One match, three responses
Once you know the live status, the duplicate stops being a dead-end flag and becomes a decision with a correct reply for each branch:
- Not yet processed → "This invoice is already with us and is being processed. No need to resend."
- Validated and scheduled → "This invoice is approved and scheduled for our next payment run."
- Already paid → "This invoice was paid on [date], and remittance advice has been sent to the email on file."
That last reply does two jobs at once. It closes the loop with the supplier and it stops the already-paid invoice from re-entering the workflow — because the system recognized it as paid, not merely as familiar.
This applies to both PO and non-PO invoices. Non-PO invoices have no purchase order to anchor against, which makes a robust duplicate-and-payment check even more important: there's no three-way match standing between a re-sent non-PO invoice and a second payment.
Why this matters more in healthcare
Healthcare AP carries a long tail of high-frequency suppliers — pharmacy, food services, clinical consumables, utilities — billing constantly across multiple sites and operating units. High frequency means more re-sends, more statements listing invoices you've already handled, and more chances for an already-paid invoice to circle back.
It also means the supplier-email volume around payment status is enormous. "Did you get my invoice?" and "When am I getting paid?" are some of the most common messages an AP inbox receives. Once you're already reading live payment status to catch duplicates, you can use the same lookup to answer those emails automatically — turning a status check into AI email exception prevention that takes the chasing off your team's plate entirely.
Where this sits in the bigger picture
Duplicate-and-paid detection is one branch of a much larger decision tree — the full set of invoice scenarios a healthcare AP team handles on Fusion, from credit notes to partial receipts to urgent stop-service demands. The common thread across all of them is the same: the value isn't in reading the document, it's in checking live ERP context and taking the right action.
Doing that on Fusion means integrating the way Oracle supports — validating against live invoice and payment data over Oracle Integration Cloud (OIC) REST, and posting through FBDI load rather than custom base-table writes. You can see how that integration is built on our Oracle EBS and Fusion integration page.
Where EZ Cloud fits
EZ Cloud checks every incoming invoice against its live status in Oracle Fusion — not just whether the number has been seen, but whether it's pending, scheduled, or already paid — and responds correctly to each. Already-paid invoices are stopped before they can re-enter the workflow, and the supplier gets an accurate, automatic reply with the payment date and remittance status.
If duplicate re-sends and the occasional double-payment are quietly costing your AP team, that's exactly the failure mode we close for healthcare finance teams on Oracle Fusion.