Verifying Job Aid P2P Cycle

8/3/2019 Verifying Job Aid P2P Cycle

http://slidepdf.com/reader/full/verifying-job-aid-p2p-cycle 1/25

Updated 8/5/2009

PROCURE-TO-PAY (P2P)

VERIFYING JOB AID

V E R I F Y I N G I N P 2 P

TARGETED USER ROLE:

> Viewers who play arole in theverification process



Updated 8/5/2009

Page 2

Look for these icons for special notes and tips:

Reminder = Tip =Note = Go To =

TABLE OF CONTENTS

1.0 P2P Overview 3

2.0 Verification of P2P Expenses 5

3.0 System of Record & Source Documents 8

4.0 Useful Reports for Verification & Lien Management 9

5.0 Steps for Verifying P2P Expenses 11

6.0 Steps for Reviewing Liens 19

7.0 Appendix: P2P Terminology 24



Updated 8/5/2009

Page 3

P2P FLOW DIAGRAM

1.0 P2P OVERVIEW

The P2P process begins when a Department creates a Requisition in the system, and ends when the Department

verifies and reviews the General Ledger. This job aid focuses on Step 11 “Department Verifies General

Ledger.”



Updated 8/5/2009

Page 4

1.0 P2P OVERVIEW

With the implementation of P2P, Departments will now be making online purchases from P2P catalog vendors.

Below is a list of the types of goods Departments will be able to purchase in P2P. All other purchases will be pur-

chased as they are today.

With this move to online purchasing comes changes to the verification process. This job aid explains what has

changed and gives guidance to Departments on how to verify P2P expenses.



Updated 8/5/2009

Page 5

2.0 VERIFICATION OF P2P EXPENSES

GENERAL LEDGER VERIFICATION AND REVIEW

The Controller’s Office guidance strongly recommends three levels of ledger review—verification, review, and ac-knowledgment. Below lists how each level of review is affected by the implementation of P2P.

Verification Responsibilities Change in P2P World

Provide reasonable assurance that financial

transactions are valid and properly classified to

the correct chartfields

Identify P2P transactions on GL Transaction Detail report by the

existence of a new Procurement Dept Code field.

P2P transactions with the CORRECT Procurement Dept Code:

These do not need further verification because they are con-

firmed through upfront P2P approval and 3-way match proc-

esses. However, they should go through a review process (see

Review section), particularly if the assigned Verifier is also the

Default Approver for the transactions.

For P2P transactions with INCORRECT Procurement Dept

Code:

These require further investigation on a transaction by transac-

tion basis.

• Review supplier invoices for accuracy

by comparing charges to purchase or-

ders

Reviewed in P2P; 3-way match process in P2P compares PO,

invoice and receipt information.

Department no longer receives invoices.

• Verify that goods purchased have been

received

Verified in P2P; Receiver Role enters receipt in P2P to verify

receipt of goods and authorize payment to vendor.

• Perform monthly verifications of GL

ledger accounts payable transactions to

ensure accuracy and timeliness of ex-

penses and recording under correct

chartfields.

Ensured in P2P; Default Approver role ensures accurate chart-

fields and available funding.

• Review for payments to employees and

vendors not recognized.

Employee payments are not part of P2P. For vendor payments,

Default Approver and Ad Hoc Approver roles ensure that re-

quest to a specific vendor is appropriate; Receiver role must

record receipt of goods prior to vendor payment.

• Look for duplicate payments Less likely to happen for P2P transactions since vouchers aresupported vouchers (e.g. assigned to POs) and due to the re-

sulting matching rules process; Invoice must be tied to a Re-

ceipt and PO in order to get paid.

• Check for expired grants or contracts

(fund years)

This check should occur during the requisitioning stage by the

Default Approver.

Investigate any unusual changes in summary

ledger balances

No change to process; Review Weblinks Summary reports as

usual.

P2P Transactions that have not been paid will now be

reflected in balance.

Key Changes for When P2P Transactions Include Correct

Procurement Dept Code:



Updated 8/5/2009

Page 6


Review Responsibilities Change in P2P World

Ensure verification has been performed No change to process; Utilize Verification Check-

list.

Review summary and detail financial reports for

accuracy, appropriateness, and proper compliance

