Managing Approvals in Expenses Managers are often the approvers for expense transactions. The major concerns of a manager would typically include policy compliance and fiscal responsibility. Managers may want to review their employees' expenditure patterns and see the impact of excessive expenditures on their department or cost center. After an expense report or cash advance has been submitted, it must go through your approval process before employees can be paid. If your organization requires any auditing, the designated auditor must approve the expense report or cash advance before it is eligible for processing. Your approval policies specify the conditions for approval. Upon completion of this lesson, you will be able to: Describe how the approval process works in PeopleSoft Expenses. Use the summary approval pages. Approve an expense report. Approve a travel authorization. Approve a cash advance. Reassign approvals. Understanding Approvals Many organizations enforce rules and policies related to expenses that employees and contractors incur for which they seek reimbursement. To manage these rules and policies, organizations can require one or more approvals for expense transactions as a normal part of the business process. The expense transaction types supported for approvals in Expenses are travel authorizations, cash advances, expense reports, time reports, and time adjustments. You can activate all or some of the transaction types for approval through the approval configuration pages. Organizations can have one or more types of approvers ranging from a departmental reviewer to an auditor who reviews expense transactions after reimbursements are processed. The approval process in Expenses can involve certain actions that an approver can perform such as Approve, Deny, Send Back, or Hold. The actions that an approver can take are determined through set up and configuration of the approver. Reviewing and approving expense transactions are performed through a set of pages that are entered through the Approve Transactions pages, worklist, email notification, or email. These are a centralized set of pages used by approvers and auditors. Expenses enables reviewers, approvers, and auditors to drill down to the transaction detail where they can view, modify, or take action on the transaction. Upon Completion of this topic, you will be able to describe the basic rules and parameters associated with the approval process in e*mpac Expenses. Procedure Consider this scenario: Your goal is to understand the expense approval functionality. We will review the various options that are available when reviewing expense reports.
1. The Expenses approval functionality enables reviewers, approvers, and auditors to review and approve multiple expense transactions with one approval action. You control the approver actions that can be used on the summary approval pages. You can disable summary approvals if it violates organizational policy for expense approvals and disable transactions for approval on the summary approval pages if they have exceptions. You can also configure approvals so that an approver with multiple roles can see the same transaction only once. 2. Depending on how you set up Expenses, reviewers, approvers, and auditors can approve some or all expense transactions in their queue with one action. 3. You can also approve all expense transaction types on one page or approve by transaction type. 4. You can drill down to view additional information and take action on transactions at the detail level. 5. You can change the sort order of transactions and view them sequentially in the new order. 6. You can search for transactions in a pending approval status.
7. You can view expense history for one or more employees prior to approval.
8. You establish pooled approvers by assigning multiple approvers to the same routing range of ChartFields or by adding multiple profiles to the approver list. In both cases, you must select the Notify All Approvers option in the Submission Notifications group box on the Approver Routing List page. The system defaults to require only one approver out of the pool to approve a transaction. Step 9. You can modify the number of approvers that are needed to reflect the number of approvers your organization requires by changing the Number of Approvers Needed value on the Approval Step Definition - Step page.
10. The following rules apply to pooled approver functionality: If you configure the system to require only one approver from a pool of approvers, and one of the approvers performs an approval action, the system withdraws the transaction from the other approvers' queues. If you establish multiple profiles on the approver list with multiple approvers assigned to each profile, the system only requires one approval from the pool if you set the Number of Approvers Needed field to 1.
11. If you define a profile on an approver list that is associated with a refinement or filter that excludes a transaction, the system excludes the approvers that are assigned to that profile from the pool. For example, Auditor1, Auditor2, and Auditor3 profiles are on the prepayment auditor approver list. Auditor2 uses a refinement that selects only expense reports that contain project-related expenses. When an employee submits an expense report that does not contain project-related expenses, the approver pool consists of approvers assigned to the Auditor1 and Auditor3 profiles. 12. If the system excludes all approvers in a pool because of refinements associated with their profiles, the system automatically approves the transaction for that role. 13. Approval Privilege Templates consist of a collection of attribute privileges that define the type of access to fields and records that approvers can access in their approval queue. The approval privileges range from viewing accounting dates to adding expense lines. 14. Privileges enable approvers to view and modify areas of a transaction and, in some cases, to add or delete other areas of a transaction. Some privileges may supersede others. For example, if an approver has the authority to add or delete an expense line, they automatically have the authority to add or delete distributions, change amounts, and change ChartFields.
15. An approver type is a role that defines which type of expenses an approver is authorized to approve.
16. In this example, an approver type of Reviewer has been defined. 17. In this example, an HR Supervisor approver type has been defined. Step 18. In this example, a Project Supplemental Approver has been defined. Use this approver type instead of project manager approvals, or in conjunction with project manager approvals for project-related transactions that meet defined conditions, such as report total amount or reports with billable project hours. You define these approvers through an approver list. 19. In this example, a Pre Pay Auditor approver type has been defined.
20. In general, employees cannot approve or audit their own expense transactions. Expenses compares the employee ID on the transaction with the employee ID that is associated with the user ID of the approver or auditor. 21. Expenses uses these rules for final approvals: You must authorize at least one active approver type to approve expense report transactions for payment. You must authorize active approver types for expense report transactions to either approve for payment, approve for billing, or both. Expenses sets the status for travel authorizations and cash advances to Approvals In Process until the final approver approves the transaction. Expense reports display a status of Approvals In Process until the final approver who is authorized to approve for payment has approved the transaction. Upon final approval, Expenses changes the status to Approved for Payment. If no reimbursement is due back to the employee, Expenses sets the status to Paid. If a transaction is in the Staged or Paid status, Expenses does not enable the Deny or Send Back actions for subsequent approvers and the transaction displays a Pending Billing Approval status. The exception to this rule is that a post payment auditor can deny lines on an expense report or deny the entire transaction.
22. Expenses uses these rules for privileges: If there are multiple approvers and one of the approvers adds a new line to an expense transaction, Expenses automatically sets the line to Approved for Payment. Subsequent approvers cannot deny the line. Use the Modify Approved Transactions page to modify or remove the line. If an approver adds a line or modifies a line to change the value of a routing ChartField in any distribution, Expenses does not route the transaction back to the beginning of the approval process; only subsequent approvers will see the line. Step 23. Expenses uses these rules for routing. The general defaulting rule used in rerouting (escalation), delegation, or reassignment functionality is: If the system cannot determine the appropriate approver based on the configuration, the system routes the transaction to the designated approver in the employee's profile. If the system cannot determine the designated approver through the employee's profile, the system routes the transaction to the Expense System Administrator that you define in the transaction definition.
24. Expenses uses these rules for routing: If the escalation process picks up a transaction for rerouting, and the approver who is designated as the target for rerouting is the same person as the employee or submitter, the system routes the transaction to the approver's delegated approver. If the rerouting process picks up a transaction for rerouting, and the approver who is designated as the target for rerouting is the same person as the employee or submitter, the system routes the transaction to them but does not enable them to take any transaction approval action on the approval pages. If you reassign a transaction to an approver who has already approved the transaction, the system will not route the transaction to that approver again.
25. When you use the Define Security - Reassign Work page to reassign work from one approver to another, Expenses validates user IDs and transactions: Expenses generates an error and terminates the reassign operation if you enter the same approver in the Reassign Work To field on the Define Security - Reassign Work page. For example, MGR1 cannot reassign work to MGR1. If the originator of an expense transaction is the same as the reassigned approver, Expenses performs the reassignment but when the new approver attempts to perform an approval action, they receive a message indicating that they are not authorized to approve a transaction that they submitted. For example, MGR1 reassigns the work to MGR2. Expenses encounters an expense transaction that MGR2 created and submitted to MGR1 for approval. 26. If the alternate approver is the same person as the approver whose work is being reassigned, the system reassigns the work as follows: MGR1 assigns the work to MGR2. MGR1 is also the alternate approver for MGR2. The system ignores the delegation and reassigns the work to MGR2.
27. If an approver reassigns work to another approver who has designated an alternate approver, who in turn has designated an alternate approver who is the original approver, it is considered a circular reference and the reassignment stops at the first approver it encounters who is not the originator. Example: MGR1 designates MGR2 as the alternate approver. MGR2 designates MGR3 as the alternate approver. MGR3 designates MGR4 as the alternate approver. MGR4 designates MGR1 as the alternate approver. The approval engine loops through the delegated approvers until it can find no more alternates or until an alternate appears who has already appeared once in the approval chain of alternates. In the example above, the system would route the transaction to MGR4 and stop there because the alternate is an approver who has already been processed in the loop. Step 28. You cannot route cash advances to a project manager or project supplemental approvers.
29. For travel authorizations and cash advances, all active approvers must approve before the system marks the transaction header with a final approval status. Final approval status is Approved for these transactions. 30. The transaction header status changes to Approved for Payment upon approval by the last active approver type. If subsequent approvers are active, the system routes the transaction to them; however, the expense report is eligible for payment processing, regardless of any subsequent approver actions. If the expense report is in Approved for Payment status, subsequent approvers can deny it or send it back for revision during the prepayment approval process. However, subsequent approvers cannot deny or send back for revision if the expense report has been staged for payment or paid. 31. For expense reports, a transaction status of Approved for Payment and project manager flag value of N sets the expense report to be eligible for staging to Project Costing. 32. Congratulations! You have successfully reviewed the approval process. End of Procedure.