City of Phoenix Accounts Payable Risk Matrices

Contributed August 29, 2001 by julia.bird@phoenix.gov City Auditor Department SAP Accounts Payable Control Matrix

01/29/12

The attached control matrix is the result of updating the post-implementation control matrix. The matrix outlines risks and controls. Controls will be validated and tested in the 2000-01 file for SAP Application Controls for Accounts Payable (File number 1010043) The FI-AP module process all invoices related to regular invoices, and invoices related to DPOs and CORs. Invoices related to POs are entered in the MM module, and controls are tested there. This matrix will be helpful in identifying the risks and controls over Accounts Payable processing. The 2000-01 fiscal year audit work can be relied upon for a review of internal controls over SAP & Central Accounts Payable processing. However, it will still be necessary to evaluate individual departments business processes and sample transaction when conducting audits of individual departmental expenditures. The control matrix contains 4 categories: 1) Vendor Master 2) Invoice Processing 3) Invoice Verification 4) Disbursements

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

City of Phoenix Accounts Payable Risk Matrices

N o Risks Possible Negative Results Risk (High / Med / Low) H Controls P / D Audit Step

01/29/12

Teammate Ref

SOC

Vendor Master Users may have unauthorized access to update vendor master files.

Financial Loss due to payments made to incorrect vendor. (fraud)

1. Appropriate transaction codes and other object authorizations should be assigned to authorized users. The following transactions need to be restricted: Create, change and display master records Block and unblock master records Mark record for deletion

1a. Review user profile for reasonableness of access. 1b. Review the Vendor Master File for changes that have been made and verify that all of the users who made the changes have the appropriate Vendor Master Change profile.

1a. - VM2 1b. - VM1 2. - VM2 3 VM2

1 =S

2. Incompatible segregation of duty transactions such as the following are restricted: Create/change vendor master data and accounts payable activities Create/change vendor master data and process warrants/distribute warrants. 3. City Controller signs off on security forms and check for these incompatibilities.

2. Review user profile for conflicting access (Refer to the D&T segregation of duties testing performed during the BASIS audit). 3. Review user profiles added for A/P Vendor Master, for City Controller approvals.

2 =S

3= S

P 2 Creation or deletion of vendor master files may not be authorized or detected. Financial Loss due to payments made to unapprove d vendor. (fraud) H 1. Creation or deletion of a vendor master file requires a vendor coding form authorization by the appropriate users. 2. The vendor coding form will be attached with source documents and the A/P supervisor approves it. Then the Accounts Admin Section verifies AP Supervisor approval. 3. The Accounts Admin Section reviews the SAP report P 1,2. Select a sample of vendor master records created. Trace information to vendor coding form, and verify proper authorization. 3. Verify Accounts Admin reviews list of modified/created vendors. 1,2 VM1 3 VM4 1,2 = S

3= O

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

City of Phoenix Accounts Payable Risk Matrices

N o Risks Possible Negative Results Risk (High / Med / Low) Controls P / D Audit Step

01/29/12
Teammate Ref SOC

(RFKABL00) listing modified vendors monthly. A sample of new/changed vendors is agreed to the vendor coding form.

Inaccurate or incomplete vendor data may be entered.

Unpaid vendors. Legal liability for noncomplianc e with governme nt regulation s

1. Mandatory fields in the vendor master file are defined and required. These fields include payee name (other required information depends on the Account Group). 2. 1099 information is requested prior to setting up vendor master record. For taxreportable vendors, the vendor is blocked until the 1099 information is provided 3. Vendors with incomplete info will be manually blocked from payment by AP staff. 4. Inappropriate override for mandatory fields are prevented by SAP. 5. The vendor coding form will be attached with source documents and the A/P supervisor approves it. Then the Accounts Admin Section verifies AP Supervisor approval. 6. The system displays an error / warning message whenever there is erroneous or omitted vendor data during data entry.

