Oracle Fusion Receipt Strategies
Oracle Fusion · Procurement · Receiving · AI Agents

Six Ways to Confirm a Receipt in Oracle Fusion

From receiving docks and Self-Service Receiving to AI agents and email confirmations: how do you choose the right approach without sacrificing transaction accuracy?

Oracle continues to make receiving easier. But the more ways we give users to confirm a receipt, the more important it becomes to understand exactly what they are confirming.

The goal isn't to make it easy to click "Received." It's to make it easy to accurately record what physically arrived.

Receiving Is More Than an Administrative Task

Think about the last purchase you made for work. You may have placed a requisition, received an approval, and waited for the supplier to deliver it. At some point the package arrived, and someone needed to tell Oracle Fusion that the goods had been received.

That final action can seem trivial. But in a three-way matching process, the receipt helps establish whether Accounts Payable can pay the supplier. When the receipt is missing, invoices may be placed on hold and the requester, buyer, and AP team must spend time investigating.

Oracle now supports several different ways to create that transaction. Some require a person to enter the receipt in an application. Others make it possible to work directly from an invoice hold, email notification, chat conversation, or supplier email.

There isn't a single correct approach for every organization. A hospital with a central receiving dock has very different needs from a consulting firm where employees have laptops shipped directly to their homes.

Three Events That Are Easy to Confuse

  1. Supplier shipment: The supplier says the goods were shipped.
  2. Physical delivery: The goods reached a dock, campus, office, or employee.
  3. Oracle receipt: A transaction records that the designated receiving responsibility accepted the specified quantity.
A fourth event may follow: the receiving dock delivers the package internally to the requester. That final handoff is where Oracle Receipt Deliveries can add value.
1

Who Actually Received It?

The dock, requester, department, remote employee, or another accountable recipient?

2

What Evidence Exists?

Physical inspection, signed delivery, carrier proof, supplier statement, or user acknowledgment?

3

What Transaction Is Appropriate?

A full receipt, partial receipt, detailed receipt, exception, or no transaction yet?

Six Ways to Confirm Receipts

With more options than you can count on one hand, keep in mind that it's not or, it's and. Lets review the options, the pros and cons, so you can feel comfortable with the mix that works for your site.

1

The Receiving Dock Receives and Delivers

Goods arrive at a central dock. Receiving personnel perform the Oracle transaction, identify the destination, and route the package internally.

Advantages

  • Physical receipt is confirmed by trained staff.
  • Strong fit for palletized or sensitive goods.
  • Supports scanning, quantity checks, damage checks, and inspection processes.
  • Clear ownership and consistent receiving practices.
  • Can be paired with Receipt Deliveries for last-mile handoff tracking.

Limitations

  • Requires dock staffing and internal logistics.
  • May be slower for direct-to-requester purchases.
  • Poorly labeled packages can be lost in the warehouse.
Best fit: Centralized facilities, campuses, hospitals, laboratories, controlled products, and shipments that actually pass through a designated receiving team.
2

Requester Confirms Receipt in the Oracle UI

The requester opens Self-Service Receiving, locates the purchase order, and creates the receipt.

Advantages

  • Users can review orders and select quantities actually received.
  • Supports partial receiving and additional details.
  • Useful for direct shipments to employees and departments.

Limitations

  • Users must remember to access the application, and some users dislike the task.
  • Receipt compliance can suffer among occasional requesters who forget to visit the page.
  • More clicks than a notification or AI interaction.
  • Requires role setup and assigning, search indexing, and Redwood setup.
Best fit: Direct delivery with an accountable requester, partial shipments, and situations where users need to examine or enter receiving details.
3

Confirm from My Requisitions When an Invoice Is on Hold

After 25C, Oracle shows receipt holds on My Requisitions page. They can confirm receipt in full or up to the invoiced quantity from My Requisitions or Requisition Details.

Advantages

  • Makes a missing receipt visible where requesters manage requisitions.
  • Connects receiving with supplier payment consequences.
  • Can resolve qualifying holds without navigating to another page.
  • Offers a route to My Receipts when more detail is needed.

