Once an invoice is captured, validated, and approved, it has to land in Oracle Fusion Cloud ERP. How you get it there is one of the most consequential architectural decisions in an AP automation project — and the one most likely to come back to bite you at the next quarterly update.
The wrong answer is to write directly to Fusion's base tables. It feels fast in a demo and it's brittle forever: every Fusion update is now a risk, because you're depending on internal structures Oracle never promised to keep stable.
The supported answer is FBDI load orchestrated over Oracle Integration Cloud (OIC) — Fusion's File-Based Data Import for AP invoices, fed by an OIC integration that picks up your file, kicks off the import, and reports the result. No custom base-table writes, no middleware reaching into internals. Get the orchestration right and your Fusion updates stay boring. But there are three operational details that decide whether the load runs clean or fails the whole batch.
Detail 1: batches are all-or-nothing, so group them deliberately
FBDI is a batch mechanism. The OIC integration that submits the import treats every file waiting in the inbound folder as a single run. That has a sharp consequence: a single bad record can fail records that were perfectly fine, because they were in the same batch.
So batching is a design decision, not an afterthought. Invoices need to be grouped sensibly — typically by business unit / operating unit — so a problem in one group can't take down another. And the moment you're batching, you have to think about what can collide inside a batch.
Detail 2: invoice-number collisions fail the whole load
Oracle's AP interface enforces a uniqueness constraint across invoice number, supplier, and operating unit. The trap is subtle: two different suppliers can each legitimately use the same invoice number. Individually, both are fine. Put them in the same FBDI batch and the load throws a unique-constraint error — and because the batch is all-or-nothing, every invoice in the batch is rejected, not just the two that clashed. The file gets moved aside, and someone has to untangle it by hand.
The fix is to scan for collisions before you build the import file:
- Normalize each invoice number (trim, upper-case) and look for the same number appearing under two different suppliers in the batch.
- When you find a collision, exclude only the colliding invoices and mark them for separate handling — don't let them poison the rest.
- Log the collision so it's visible and the held invoices get reprocessed in a later batch, where they no longer clash.
That keeps a one-in-a-thousand coincidence from rejecting a thousand good invoices.
Detail 3: attachments arrive on their own schedule
Auditors expect every invoice image attached to the transaction in Fusion and retrievable later. With FBDI, the attachment upload is a separate step from the invoice import, and the two don't happen at the same instant.
In a typical Oracle-designed flow, the attachment-upload job is scheduled to run after the invoice import — often around an hour later — so the invoice records exist in Fusion before the attachments are linked to them. Try to attach a document to an invoice that hasn't been created yet and there's nothing to attach it to.
This timing gap is invisible until someone looks too early. An AP officer who checks ten minutes after export sees the invoice posted but no document attached and assumes something broke. Nothing broke — the attachment job simply hasn't run yet. The right move isn't a code fix; it's an expectation fix: surface a clear status while the window is open, something like "attachment upload in progress — Fusion links attachments up to an hour after invoice import," so nobody chases a non-problem.
A couple of practical guardrails round this out. OIC has file-size limits — the invoice file and the attachment archive each have a ceiling — so it's worth checking sizes before upload and warning before you hit them. Naming matters too: a consistent convention that ties each attachment back to its invoice and supplier is what lets Fusion link the right document to the right record.
Why this is the durable choice
Every one of these details is a consequence of doing it the supported way. Direct base-table writes would let you sidestep batching, collision rules, and attachment timing — right up until a Fusion update changed something underneath you and the whole pipeline went dark.
FBDI-over-OIC keeps the integration on Oracle's supported surface area. The cost is that you have to respect how the mechanism actually behaves: batch boundaries, the uniqueness constraint, and the asynchronous attachment step. That's a fair trade for a pipeline that survives quarterly updates without a project to fix it each time.
Posting is the last mile of a longer pipeline. Before an invoice reaches FBDI it has to clear duplicate and already-paid checks, supplier validation, PO-status checks, and — for PO invoices — a receipt-balance match. The full picture of what a healthcare AP team handles upstream of the post is in our Oracle Fusion invoice scenarios article.
Where EZ Cloud fits
EZ Cloud posts approved invoices into Oracle Fusion through FBDI load orchestrated over OIC — batched by operating unit, screened for invoice-number collisions so one clash can't sink a batch, and with attachments uploaded on Fusion's expected timing and surfaced honestly while the window is open. No custom base-table writes, nothing for a Fusion update to break.
If your team is moving AP onto Fusion and weighing how to post into it, the integration method is the decision that determines how much upgrade risk you carry for years. You can see how we build it on our Oracle EBS and Fusion integration page, and how it fits a full operation for healthcare finance teams running Oracle Fusion.