1. Observe a user creating a Vendor Master Record, and document mandatory fields are required for entry. 2. Observe a user creating a Vendor Master Record, and verify the 1099 is present, or vendor is blocked for payment. 3. Select a sample of unblocked vendor files and verify they have the required information. 4. Evaluate override authorizations (if any) 5. Select a sample of vendor master records created. Trace information to vendor coding form. 6. Observe that an error/warning message appears when erroneous information is entered, or required information is omitted.

1 VM3 2 VM3 3 VM1 4 VM3 5 VM1 6 VM3

1= O

2= O

3= S

4= O

5= S

6= O

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

City of Phoenix Accounts Payable Risk Matrices

N o Risks Possible Negative Results Financial loss. Risk (High / Med / Low) H Controls P / D P Audit Step

01/29/12
Teammate Ref SOC

Sensitive fields, such as Alternative Payees, may be inappropriately completed and not reviewed.

1. Alternative payees cannot be set up in the vendor master record without proper authorization. Alternate payees are used for collectors, levies, IRS or AZ Department of Revenue levies only. The creation or modification of alternative payee is subject to the same requirements as setting up or changing a vendor master record. 2. The vendor coding form will be attached with source documents and the A/P supervisor approves it. Then the Accounts Admin Section verifies AP Supervisor approval. 3. The Accounts Admin Section reviews the SAP report (RFKABL00) listing modified vendors monthly. A sample of new/changed vendors is agreed to the vendor coding form.

1. List all master vendor records with an alternative payee. 2. Select a sample from the list and review supporting documentation for accuracy and proper approval. 3. Verify Accounts Admin reviews list of modified/created vendors.

1 VM5 2 VM5 3 VM4

1, 2 =S

3= O

D P 1. Observe user creating a vendor master record, and verify the user checks for same name. 2. Select a sample of newly created vendor master records, and verify proper approval. 3. Observe creation of vendor names and verify naming conventions are used. 4. Test vendor master file for duplicate records. P 1. Perform same 1 VM3 2 VM1 3 VM3 4 VM1 2= S 1= O

Duplicate vendor records may be created.

Incomplet e vendor reporting due to more than one vendor number. Confusion when selecting vendor when invoicing.

1. A/P clerk checks for same name address, etc. when submitting or approving vendor master input form. 2. A/P supervisor signs off on vendor master input forms. 3. Standard naming conventions are used to reduce the possibility of duplicate vendor names P

3= O

4= S All VM 1=S,

Housing / Election

Financial

1. Housing vendors are subject

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

City of Phoenix Accounts Payable Risk Matrices

N o Risks Possible Negative Results loss. Risk (High / Med / Low) Controls P / D Audit Step

01/29/12
Teammate Ref SOC

vendors may not receive the same level of review/control as centralized A/P vendors. 7 Unauthorized changes to vendor master data may go undetected.

to the same controls mentioned in Vendor Master points 1-5.

audit steps for Housing (and any other users with vendor master authorization D 1. Run the RFKABL00 report, and ask users to explain the items.

steps

Financial loss

1. The Accounts Admin Section reviews the SAP report (RFKABL00) listing modified vendors monthly. A sample of new/changed vendors is agreed to the vendor coding form.

VM4

1= S

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) H Controls P / D Audit Steps

01/29/12

Teammate Ref

SOC

FI Invoice Processing Unauthorized users may gain access to post invoice transactions into SAP.

Financial loss.

1. Appropriate transaction codes and other object authorizations are assigned to authorized users. The following transactions are restricted: post, change, delete parked and normal documents park and release parked documents block and unblock documents. 2. Invoice posting capabilities are segregated from the following: vendor/bank master file creation/change warrant distribution a/p approval/review 3. SAP security administrator will also monitor.

1. Review user profile for reasonableness of access. 2. Rely on BASIS audit to identify conflicting access. 3. Review user profiles added for A/P Invoice, for A/P supervisor and Controller approvals.

1 IP2 2 IP2 3 IP2

1=S

2=S

3= S

Terminated or employees on extended leave of absence may have access to the system.

Financial loss.

1. A/P supervisor completes a form to remove access when employees leave. 2. Finance SAP Team sends out lists to departments twice a year identifying potential terminated employees