Review Weblinks Summary reports as usual.

For detailed financial reports, consider adapting

how the Department reviews P2P transactions,

keeping in mind that:

1. P2P Requisitions were reviewed for appro-

priateness and proper compliance during

ordering process.

2. The 3-way Matching process ensures that

payments are accurate.

3. Duties are segregated within the Depart-

ment. If a Department does not use ad hoc

approving such that only a Default Ap-

prover is approving a Requisition, and if

that Default Approver is also verifying, then

additional scrutiny is needed on the review

process, with a focus on unusual vendors,

high risk commodities and general sam-

pling of transactions to mitigate opportuni-

ties for fraud.

Confirm all reconciliation items will be researchedand resolved on a timely basis (within 60 days) No change - Utilize Verification Checklist to trackcompletion.

Acknowledgement Responsibilities Change in P2P World

Confirm that financial information has been re-

viewed and that reasonable assurance of the valid-

ity of the information has been provided by the fund

owner

No change.

Assess risk to determine if monthly, quarterly, orannual review and acknowledgement is required No change.

The Controller’s Office Verification Checklist can be found at http://acctg.ucsf.edu/internal_controls/

sas112/key_controls/Verification_Checklist.doc.



Updated 8/5/2009

Page 7


The Controller’s Office procedures for monitoring/verifying expenditures to meet SAS 112—Key Control#13 can be found at http://acctg.ucsf.edu/internal_controls/sas112/index.htm.

Separation of Duties

The Controller’s guidance states that:

Duties should be separated between verification, review and acknowledgement whenever possible. At a minimum, two individuals are required.

• If separation is not feasible or practical due to staffing levels (e.g. the MSO may also be the Financial Administrator), it would be advisable to separate the verification and review function,with the reviewer signing off that the verification was performed, and monitoring if any reconciliation items are resolved on a timely basis.

• If the verification and review functions are combined, the acknowledger could sign off that both functions were performed.

• If the verification, review and acknowledgement functions are combined [into one person], an assessment should be performed to ascertain the level of risk and whether or not alternative

detective controls are necessary .

Given the Controller’s Office guidelines, below is a summary of which P2P Roles can be involved with the GeneralLedger review and verification process. As a rule of thumb, an individual who is creating or able to substantivelychange a purchasing transaction should never play a “verify” role. Because Buyers can issue Change Orders, andSelf Approving Requesters can create Requisitions without approval, their ledger roles are limited to “review” only.

P2P Roles SAS 112 Ledger Verification Roles

Requester and/or Receiver (without below roles) Review or verify but ideally, not both

Self Approving Requester Review only

Default Approver alone Review or verify but ideally, not both

Combined Default Approver/Buyer Review only

Buyer alone Review only

Because the P2P system enables Default Approvers to edit Requisitions as part of their fiscal responsibili-ties, it is highly advised that for Departments where Default Approvers also play a Verifier role, that the Re-viewer role be separate. In addition, random sampling is encouraged to mitigate opportunities for fraudand extra scrutiny is advised for unusual vendors and high risk commodities.

We anticipate that the MSO, Department head or senior designee for Sponsored Funds will typically play the SAS112 Acknowledgement role. We therefore didn’t address that above.



Updated 8/5/2009

Page 8

3.0 SYSTEM OF RECORD & SOURCE DOCUMENTS

Official System of Record

• The PeopleSoft system (owned by the Controller’s Office) is the official system of record.

• Any documentation attached to a Requisition becomes part of the official system of record.

Specific Source Documents

Record retention of Requisitions and supporting documentation must conform to UCOP and agency policy

