A proforma invoice looks like an invoice. It has a supplier, line items, amounts, often the word "invoice" printed right on it. But it isn't a payable — it's a quote dressed as a bill, issued before goods or services are delivered, frequently to request payment up front. Treat it like a real invoice and you've committed to paying against a document that has no commercial standing behind it.
This is one of the quieter traps in AP. The document reads cleanly, so a capture tool extracts it cleanly, and unless something stops it, a proforma can flow toward payment exactly like a genuine invoice would. The job of good automation here is to recognize what it is and refuse to process it as a payable — and then do something useful with that recognition instead of just dumping it on AP.
Why a proforma can't be paid like an invoice
The distinction isn't pedantic. A proforma and a tax invoice play different roles:
- A tax invoice is a demand for payment for goods or services that have been (or are being) supplied. It's what the ledger and the auditors expect to see behind a payment.
- A proforma is a preliminary document — an estimate or a request for advance payment. It typically can't support a tax claim, and paying directly against it bypasses the controls that a proper payment request is supposed to enforce.
So the right outcome isn't "post it carefully." It's "don't post it as an invoice at all." What it needs instead is the correct payment-request documentation — the internal form that authorizes an advance payment and routes it through the proper approval — so the payment is made deliberately, with the right paperwork, rather than slipped through as a routine invoice.
The bounce-back, and the exception to it
The most useful pattern is a conditional one. Whether a proforma can proceed depends on whether the right supporting documentation is attached:
- No payment-request form attached → bounce it back to the requester. The proforma can't go forward without authorization, so the system replies to the person who needs it, asking for the completed payment-request form. Once that form comes back, the documentation is complete and it can be forwarded to AP for manual processing.
- The required form is enclosed → route it straight to AP for manual handling. The authorization already exists, so there's no reason to bounce it — it just needs a human to process it manually rather than auto-posting.
That conditional is the whole trick. A blanket "reject all proformas" rule would generate friction for the legitimate advance payments that healthcare genuinely needs to make. A blanket "process everything" rule would let unauthorized advance payments through. The bounce-back-for-documentation pattern threads the needle: it stops the unauthorized ones at the door and waves the properly-documented ones through to manual handling.
Recognition is the hard part
None of this works if you can't reliably tell a proforma from a real invoice in the first place — and they're deliberately similar. Recognition leans on the cues that distinguish them: the word "proforma" itself, language about advance or up-front payment, the absence of tax-invoice markers, and the presence or absence of an attached payment-request or reimbursement form. The classifier has to read for what kind of document this is, not just lift the numbers off it.
This is the same theme that runs through almost every hard AP case: the value isn't in extraction, it's in classification and the right next action. A proforma sits alongside the other deliberately-routed documents a healthcare AP team handles — international invoices flagged for manual payment, reimbursements, statements, and urgent stop-service demands — in the broader set of invoice scenarios on Oracle Fusion.
And it pairs naturally with the supplier-email side of the work. Bouncing a proforma back for documentation is a supplier-and-requester conversation — exactly the kind of inbox exchange that, handled automatically with the right context, keeps the back-and-forth off your AP team's plate. That's the heart of AI email exception prevention: resolving the documentation gap upstream, before the document ever becomes an AP problem.
Why healthcare sees these
Health services deal with advance-payment requests across a range of suppliers — subscriptions, memberships, deposits on equipment, prepaid services — any of which can arrive as a proforma asking for payment before delivery. Mixed into a high-volume inbox, an unrecognized proforma is an easy thing to pay by reflex and an awkward thing to claw back. Catching it on the way in, and routing it by whether it's properly documented, turns a recurring control gap into a handled, predictable workflow.
Where EZ Cloud fits
EZ Cloud recognizes proforma invoices and payment-request documents on arrival and routes them on the rule that matters: no payment-request form means it bounces back to the requester for the documentation; form enclosed means it goes straight to AP for manual handling. Either way it never auto-posts as a regular payable into Oracle Fusion, so an advance-payment request can't slip through as if it were a delivered-goods invoice.
This is one branch of how we handle the full variety of a real AP inbox for healthcare finance teams running Oracle Fusion, on Oracle-supported integration methods. You can see how that integration is built on our Oracle EBS and Fusion integration page.