Hello, I am .. From Payables Product Management, and in next hour I will be discussing Payables Implementation and Configuration considerations.
In this presentation, we will go through the Payables implementation concepts, considerations and best practices. We will cover Procure-to-Pay Overview and its prerequisite setups Key Implementation Considerations around Function and Data Security Business Units and Shared Service Centers In the Invoicing area we will go through Integrated Imaging Solution Multiple Invoice Entry Methods Match Options and Match Approval Levels Tolerances and Holds Invoice Approval Tax Engine and Multiple Accounting Representations using the SLA Payment Processing Options Payables to Ledger Reconciliation Report
Lets go over Procure-to-Pay flow at a high level: Starting with Requisition where you identify the requirement and then authorize the purchase request. To purchase goods/services, you negotiate and identify the vendor, request and receive the quotation and finally create and approve the purchase orders. In logistics module, you receive the shipment notice, receive and inspect the goods and ensure that the received quantity is within the tolerance when compared to PO. In Payables, you record the supplier invoices matching them to PO or receipt, approving and finally issuing the payment.
Payables Detailed Business Processes (or L2) and Activities (L3) Payables detailed business processes fall under Procurement business process or L1. Under Setup procurement detailed business process, the L3 activity for Payables is Define Payables. Similarly Manage Invoices detailed business process comprises of Receive and Process Invoices, Submit invoices, Approve Invoices, Audit Invoices and Record Accounting for Invoices. Manage Payments contains Prepare and Record payments and Record accounting for payments Manage Accounts Payable Balances has Analyze Accounts Payables Balances, Manage Accounts payable Disputes, and Close Payables period activities
This slide depicts some of the products whose setup is required for Payables functionality Starting with Global Human Resources for employees and HR locations, General Ledger for Ledger, currency, calendar etc. Subledger accounting to define accounting rules and events, Tax for Payables tax configuration, Projects, Product Item Management for item configuration, Logistics for Receiving Parameters, supplier model for supplier configuration, Purchasing options and others setups in Purchasing.
Prerequisite Setups for Payables Setup tasks As with all Fusion applications, Payables uses the Functional Setup Manager (FSM) tool to plan, implement and maintain the functionality. Please refer to the TOI on FSM for more details on FSM tool. Payables can be configured as part of Financials or Procurement implementation projects that are available out-of-the-box. Some of the setup task-lists and tasks preceding the Payables configuration are depicted in this slide. Starting with the common application configuration for Financials where users, implementation users, Enterprise structures, ledgers, business units, facilities etc. are setup. Followed by common financials configuration for setting up transaction taxes. For Invoicing and Payment configuration, suppliers are setup first followed by Payables, Disbursement, Payment connectivity and security, SLA and Cash Management setup.
Lets review Payables setup task-lists under Financials implementation project. This first screenshot on the left depicts the Financials implementation project with all its setup task lists. The screenshot on the right expands on the Invoicing and Payment configuration displaying the task-lists under it.
Function and Data Security in Payables In Fusion, function security is implemented using Job Roles, Duty Roles and Privileges and the data security using Data Roles There are 3 predefined job roles to meet Payables job functions: Accounts Payable Specialist, Accounts Payable Supervisor, and Accounts Payable Manager Payables job roles are configured such that segregation of duties is maintained for performing supplier management, invoice creation, force approval and payment processing For the new business units that are defined in the system, the data roles for those business units need to be generated using seeded data role template The predefined job roles and the duties assigned to them can be customized using Oracle Identity Manager (OIM) and Access Provisioning Manager (APM) Refer to Oracle Fusion Financials Security Implementation and Configuration Considerations for more details.
This slide lists the duties or duty roles that job roles associated with Payables inherit. AP specialist has invoice creation and review duties while AP supervisor has invoice creation, processing, payment creation and processing duties. AP Manager is primarily responsible for period close in addition to invoice and payment processing duties.
Lets discuss business units, business units in Procure-to-Pay flow and shared service centers in next couple of slides.
Business Units in Fusion Business Unit is a unit of an enterprise that performs one or many business functions, can process transactions on behalf of other legal entities. Business unit producing a financial transaction must be assigned to a primary ledger. Refer to Oracle Fusion Financial Enterprise Structures Implementation and Configuration Considerations training for more details.
Lets discuss Shared Service Centers Shared service centers are used to reduce cost and enforce company policies and procedures and can be modeled using business units in two ways: Service Provider Model BU Data Security In Service Provider Model , you define relationships between business units for a specific business function, identifying one business unit in the relationship as a service provider and others as its clients Shared service centers can also be implemented using business unit data security where shared service center personnel are given data access to process transactions for other business units. This is referred to as Multi Org Access Control or MOAC in Oracle EBS
This slide depicts the 4 ways in which Procure-to-Pay can be implemented for various business units in the flow: Decentralized: where individual business units perform business functions like requisitioning, sourcing, procurement and payables on their own Shared Services: where individual requisitioning business units subscribe to one business unit for sourcing and procurement and payables business functions. If a business unit pays on behalf of a different requisitioning business unit, intercompany transactions are created for financial reconciliation. Central Sourcing is where a business unit is a shared service center for sourcing while Requisitioning, Procurement, and Payables is done by individual BUs Finally, in Separate Procurement and Invoicing Service Providers, Sourcing is a shared service center, and another BU is processing orders and paying on behalf of Requisitioning BU
Best Practices for Shared Service Centers In Fusion-V1, the procurement business function can be centralized. This allows the procurement business unit to negotiate supplier terms on behalf of all the client business units and allows the client business units to share the supplier sites. The centralized procurement business unit can also process requisitions for multiple requisitioning BUs. To centralize the Payables business function into a single shared service center, suppliers can be asked to send invoices directly to the central location as opposed to Buyers or other locations.
Procurement via Subsidiary In order to meet legal requirements for trading, businesses are sometimes required to setup subsidiaries in some countries although their primary operations are located elsewhere. Setting up of subsidiaries and trading via those subsidiaries also often allow businesses to take advantage of available tax favorable regimes. To facilitate buying via subsidiaries, the purchase order’s Sold-to BU can be different from the Requisitioning BU. In this screenshot on a purchase order, Vision Services is buying goods via subsidiary Vision Germany.
In next couple of slides we will talk about the integrated imaging solution that provides a seamless “out-of-the-box” user experience, supporting the entire invoice lifecycle from scanning, recognition, routing, to invoice entry, approval, and payment.
Paper invoices are still prevalent in today’s business world, prompting most organizations to implement some form of imaging capability for their Payables department, to help reduce receipt-to-payment cycle and meet audit requirements. This results in implementation of multiple point solutions. Lets review some of the challenges in implementing third party solutions and compare them to Oracle’s imaging solution. Given the a la carte selection process for current third party solutions, the end result is a disjoint, bolt-on solution footprint that is truly unique to each implementation and that operates in peripheral fashion and cannot leverage native ERP capabilities. In contrast, Oracle’s imaging solution is fully integrated “out-of-the-box” that supports the entire lifecycle of invoice processing from scanning, recognition, image routing to invoice entry, approval and payment. Third party solutions rely on multiple components from different vendors for scanning, data extraction, storage and workflow and hence require dedicated IT staff for each to set up, integrate and maintain, resulting in higher cost of ownership. Oracle’s integrated solution is installed and maintained by a common provisioning framework, with minimal configuration and setup needed. Third party solutions have disparate platforms, certification and release cycles that increases the risk of incompatibility and maintenance overhead. In contrast for Oracle’s imaging solution, all components are certified and supported by Oracle.
Lets review the process flow for integrated imaging solution Fusion Payables invoice imaging process begins with invoices arriving in the mail room. Imaging specialist(s) preps and sorts them based on parameters such as geography, invoice amount, and due date and scans the invoices using Oracle Document Capture (ODC). Images are then sent to a central Oracle Forms Recognition server over a network file share for intelligent data recognition and extraction. Any invoices that fail data extraction or validation are sent to Oracle Forms Recognition Verifier for manual resolution. Upon successful data extraction, the invoice images are sent to IPM for storage and routing to accounts payable specialists using BPEL workflows. Accounts payable specialists can view the list of scanned images for invoice entry in the Scanned Invoices region of the Invoice workarea. After selecting the invoice image, they proceed with invoice entry using dual monitors where invoice entry UI is displayed on one monitor and the image is displayed on the other. The key invoice header attributes are already pre-populated with the data extracted by OFR thus reducing the invoice entry time and data entry errors.
Lets start reviewing the components for integrated imaging solution in detail over next couple of slides. Oracle Document Capture or ODC plays the first crucial role in digitizing paper invoices to images to support the automation that is necessary for streamlining invoice processing. ODC runs on desktop personal computers connected to scanners and converts paper invoices to industry-standard image formats. It supports most enterprise class scanners and the two leading high-volume document scanning interfaces: ISIS and Kofax Adrenaline/VirtualReScan. It is designed for high volume, centralized image capture, where batches of invoices can be scanned at a time. The architecture supports implementation scenarios where companies can centrally scan all invoices by having suppliers send invoices to one location or they can scan documents in field offices using multiple ODC instances.
Now lets review some of the implementation considerations and recommendations for ODC. For centralized scanning, request suppliers to send invoices to one central location or decentralize ODC at each invoice receipt location For centralized scanning in one location, consider legal requirements which may require invoices to be processed and stored in the same country as receipt You should install ODC on machine with at least dual CPU cores at 2 GHz and 4 GB RAM When evaluating hardware scanning throughput, plan for 60% efficiency of maximum throughput, This is to also to account time for image quality review Enable Adaptive Thresholding on scanners to remove background colors and gradients for pure black-and-white images Use TIFF image format with CCIT Group IV compression at 300 dots per inch for optimal balance between scan quality and image size We do not recommend JPEG format due to its lossy compression We recommend less than 25 images in a batch to avoid delay caused by recognition exceptions Also, to optimize high volume scanning we recommend you implement ODC commit server to schedule the export of images to OFR import directory every 15-20 min
Lets review Oracle Forms Recognition in detail. OFR offers cutting-edge intelligent recognition capabilities for extracting the key invoice header data from scanned images. This extracted data is later pre-populated directly into invoice entry user-interface. Unlike other solutions that use supplier specific templates to extract information, OFR can intelligently locate data within the invoice regardless of its location on the image and whether or not it has processed invoices from that supplier before. OFR has self-learning intelligence to improve scan accuracy for suppliers over time and provides flexibility to define specific rules for attributes such as format masks on invoice and PO number to further boost recognition results. Implementers can also configure validations for the extracted data against the Fusion Applications database. This results in highly accurate data recognition that dramatically decreases the need for human intervention to correct and resolve exceptions. For Payables invoice processing, purchase order number, supplier, invoice number, invoice amount, and invoice date are extracted out-of-the-box.
Considerations for OFR Oracle Forms Recognition Runtime Service runs in the background as a server process. Each RTS instance can be configured to perform specific steps within the overall process and multiple RTS instances can run on a single server. For scalability purposes, you can set up multiple servers each running multiple instances of the RTS that can be centrally managed by the OFR RTS Manager. Each RTS instance can be configured to either run the Import/Export/Cleanup service or the Recognition/Classification/Extract service. You must designate 1 RTS instance for Import/Export/Cleanup for every 2-4 instance of RTS that runs data recognition Number of RTS instances running on a machine must not exceed the number of CPU cores available RTS instance that is dedicated to data recognition can process up to 250 invoices per hour Each additional instance can achieve near linear scalability depending on scan volume, document complexity and the number of attributes validated on the invoice image Hardware Recommendation is to have A quad CPU core server with minimum 8 GB RAM so more OFR RTS instances can be dedicated to the resource intensive recognition task You can either use a single server with enough CPU cores or scale by setting up multiple OFR RTS servers or slave servers
Oracle Forms Recognition consists of the following components: OFR Designer; OFR Runtime Service and OFR Verifier We have already discussed OFR runtime service in the prior slide, so now lets focus on OFR Designer and OFR Verifier. OFR Designer is a client tool that enables implementers to customize invoice data recognition process, such as information to be extracted and verification of the processing results. Such configurations are defined in what is called as ‘OFR project’ and its initialization configuration files or INI. The OFR Designer is only used during implementation time and is not part of the daily processing. OFR Verifier is the quality assurance application of the Oracle Forms Recognition suite. If RTS fails to extract and validate an invoice in a batch, the entire batch is marked as failed and will not be sent to IPM for routing. Recognition failure can be due to one of the following: Extracted values for one or more attributes failed validation against the Fusion Applications database. Payables imaging solution currently only validates the Supplier on the invoice; Failure could also be when OFR could not find a value with a sufficient confidence level for one or more attributes or Stamps or notes on the documents making sections illegible for OFR or Missing information on the scanned image A payables specialist reviews incomplete batches using OFR Verifier and re-submits them after correcting the exceptions. The Verifier, like ODC, is another client application providing multiple deployment options. Verifier can either be setup on each designated user’s workstation or users can access Verifier instances using remote desktop technologies.
Lets review Imaging and Process Management (IPM) in detail. IPM is an application running on the Enterprise Content Management (ECM) where invoice images are stored and then routed to payables specialists. For the rest of the invoice lifecycle, any reference to the invoice image will point to this repository so documents are never replicated. Images sent by OFR will be imported by the IPM Input Agent using a scheduled process. IPM and its content repository give you the flexibility to attach configurable storage and security policies to content. For example, for invoices you can set metadata to determine how long the documents will be stored, on what storage device, and who will be able to access and view them. The ability to move images over storage devices as needed maximizes the use of your infrastructure. After images are stored, IPM creates a BPEL task for each invoice which then routes the images to appropriate payables specialist(s) for data entry. IPM also provides an image viewer embedded within Fusion Payables application allowing payables specialists to review and annotate on the images.
Implementation Consideration for IPM The IPM image repository is installed and preconfigured by the common provisioning framework and there is no post-install manual configuration required. Prior to running the provisioning process, the IPM Input Directory (which is the same as the OFR Export folder) file system needs to be set up since its location is required to provision IPM. It is recommended that the IPM image repository be co-located with the IPM Input Directory to minimize network traffic when transferring images. The average size of a black-and-white invoice image saved in TIFF format with CCIT Group IV compression at 300 DPI is 40 KB per page. It is critical that invoices are digitized using the Adaptive Thresholding technology to remove gray scaling, otherwise the image size can go up to 300 KB per page. Implementers can use this sizing information together with the estimated invoice volume to determine the amount of storage needed for IPM.
Image Routing Considerations for Invoice Entry A default image routing rule based on the invoice amount assigned to individual users will be seeded as part of the provisioning process. Implementers will need to modify this routing rule using the Worklist application to achieve the desired specialization within the Payables department. For example, routing can be based on supplier, PO prefix, invoice number prefix to ensure the right group of payables specialists will process invoices based on their specific assignments. Moreover, to achieve optimal load balancing among specialists and to avoid task re-assignment, rules should be set up to assign invoice to a user group instead of individual specialist in the system.
Oracle Fusion Payables supports a variety of invoicing methods to meet the needs of your organization. For manual invoicing, Payables is pre-integrated with ODC, OFR, and IPM to support scanning of invoices for paper-less processing and routing. The robust invoice workbench allows you to enter complex invoices with sophisticated defaulting and matching logic to match to POs or receipts. It also provides a holistic view of the invoice throughout its lifecycle. You can view the invoice status, installments, holds placed, payments made, prepayments that have been applied, etc. You can also drill down to the original PO or receipt. For high volume invoice entry that does NOT require extensive online validation, we have a spreadsheet invoice entry. The invoice open interface can be populated to import the invoices into Payables in bulk. Supplier Portal –Allows suppliers to enter their own invoices in a self-service manner. Any unmatched invoices are then routed through approval rules for approval. For Automated Invoicing: To alleviate the workload of your Payables staff, there are many ways in which invoices are created automatically. Oracle supports the Evaluated Receipt Settlement (ERS) process to help you get early payment discounts you’ve negotiated by automatically creating an invoice in Oracle Payables upon receipt of goods Using the Return to Supplier (RTS) feature, the system automatically creates debit memos directly in your Payables system when you return goods to your supplier. Payables will automatically create invoices from expense reports entered by employees in Oracle Fusion Expenses to facilitate payment. For Electronic Invoicing: Payables supports a web service and B2B invoice in XML format for creating invoices electronically. Regardless of the invoicing method you use, Payables supports foreign currency conversion, automatic tax calculation, invoice approval, online accounting, multi-period accounting, and multiple accounting representations.
Lets review considerations for various invoice entry methods Using Supplier Portal, have suppliers enter their own invoices and inquire on PO agreements, invoices and payment s to reduce paper and transaction processing costs Using Evaluated Receipt Settlement or pay on receipt, automate invoice creation upon receipt in Logistics ERS is best suited for inventory purchases as ERS can work if there is a PO; Also POs should include all costs to produce and ship the product, including freight charges and miscellaneous charges. POs also must have firm pricing that should not be affected by unexpected charges Consider Invoice spreadsheet for invoices having similar lines to utilize spreadsheet features like copy/paste, drag/drop, hide/unhide cells etc. Spreadsheet is not ideal for payables specialist performing high volume invoice entry in a shared service center. Use Payables open interface for importing invoices into Payables from other sources
Lets review invoice approval considerations Invoice Approval uses Oracle Approvals Management to determine who approves invoices and how they will be routed to different approvers. You can have different approval rules for PO matched invoices and Unmatched. Invoice approval is required for self service invoices that are not matched to a purchase order. Approvers can approve or reject the invoice. If an approver approves the invoice, then the invoice goes to the next person in the approver list until all required people approve the invoice. If an approver rejects the invoice, then the approval process ends. If an approver rejects an invoice, then you can: Use the Force Approval option to manually approve the invoice. Allow few selected users to force approve on exception basis Use the Initiate Approval option to resubmit the invoice to the Invoice Approval after correcting any issue that caused the approver to reject the invoice Approval Rules can be setup for position, job and supervisory hierarchy depending on approval needs. Consider implementing approval before validation to reduce days payable outstanding (DPO) or alternatively require validation before approval to ensure data accuracy Consider auto-approving specific invoices that need little review E.g. If your utility bill invoices are always under $500, consider setting up an auto- approval. For expense report and customer refund payment requests, you need not configure approval rules as they are upstream transactions that are already pre-approved
Invoice Approval Rules Configuration Invoice Approval Rules are defined in Worklist application Approval Rules are based on Data driven conditions having effective dates and priorities and they can be activated or de-activated An example rule could be where for invoice type standard, and for amount greater than 2000, approval is needed by Manager, and for amounts less than 2000, approval is needed by Supervisor. For invoice type of payment request, the invoice is auto-approved and for other conditions the one level supervisor approval is needed
Match Approval Levels To enforce company policies and ensure that you only pay for goods or services you receive and that suppliers do not over-bill you, Oracle Payables with Purchasing supports 2, 3, and 4 way matching for both goods and services 2 way matching can also support the automatic generation of invoices in AP when goods or services are received. The 2-Way matching checks that Invoice Quantity does not exceed PO Quantity and Invoice Price does not exceed PO Price 3-way matching: checks the same plus Invoice Quantity does not exceed Received Quantity 4 way matching checks above plus Invoice Quantity does not exceed Accepted Quantity
Here are some of the considerations for 2, 3, and 4 way approval. Consider 2-way for purchases where receipt is not applicable and for non-inventory purchases or service industries E.g. Insurance, Financial Services 3-way is the recommended and most widely practised and is used for physical goods, inventory or non-inventory services with units E.g. Consulting labour hours 4-way can be considered for inventory items that require inspection E.g. Manufacturing, Wholesale and Retail Industries Unmatched invoices can be used for legal services or utility bills and payment requests for employee expense reports and customer refunds generated in receivables
Tolerances and Holds You can define the matching tolerances to allow for variances between Invoices, POs and Receipts. Tolerances can be both percentage-based and amount-based. Multiple tolerance templates for goods or services can be defined and then assigned to the appropriate supplier sites. This allows you to manage your tolerances centrally yet assign your policies at the trading partner location. If your invoice amount and/or quantity exceeds the tolerance levels you defined, then Payables will automatically apply holds to the invoice and prevent payment until the hold is released.
Lets review some other considerations for Invoice processing: Setup default accounts to speed transaction entry and implement internal control in Common Options for Payables and Procurement, Supplier and Site configuration and Distribution sets Implement early pay discounts with multiple discount dates to avoid missing discount period using Invoice Options and payment Terms Apply available prepayments during invoice entry by enabling Show available prepayments during invoice entry in Payables Invoicing Options - Schedule invoice validation and create accounting to process daily
Fusion Tax: Payables relies on Fusion Tax for tax configuration and calculation. Oracle Fusion Tax consists of a tax knowledge base, a variety of tax services that respond to specific tax events, a set of repositories (for tax content and tax recording) that allows customers to manage their local tax compliance needs in a proactive manner. Oracle Fusion Tax supports all types of taxes, such as sales and use taxes that are recoverable or non-recoverable. It supports deferred tax and tax on freight. It supports the creation of Quantity Based tax rates for duty taxes. Users can specify whether a tax is inclusive in the amount of the good/service or not when defining taxes in the system. It also supports offset taxes, which is a negative-rate tax used to fully or partially reduce another tax. You can control whether or not to allow overrides of calculated tax amounts during transaction entry. You can set controls to allow overrides at multiple levels, such as at the transaction type, user, and tax level. For example, you may allow overrides to GST but not for VAT. Reporting on Tax Calculated taxes are then stored in the form of tax lines in the tax repository. These tax lines have all necessary information needed for tax reporting. Refer to Oracle Fusion Tax Implementation and Configuration Considerations training for more details.
Payables uses SLA to define the accounting events and rules and generate accounting. A single invoice in AP can create multiple accounting representations in multiple currencies. In this example, the Primary Ledger represents the corporate representation for a French subsidiary. It uses the parent’s US GAAP accounting method and corporate chart of accounts. It uses the local currency, euros. The Secondary Ledger represents the French statutory representation that uses the French interpretation of IFRS and the French statutory chart of accounts that is also in euros. For consolidation to the U.S. parent, we have a USD Reporting Currency assigned to the primary ledger. Refer to Oracle Fusion Subledger Accounting Implementation and Configuration Considerations training for more details.
Lets review considerations for payment processing
In the payment processing area We recommend you use Single Payment for off-cycle payments such as during period close and supplier inquiries on due payments Optimize the payment process request frequency based on organization’s size to aid in availing early pay discounts and to avoid off-cycle single payments Schedule Cash Requirements Report to run before Payment Process Request to accurately forecast cash needs For employee expense reimbursement based on expense policy consider Payment Process with straight through processing as it results in prompt payment for expense related invoices that are based on policy and strict payment terms Refer to Oracle Fusion Payments Implementation and Configuration Considerations training for more details.
Lets review Payables to General Ledger Reconciliation Report Close your books faster by automating the labor-intensive process of matching subledger transactions to accounting entries and identifying the discrepancies. Depending on how work is assigned in your organization, the Accounts Payable Manager or the general accounting manager both can access the reconciliation report. Payables to General Ledger Reconciliation report allows you to: Identify reconciliation exceptions automatically Identify beginning and ending balances that matches Payables Trial Balance Drilldown to journal and transaction reports for detailed analysis Download and analyze report output in a spreadsheet Reconcile by ledger, specific business unit or account balancing segment
Implementation considerations for Payables General Ledger Reconciliation Report Consider data purge frequency for the reconciliation extract data by setting up profile option AP: Reconciliation data purge frequency . This option indicates the number of days for which reconciliation extraction data is kept in the tables. Financial Category of value Payables must be included in Chart of Account setup or the report will not select any data. If you try to choose GL account values in the extract parameters that do not have this category assigned, the extract program will error, indicating the financial category is not assigned.
Some of the best practices around reconciliation report are: Payables Period should be set to Close because the detail reports are real-time. In order for the detail to match the Summary data on the Reconciliation report, you must make sure to limit access to that accounting period. Be sure the subsequent period is already open so business operations continue during the reconciliation process. Reopen the reconciling period to make adjusting entries, but restrict access at that time to control final accounting. For quicker, cleaner reconciliation, general ledger sources other than Payables should not be allowed to post to the Payables accounts.
Let me point to some other resources that would be useful: Some useful Implementation Trainings are: Oracle Fusion Payments Implementation and Configuration Considerations Oracle Fusion Subledger Accounting Implementation and Configuration Considerations Oracle Fusion Tax Implementation and Configuration Considerations Oracle Fusion Common Procurement Implementation and Configuration Considerations Also refer to following Functional TOIs Fusion 1.0 TOI: Set Up Procurement – Define Payables Fusion 1.0 TOI: Set Up Procurement – Define Disbursements
This concludes this session on Payables Implementation and Configuration Considerations. Thank you.