There's a comfortable assumption baked into a lot of AP automation: once the system says an invoice was "sent to the ERP," the job is done. The invoice is in. Pay it and move on.
It isn't necessarily in. Sending an invoice to an enterprise ERP and the invoice actually becoming a posted payable are two different events, often separated by minutes, sometimes by a failure nobody sees. Treating the handoff as the finish line is how invoices go missing in plain sight — accepted by the integration, never landed in Payables, and discovered only when a supplier calls asking where their payment is.
The handoff and the import are not the same step
Modern ERPs don't post an invoice the instant you hand it over. They stage it, then run an import process that validates and converts the staged data into a real payable. That import is asynchronous and rule-bound, and it's where the actual outcome is decided.
The pattern is consistent across the major Oracle systems, even though the mechanics differ:
- Oracle Fusion Cloud ERP ingests invoices via an FBDI file load, then runs the Import Payables Invoices process that turns the loaded rows into invoices. The load succeeding tells you the file was accepted — not that every row imported.
- Oracle E-Business Suite writes to the
AP_INVOICES_INTERFACEstaging tables, then the Payables Open Interface Import program promotes those rows into the workbench. Rows can sit in the interface or get marked rejected without the upstream integration ever knowing.
In both cases there's a window where the invoice has been submitted but its fate is still undecided. The integration call returned success — but success meant "your data was accepted for processing," not "your invoice is now a payable."
Why "submitted" so often hides a failure
The reason this gap is dangerous is that the import step is exactly where invoices get rejected for reasons the handoff can't see. A closed GL period, an unresolved supplier site, a malformed tax line, a missing required value — these don't fail at submission. They fail during the asynchronous import, after the handoff already reported success. (For Oracle EBS specifically, we walked through the most common silent-rejection causes in why Oracle's AP Open Interface Import silently rejects invoices.)
So an automation layer that stops at "submitted" is reporting a number that doesn't mean what the AP team thinks it means. The dashboard says 200 invoices went to the ERP today. The ledger has 197. The other three were rejected during import, and unless someone is reconciling the staging area, nobody finds out until the gap surfaces downstream — a late payment, a supplier escalation, a month-end that won't tie.
The cost isn't just the missing invoice. It's the erosion of trust in the automation. Once an AP team has been burned by an invoice that "was sent" but never posted, they start manually verifying everything in the ERP anyway — which defeats the point of automating in the first place.
What real confirmation looks like
Closing the gap means treating posting as a state machine the AP team can see, not a fire-and-forget event. In practice:
- Distinguish the states explicitly. Submitted to ERP, import in progress, posted, and rejected are four different things, and the interface should never collapse them into a single "done."
- Poll the import outcome, don't assume it. After the handoff, the integration should check the asynchronous import's result and update status from the ERP's actual response — not from the fact that the submission call returned.
- Surface rejections with their reason, back to AP. A rejected invoice should land in front of a person with the ERP's rejection reason attached, so it can be fixed and resubmitted — not vanish into a staging table.
- Reconcile counts, not just individual rows. What went in versus what posted should be a number the team can trust at a glance, so a silent shortfall is impossible to miss.
The point is to give AP confirmation, not optimism — a definitive answer that the invoice landed, or a clear, actionable signal that it didn't.
Why the integration method underwrites all of this
Reliable confirmation depends on integrating with the ERP through its supported, observable interfaces — the FBDI load and import process in Fusion, the Payables Open Interface in EBS — rather than writing directly to base tables or pushing through brittle middleware that can't report back on what the import actually did. Supported integration is what makes the import outcome visible in the first place, and it's what keeps the integration durable across the ERP's regular updates. That's the foundation of our native ERP integration and the basis of how we handle posting on the Oracle EBS and Fusion integration page.
Where EZ Cloud fits
EZ Cloud treats ERP posting as a tracked, asynchronous outcome rather than a one-way send. After an approved invoice is handed to the ERP, it polls the import result and reflects the real status back to the AP team — posted, still importing, or rejected with the ERP's own reason ready to act on. AP gets a trustworthy answer to the only question that matters at the boundary — did the invoice actually land? — instead of a hopeful "submitted" that may or may not have stuck. That's what lets a team stop double-checking the ledger by hand and actually trust the automation it bought.