Third Party Payments in Oracle Payables

Payments are generally made to the original supplier providing the goods or services; however there can be specific arrangements made wherein the suppliers can specify a different party to be paid on their behalf. The payments made to other parties on behalf of the suppliers are termed as Third Party Payments.

Third Party payments help parties involved in business to set off their liabilities without directly paying them. This reduces the direct funds movements and transactions are settled easily.

When customers make payments from their Payables system, there might be instructions from the supplier to make the payment to a different party that is the Third Party. In that case, the remittance of the payment goes to the Third Party. For all legal purpose including 1099, it is treated as a payment to the original supplier.

The Payables department maintains the Supplier information. Establishing Third Party

Payment relationship is part of the supplier maintenance activity.

The Payables clerk may also have information of the Third Party at the time of entering the invoices. The Payables clerk can have the right to override the Third Party defaulted at the time of invoice entry.

The Payments clerk processes the payment for the invoices that are due for payment.

Generally the payments clerk is aware of the Third Party suppliers to whom the payments can be released on behalf of the supplier. The Payment's department has the right to override the actual party to whom the payment can be made at the time of making payments.

This functionality lets you do the following:

• Establish Third Party relationship

• Default Third Party supplier information when creating invoice and processing payments

• Override Third Party supplier information on the Invoice and Payments windows

• Default Remit To Bank Account for the Third Party supplier on Invoice and Payment windows

• While processing payments to Third Party Supplier:

• Uses the address of the Third Party supplier, when the Payment Process Type is

   Printed

• Uses the Bank and Bank Account information of the Third Party supplier, when the           Payment Process Type is Electronic to transfer funds

Oracle Payables introduced third party payments functionality in release 12.1.1.

Setup Supplier Third Party

Third Party supplier needs to be setup in Oracle prior to using the third party payments functionality. In addition to the regular setup of supplier third party supplier needs to be setup, add a relationship between the first party supplier and third party supplier has to be setup.

Supplier relationship is established between suppliers at the site (address) level.

Ex: ASG Shoes Inc is a supplier who requests the payments be made to Fashion Domestic.

In order to establish a third party relationship, ASG Shoes supplier record will need to be related to Fashion Domestic supplier record. Fashion Domestic supplier record needs to be setup in oracle for the purpose of establishing a relationship with the primary supplier.

Supplier can have relationships with multiple third parties, but at any point of time only one third parties can have a relationship that is classified as Primary. During invoice entry and payment entry the third party suppliers that have an established relationship with the main supplier are available to be keyed in the field Remit-To Supplier Name.  Remit-To supplier name field is the key field in the functionality of third party payments.

Manage Supplier Third Party

Third parties (Remit-To suppliers) that have been setup for a given supplier can be managed from the Relationship menu option on the supplier’s page. New relationships can be setup, existing relationships inactivated from this page.

Payables Invoice options useful for Third Party Payments

Third Party supplier functionality has been introduced by providing additional fields on the Invoice and Payment entry screens. These fields are “Remit To Supplier Name”, “Remit To Supplier Site”.

Remit To Supplier information is defaulted to the Invoice entry screen based on the setup of the supplier, if there is a primary relationship that exists the third party supplier is used as remit to supplier. The ability to change the Remit to Supplier information during invoice entry is controlled by the payables system option for invoices. Allow Remit-To Supplier override has to be checked if during invoice entry the Remit To Supplier information can be allowed to change.

Payable Options -

Allow Remit-to Account Override. Check this check box if you want to allow users to change the default primary supplier site bank account during Quick payment and payment batch creation. If you enable this option, you can override the Payables default of the Remit-to field of the Payments window and the Modify Payment Batch window. You can then select an alternate Remit-to account from a list of the supplier site's active bank accounts that use the same payment currency.
Allow Remit To Supplier Override. If this option is enabled, then you can override the default Remit To Supplier Name and Site values at the Invoice windows

Payables Payment options useful for Third Party Payments

Allow Remit To Supplier Override. If this option is enabled, then you can override the default Remit To Supplier Name and Site values at the Payment windows.

Using Third Party Payments Functionality in AP

Third party payment functionality is useful in many situations, but a few common situations are as below:

Supplier’s who do not collect their receivables themselves but Factor to another party.

Supplier has gone Bankrupt and as per the court order the payment needs to be made to a different party.

The key to making third party payments is by establishing a relationship in the supplier screen, making sure the payable options for Remit to supplier are setup in the system as desired to provide the ability to change the Remit information in Invoice Entry and Payment Entry.

