Move accounts payable from on-premise WebCenter to the cloud and a question rightly moves to the front: invoices carry some of the most sensitive data an enterprise handles — bank details, payment terms, supplier contracts, pricing — so where does that data actually go, and who can reach it?
The answer that should satisfy your security team isn't "it's in the cloud, it's encrypted." It's an architecture where the AP workload runs inside your own OCI tenancy, talks to your Oracle estate over private networking, and never exposes invoice data to the public internet. Here's what that design looks like in practice, and why each choice matters.
The principle: AP runs in your tenancy, not a vendor's
The foundational decision is deployment model. There's a meaningful difference between sending your invoices to a multi-tenant SaaS that processes them somewhere you don't control, and running the AP automation OCI-native inside your own tenancy, alongside the Oracle ERP it serves.
Customer-controlled deployment means:
- The data doesn't leave your boundary. Invoices are captured, extracted, validated, and posted within infrastructure you own and govern.
- Your security posture applies. Your IAM policies, your network controls, your logging and key management — not a vendor's defaults.
- Compliance is demonstrable. When audit or InfoSec asks where invoice data resides and who can access it, the answer is "our tenancy, under our controls," which is a far easier conversation than tracing a third-party SaaS data path.
This is the same architecture pattern behind a WebCenter-to-OCI lift-and-shift — the AP layer lands next to the workload it integrates with, not in someone else's cloud.
No public IPs: keep the data plane private
The defining trait of a hardened design is that the components processing invoices have no public IP addresses. Nothing in the AP data path is directly reachable from the internet.
Concretely:
- Compute and processing tiers sit in private subnets inside an OCI Virtual Cloud Network (VCN). They can't be scanned, probed, or reached from outside.
- Inbound access is mediated, not direct — typically a load balancer in a controlled subnet for the limited surfaces that must be reachable, with everything behind it private.
- Outbound access is governed through NAT and service gateways where needed, so internal components reach Oracle and external services without becoming reachable themselves.
If invoice extraction and posting components have no public IP, the entire class of "exposed endpoint" risk simply doesn't apply to them. That's a stronger statement than "we firewalled it."
VCN peering: private connectivity to your Oracle estate
AP automation only earns its keep if it talks to Oracle — reading PO and receipt data, validating against the supplier master, posting invoices. The question is how that traffic flows.
The secure answer is private connectivity, not internet round-trips:
- VCN peering connects the AP workload's network to the network hosting your Oracle ERP and integration tier, so traffic between them stays on Oracle's backbone, never traversing the public internet.
- Oracle Integration Cloud (OIC) is reached over that private path for the supported integration flows — FBDI load, REST validation, PO and receipt lookups — keeping the connection model both private and Oracle-supported. The posting detail is on Oracle EBS & Fusion integration.
- The database and storage tiers — Autonomous Database / ATP for metadata, Object Storage for the image archive — are reached privately within the VCN topology, not over public endpoints.
Private connectivity does double duty: it shrinks the attack surface and it tends to be faster and more reliable than internet-routed integration, because the traffic stays on Oracle infrastructure.
Documents: signed URLs, not open buckets
The invoice image archive deserves its own controls. Images live in OCI Object Storage, and access to them should be explicitly governed:
- No public buckets. The archive is private by default.
- Short-lived signed URLs grant time-boxed, scoped access to a specific document when a legitimate user needs it — from inside the ERP transaction context, the way Managed Attachments worked, but with cloud-native access control.
- Access is auditable. Who retrieved which document, and when, is something you can answer — which matters as much for audit as the document's availability.
Why this architecture, specifically
It's reasonable to ask whether all of this is over-engineering. It isn't, for one reason: AP data is exactly the data attackers want and auditors scrutinize. Banking-change fraud, payment redirection, and supplier impersonation all target the AP data path. An architecture with no public IPs, private VCN peering, customer-controlled deployment, and governed document access closes the doors those attacks walk through — and gives your security team a design they can actually sign off on, rather than a SaaS data path they have to take on trust.
It's also the architecture Oracle itself favors. Running natively on OCI with private networking is consistent with Oracle's reference patterns, which is part of why it integrates cleanly and keeps quarterly Oracle updates uneventful.
Where EZ Cloud fits
This is how we deploy, by default. Our roots are in Oracle AP from the WebCenter era — WCI, WFR, WEC, Managed Attachments — and the OCI services that now host that work: Object Storage, Autonomous Database / ATP, OIC, BI Publisher, and VBCS, configured with no public IPs, VCN peering to your Oracle estate, and signed-URL document access, all inside your own tenancy. The invoice data stays within your boundary, under your controls, end to end.
We're published on the Oracle Reference Architecture for OCI and featured in Oracle's own technical case studies — the secure, OCI-native architecture this article describes is exactly what those references document.
If you're moving Oracle AP to the cloud, the deployment architecture is a security decision before it's a convenience one. Bring your InfoSec team into that conversation early — the right design is one they'll thank you for.