You build a clean invoice payload, insert it into Oracle E-Business Suite's AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE tables, kick off the Payables Open Interface Import program (APXIIMPT), and wait for the invoice to appear in the AP workbench. It doesn't. No error toast, no exception in your application logs — the interface rows just sit there, or get marked rejected, and the invoice never becomes a real payable.
This is one of the most common failure modes when integrating with Oracle EBS Payables. The integration "worked" right up to the ERP boundary, and then the data quietly disappeared. The good news: the rejections almost always trace back to a small set of well-understood causes, and every one of them is preventable upstream.
Where the rejections actually surface
Open Interface Import doesn't fail loudly. When it can't process an interface row, it writes a rejection reason to AP_INTERFACE_REJECTIONS, keyed back to the interface header, and moves on. If nobody is reading that table, the invoice is simply gone from the integrator's point of view.
So the first principle of a durable EBS AP integration is: always read AP_INTERFACE_REJECTIONS after every import run and surface the reason back into your own workflow. A rejection reason like INVALID SHIPMENT TYPE, DUPLICATE INVOICE NUMBER, or INVALID DISTRIBUTION ACCT tells you exactly what to fix. Treating import as fire-and-forget is how invoices vanish.
Cause 1: Multi-Org (MOAC) not initialized
This is the silent killer. Oracle EBS uses Multi-Org Access Control (MOAC) to scope data to operating units. The Payables Open Interface Import program needs a valid operating-unit context to know which org the invoice belongs to — and that context comes from the database session, not from a column you set.
Two mistakes break this:
- Setting the operating unit directly on the interface row as if it were just another field. It isn't enough on its own, and forcing it can fight with the session context.
- Failing to call
fnd_global.apps_initializebefore the import. Without an initialized applications context (user, responsibility, and the resulting org context), the import either rejects the rows or processes them against the wrong org.
The correct pattern is to call fnd_global.apps_initialize to establish the user and responsibility, let that drive the operating-unit context, and not try to hard-set the operating unit on every interface line. Get this wrong and rows reject with org-related reasons that look baffling until you realize the session was never scoped.
Cause 2: The GL period isn't open
Oracle will refuse to import an invoice whose accounting date falls in a closed or never-opened GL period. The rejection reads like ACCT DATE NOT IN OPEN PD — accounting date not in an open period.
This bites hardest at two moments:
- Month-end and fiscal-year cutover, when the prior period has closed but invoices dated into it are still arriving.
- Backdated invoices, where the supplier's invoice date legitimately sits in a period that's no longer open for transactions.
Prevention is a date check before you ever write to the interface: validate the intended accounting date against the open-period calendar, and if the period is closed, either roll the accounting date forward to the earliest open period (per your finance team's policy) or hold the invoice in your own queue with a clear, human-readable reason — never push it blindly and let it reject.
Cause 3: Malformed tax and distribution lines
The third major category is line-level structure. The interface is strict about how lines are typed and how they sum:
LINE_TYPE_LOOKUP_CODEmust be a valid value (ITEM,TAX,MISCELLANEOUS,FREIGHT, and so on). A line that should be a tax line but is typed asITEMwill either reject or post to the wrong place — and your tax reporting goes sideways.- The lines must sum to the header. If
INVOICE_AMOUNTon the header doesn't equal the sum of the interface lines to the penny, the import rejects. This is exactly where naive tax-splitting and currency rounding create out-of-balance conditions: split a total three ways and the pennies don't reconcile unless you enforce it deliberately. - Distribution accounts must be valid and active. An
INVALID DISTRIBUTION ACCTrejection means the GL combination doesn't exist or is disabled in the chart of accounts.
For non-PO invoices in particular, getting the line typing right — and splitting tax onto correctly-typed, penny-balanced lines — is the difference between a clean import and a stuck batch.
A prevention-first integration design
The pattern that holds up in production isn't "import and hope." It's a validation gate that runs before the interface insert:
- Initialize the applications context with
fnd_global.apps_initializeand let MOAC derive the operating unit — don't fight the session context. - Check the GL period is open for the intended accounting date, and apply an explicit policy when it isn't.
- Validate line typing and header-to-line balance so the rows are correct by construction, not corrected after rejection.
- Read AP_INTERFACE_REJECTIONS after every run and feed the reason back into your workflow so a human sees a meaningful message — not a silently missing invoice.
This is the kind of ERP-native discipline that separates an integration that survives Oracle patches and upgrades from one that breaks every quarter. We dig into the related cases in splitting tax lines onto separate non-PO invoice lines and in self-assessed use tax capture before the invoice reaches Oracle — both depend on getting the interface contract exactly right.
Where EZ Cloud fits
EZ Cloud posts into Oracle EBS Payables through the supported Open Interface path — building correctly-typed, penny-balanced interface rows, initializing the MOAC context properly, checking the accounting period before insert, and reading the rejection table on every run so nothing disappears silently. The design philosophy is the same one behind our native ERP integration approach: respect Oracle's own contracts so your AP automation doesn't carry upgrade risk.
If your team has ever watched an invoice "import successfully" and then never appear, the rejection table almost certainly has the answer — and a prevention-first integration means you stop reading it after the fact. That's exactly the gap we built our Oracle EBS and Fusion integration to close.