Ask a vendor how good their AP automation is and they'll quote you an extraction-accuracy number. Ask a healthcare AP manager what eats their week and you'll get a different answer: it's not reading the invoice, it's knowing what to do with it.
A hospital or health-service AP inbox is not a tidy queue of purchase-order invoices waiting to be matched. It's a mixed stream — credit notes, supplier statements, proformas, reimbursement claims, international payment requests, "URGENT, you're about to cut off our service" emails, and the same invoice sent four times. The work isn't volume. It's variety.
When teams move AP onto Oracle Fusion Cloud ERP and bolt a generic OCR tool on top, they discover this the hard way. The OCR reads the document fine. Then it hands a credit note to a workflow that only knows how to three-way match a goods invoice — and a human has to step in. Every time.
Below is the taxonomy a real healthcare AP operation has to handle. We built our scenario model for healthcare finance teams running Oracle Fusion, and it's organized the way the work actually arrives — not the way a demo script wishes it would.
The clean case (and why it's the minority)
PO invoices — goods and services. An invoice arrives carrying a purchase-order number. The system extracts it, validates the PO is open in Fusion, and runs a three-way match against the receipt before posting. Goods and fixed-price services behave slightly differently, but this is the path everyone pictures when they imagine "automated AP."
It's also the easy 60%. The other 40% is where automation projects quietly fail.
Duplicates and already-paid invoices
Suppliers resend. They resend because they're nervous, because remittance was slow, or because two people in their AP team both chased the same invoice. A naive system checks "have I seen this invoice number before" and stops there.
That's not enough on Fusion. You need to know where the invoice is in its lifecycle:
- Not yet processed — it's in the queue. Tell the supplier so and ask them not to resend.
- Validated and scheduled — it's going out on the next payment run.
- Already paid — it cleared, and remittance has gone to the email on file.
A duplicate that's already been paid is a completely different conversation from one that's still pending. Conflating them is how you end up double-paying — or how you generate the supplier email that ties up your team for a week. We cover this case in depth in catching duplicate and already-paid invoices before they double-bill.
Non-PO invoices — coded, uncoded, and everything between
Healthcare runs on non-PO spend: professional services, utilities, memberships, one-off purchases nobody raised a PO for.
- No PO and no coding — the system can't post this blind. The right move is to reply to the sender and request a PO or coding, not to dump it on AP.
- No PO but coded — the GL string is on the document or supplied by the requester. Extract it and route for approval.
Generic tools treat "no PO" as a single bucket. In practice it's two very different workflows with two very different first actions.
Credit notes
A credit note is not a negative invoice you can shove through the same pipe. It has to be recognized as a credit and applied against the correct account so the supplier balance is right. Miss the recognition step and you'll either pay a credit as if it were a charge, or strand it where no one reconciles it.
Statements
Suppliers send statements — and statements look enough like invoices to fool a classifier that's only reading layout.
- A document that says only "Statement" is a statement: route it to AP for reconciliation, don't process it as a payable.
- A document that also says "Invoice" or "Tax Invoice" is an invoice and follows the invoice path.
The valuable move is to take each line on a statement and check its status in Fusion — already paid, scheduled, or not yet seen — so AP gets a reconciled summary instead of a wall of line items to chase manually.
Receipting edge cases
Not-yet-receipted PO invoices. If a PO invoice arrives but no goods receipt exists in Fusion, you can't pay it yet. The invoice goes on hold and the right person — usually the requester who ordered the goods, not AP — gets nudged to confirm receipt.
Partial receipts. This is the one that trips up almost every off-the-shelf tool. A blanket PO gets receipted in stages, and several invoices draw against the same receipted balance over time. Treating "partially receipted" as automatically invalid is wrong — partial receipting is standard practice. The correct test is whether the invoice fits within the remaining receipted balance, accounting for what other in-flight invoices have already committed. We walk through that model in validating invoices against partial receipts in Oracle Fusion.
Documents that aren't invoices at all
A real AP inbox is full of things that should never reach the ledger:
- Sales orders — your supplier's paperwork, not a payable. Identify and exclude.
- Corporate and marketing mail — filter it out before it clogs the queue.
- Internal payment enquiries — when someone inside the organization asks "has this been paid?", the answer is a live lookup against Fusion (not processed / scheduled / paid on this date), not a new invoice.
Getting these wrong doesn't double-pay anyone, but it buries the exceptions that do matter under noise.
The manual-handling exceptions
Some invoices shouldn't be auto-posted even when they're perfectly readable. The skill is detecting them and routing them cleanly:
- International / manual-payment invoices — flagged by foreign currency or SWIFT details, routed to AP for manual processing rather than pushed into the standard import.
- Urgent / stop-service invoices — flagged by keywords or email priority, pushed to the front of the queue so a disconnection notice doesn't sit for three days.
- Employee and patient reimbursements — recognized as non-PO reimbursement workflows and routed for manual coding.
- Proformas and payment-request forms — a proforma without the right form bounces back to the requester for documentation; with the form enclosed, it goes to AP for manual handling.
The line-level special cases
Even within a "normal" invoice, certain lines need special treatment before posting:
- Freight lines split out as their own distribution line.
- Project / WIP-coded lines posted to the work-in-progress account rather than a standard expense line.
Get these wrong and the invoice posts, but your project accounting and freight reporting quietly drift out of true.
Why generic OCR breaks here
Notice what almost none of these scenarios are about: reading text off a page. Modern OCR does that well. The hard part is classification and decisioning — is this a statement or an invoice, paid or pending, receipted or not, urgent or routine, postable or manual — and then taking the right action for each branch.
A capture tool that only extracts data leaves all of that decisioning to your team. So you automate the easy 60% and your people absorb the messy 40% by hand — which is exactly the 40% that was costing them their week in the first place.
Doing this properly on Fusion also means respecting how Fusion expects to be fed: posting through FBDI load with real-time validation over Oracle Integration Cloud (OIC) REST, not custom writes to base tables. That keeps your quarterly Fusion updates uneventful while the AP layer above does the classification work. You can see how the pieces connect on our Oracle EBS and Fusion integration page.
Where EZ Cloud fits
EZ Cloud was built around this taxonomy, not a happy-path demo. We classify every document in the inbox, decide the correct action for each scenario above, and resolve a large share of the exceptions through AI email exception prevention — answering the supplier with live Fusion status before a human is ever pulled in. The clean PO invoices post straight into Fusion through Oracle-supported methods; the awkward 40% gets handled instead of dumped.
If your AP team is moving onto Oracle Fusion and bracing for the variety this article describes, that's exactly the conversation we have every week with healthcare finance teams.