An invoice arrives carrying a purchase-order number. To a lot of AP automation tools, that's a green light: there's a PO, so match it and post it. But the PO number alone tells you almost nothing about whether the invoice can actually go into Oracle Fusion Cloud ERP right now.
What matters is the PO's status. A purchase order moves through a lifecycle, and each stage changes what AP is allowed to do against it. Treat every PO the same and you'll either block invoices that should post or push invoices toward a PO that can no longer accept them.
The statuses that decide invoiceability
Fusion tracks where a purchase order is in its life. For AP purposes, three states do most of the deciding:
- Open — the PO is live. Goods or services can still be received against it, and invoices can still be matched and posted. This is the only state where the normal three-way-match path applies cleanly.
- Closed for receiving — no further receipts will be recorded against this PO, but invoicing can still happen against what's already been received. An invoice here isn't automatically wrong; it just can't expect new receipts to appear.
- Closed for invoicing — the PO is done accepting invoices. An invoice that arrives against it needs a human decision, not an automatic post. Something has changed since the PO was raised.
A naive check that only asks "does this PO exist?" collapses all three into "found it." That's the error. The PO existing and the PO being open are two different facts, and only one of them means the invoice can post.
"Not open" is not the same as "doesn't exist"
This distinction matters more than it first appears. We've seen integrations that, when a PO check comes back negative, label the invoice with "doesn't exist in ERP." But the PO often does exist — it's simply closed, completed, or cancelled. Recording the wrong reason has real downstream cost:
- The AP officer reads "doesn't exist" and goes hunting for a typo or a missing PO that was never the problem.
- Any reporting built on that status field is now wrong — it can't distinguish a genuinely unknown PO from a closed one.
- The supplier gets the wrong message, and a closed-PO conversation gets framed as a data-entry error.
The accurate status to record is "not open in ERP." It's a small wording change with a large effect on how fast the exception gets resolved, because it points the human at the actual cause.
Why you can only learn this live
You can't infer PO status from the invoice. The PO might have been open when the invoice was generated and closed for invoicing by the time it lands in your inbox a week later. The only reliable source of truth is Fusion itself, queried at the moment of validation.
The Oracle-supported way to do that is over Oracle Integration Cloud (OIC) REST — a synchronous call to a PO-check integration that returns the PO's current status. Critically, the integration returns invalid for any PO that is not currently open, not only for POs that can't be found. So the AP layer has to read the result carefully and map it to a meaningful, accurate status rather than a single pass/fail flag.
There's one OIC convention worth knowing here: Oracle's integrations return HTTP 200 even when there's a downstream error, signalling the real outcome in a custom response header and an error field in the body. An AP layer that only checks the HTTP status code will read an error as a success. The validation logic has to honour the header, not just the status line — or it will silently treat failed checks as clean.
What "good" looks like
A PO-status check that's actually useful does three things:
- Branches on the specific status, not on a single yes/no. Open routes to three-way matching; closed-for-receiving still allows invoicing against existing receipts; closed-for-invoicing is an exception, not a post.
- Records the real reason — "not open in ERP" — so the human who picks up the exception knows whether to chase a typo, a closed PO, or a requester.
- Combines cleanly with the other validations. PO status is one input. The invoice still has to pass duplicate detection, supplier validation, and — for a goods or service PO — a receipt check against the available receipted balance. An invoice posts only when all of those agree.
This PO-status branch is one node in the larger decision tree a healthcare AP team works through on every invoice — the full set of invoice scenarios on Oracle Fusion, from duplicates to credit notes to partial receipts. The common thread is the same one that runs through PO status: real validation means reading live ERP state and acting on it, not reading a field on the document and hoping.
Where EZ Cloud fits
EZ Cloud checks every PO invoice against the purchase order's live status in Oracle Fusion over OIC REST, branches on whether the PO is open, closed for receiving, or closed for invoicing, and records the accurate reason when it isn't postable — so a closed PO never gets mislabelled as a missing one. The clean, open-PO invoices flow through three-way matching and post natively; the rest are routed as proper exceptions with the right explanation attached.
We integrate the way Oracle supports — validation over OIC REST and posting through FBDI load, with no custom writes to Fusion's base tables — which is what keeps the integration durable across Fusion's quarterly updates. You can see how the pieces connect on our Oracle EBS and Fusion integration page, or how this fits a broader AP operation for healthcare finance teams running Oracle Fusion.