1. Compare user profiles for Invoicing to active employee list 2. Verify SAP Team sends out lists. 1. Select a sample of invoices and verify supervisory and central a/p staff review. 2. Select a sample of invoices greater than $100,000 and verify Finance Admin Supervisor review.

IP2

1=S

Users may be able to post high dollar transactions without proper authorization.

Unauthori zed large payments

1. Workflow process: Supervisory approval of invoice, and Finance A/P review & approval 2. Finance Dept Admin Supervisor reviews all payments greater than $100,000.

1 IP1 2 D10

1= O

2=S

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) Controls P / D Audit Steps

01/29/12
Teammate Ref SOC

Invalid invoices may be entered

Financial loss.

1. Workflow process: Supervisory approval of invoice, and Finance A/P review & approval 2. Original invoices are required as source document. Supervisors must approve paying on a fax or copy.

D P

1. Select a sample of invoices and verify supervisory and central a/p staff review. 2. Select a sample of invoices and trace information to supporting document. 1. Observe the entry of invoices, and the SAP controls for mandatory and intelligent fields. 2,3. Select a sample of invoice documents and verify supervisor and AP staff approval, and agree to source document. 1. Select a sample of invoices, and review for proper approval. 1. Enter an invoice twice, and verify that the system does not allow duplicate invoice numbers. 2. Review copies of the duplicate invoice report to verify that Finance is reviewing the report and taking appropriate action. 3,4. Select a

1 IP1 2 IP1

1, 2 =S

Inaccurate or invalid data could be input when record first entered into SAP

Financial loss.

1. Intelligent and mandatory fields have been set up. 2. SAP automatically required supervisor approval of invoices. 3. AP also traces information entered to the source document.

P D

1 IP3 2,3 IP1

1=O

2-3 =S

Invoices may not be properly approved.

Financial loss.

1. Workflow process: Supervisory approval of invoice, and Finance A/P review & approval. 1. System does not allow duplicate invoices upon invoice entry if the invoice number, vendor number and invoice date are the same. 2. Finance staff reviews the duplicate invoice report (zdup) daily. The report identifies all invoices with the same invoice number and the same amount. 3. Original invoices are required as source document. Supervisors must approve paying on a fax or copy. 4. AP staff physically stamp

IP1

1=S

Invoice is posted into SAP more than once.

Financial loss from duplicate invoices. Misstated financial statements .

1 IP3 2 IP4 3,4 IP1 5 IP4

1=S

2=S

3,4 =

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) Controls P / D Audit Steps

01/29/12
Teammate Ref SOC

paid on invoices after approval.

sample of invoices and trace information to supporting document, and verify invoice is stamped paid. 5. Use ACL to test for duplicate invoices in a variety of ways. 1. Observe Finance AP staff trying to change the payee or amount after the invoice is posted to verify SAP controls. 1. Determine if SAP or Finance checks for reversal entries. 2. Verify that only Finance AP supervisors have access to reverse a document.

Invoice may be changed after it is posted

Financial loss.

1. Payee or amount can not be changed once supervisor has released PCD.

IP3

1=S

The original transaction is inappropriately reversed out from the system.

Misstated financial statements . Unpaid vendors resulting in lost discounts, or late fees.

1. SAP will automatically verify the following, before a reversal entry is accepted: no cleared items original transaction was within the original posting module 2. Only Finance AP supervisors have access to do reversal documents (FB08, MR08), and a reason code is required. Standard procedure is to also enter information in the text field.

1 IP6 2 IP6

1=S

10

Invoice may contain mathematical errors.

Financial loss

1. The creator of the invoice or manual PCD is responsible for verifying the mathematical accuracy of the invoice. There are no subsequent controls. 1. Workflow process: Supervisory approval of invoice, and Finance A/P review & approval 2. Finance AP check for PO reference on the invoice. 3. Finance AP identifies

11

Invoices may be incorrectly or inaccurately keyed in through the FI module and not through the MM module, which would bypass the three way match (PO, invoice and

Financial loss from duplicate invoices. Misstated financial statements .

1. Select a sample of invoice documents and verify mathematical accuracy of the invoice. 1. Select a sample of invoices and verify supervisory and central a/p staff review. 2&3. Observe Finance AP

IP1

1 =S

1 IP1 2 IP3 3 IP7

1=S

2,3 =

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) Controls P / D P Audit Steps