on retention requirements (http://www.ucop.edu/ucophome/policies/bfb/rmp2.pdf)

Packing Slip

PI Signature on Controlled Substances

Verification Checklist

Same as today

CENTRALIZED Receiving: Recommendation:

Physical receivers of goods sign and sendpacking slips to the Administrative Depart-

ment for data entry into P2P by a central

Receiver

Central Receiver references packing slip num-ber when inputting the receiving information in

PeopleSoft, and then files the packing slip.

Internal Audit has indicated the packing slip

must be maintained for five years.

Requesters are also Receivers in the sys-

tem for their own goods

Same as above. Departments need to define

filing process for the packing slips, e.g. if each

Requester should maintain their files or if a

central departmental person will.

DECENTRALIZED Receiving: Recommendation:

Requesting Controlled Substances Recommendation:

Requesters scan the PI signed Requisition

and attach it to online P2P Requisition

Attachment is part of official system of record.

Keep as supporting document only if copy was

not attached to the online Requisition.



Updated 8/5/2009

Page 9

4.0 USEFUL REPORTS FOR VERIFICATION & LIEN MANAGEMENTReporting Overview

Along with the implementation of P2P comes a new Reporting Database that will provide information to help man-age the people and activities associated with requesting, purchasing, receiving, and paying.

Go to the Reporting Manual for more information on the specific reports and how to run them.

Summary of Reports Useful for Verification Process

WEBLINKS Reports

GL Transaction Detail Most commonly used report for financial verification/review, including

tracking encumbrance activities and expenditures. A new template

has been prepared and issued by the Controller’s office to facilitate the

export and reconciliation of transactions. The “WL Reconcile Voucher”

template is located on the Controller’s website.

Change in P2P world:

o Report shows line level liens/expenses reflecting individualline items on a PO/Invoice

o P2P transactions contain a Procurement Dept Code for easyidentification

Summary Reports Provide a view of the “big picture” for a Department, a DPA, or a Fund.

Change in P2P word:

o P2P transactions that have not yet been paid will now be re-

flected in the balances

REPORTING DATABASE Reports

Voucher Document Status Provides information associated with Voucher, including Invoice ID,

invoice date, and amount; Links to Requisition, PO, and Receipt

documents associated with it.

Requisition Inquiry Provides information associated with P2P Requisition, including Re-

quester ID, request date, and items requested

PO Inquiry Provides information associated with P2P PO, including vendor,

amount, items, Buyer, and PO status



Updated 8/5/2009

Page 10

4.0 USEFUL REPORTS FOR VERIFICATION & LIEN MANAGEMENT

Summary of Reports Useful for Lien Management

REPORTING DATABASE Reports (Continued)

PO Accounting Entries Provides lien details for a specified P2P PO, including the month the

lien was created and if and when the lien was relieved by a Voucher.

PO Details Including Liens Provides list of current liens that can be run by Fund-DPA and daterange.

Both Weblinks and Reporting Database will be refreshed with PeopleSoft data on a nightly basis.



Updated 8/5/2009

Page 11

5.0 STEPS FOR VERIFYING P2P EXPENSES

There are several reports to help verify Department expenses. Here is a summary that shows which report to use

for what.



Updated 8/5/2009

Page 12

1. Sign in to Weblinks and select the GL Transaction Detail report from the Financial Detail menu.

2. Select appropriate report criteria.

3. Click [Start].


STEP 1: RUN WEBLINKS GL TRANSACTION DETAIL REPORT

Go to OLFS Weblinks Manual—Chapter 3 for more details on how to run the GL Transaction

Detail report.

GL Transaction Detail Report shows line level liens/expenses reflecting individual line items on aPO/Invoice.

3

2



Updated 8/5/2009

Page 13


Go to http://acctg.ucsf.edu/OLFS/trainingarchives/jobaids.htm for complete information on exporting the

GL Transaction Detail to the GL Transaction Detail Rollup Template.

STEP 2: EXPORT TO GL TRANSACTION DETAIL ROLLUP TEMPLATE.

From the report results page, click [Excel] to export report.

P2P transactions are

identified by existence

of Procurement Dept



Updated 8/5/2009

Page 14


STEP 3: IDENTIFY QUESTIONABLE PROCUREMENT DEPT CODES

For Accounts Payable transactions, “Reference” column is the Voucher Number that is assigned when the

invoice is entered into PeopleSoft.

Create a list of Dept Codes in the Department/Division and use a reference.

STEP 4: NOTE THE VOUCHER ID OF QUESTIONABLE TRANSACTION

Things to consider:

• Could this be a split-funded transaction, where the Department is paying for a portion of a shared item?

• Did the Requester recently move from another Department and his/her PeopleSoft ID was not deacti-vated from the previous Department?

Because verifying P2P transactions depends largely on the Requester’s Procurement Dept

Code, remember to submit the PeopleSoft User Request Form when an employee transfers

from one Department to another.

http://acctg.ucsf.edu/peoplesoft/system_access/userrequestSubmit.htm

Questionable

Procurement

Dept Code

Voucher

ID





Updated 8/5/2009

Page 16

5. View PO, Receipt, or Requisition details.

a. PO Inquiry Click [DOC ID] Number next to the “PO” Document Type to view the PO details, including who is the

PO Buyer and what are the PO items). A new browser window/tab opens.