Limitations

  • Reactive: the invoice problem must already exist.
  • Depends on scheduled processing, invoice validation, eligibility, and security.
  • Users may mistake invoiced quantity for quantity actually received.
  • Infrequent requesters may not be in this page and it's easy to overlook the warning flag.
Best fit: A complementary exception-management path, not the primary receiving strategy.
4

Use the Receipt Creation Assistant AI Agent in Chat

After 26A, the Receipt Creation Assistant allows users to describe a receipt using natural language or paste relevant delivery confirmation email data into a chat interaction. The agent interprets the information and creates the receipt.

Advantages

  • Reduces navigation and manual data entry.
  • Natural-language interaction is convenient for occasional users.
  • Can turn delivery email content into a receipt.
  • Useful when users already have receipt evidence in another application.

Limitations

  • Requires AI Agent Studio setup, role assignment, and applicable receiving privileges.
  • The task is available from requisitioning screens, but still requires that a user know they need to process a receipt and where to find it.
  • Ambiguous PO numbers, quantities, or dates can create processing problems especially if they order similar items frequently.
  • Users must distinguish delivery evidence from shipment notices. A user copying a shipment notice that hasn't been received physically still causes problems.
Best fit: Direct delivery with reliable evidence and users who prefer conversational interactions.
5

Forward an Email to a Central Inbox for AI Receiving

In 26B, Oracle added email inbox capabilities to the AI Receipt agent. A designated inbound email account can receive delivery information, and the agent can process that content to create a receipt.

The system uses an email account, folder, polling interval, and configured agent trigger.

Advantages

  • Can eliminate the need to open Oracle for simple receiving.
  • Allows forwarding relevant emails into a central workflow.
  • Supports automated processing of repeatable receipts.
  • Can provide transaction status feedback by email.
  • Optional human approval adds a control point.

Limitations

  • A supplier email is not necessarily proof of delivery, espeically if they forward a shipment notification instead.
  • Needs clear rules for which messages are eligible for processing.
  • Automation may magnify errors if poor input evidence is accepted.
Best fit: High-volume, low-complexity direct receipts with trusted delivery evidence. For higher-risk scenarios, enable human confirmation or review instead of fully automatic creation.
6

Respond to a Confirm Receipts Email Notification

Oracle can reactively send a Confirm Receipts workflow notification to an eligible requester once an invoice is on hold. The user can indicate that goods were received, that they were not received, or that a receipt should be created up to the invoiced amount or quantity.

These notifications are generated through scheduled processing and apply to specific document and receipt-routing scenarios. They are not simply sent for every purchase order.

Advantages

  • Reminder reduces forgotten receipts.
  • Convenient for employees who rarely use receiving screens. No evidence needed, just repond.
  • Can prompt buyer investigation when goods are not received.
  • Redwood notification templates support modern email and worklist presentation.

Limitations

  • Users can click Received without physical verification.
  • Over-notification can encourage people to dismiss tasks.
  • Doesn't handle situations where the receipt should be something other than everything or invoiced quantities.
  • A user who clicks Received when they didn't actually get it, causes havoc for central receiving.
  • Notifications go out as soon as the process runs and the invoice is on hold. If supplier sends invoice at shipment, this means notification can go out before the item could have possibly arrived, and there is no way to build in a delay.
Best fit: Direct-to-requester expense purchases or situations where items arrive to a dock without a PO number and get sent to requester by mistake due to poor labeling.

Comparison at a Glance

Method Convenience Physical Validation Automation Best Use
Dock High for requesters; more work for dock Strong when dock checks goods Moderate Central receiving
My Receipts UI Moderate Requester-dependent Low Detailed and partial receipts
My Requisitions High for qualifying holds Requester-dependent Moderate Invoice hold resolution
AI Chat High Evidence-dependent Moderate Natural-language receipt entry
AI Email Very high Evidence and approval-dependent High Trusted low-complexity automation
Notification Very high Requester-dependent Moderate Reminding direct recipients

The Biggest Trap: Receiving Something That Hasn't Arrived

Suppose an employee receives a confirmation email for something that was ordered. They select "Yes, received" because they know the supplier shipped it, want the invoice to be paid, or simply want the notification to go away.