01/29/12
Teammate Ref SOC

goods receipt) control to detect any errors.

invoices for commodities, and investigates any commodities not being paid against a DPO, COR, or PO. 4. Finance AP reconciles all outstanding open items in g/l account 291000. This g/l account recieves all GR (goods receipts) and INV (invoices) posted. Thus Finance AP can identify: GR without INV INV without GR GR different from INV, and vice versa

process and verify they check for PO reference on the invoice, and they check commodities not paid against a DPO, COR or PO. 4. Review of g/l account 291000.

4 =O

12

Invoice is not applied towards the related RF

Misstated financial statements

1. Creator of the invoice enters the RF# in a user-defined field. 2. Workflow process: Supervisory approval of invoice, and Finance A/P review & approval. 3. Finance A/P staff approving the invoice look for the RF# on the invoice, and verify the number is on the SAP invoice. 4. After Finance AP staff approves the invoice, SAP verifies matching data (ie vendor number) and automatically updates the RF. 5. Departments are responsible for their budgets, and may notice invoices not applied to RFs.

1-3. Observe Finance AP process and verify the reviewer checks for RF#. 4. We did not test for invoices with RF references, that were not applied to the PO. We relied on the other controls. 5. No test necessary.

1-5 IP8

1-5 =S

13

Invoices may not be input in a timely manner.

14

Invoices that are

Late payments to vendors, resulting in lost discounts, or late fees. Late

1. Vendor inquiries are investigated.

1. Review cycle time information for timeliness of invoice input. 2. Review report on number of invoices paid late.

1 IP5 2 IP5

1,2 = S

1. Finance A/P management

1&2. Review the

1,2 IP5

1,2 =

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results payments to vendors, resulting in lost discounts, or late fees. Misstatem ent of financial statements . Risk (High / Med / Low) Controls P / D Audit Steps

01/29/12
Teammate Ref SOC

parked may not be posted and cleared on a timely basis.

monitors the number of items and age in workflow inboxes. 2. Finance AP management investigates all parked items over 2 weeks old. H 1. The FI accounts payable and FI general ledger are fully integrated within SAP. A posting to the vendor account will automatically post to the appropriate reconciliation account in the general ledger on a real time basis. GL account number 222000 is the only reconciliation account. 1. The workflow process is comprised of supervisory approval of invoice, and Finance A/P review & approval. 2. SAP gives a warning message if posting information (ie Business Area /cost center) is not compatible. 3. Reconciliation account 222000 is used to ensure integrity between GL and AP sub-ledger. Direct posting to reconciliation account is blocked. D

most recent report of invoices parked, and document the staffs comments.

15

The General Ledger account balances may not be updated when a transaction is posted into a Vendor Account e.g., the reconciliation process may not be correctly set-up.

1. Select a sample of invoices and verify that the posting to the vendor account agrees to the general ledger posting.

1 IP1

1=S

16

Transactions may be posted to the wrong account / project / business area.

Misstatem ent of financial statements .

1. Select a sample of invoices and verify supervisory and central a/p staff review. 2. Observe SAP warning when Business Area and Cost Center are not compatible.

1 IP1 2 IP3 3 IP1

1,2 = S

17

Invoices may not be stored for payment disputes, etc. Posting keys for A/P transactions may not be restricted.

Lack of document ation for auditors.

1. All supporting documentation (ie invoice) is stamped paid and filed. 1. SAP automatically selects posting keys based on input information. 2. SAP requires the matching of debits and credits before an invoice is posted.

18

P P

3. Review items in the 222000 g/l account and document the staffs comments. 1. Select a sample of invoices and verify that documents were stored properly. 1-2. Observe that posting key controls are in place.

IP1

1=S

IP3

1-2 = O

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

10

City of Phoenix Accounts Payable Risk Matrices

01/29/12

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

11

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) M Controls P/ D Audit Steps

01/29/12

Teammate Ref

SOC