b. Receipt Inquiry

Click [DOC ID] Number next to the “Receipt” Document Type to view the Receipt details, including

who entered the Receipt. A new browser window/tab opens.

c. Requisition Inquiry

Click [DOC ID] Number next to the “REQ” Document Type to view the Requisition details, including

who entered the Requisition and when. A new browser window/tab opens.

5a

5b

5c


STEP 6: VIEW PO, RECEIPT, OR REQUISITION INQUIRY



Updated 8/5/2009

Page 17

PO Inquiry shows:



Who is the

Buyer?

What was

purchased?



Updated 8/5/2009

Page 18

Receipt Inquiry shows:



Requisition Inquiry shows:

Click [Requisition] ID to see additional Requisition details.

Who enteredReceipt and

when?

Click Header

Details link.

Who initiatedRequisition?



Updated 8/5/2009

Page 19

6.0 STEPS FOR REVIEWING LIENS

Review liens on a regular basis to ensure that financial balances are accurate. Below is a summary of which report

to run for what.



Updated 8/5/2009

Page 20

PO Details Including Liens is a useful query that provides a list of current P2P liens that can be run by Fund-DPA

and date range.

1. Sign in to Reporting Database.

2. Navigate to eProcurement > Purchasing Reports > PO Details Including Liens.

3. Type Fund From, From To, DPA From, DPA To, Date From, and Date To.

4. Click [View Results].


STEP 1: RUN PO DETAILS INCLUDING LIENS

2

Date From and Date To are required fields.

If you type a Fund From , you must type a Fund To . The same goes for DPA From / To or NCA

From / To . Otherwise, the results may come back without any data.

3

4



Updated 8/5/2009

Page 21


STEP 2: REVIEW & IDENTIFY ANY QUESTIONABLE LIENS

Sort to identify old liens

that need follow up or to

be updated in P2P.

Sum for a lien total

that can be added

to financial projec-

tions.



Updated 8/5/2009

Page 22

PO Accounting Entries is helpful to research partially paid PO’s or see the payment history of a PO.

1. Sign in to Reporting Database.

2. Navigate to Purchasing > Purchase Orders > Review PO Information > PO Accounting Entries

3. Type PO number to research in From PO ID .

4. Click [OK]


STEP 3: RESEARCH QUESTIONABLE LIENS IN PO ACCOUNTING ENTRIES

2

3

4



Updated 8/5/2009

Page 23

PO Accounting Entries Example

• Line 1 shows the initial PO lien amount of $240.00 on 19900-401901 in December 2007.

• Line 2 shows the lien reversal of -$240.00 by Voucher ID 02343422 in December 2007.

Line 1

Line 2

Line 1

Line 2

Screen Continued

PO Lien

PO Lien

Reversal

Voucher ID used

to reverse lien

Accounting

Period 6 =

December

Fiscal Year 2008

= 7/07-6/08


STEP 3: RESEARCH QUESTIONABLE LIENS IN PO ACCOUNTING ENTRIES



Updated 8/5/2009

Page 24

7.0 APPENDIX: P2P TERMINOLOGYAgreement Items

Catalog

UCSF managed catalog containing unique agreement items from department

contracts. These catalog items are available to all departments. As new con-

tracts are negotiated, and other contracts expire, the list of agreement items and

vendors in this catalog will continue to change.

AP Accounts Payable unit within the UCSF Controller’s Office. Responsible for all

campus vendor, employee reimbursement and non-Payroll payments.

Catalog Set of goods made available by vendors electronically in P2P. There are 3

types of catalogs in P2P: Hosted (Perfect Commerce), Agreement Items, and

Punch-Out (Office Max).

Catalog

Enablement

Process of establishing and managing electronic catalogs.