Unfortunately, the package hasn't actually arrived at their desk.

When the dock later attempts to receive the purchase order, the quantity has been consumed by the earlier Oracle receipt. Now the receiving team has to investigate and potentially correct an inaccurate transaction.

That isn't an email problem or an AI problem. It's a mismatch between who is accountable for confirming the goods and who has the best evidence that they actually arrived.

Design Controls Before Enabling More Receiving Channels

  1. Assign one primary receipt owner. Determine whether the dock or requester is responsible for the Oracle transaction.
  2. Explain the difference between shipped and received. A shipping notice is not a receipt.
  3. Handle partial quantities and exceptions. Do not encourage full receipt just because it is the easiest option.
  4. Monitor corrections and repeat problems. Frequent reversed or corrected receipts can reveal poor process design, inadequate training, or suppliers shipping items without the proper documentation and labeling.
Interactive Design Advisor

Which Receipt Methods Should You Use?

Tell us about your receiving environment and select the priorities that matter most. The recommendation automatically updates every time you change an answer, so experiment with different operating models and see how the result changes.

1. Where do most purchases physically arrive?

Think about the normal physical route for the purchases you're evaluating.

2. What evidence is usually available?

Consider what actually establishes that the goods were delivered, not just shipped.

3. Which considerations matter most?

Choose as many as you like. Each one influences the relative strength of the receiving options.

4. How sensitive are these purchases?

Consider the financial, operational, or regulatory consequences of an inaccurate receipt.

5. Are you comfortable allowing AI to create receipts from incoming email?

This controls whether fully automated email receiving is eligible for recommendation.

✓ Recommendations update automatically

My Preferred Design: Use More Than One Method, but Define Ownership

For most organizations, the practical answer is a hybrid model. The dock handles deliveries addressed to the organization's central receiving locations. Requesters handle goods shipped directly to them, ideally using Self-Service Receiving, notifications, or AI-assisted workflows according to their preferences and transaction complexity.

My Requisitions should serve as an exception-remediation path when an invoice hold exposes a missing receipt. That makes it a valuable complement to the primary methods rather than a replacement for timely receiving.

AI email receiving offers some of the most interesting opportunities. However, I would start with a narrower class of purchases where the organization has determined that delivery evidence is sufficient, then expand based on successful processing, exception rates, and control requirements.

Choose the receiving channel based on who knows the goods arrived—not on who happens to receive the easiest email.
Knowledge Check

Test Your Receiving Design Knowledge

A few common design scenarios help illustrate why transaction accuracy matters more than simply finding the fastest way to create a receipt.

References and Further Reading

Release-specific availability, roles, notification conditions, workflow configuration, and AI features should be validated in each customer's environment.

Get in Touch

Need Help With Your Oracle Receiving Design?

Working through a complex Oracle Fusion design, planning an implementation, or exploring how AI can simplify procurement and supply chain? Send me a note.

Thanks for reaching out!

Your message has been sent. I'll get back to you as soon as I can.

About the Author

Michael Gibby headshot

Michael Gibby

mgibby@hcg.com | www.mikegibby.com

Michael Gibby is a Director at Huron Consulting Group specializing in Oracle Fusion Supply Chain and Procure-to-Pay transformation across healthcare, higher education, and commercial industries. He helps organizations move beyond implementation and quarterly regression testing to build practical operating models for continuous adoption, process improvement, and measurable business value.

With experience spanning Oracle E-Business Suite, Oracle Fusion Cloud, international manufacturing, healthcare supply chain, and P2P operations, Michael brings a rare blend of functional depth, technical fluency, and business process design. His work focuses on Redwood readiness, supply chain modernization, AI-enabled support models, testing strategy, reporting, integrations, and adoption frameworks that help organizations turn Oracle’s quarterly innovation cycle into a repeatable business discipline.

Outside of work, Michael is a technologist and technical cave diver who has developed mobile applications for rebreather equipment validation, task management, and Oracle Cloud inventory counting. He is also raising two future Oracle Cloud consultants and occasionally finds time to explore underwater caves in North Florida.