6.3 Disbursement System Options, Payment Security and Payment Approval Rules
Key Takeaways
Manage Disbursement System Options holds the payment method default basis and the Enable payment approval option.
Payment approval needs Enable payment approval plus the Payment Process Request Status Report format with Automatically submit at payment process request completion selected.
Payment approval rules are configured in the BPM Worklist through Manage Task Configurations for Financials on the PaymentApproval task, and they route notifications sequentially only.
Payment approval applies only to payment process requests, not to payments created on the Create Payments page.
Rejecting payment approval terminates the payment process request; approvers who want to pay the rest first remove the unwanted payments and then approve.
Two published payment objectives are covered here: Manage Disbursement Options and Manage Payment Approval Rules. Both are set in the Payments functional area and, unlike payment options, apply across the deployment.
Manage Disbursement System Options
Disbursement system options are the enterprise-level defaults for how the disbursement process runs. Source products, and the individual payment process request (PPR), can override some of them. The options you need to know:
| Option | Effect |
|---|---|
| Payment method default basis | Based only on payment method defaulting rules setup, or Override defaulting rules when default method set for payee (section 6.1) |
| Enable payment approval | Turns on payment approval for all payment process requests |
| Payment Process Request Status Report format, with Automatically submit at payment process request completion | Produces the report that shows a PPR's contents and status. Oracle's approval setup requires selecting it, so that an approval document exists before final payment. |
| Validation and processing defaults | Defaults for how the payment process behaves, which a PPR or template can override, for example validation failure handling for documents and payments |
Related security settings
Manage System Security Options (also in Payments) protects sensitive payment data:
- Encryption of bank account and credit card data, using a master encryption key stored in Oracle Platform Security Services. Apply Quick Defaults creates the wallet and key and turns on encryption.
- Tokenization of credit cards.
- Masking of payment instrument numbers.
- Rotation of the master encryption key and its subkeys.
Oracle requires encryption or tokenization of credit cards in Payments before corporate cards can be imported into Expenses, and tokenization if card data is used anywhere other than Expenses. Bank account access security (business unit access and user and role security) is covered in section 2.3.
Payment approval
Payment approval lets management control payments by prioritizing available funds. When it is enabled, the payment process stops at the Review Proposed Payments stage. Approvers then review the request, can remove payments from it, and approve or reject it.
Setting it up
Oracle lists three steps:
- Enable payment approval. In Manage Disbursement System Options, select Enable payment approval. Select the Payment Process Request Status Report format and Automatically submit at payment process request completion.
- Define a payment approval policy. Decide when approval starts, what triggers it (for example the bank account or pay group), and who approves.
- Configure payment approval rules.
- Open Manage Task Configurations for Financials (the BPM Worklist).
- Choose Task Configuration, then the PaymentApproval task.
- On the Assignees tab, switch to vertical layout, click the diamond icon in the Payment Approval box, and choose Go to rule.
- Edit the task and create the rules.
Oracle notes that payment approval rules route notifications to approvers in sequential order only. Design approval chains, not parallel panels.
Scope: what is and isn't approved
- Only PPR payments are approved. Payments created on the Create Payments page, such as Quick and manual payments, aren't covered.
- Every PPR is covered once approval is enabled. When a submitted PPR reaches Review Proposed Payments, approval starts and the status becomes Payments Approval Initiated.
- Approvers receive email and BPM Worklist notifications.
Approval actions by channel
| Where the approver acts | Actions available |
|---|---|
| Review Proposed Payments page | Approve, Reject, Withdraw approval, Resubmit for approval |
| Email notification | Approve, Reject |
| BPM Worklist notification | Withdraw approval, Resubmit for approval, Reassign, Delegate, Request for more information |
| Action | Who can take it | Result |
|---|---|---|
| Approve payment | Approvers, when the status is Payments Approval Initiated | Status changes to Approved. Processing resumes automatically, with no manual step. |
| Reject payment | Approvers, at the same point | The PPR is terminated immediately (status Terminated) |
| Withdraw approval | The submitter or an approver | The approval task ends and the status becomes Withdrawn. Active notifications are removed. Fix the issue and resubmit. |
| Resubmit for approval | The submitter or an approver, when the status is Withdrawn from payments approval or Error in payments approval | Approval restarts (Payments Approval Initiated) |
| Terminate payment process request | Anyone, at any time | The PPR ends and notifications are removed |
Because rejection terminates the whole request, an approver who objects to a single payment should remove that payment on the Review Proposed Payments page and then approve the rest. The removed payment's installments go back to Payables, unpaid, for a later run.
The Requiring Attention tab on the Payments overview page lists requests by approval status:
- payments approval initiated;
- pending payment approvals;
- withdrawn from payments approval;
- payments approved.
Exam patterns
- Approvals enabled, but a Quick payment went out without approval. That is expected, because approval only covers PPRs.
- An approver rejected one payment and the whole run stopped. Reject terminates the PPR. The approver should have removed the payment and then approved.
- Approval should start for payments from the treasury account over USD 1,000,000. That is a PaymentApproval rule condition on the payment attributes, configured in the BPM Worklist, after enabling payment approval in disbursement system options.
Payment approval is enabled. An AP manager makes an urgent Quick payment from the Create Payments page. What happens?
It isn't routed, because payment approval only covers payments from payment process requests
The payment stops at Review Proposed Payments until a treasury approver releases it for printing
The payment is rejected, because Quick payments are blocked when approval is enabled
The payment goes to the invoice approval workflow instead
A PPR with 40 payments is pending approval. The approver objects to one USD 45,000 payment but wants the other 39 to proceed today. What should the approver do?
Reject that payment in the email notification so only it is cancelled
Reject the request, because a rejection only removes the payments that were flagged
Withdraw approval, which removes the disputed payment automatically
Remove the disputed payment on Review Proposed Payments, then approve the request
An implementer has selected Enable payment approval and now needs rules that route large payments to the treasury director. Where are payment approval rules configured?
In Manage Payment Options for each payment business unit
In the Manage Workflow Rules in Spreadsheet Invoice Approval templates
In the BPM Worklist, on the PaymentApproval task's assignee rules
On the payment process profile's Reporting tab
Sections you finish are checked off in the contents.