How to automate email-to-transaction in Oracle E-Business Suite
Short answer
Read the shared inboxes with IMAP or Microsoft Graph, classify and extract each message with a model, validate against EBS reference data, and load clean results into the open interface tables (Order Import, Payables Open Interface, PO acknowledgement paths). Low confidence items go to a review queue instead of the interface.
Order desks and buyer teams on EBS often live in a shared inbox. Customer POs arrive as PDFs, supplier acknowledgements as free-text replies, and invoices as attachments, all re-keyed by hand into Order Management, Purchasing or Payables. The keying is slow and error-prone, but the volume is too irregular for classic EDI.
Modern language models read messy email well, but the risk sits on the EBS side: a wrong customer site or item cross-reference creates a bad order that someone has to unwind. The design principle is simple. Let the model propose, let EBS reference data and business rules verify, and let a human approve whatever is uncertain.
This page sets out an EBS-specific path using supported interfaces and no direct base table writes.
What teams use it for
Customer PO to sales order
Extract customer, ship-to, customer PO number, items and dates from the email, resolve them with customer item cross-references, and load via Order Import for a CSR to book.
Supplier acknowledgement parsing
Read replies like confirmed for the 14th, partial shipment, and propose promise date updates on PO shipments for buyer approval.
Invoice intake to Payables
Pull invoice PDFs from an AP mailbox, extract header and lines, match to PO and receipt, and stage in the Payables Open Interface for import.
RFQ response capture
Parse supplier quote emails into a comparison sheet linked to the sourcing event or requisition lines.
Order change requests
Detect customer emails asking to move a date or change quantity and create a change task attached to the sales order for the CSR.
Shipping notices from carriers
Match carrier emails to deliveries and update tracking information in a custom field or a descriptive flexfield for customer service.
Oracle E-Business Suite integration surface
- Order Import: OE_HEADERS_IFACE_ALL, OE_LINES_IFACE_ALL and related interface tables loaded then processed by the Order Import concurrent program, with the Process Order public API as the alternative.
- Payables Open Interface: AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE followed by Payables Open Interface Import, with rejections visible in the rejections table and report.
- Purchasing: PO_HEADERS_INTERFACE and the change request process, plus the PO acknowledgement features in the Purchasing and iSupplier Portal modules (exact capabilities vary by release and patch level).
- Oracle Workflow Notification Mailer, which can already process inbound email responses to notifications and is worth reviewing before building something new.
- Attachments through FND_ATTACHED_DOCUMENTS and FND_DOCUMENTS, used to store the original email and PDF against the created document.
- Cross-reference tables such as MTL_CUSTOMER_ITEMS and MTL_CUSTOMER_ITEM_XREFS plus customer site data in HZ_CUST_ACCOUNTS and HZ_CUST_SITE_USES_ALL, used to validate extracted values.
How it works
- 1
Connect to the mailbox
Use IMAP, Exchange Web Services alternatives or Microsoft Graph with application permissions limited to the shared mailboxes. Process messages once, move them to a handled folder and keep the message ID as the idempotency key.
- 2
Classify the message
Decide whether it is a PO, acknowledgement, invoice, RFQ response, change request or noise. Unknown types go straight to a human.
- 3
Extract structured data
Use a model with a fixed JSON schema for each type. Send attachments through OCR first where they are scans, and capture the model's confidence per field.
- 4
Resolve against EBS reference data
Match customer, site, item and unit of measure with lookups against the cross-reference tables. Reject or flag anything that does not resolve exactly, and never invent a mapping.
- 5
Apply business rules
Check credit status, price within tolerance of the price list, quantity tolerance on the PO, duplicate customer PO numbers and open order existence.
- 6
Stage in the open interface
Write into the interface tables with a batch identifier, submit the import program and read back errors. Store the original email as an attachment on the resulting document.
- 7
Review queue and feedback
Present each flagged item beside the source email. Corrections become rules, such as a new customer item cross-reference, so the same mistake does not repeat.
Example flows
Customer PO by email
Trigger: An email with a PDF purchase order arrives at orders@ the company.
- Classifier tags it as a customer PO and OCR extracts the text.
- Model returns customer, ship-to, PO number and lines.
- Lookups resolve every item through customer item cross-reference; one line fails.
- The order goes to the review queue with the failed line highlighted.
- CSR fixes the cross-reference, the order loads through Order Import and is booked.
Result: The CSR spends time on exceptions, not on keying each line.
Supplier ack with a new date
Trigger: A supplier replies that line 3 will ship a week late.
- The model extracts PO number, line and new date.
- System verifies the PO is open and the supplier matches.
- Proposed promise date change is shown to the buyer.
- On approval the change is submitted through the PO change path.
Result: Promise dates reflect reality and buyers see slipping supply earlier.
Keeping data on-prem
Mail content is sensitive: customer POs carry pricing, drawings and delivery locations. For on-prem EBS sites, run extraction on models hosted on your own GPU servers and read mail from your own Exchange or a private mail gateway, so message text and attachments never go to an external AI service. The staging database, review UI and import jobs stay inside the network, and only the interface table writes touch EBS. For air-gapped environments, copy mail in through an approved transfer path rather than giving the system internet access, and export the review queue results back the same way.
Security checklist
- Grant mailbox access only to the shared mailboxes involved and log every read.
- Never write to base tables; use open interfaces and public APIs only.
- Treat email content as untrusted input and keep model output constrained to the schema with validation before staging.
- Retain the original message and attachment against the EBS document for audit.
- Restrict the review UI by role and operating unit using the same rules as EBS.
Ways to get it done
Use Workflow Notification Mailer for reply-based approvals
Effort: Configuration only if the mailer is already running.
Fits simple yes or no responses to notifications you already send.
Build a pipeline in-house
Effort: Two to four months including review UI and monitoring.
Fits teams with integration engineers and a clear document set.
Partner build with Netray
Effort: Pilot on one mailbox and one document type.
Fits sites wanting private models and a ready review workflow for orders and invoices.
Pitfalls
- !Auto-booking orders without a CSR check can create duplicates when a customer resends the same PO.
- !Customer item cross-references in EBS are often incomplete, so expect many unresolved lines at first.
- !Order Import and Payables import rejections are reported in different places; surface both in your review UI.
- !Multi-org context must be set correctly before inserting interface rows or they will be invisible to the import.
- !Forwarded email chains hide the real sender and quoted old messages confuse extraction; strip quoted text first.
Frequently asked questions
Can EBS read inbound email natively?
Only in narrow ways. The Workflow Notification Mailer can process replies to notifications it sent. It does not read arbitrary POs or invoices from a shared inbox, so a separate pipeline with a model and the open interfaces is needed.
Which interface should I use for sales orders?
Order Import with the interface tables is common for batch loads, while the Process Order public API suits one at a time creation. Pick based on volume and error handling needs, and confirm the supported approach for your release in the Integration Repository.
How accurate is extraction from emails?
It depends on how structured the documents are, but plan on a review queue for a meaningful share at first. Accuracy improves as cross-references and rules are corrected. Measure straight-through rate per customer rather than relying on a single average.
Does the email content leave our network?
Not if you host the model and OCR on your own servers and read mail from your own mail system. That setup is typical for defense and aerospace suppliers with controlled data.
What about EDI customers?
Keep EDI through Oracle e-Commerce Gateway or your translator where partners support it. Email automation is for the long tail of customers and suppliers who will never move to EDI.
Want Email automation working on your Oracle E-Business Suite?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment