Health Canada
www.hc-sc.gc.ca
Common menu bar links
Audit of Data Integrity for the Standard Payment System (Interdepartmental Settlements)
June 2008
Help on accessing alternative formats, such as Portable Document Format (PDF), Microsoft Word and PowerPoint (PPT) files, can be obtained in the alternate format help section.
(PDF Version - 169 K)Table of Contents
Executive Summary
The Standard Payment System (SPS) is owned, operated and maintained by the Public Works Government Services (PWGSC). It is the vehicle used by all Federal Departments to settle invoicing and payments between government departments.
Departments providing goods and services (Called Creditors) to other government departments (Called Debtors) create invoices in their accounting system. The invoices are electronically submitted to the SPS which edits the invoices, assigns a reference number to the invoices, transmits the invoices to the appropriate government department and automatically transfers funds from the Debtor department (receiving the goods/services) to the Creditor department (providing the goods/services).
The objectives of the audit is to:
- a. determine the quality of the data, in terms of completeness and accuracy, of applications that interface with FIRMS/SAP; and
- b. provide an overall assessment of the internal control environment around those applications.
The Audit and Accountability Bureau conducted the audit in accordance with the Government of Canada's Policy on Internal Audit. SPS-IS is one of several applications, which interfaces with SAP that was included in the audit plan.
The Health Canada accounting system, Framework for Integrated Resource Management System (FIRMS), more commonly known as SAP, receives Interdepartmental Settlement (IS) transactions from the SPS system. SAP performs amongst all other edits, an edit on the invoices received to ensure that they correspond to authorized goods/services. If not, then the transaction is rejected and reversed.
SPS interface files uploaded to SAP were sampled as part of the conduct phase of the audit. There were no discrepancies in the control totals. IS transactions are part of the SAP database. Based on a review of SAP backup logs, we determined that backups of the SAP database were performed adequately. Finally, we obtained a list of users of the interdepartmental settlement process in SAP and found no issues related to access controls and separation of duties.
Based on a review of the processes and procedures in place, the existing controls environment around the interface files, that were processed by SAP within Health Canada, are functioning well. The quality of the data within the interface settlement files is accurate and complete.
Introduction
Background
The Interdepartmental Settlement (IS) is the payment instrument used to settle invoices and credit memos between government departments. This payment between government departments is settled using the Standard Payment System (SPS) owned and maintained by PWGSC.
Agreements with Other Government Departments (OGDs) to supply goods or services result in the creation of Purchase Orders, Funds Reservations, or Funds Commitments by the acquiring Debtor Department. Once these documents are created, the appropriate government department is advised as to the specific reference information to enter on their Interdepartmental Settlement (IS) advice related to each order. After the shipment of goods or delivery of services, the Creditor Initiator department is able to generate, via the Standard Payment System (SPS), both an IS advice to the Debtor Recipient department and the transfer of funds from the Debtor Department's account to the Creditor Department's account in the Receiver General-General Ledger.
Under the payment settlement process, Health Canada sends a settlement transaction from its accounting system to SPS via the SPS Settlement file known as the IS Return/Notification file. Normally Health Canada would be the Creditor (the department receiving money), but Health Canada can also be the Debtor department (the one who is on the paying end of the transaction). The two departments in such a transaction are designated as either the Initiator (the department that sends the record to SPS) or the Recipient (the department that did not initiate, but will receive a notification from SPS that the transaction occurred). For the Fiscal Year April 1, 2005 to March 31, 2006, $486 million was processed as interdepartmental settlements in SAP of which $142 million were initiated by Health Canada.
SPS processes the IS transactions on a daily basis and creates a file for each government department to provide transaction processing details. Returns and Notifications are contained in the same file. Appendix A is a high level representation of the interrelationship of the IS process involving SPS.
Health Canada and each department define a threshold limit for SPS to determine the maximum amount they will allow to be initiated against them automatically. Any transaction having an amount above that threshold is set to "Pending" status for a maximum period of 5 days to allow the department to confirm that it can proceed. If confirmation is not received by SPS within the 5 days then SPS automatically cancels the transaction and notifies the appropriate departments. Health Canada's threshold is $500,000.
The audit was undertaken by the Audit and Accountability Bureau in accordance with Health Canada Risk-Based Audit plan which was approved by the Departmental Audit and Evaluation Committee October 4, 2006. The audit was conducted in accordance with the Government of Canada's Policy on Internal Audit. SPS is one of several other feeder applications, which interface with SAP that was included in the audit plan
Objectives
The objectives of the audit were to:
- c. determine the quality of the data, in terms of completeness and accuracy, of the application that interfaces with FIRMS/SAP; and
- d. provide an overall assessment of the internal control environment around the application.
PWGSC is the SPS application owner and this is outside the scope of the audit. As a result, the audit did not include the assessment of the internal control environment within SPS.
Scope and Approach
The audit focussed on interdepartmental settlements processed by SAP in the calendar year 2006.
The audit for the SPS interface was conducted in the National Capital Region. The audit consisted of interviews with departmental officials at Health Canada, a review of relevant documentation and tests of the general computer controls and application controls concerned with the SPS to SAP interface. The audit focussed only on the interface files were processed in SAP within Health Canada. The period assessed was from January 1, 2006 to December 31, 2006.
Evidence gathered and analysed consisted of the actual data files transferred from SPS to SAP during the calendar year 2006. Tests on 65 files were conducted and the information contained in these files was verified against the actual Program/Finance information in SAP.
The audit was conducted using two sources of criteria:
- ISACA's COBIT (Control Objectives for Information and Related Technology) which is an IT governance model; and
- Treasury Board's Internal Audit Policy.
Interviews were conducted with staff using the IS processing in SAP, staff using the SPS system, staff providing SAP IT security, and staff performing SAP database backups. Documentation reviewed included user manuals and technical manuals.
The lines of enquiry for the audit included:
- Completeness and Accuracy of Data
- controls to ensure that all data was successfully interfaced;
- controls to ensure that transactions are completely processed;
- transactions that have been incorrectly processed are identified and corrected in a timely manner;
- segregation of duties with respect to transaction processing;
- General Controls Environment
- access controls;
- authenticity of the data; and
- backup and restore procedures.
Findings
Completeness and Accuracy of Interface Files
Input/Processing/Output Controls
a) Transaction data that are entered for processing are subject to a variety of controls to check for accuracy, completeness and validity. Procedures also ensure that input data are validated and edited as close to the point of origination as possible. Procedures for data processing validation, authentication and editing are performed as close to the point of origination as possible. Output is routinely balanced to the relevant control totals.
SPS performs three key functions automatically:
- notifies the Debtor Recipient Department of the payment transaction (NOTIFICATION);
- processes the payment transaction to the Creditor Initiator Department (RETURN); and,
- advises the Receiver General (RG) to transfer the funds from Debtor to Creditor in the RG-GL.
It is left to the Debtor Recipient to record both the invoice and the settlement in the Department Financial Management System (DFMS).
The SAP processing for the SPS Return/Notification interface includes:
- validation / identification checks on the header and detailed records to ensure overall file validity. If any critical errors are found (invalid record layout, invalid department, invalid date or amount, invalid counts, etc.), the entire file is rejected;
- validation of the complete set of input prior to creating any transactions or updating any database tables;
- identification of an originating document (purchase order, Funds Reservation or sales order) or an IS Coding Key which matches the Recipient Reference field on the IS file;
- matching against the initiating document for returns (which are IS initiated by the Department);
- preparation of appropriate billing or invoice documents when matching transactions returned by SPS in the SPS Return/Notification file to SAP; and
- reports to handle the necessary management of error conditions, unmatched amounts, and interface processing control totals.
There is one interface file to SAP for every business day resulting in approximately 240 files in 2006. Sixty five (65) files from the months of March, April and June 2006 were selected for examination. This represents a sample of 27% of all files interfaced in 2006. The control record for each interface file was matched against the number of requisitions, number of IS transactions and total amount of IS transactions. No discrepancies were found.
b) Procedures exist to ensure that all authorized source IS documents input into SAP are complete and accurate. SAP rejects all incomplete transactions.
Controls exist to ensure that source documents expected are received, and that all required data are processed. Also, SAP matches the Interdepartmental Settlement Reference Number (ISRN) on the incoming transaction from SPS to an ISRN on an existing SAP document. If no match is found then the transaction is rejected and sent back to the originating government department.
Based on the review of these processes, no anomalies were identified.
Segregation of duties is present regarding the preparation and approval of source documents leading to interdepartmental settlements. Transactions must receive an electronic FAA (in accordance with the Financial Administration Act) Section 33 approval prior to interfacing from SAP to SPS. This approval is performed by a different person other than the person who input the IS transaction into SAP. No issues related to segregation of duties were identified.
Procedures exist for the correction and re-submission of erroneous data input of IS transactions at Health Canada. Error handling procedures exist during IS data origination into SAP to ensure that errors and irregularities are detected, reported and corrected. These are normal SAP processes. Procedures exist to ensure erroneous IS transactions are identified in SAP before processing and without undue disruption of the processing of other valid transactions.
All the rejected transactions identified on the SPS interface files in June 2006 were selected. Out of these 29 transactions, only 3 originated in Health Canada and therefore only those three could be verified. Each of the three transactions followed SAP and IS procedures for identifying the transactions before SAP processing. Errors were properly identified in the ISRN reports and were subsequently corrected. Since the logic of all transactions is the same as that of the three transactions, we were satisfied that this sample was sufficient to determine the effectiveness of the control.
General Controls Environment
Procedures exist to ensure that only authorized staff members perform data input to SAP for IS transactions. User access rights to the SAP and SPS systems is centrally managed and based on defined and documented business needs and job requirements. Health Canada users of SPS must receive authorization to access SPS by completing the Mainframe User ID Security Request form (5136) and acknowledging the rules identified on the form. The appropriate Health Canada Security officer must also sign this form. Users must also sign the Security Responsibilities for Financial System(s) Users form.
A sample of 33% of the IS users in SAP was selected and a verification was made to determine if they all received appropriate authorization. All users in our sample did receive appropriate authorization.
Transaction data are exchanged over a path or medium with controls to provide authenticity of content, proof of submission, and proof of receipt and non-repudiation of origin.
Even though the creation of the SPS interface file is created outside of Health Canada (and therefore out of this audit scope), limited testing was conducted to ensure that the SPS interface files did contain effective controls to provide authenticity to the data. A review of the log of the interface files from June 7, 2007 (since the 2006 logs no longer exist) was conducted. The log for the interface of 3 different files identified the specific transaction code and the start/end time of the interface. Each file also contained a unique identifier that was used to validate the file.
There are defined and implemented procedures for backup and restoration of SAP data. Off-site storage of critical back-up media and other IT resources is established.
The Archive Snapshot created by the IBM Tivoli Storage Manager on July 15, 2007 and the Backup Online Log of July 13, 2007 were reviewed. The backups of the SAP database were successfully completed. Documentation was reviewed that supports that the SAP database was successfully restored.
Appendix A