Invoice Verification Incorrect or invalid invoice data may be entered when the record is first entered via the MM module.

Financial loss

1. The system requires entry of the following information upon entry of the invoice: purchase order number document date invoice number total invoice amount 2. The system automatically displays all lines of the related purchase order and the value of the related goods receipt (GR) entered. Therefore AP staff can select the line items relevant to the specific invoice.

1. Observe the entry of invoices, and the SAP controls for mandatory and intelligent fields. 2. Observe data entry and verify SAP displays PO limitations.

1 IV3 2 IV3

1, 2 =S

The tolerance limits for invoice verification procedures may be set too high. The tolerance limit is used to match the FI invoice with the MM PO goods receipt.

Unauthori zed large payments.

1. The tolerance limits used to check on the three way match process are set according to the Citys policies and standards. The standard is 10%, or $100 per line item. 2. If the tolerance is exceeded, the system will not display the PO line items. Then the AP clerk will not process the invoice, and will notify Purchasing of the discrepancy.

1. Run the tolerance limit report for AP and MM, by transaction key, and compare the limits to the City standards. 2. Observe the entry of invoices and verify SAP warning message and AP clerk action. 1,2. Observe the entry of invoices and verify SAP warning message and AP clerk action.

1 IV4 2 - IV3

1= S

Payment blocks may not be placed on invoices during the invoice approval process.

Financial loss due to invoices being paid before final approval.

1. Payment blocks include: Invoice amount exceeds PO amount by tolerance limits The quantity on the invoice exceeds the quantity on the goods receipt (GR). 2. The system blocks the payments automatically if one of the above situations exists. 1. Finance AP check for PO reference on the invoice. 2. Finance AP identifies invoices for commodities, and investigates any commodities not being paid against a DPO,

IV3

1= O

2=O

Purchase made through PO is paid by PCD.

Misstated financial statements .

1,2. Observe Finance AP process and verify they check for PO reference on the invoice, and they

1,2 IV3 3 IV4

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

12

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) Controls P/ D Audit Steps

01/29/12
Teammate Ref SOC

COR, or PO. 3. Finance AP reconciles all outstanding open items in g/l account 291000. This g/l account recieves all GR (goods receipts) and INV (invoices) posted. Thus Finance AP can identify: GR without INV INV without GR GR different from INV, and vice versa 1. If there is a quantity variance where the quantity invoiced is different than the quantity of goods received, and if there is no further goods receipt recorded by the system, the GR/IR account will not be cleared automatically. 2. A batch job is run to match GR and IR entries within the account on a daily basis. 3. Finance AP staff reviews the GR/IR clearing account monthly for long outstanding, open items, and makes the appropriate corrections.

check commodities not paid against a DPO, COR or PO. 2. Review of g/l account 291000.

Large outstanding payable balances may build up and not be reviewed on a regular basis in the GR/IR general ledger account. An example is the account where tolerance differences are posted.

Late payments to vendors, resulting in lost discounts, or late fees.

1. Review of g/l account 291000.

IV4

NA

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

13

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) H Controls P / D Audit Steps

01/29/12

Teammate Ref

SOC

Disbursements Unauthorized users may be able to post invoice transactions into SAP. Unauthorized access to the Payment Output file. (Note: Payment Output File is the result of a formatted payment batch. It contains all of the formatted payment information, in report format, to cut checks. Access to the directory should be restricted or extremely limited.) Cash disbursement details may be inaccurate and incomplete.

Financial loss Financial

1. See controls for Invoice Processing. 1. SAP Security Profiles: Only 3 A/P supervisors have access.

1. Rely on Invoice Processing tests. 1. List all users with this profile and review for reasonableness and proper authorization.

IP all

D3

1=S

Financial loss. Misstated financial statements .

1. Disbursement data is based on information provided during invoice entry (either via FI or MM module). 2. Prior to the payment run, SAP creates an exception report for invoices where mandatory fields are not populated, and for invoices blocked for payment. 3. The A/P supervisor reviews the Payment Proposal List (RFZALI00) and the Exception List (RFZALI10).