Paying close attention to the field’s Remit to Supplier, Remit to Supplier Site and in case of electronic payment Remit to Bank Account during invoicing and payments is very important.

Approval Management options for AP and OIE

Oracle Internet Expenses (OIE) has traditionally integrated with HR for the approval hierarchy creation along with seeded workflow APEXP. Expense report submitted by an Employee would require approver from Employee's Supervisor who has been setup with required approval signing limit, if the immediate Supervisor does not have enough signing limit the workflow would pass the document to the next Supervisor. This process of finding the approver with required signing limit using the Employee HR Hierarchy has been the core of the logic embedded in the APEXP Workflow.
Customer's Implementing OIE had to customize the APEXP Workflow if their requirements around Expense report approval were different than the seeded workflow.

Oracle Payables up to the release of 11.5.10 did not have the functionality of Invoice approval seeded, clients that needed an approval process on Invoices had to use custom approach or use an offline approach.
Payables was enhanced to provide the Invoice approval functionality by means of an integrated Invoice Approval Workflow and use of OAM (Oracle Approvals Management) for deriving the approvers list.
This enhancement was available to the existing clients who were already on 11.5.10 by means of certain patch sets.

OAM has since undergone a name change and is now more familiar as AME (Approval Management Engine). AME is a rules engine that can provide a list of approvers to the calling application. Customer's can configure AME for a particular business transaction by use of simple static or dynamic values base on sql statements for generating an approver list.

AME has been integrated with Payables for the Invoice approval at the same time it also integrates with OIE (Oracle Internet Expenses). OIE approvals can now happen either by use of the old and traditional HR Hierarchy logic embedded with in the APEXP workflow or use AME and generate an approver list as per the business needs. Customer's who needed the Expense report to follow a different path of approval than the traditional HR hierarchy need not have to open up the APEXP workflow and customize rather they could use AME.

AME for Payables Invoice approval is the only option.

Having provided the introduction or overview of the approval process in AP and OIE, I would like to present a real time situation.

I had the opportunity to work on a project where the customer was implementing Oracle EBS R12; they were going to use Payables and OIE. We first started addressing the payables invoice approval requirement, I configured AME for use with payables and the solution was finalized. Internet Expenses requirement for the customer were reviewed and they were not complex, the approval process was the Employee HR Hierarchy and we knew the standard Internet Expense flow would fit the needs.

As we started testing Internet Expenses none of the expense report would be routed to the Employee's supervisor rather they would become eligible for Payables approval. We were surprised, why would the traditional HR hierarchy not be used for approval?

Little digging thru....the solution or issue was addressed.

Oracle AME can be turned on or off  at an application level, as I mentioned earlier Payables Invoices have to go thru AME where as Internet Expenses can go thru HR(Traditional approach) or AME.
Payables (SQLAP) is the application that owns both the Payables Invoice Approval and Expense report functionality, even though OIE (Internet Expenses) is considered an application by itself it really is considered part of the Payables application.

That was the issue, we intended to use AME for AP but for OIE we did not need AME and were happy with the seeded HR Approach, but since we turned on AME for Payables application OIE would not use the HR approach.

This setup for AME is controlled by the Profile ‘AME:Installed’, to enable approval for Payables set this profile value to  ‘Yes’. This essentially means you would want to use AME for Payables application and that means both Invoice approval and Expense report approval.

I would think it would have been more appropriate to have the option for the customer to choose AME at a Transaction type within an application. I should have had an option to say AP INVOICE  - AME  Y and AP EXPENSE REPORT - AME N.

Well that was the issue, and here is the solution.

Having decided to use AME for Invoice approval but for OIE we had to take the traditional HR approach.
We let the profile for AME turned on for Payables, which makes both Invoice and Expense report to follow AME as per setup. Expense report workflow was tweaked to ignore the AME profile setup and assume that AME is not installed thus passing the Expense report to take the HR hierarchy. Key is to change the functionality of AME Enabled process in the APEXP Workflow.

If AME is enabled the process takes a different route

We need to make it believe that AME is not enabled.

That will take the traditional route as below, this was the desired approach.

This approach worked for the customer requirement of using AME for Invoice approval and ignore AME for Expense reports.

Applied this approach on couple of implementations to workaround the issue of  having one profile option for both Business transaction types.

Hope this helps for some one dealing with a similar situation!