Change Order A change issued by the Buyer to modify or cancel a PO after it has been dis-

patched to a Vendor. Change orders are not created to increase order quantityor add items to a PO.

CPBC Campus Procurement & Business Contracts department at UCSF. Responsible

for delivering business and procurement contracts, transactions and advice and

ensuring compliance with applicable policies, laws and regulations. All P2P

documentation is available on the CPBC website at http://cpbc.ucsf.edu.

Dispatch The act of sending a PO or Change Order to a vendor. PeopleSoft electronically

dispatches new Purchase Orders 3 times per day and Change Orders every

hour, either by EDI, email or fax transmittal. Download the P2P Dispatch Sched-

ule at http://cpbc.ucsf.edu.EDI

(Electronic Data

Interchange)

Set of standards for computer-to-computer information exchange. Refers to the

way PO or invoice data is transmitted between UCSF and vendors. EDI trans-

missions require no manual intervention.

EDI Invoice

Vendors

Vendor invoices that arrive electronically in the UCSF PeopleSoft system.

EDI PO Vendors POs electronically delivered from the UCSF PeopleSoft system directly to a Ven-

dor’s order management system. Fisher Scientific, VWR and Office Max are

sample EDI PO Vendors.

eProcurement (ePro)

PeopleSoft module where users can create, manage and approve Requisitions,receive items, and manage favorites and templates. The ePro module, along

with the Purchasing module and Accounts Payable module are what comprise

P2P.

Hosted Catalogs A type of P2P catalog where the content is “hosted” by a third party provider

(Perfect Commerce). Hosted catalogs include key vendors such as Fisher

Scientific and VWR.

Invoice Vendor document requesting payment after goods are shipped. UCSF receives

invoices by U.S. mail and EDI. See EDI Invoice Vendors.

http://cpbc.ucsf.edu/






Page 25

7.0 APPENDIX: P2P TERMINOLOGYMatching and

Match Exception

PeopleSoft process to compare specific elements (i.e., price, quantity, etc.) on

the PO, Receipt and Voucher. When all elements meet the matching rules, the

Vendor is automatically paid. When items do not match, the system creates a

match exception which must be managed before the Vendor is paid.

P2P Procure-to-Pay. An end-to-end solution for requisitioning and approving items,routing Requisitions based on sourcing rules, converting Requisitions into Pur-

chase Orders, dispatching POs to vendors, recording receipt of goods, obtaining

invoices, and paying vendors.

PMO Program Management Office. Responsible for the planning and implementation

of selected academic, research, financial and student systems which support the

mission of UCSF.

Perfect Commerce See Hosted Catalogs.

Purchase Order

(PO)

A written agreement between UCSF and a Vendor containing the essential

terms and conditions under which items or services are to be furnished to UCSF.PO is part of the 3-way matching process.

Punch-Out

Catalogs

A type of P2P catalog where the content is managed externally by the vendor.

The catalog is accessed by punching out to the vendor’s website through Peo-

pleSoft. Example: OfficeMax

RSA Research Services Analysts. Responsible for pre-award and/or post-award grant

activities and budgets. Also referred to as “Analysts” or “Financial Analysts.”

Receipt An electronic record indicating receipt of goods from a vendor. Receipt is part of

the 3-way matching process.

Requisition An internal form used by departments to convey a need for acquisition of goods

or services. P2P requisitions are created by Requesters, and routed electroni-

cally for approval. Once approved, the requisition is sourced and converted into

a PO.

SMEs Subject Matter Experts. With P2P, SMEs included purchasing experts across

campus who provided input on the development of the P2P system and guid-

ance on the business processes for the campus.

Sourcing The act of applying UCSF purchasing rules to convert an approved P2P requisi-

tion into a purchase order.

Supplier

Enablement

The process of collaborating with vendors (aka, “suppliers”) for efficient and ef-

fective electronic trading.

Voucher UCSF representation of the vendor invoice in PeopleSoft . Vouchers are auto-

matically created from EDI invoices, but must be data entered by AP staff for

paper invoices. Voucher is part of the 3-way matching process

Worklist Organized list of specific pending actions for P2P Approvers and Reviewers.

Date post:	07-Apr-2018
Category:	Documents
Upload:	dracular-man
View:	225 times
Download:	0 times