Four Ways to Handle Payment Request Forms in Oracle Fusion
Higher Education and Healthcare organizations have a unique challenge: Payment Requests. Guest speakers, student workers, honoraria recipients, visiting faculty and other non-traditional payees.
At first glance, these don’t fit neatly into the three traditional categories for Procure to Pay workflows. They aren’t expenses, because they are not reimbursing employees. They aren’t invoices, because the payment is being made, not requested. And they aren’t purchase orders, because the individual doesn’t run a storefront where they receive orders. Yet, the request still needs the appropriate controls, approvals, tax reporting, auditability and good end user experience for both requester and payee.
In Oracle Fusion, there is not one single “right” solution. There are four realistic options, and the best approach(es) depend on volume, initiator, and approvals path.
The Four Options
There are four realistic ways to handle payment requests in Oracle Fusion:
- One Time Payment upload into Payables
- Custom Payment Request Form in Payables
- Requisition Form using Special Handling in Procurement
- AI Agent chat experience in Procurement or Payables
Each option can work, and many organizations leverage at least two in order to handle different types of payment requests.
Option 1: One Time Payment Form Uploaded in Payables
Another option is to use a One Time Payment Form that is uploaded into Oracle Payables. This can be useful for mass uploads or batch-oriented payment activity. In this model, the request does not start as a requisition. Instead, the payment data is prepared and uploaded into AP, where invoice approval routing can be used.
This approach is often more natural for Accounts Payable teams that receive payment requests in batches or need to process many similar payments at once, but it does require that there is some form or process outside of Oracle to send these in to AP.
This is a good fit for high-volume or centrally managed payment activity. Examples could include student refunds, research participant payments, awards, stipends, reimbursements, honoraria batches, or other payment types where a central team collects and validates information before upload.
It is also useful when the payment should not go through Procurement or when the institution wants the approval process to live in Payables rather than requisition approval.
Strengths
This process is the most “seeded” and requires the least setup, configuration or development.
Limitations
The biggest downside is front-end experience and control before upload. If the form is completed outside Oracle, the institution must manage version control, validation, attachments, duplicate prevention, and auditability carefully. End users may play less of a role, increasing AP workload.
Additionally, invoice approval processes are usually less robust than requisitions, with fewer levels and less hierarchy based on cost center and requester.
Option 2: Custom Payment Request Form which generates an Invoice
The second option is a custom payment request form using Oracle Visual Builder Studio. The form collects the necessary payment details and creates the appropriate transaction in Payables, where invoice approval routing is used.
Similar to the agent approach, this is customizable to your exact needs. Unlike agents, it is a static form that doesn’t adapt to each situation.
Strengths
The biggest advantage is that the user experience can match the business process. The requester can see fields that make sense for payment requests, not procurement fields that need to be explained away. For example, they won’t see the word “supplier” which can be confusing for payment requests.
Limitations
The tradeoff is build and maintenance effort, a heavy focus on AP involvement in the process, and reliance on invoice approvals instead of requisition.
Option 3: Requisition Form via Special Handling
In this model, payment requests are entered as a requisition from Self Service Procurement. The requisition must be marked as Special Handling, and you can name this as desired, typically “Payment Request.” The payee must be set as a supplier, and their site configured as pay on receipt. The special handling type is set up to automate the receipt, so even though this is a requisition that converts to a purchase order, there is no need to enter an invoice or a receipt.
This model is a good fit for departments that already use Oracle requisitions heavily and want a consistent requester experience. It is also helpful when the institution wants Procurement to retain visibility and control before the transaction becomes payable.
Strengths
The biggest advantage is that this option uses standard Oracle Procurement functionality. Requesters stay in the requisition experience, approvals can use requisition approval rules, and the institution can maintain procurement visibility before payment activity reaches Accounts Payable. Traditionally, requisition approval workflows are more robust than invoice, with more layers based on cost center and requester.
It also supports a cleaner audit trail than an offline form because the request starts in Oracle, routes through configured approvals, and links to the downstream purchasing/payment process.
Limitations
This does hinge on the supplier site being set up correctly to pay on receipt, and if this is missed then an invoice would need to be entered. Also, special handling is a separate click during the requisition process. This is to say that you could have a smart form labeled Payment Request, but even with this, users must select that it is Special Handling type. There is an Idea in the Lab to allow Smart Forms to default to a certain Special Handling.
Additionally, the user would see the payee labeled here as a Supplier, which can be confusing even when paired with support text and training.
Option 4: AI Agent Chat Experience
The most modern option is streamlining the process through AI Agents. It’s conversational, and collects the required information without forcing the user to go in any specific order, including supplier record creation. This can either go in tandem with special handling, or by having the agent create the invoice in the background.
This option is especially interesting for higher education because many campus users do not live in Oracle every day. They may submit a payment request only a few times per year. A guided chat experience can reduce training burden and help users provide complete information the first time.
Strengths
The biggest strength is usability. The agent can hide process complexity from the requester while still enforcing controls behind the scenes. It can also reduce incomplete requests by asking follow-up questions before submission.
It provides a more flexible front end than a typical requisition because the agent can adapt based on payment type, supplier status, department, amount, and policy requirements.
Limitations
The AI Agent approach requires more design discipline. The institution must clearly define what the agent is allowed to do, when it should create a supplier, when it should stop and route to a human, and how it validates supplier, tax, banking, and compliance information.
You may also wonder if cost is a limitation, because this type of agent does take development to build and would consume tokens to run. Based on design variables, it may cost $.25 to $1 to create and complete all aspects of the payment. However, consider that this correct-from-the-start requisition reduces workload of errors, and if you allow it to handle supplier creation, saves all parties time there as well, meaning the $1 cost still has a positive ROI.
Supplier Registration Considerations
Supplier registration is one of the most important design points for payment requests. In higher education and healthcare, the person being paid may not think of themselves as a supplier. A guest speaker, student worker, honoraria recipient, visiting faculty member, researcher, performer, or patient participant may be confused by supplier terminology, even though Oracle must often represent them as a supplier or payee behind the scenes.
That creates two related challenges:
- The organization needs complete and compliant supplier/payee data.
- The payee needs a simple experience that does not feel like a procurement onboarding process.
A good design should soften the supplier registration experience without weakening the control requirements.
Emailing the Payee a Registration Link
One common approach is to email the payee a link to register themselves. This avoids having the requester collect sensitive tax or banking information manually. It also helps ensure that the payee enters their own information directly into the controlled supplier registration process.
This is especially important for banking details, tax identifiers, and other sensitive information that should not be passed through email, spreadsheets, or department-level forms.
The payment request process should make it clear when the requester is initiating the payment and when the payee must complete their own registration before payment can continue.
Customizing Supplier Registration Language
Even if Oracle uses the word supplier internally, the registration experience can often be improved with help text, page personalization, instructions, and guided messaging.
For example, the page can explain:
“For payment request purposes, Oracle uses the term “supplier” to refer to the person or organization being paid. This may include guest speakers, honoraria recipients, visiting faculty, students, research participants, or other payees.”
Using Visual Builder Rules to Simplify the Experience
Visual Builder rules simplify the registration experience by hiding, defaulting, or conditionally requiring fields based on supplier type or payee category.
For example, once the registrant identifies themselves as an individual, honoraria recipient, guest speaker, or other non-traditional payee type, the page can be adjusted to remove fields that are not relevant and highlight the fields that are required.
This can make a generic supplier registration flow feel more like a payment-specific onboarding process.
The limitation is that the supplier type or classification field does not appear as the first option, and we cannot eliminate the word “Supplier” from appearing. It enhances the page to the point that additional help text can round out the experience.
Using Guided Journeys for Payee Support
Guided Journeys provide help directly on the registration pages.
Guided Journey content can explain:
- Why the payee is being asked to register
- What “supplier” means in this context
- Which fields are required for individuals versus organizations
- What documentation may be needed
- Who to contact for help
- What happens after registration is submitted
This is also a good place to embed or link to AI Agent assistance. For example, a payee could ask, “Why am I being asked for this?” or “Which supplier type should I choose?” and receive contextual guidance.
Practical Recommendation
The simplest starting point is usually the One Time Payment Form uploaded into Payables. It is the most seeded and requires the least development. It can work well for AP-owned or centrally managed payment batches.
A slightly better user experience is the Custom Payment Request Form in Payables. It lets the organization present the process as a true payment request instead of forcing the requester through procurement language. This is a strong option when the organization wants a structured, controlled, payment-specific form. It was the leading practice before Oracle introduced Special Handling and AI Agents!
The Requisition Form via Special Handling is a great fit when the organization wants to preserve procurement control and use requisition approvals. It is especially attractive where requisition approval rules are already more mature than invoice approval rules. However, it requires careful supplier site setup and a willingness to accept that the requester experience still looks and feels like procurement.
The best long-term solution is the AI Agent chat experience. It can ask the right questions, check supplier readiness, guide the requester, reduce incomplete submissions, and initiate the correct downstream process, while preserving more user friendly language and terminology.