1. Rely on Invoice Processing controls. 2,3. Observe the documentation existing to verify supervisory review of payment proposal list and exception list.

1 all IP 2,3 D4

1=S

2= O

Inaccurate or incomplete vendor invoices may be paid.

1. Vendors with incomplete info will be manually blocked from payment by AP staff.

1. Select a sample of unblocked vendor files and verify they have the required information. 1. Select a sample of invoices and trace the check

VM3

1= S

Check number may not be indicated in the payment document during payment

1. The system captures the check number in the document allocation fields, and automatically prints the

1 D1 2 D2

1=S

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

14

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) Controls P / D Audit Steps

01/29/12
Teammate Ref SOC

processing.

number on the check. 2. Check number is pre-printed on manual checks.

number back to the record. 2. Trace manual check numbers back to invoices to make sure the manual check number was entered. 1. Select a sample of payments > $100,000 and verify Accounts Admin signature. 2. Observe check run and verify checks =>$100,000 are approved by Accounts Admin. 1. Run a report of all invoices due for a specific date, and compare that to the automatic payment run. 2. Document managements review of the Payment Proposal List and Exception List. 1. Select a sample of paid invoices and verify they were assigned a clearing document number and clearing date.

Large or unusual payments may not be blocked for management review.

Unauthori zed large payments.

1. The Accounts Admin staff approves all payments over $100,000, and all payments to 1-time vendors. 2. Procedures exist to review and approve invoices that are blocked.

P D

1 D10 2 D4

1, 2 =S

Invoices selected for payment may not be reviewed.

Financial loss

1. The system is configured to propose invoices that are due for payment in the automatic payment run. A/P reviewer approval is required before payment.

1 D1 2 D4

1, 2 =S

Payments could be made more than once for an invoice.

Financial loss from duplicate payments.

1. SAP automatically assigns a clearing document number and clearing date when payment is made for open invoice item. 2. SAP will not select cleared items for payment. 3. Print file disappears after it is printed, so checks cant be

1 D1 2 D1 3 D1

1, 2, 3=S

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

15

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) Controls P / D Audit Steps

01/29/12
Teammate Ref SOC

printed again.

2. Test the disbursement run to make sure no cleared items were paid. 3. Document that the print file disappears after it is printed.

Payments made are posted to the wrong accounts.

Misstated financial statements .

1. The FI accounts payable and FI general ledger are fully integrated within SAP. A posting to the vendor account will automatically post to the appropriate reconciliation account in the general ledger on a real time basis. GL account number 222000 is the only reconciliation account. 1. SAP automatically assigns a sequential check number to each check, and records it in the register 2. The check register is used to keep track of physical check numbers. 3. Procedures exist for reviewing the check number in the check register. The procedures cover: Reviewing missing checks or checks number not running in sequence; Reconcile check register after each check run; Are spoiled manual checks retained; Checks printed as overflow documents are denoted as void Payment is made by the first check in the series only, and others are denoted as void.

1. Select a sample of invoices and verify the g/l account entry. 2. Review activity in g/l account #220000 to verify all invoices were posted to FI-GL. 1. Identify process for assigning both electronic and manual check numbers. 2. Review the check register for missing check numbers. 3. Observe procedures for: reviewing missing checks or check numbers reconciling check register after each run spoiled checks voided checks 4. Verify SAP reports all

1 D1 2 D1

1=S

2= O

10

The check number in the check register may not be updated.

Financial loss due to the difficulty reconcilin g bank accounts, and noting missing checks.

1 D2 &D4 2 D1 3 D1 4 D1

1=S

2=S

3= O

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

16

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) Controls P / D Audit Steps

01/29/12
Teammate Ref SOC

4. SAP reports all voided checks during the check run, and the AP Supervisor reviews the report. 5. The AP Supervisor reconciles the number of checks from the check register report to the count on the Job Log. 11 The discount amount may be calculated incorrectly. Financial loss. M 1. The system automatically calculates discounts. P

voided checks during the run. 5. Document the reconciliation of Check register and SAP Job Log 1. Select a sample of invoices and verify that the appropriate discount was taken. 1. Select a sample of paid invoices and verify they were assigned a clearing document number and clearing date. 1. Document any check print restart events, and verify spoiled checks were retained and checks were completed. 1 D5

4=S 5=S

1=S

12

The transaction in the system may be left as an open item eventhough payment has been made.

Financial loss from duplicate payments.

1. The system assigns a clearing number and a clearing document to close an outstanding transaction when payment is made.

1 D1

1=S

13

In the Check Print Restart and Reset Payment Batch functions: spoiled checks may not be retained for evidence as to restart. Completeness of checks may not be verified prior to restart. Checks issued to employees may be inappropriate.

Financial loss due to discarding spoiled checks.

1. Have not had to do a check print restart yet. Could not validate.

1 D1

1=O

14

Financial loss.

1. Employees are grouped in a separate account group. 2. Supervisory approval required through workflow. 3. A/P audit review. 4. Manual approval required on PCDs entered by A/P clerks.

P P D D

1. Select a sample of checks paid to employees, and verify proper approval and proper account group. 2-4 Rely on Invoice Processing

1 D8 2-4 all IP

1-4 = S

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

17

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) H Controls P / D Audit Steps

01/29/12
Teammate Ref SOC

15

Manual checks issued may not be recorded in the system.

Financial loss due to the difficulty reconcilin g bank accounts, and noting missing checks.

1. Manual checks are recorded in the SAP check register. 2. The City Controller reviews the SAP check list prior to the release of manual checks. 3. An Accounts Admin staff member reviews the log of manual checks to ensure that no checks are missing and all numbers are entered. 4. Blank check stock is secured.

testing 1. Take an inventory of the manual checks, and verify all missing check numbers are in SAP and on the manual log. 2. Document City Controller requires SAP Check List prior to signing manual checks. 3. Verify independent review of manual check log. 4. Verify blank checks are secure.

1-4 D2

1=S

2=O

3=O

4=S

16

Printed checks may be lost or stolen.

Financial loss

1. The check printer is stored in a public area, but is supervised during the printing. 2. Checks are mailed out the same day they are printed. 3. Printed checks kept for pick up are kept in a secretarys desk, and locked in the safe for the night.

1. Observe the check run, and review the security methods used to make sure checks are mailed out or kept in a secure location.

D1

1 =O

17

Cancellation and reissue of checks may be improperly processed.

Financial loss. Misstatem ent of financial statements .

1. Controls are in place to ensure that warrants already issued have not been cashed before the re-issue of another warrant by checking with the bank and SAP. 2. Appropriate and authorized documentation is received from the vendor for review before the re-issue of another warrant.

1. Select a sample of reissued checks and verify that the original warrant was never cashed. 2. Agree check information to supporting documentation.

1-3 D11

1, 2, 3=S

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

18

City of Phoenix Accounts Payable Risk Matrices

N o Risks Potential Negative Results Risk (High / Med / Low) Controls P / D Audit Steps

01/29/12
Teammate Ref SOC

3. A/P supervisor checks documentation and approves transaction 18 The bank amount in the books may not agree with the amount at hand in bank. Financial loss. Misstated financial statements . H 1. An independent person reviews the bank reconciliation . 2. The bank account is reconciled automatically daily, with exceptions cleared manually. D

3. Verify supervisor approval on all re-issued checks. 1. Document segregation of duties between disbursements and bank reconciliation. 2. Select a sample of reconciliations and review unreconciled items. 1. Verify the signature stamp is secure. 1. Verify that Treasury reviews all checks => $100,000. 1. Observe credit memo run and document issues.

1-2 - D9

1= O

2=S

19 20

21

Signature stamp is used by an unauthorized person Payment to vendor may be made when there is a large outstanding receivable from that company Credit memos due to Accounts Receivable customers may not be processed properly

Financial loss Financial loss

H M

1. The signature stamp is kept in a safe in Accounts Admin 1. AP provides Collections with a list of all checks => $100,000 daily for their review. 1. Finance staff performs a separate payment run for credit memos

D2 D10

D7

/opt/scribd/conversion/tmp/scratch6135/82809076.doc

19