Office of the Chief Financial Officer Washington, DC New Core Project: Phase 1, Release 3, Implementation and New Core Interface Solution Functionality Information Systems Audit Division Audit Report Number: 2016-DP-0004 Washington, DC September 20, 2016 Audit Report Number: 2016-DP-0004 Date: September 20, 2016 HUD Rushed Implementation of Phase 1, Release 3, of the New Core Project Highlights What We Audited and Why We audited the functionality of the U.S. Department of Housing and Urban Development’s (HUD) New Core Interface Solution (NCIS) for phase 1, release 3, as part of the internal control assessments required for the fiscal year 2016 financial statement audit under the Chief Financial Officer’s Act of 1990. Our objective was to determine whether adequate internal controls were in place for the phase 1, release 3, functionality of NCIS and the impact of the release implementation on the project. This audit is the third in a series of audits completed on the New Core Project implementation. What We Found Following the implementation of phase 1, release 3, of the New Core Project on October 1, 2015, HUD had unresolved data conversion errors, inaccurate funds management reports and lacked a fully functional data reconciliation process. In addition, NCIS’s performance was not monitored, tracked, or measured, and controls over processing errors within Oracle Federal Financials were routinely bypassed. These conditions occurred because HUD rushed the implementation of the release. Specifically, HUD did not move the implementation date when issues were identified during system testing to allow time to resolve the issues, development of the custom reports was not far enough along to allow full system testing, development of the reconciliation tool could not be completed before the scheduled implementation date, and time did not permit the establishment of performance metrics. As a result, in June 2016, unresolved data conversion errors were estimated at an absolute value of more than $9 billion, HUD’s funds management reports contained inaccurate data, the newly completed status of funds reconciliation report indicated that there was an absolute value of $4.5 billion in differences between the HUD Centralized Accounting and Processing System and Oracle Financials, and it was difficult to tell whether NCIS met user needs and business process requirements. What We Recommend We recommend that HUD correct the data conversion errors, verify the reconciliation reports and resolve differences, and improve the custom Oracle Discoverer reports and error handling. Table of Contents Background and Objective......................................................................................3 Results of Audit ........................................................................................................5 Finding 1: HUD Rushed the Implementation of Phase 1, Release 3, of the New Core Project ....................................................................................................................... 5 Scope and Methodology .........................................................................................14 Internal Controls ....................................................................................................15 Appendixes ..............................................................................................................16 A. Description of the NCIS Error Resolution Process .............................................. 16 B. Auditee Comments and OIG’s Evaluation …………………………………..…. 17 2 Background and Objective In July 2013, the U.S. Department of Housing and Urban Development (HUD) signed an interagency agreement with the U.S. Department of the Treasury’s Bureau of Fiscal Services’ Administrative Resource Center (ARC) to migrate its financial transactions and systems to ARC. The agreement provided that ARC would support (1) funds management, (2) purchasing, (3) accounts payable, (4) accounts receivable, (5) cash management, (6) cost accounting, (7) the core financial system, (8) the general ledger, (9) financial reporting, (10) grants management, and (11) loans management. With this agreement, HUD became the first cabinet-level agency to commit to adopting a Federal financial shared services solution for its core accounting. The New Core Interface Solution (NCIS) is a custom developed system owned by HUD and hosted by Oracle Managed Cloud Services. NCIS performs the extract, transform, and load functions, as well as a variety of error processing, reconciliation, and interface file management functions to support the interface of HUD systems with ARC’s systems. With the implementation of phase 1, release 3, there are two specific interfaces between NCIS and Oracle Federal Financials. NCIS budget interface: Budgets for both programmatic and salary and expense funds are established in Oracle Financials via ARC budget templates, following standard ARC template processing. Once entered into Oracle Financials, programmatic budget lines are filtered from Oracle Financials via a budget filter table and transmitted to HUD through the budget interface to update legacy systems and allow for programmatic transactions. Existing legacy system interfaces were not altered in release 3 and continue to operate as designed. NCIS general ledger interface: Programmatic (not salary and expense) transactions continue to be processed in HUD legacy systems, which interface these transactions into the HUD Centralized Accounting and Processing System (HUDCAPS). Each night, the transactions posted to the HUDCAPS general ledger are transmitted to Oracle Financials through the NCIS general ledger interface. The Oracle Financials general ledger is updated with the resulting programmatic activity. Oracle Financials then transmits a confirmation file to NCIS, which identifies any errors encountered in processing the interfaced general ledger data into Oracle Financials. With the phase 1, release 3, implementation, the functionality of NCIS was modified to transfer budget information to legacy systems from Oracle Financials and transfer programmatic financial transactions from legacy systems to Oracle Financials, translating between the HUDCAPS account code structure and the Oracle accounting flex field 1 in both instances. Also, 1 The accounting flex field is a feature within Oracle applications that provides a flexible way for the applications to represent objects such as accounting codes. The accounting flex field aligns to the Common Government-Wide Accounting Classification structure. This structure represents an accounting classification, which provides a 3 with the implementation of release 3, Oracle Financials is now the financial system of record, and HUD has transitioned procurement systems from the HUD Integrated Acquisition Management System to ARC’s PRISM. 2 ARC will be responsible for producing external regulatory and consolidated financial reporting on behalf of HUD, and HUD will be responsible for validating and certifying the ARC-generated financial statements for inclusion in the annual financial report. Oracle Discoverer is a Web-accessible reporting tool that ARC provides to customer agencies to access data processed in Oracle Financials. Oracle Discoverer allows real-time queries to be executed against any data elements captured in Oracle Financials. The user can view real-time data in various ways, including drill up or down capabilities. The user may also download report data to a spreadsheet or other desktop applications. Oracle Discoverer allows queries to be built against most data elements in any application hosted by ARC on an Oracle Financials database. A library of most commonly used reports is maintained and made available, including status of funds and detail trial balance. ARC supports two different versions of Discoverer. Discoverer Viewer is the version most commonly used and accommodates users that only need to view pre- established reports and make minor changes to the report parameters and layout. Selected reports allow the user to view real-time data in various ways, including drill up or down capabilities. The user may also download the report to spreadsheet or other desktop applications. Discoverer Plus is available for users with a need to create or modify reports. In addition, Discoverer Plus provides all of the functionality of Discoverer Viewer as explained above. This audit was conducted as a component of the internal control assessments required for the fiscal year 2016 financial statement audit under the Chief Financial Officer’s Act of 1990. Our objective was to determine whether adequate internal controls were in place for the phase 1, release 3, functionality of NCIS and the impact of the release implementation on the project. Specifically, we wanted to determine whether (1) New Core, release 3, financial management interface processing was adequately controlled and (2) data reconciliations between the systems were accurate and complete. This audit is the third in a series of audits to be completed on the New Core Project implementation. consistent means for classifying financial events that enables the summarization and reporting of information in a meaningful way. 2 PRISM™ is a Web-based application that provides Federal and defense acquisition communities with the tools needed to support the complete acquisition management life cycle, from initial planning and requisitioning through source selection, award, post award management, and closeout. 4 Results of Audit Finding 1: HUD Rushed Implementation of Phase 1, Release 3, of the New Core Project Following the implementation of phase 1, release 3, of the New Core Project on October 1, 2015, HUD had unresolved data conversion errors, inaccurate funds management reports and lacked a fully functional data reconciliation process. In addition, NCIS’s performance was not monitored, tracked, or measured, and controls over processing errors within Oracle Federal Financials were routinely bypassed. These conditions occurred because HUD rushed the implementation of the release. Specifically, HUD did not move the implementation date when issues were identified during system testing to allow time to resolve the issues, development of the custom reports was not far enough along to allow full system testing, development of the reconciliation tool could not be completed before the scheduled implementation date, and time did not permit the establishment of performance metrics. In addition, procedures developed to address individual infrequent errors were not sufficient to address the number and frequency of errors that occurred. As a result, in June 2016, unresolved data conversion errors were estimated at an absolute value of more than $9 billion, HUD’s funds management reports contained inaccurate data, the newly completed status of funds reconciliation report indicated that there was an absolute value of $4.5 billion in differences between HUDCAPS and Oracle Financials, and it was difficult to tell whether NCIS met user needs and business process requirements. Data Conversion Errors Remained Uncorrected Data conversion errors complicated the analysis and monitoring of balances for funds control purposes and increased the risk of invalid spending transactions and inaccurate financial reporting. These errors created the following conditions: • Negative budget authority 3 in some accounts and too much authority in others, • Incorrect balances in budget lines that were populated with default values, and • Obligations containing miscellaneous 4 vendors as opposed to valid vendors. 3 Budget authority is the authority provided by law to incur financial obligations that will result in outlays. This definition is the same as that in section 3(2) of the Congressional Budget and Impoundment Control Act of 1974, which Congress uses in the congressional budget process. You violate the law if you enter into contracts, issue purchase orders, hire employees, or otherwise obligate the Government to make a payment before a law has provided budget authority for that purpose (Office of Management and Budget (OMB) Circular No. A-11 (2015), page 11 of section 20.4 (a)). The specific forms of budget authority are appropriations, borrowing authority, contract authority, and spending authority from offsetting collections (OMB Circular No. A-11 (2015), page 3 of section 20). 4 Miscellaneous vendor is a term HUD used to describe the data inaccuracies that occurred. HUDCAPS allowed a user to select any vendor at the time of obligation and then modify the vendor at the time of payment. 5 Office of Management and Budget (OMB) Circular No. A-123, Appendix D, Compliance with the Federal Financial Management Improvement Act (FFMIA) of l996, section 7, FFMIA compliance, states, “Financial reporting objectives include reliable, timely, and accurate financial information for managing day-to-day operations and reporting on an agency’s financial condition. Reliable financial reporting also includes maintaining internal control over financial reporting and financial system security.” The data conversion errors created negative budget authority in some funds and too much authority in others. In October 2015, HUD identified 86 funds valued at more than $73 million with negative balances in Oracle Financials. These errors were classified into two categories, simple and complex. The simple errors required minimal analysis and the processing of journal entries to reclassify the funds. The complex errors required a more in depth analysis, collaboration among multiple HUD entities and ARC, and multiple journal entries to resolve. Forty-six funds were classified as simple and 37 as complex and were handled by a tiger team 5 formed specifically to assess and remediate negative budget authority identified in Oracle Financials. The remaining three funds were handled by established operations and maintenance business processes and not by the tiger team. These errors resulted from a reclassification issue within the Oracle Financials fund values, a difference in business processes that was not identified before implementation. Because the Oracle Financials Discoverer reports were not fully developed when user acceptance testing was performed, this issue was not discovered until just after implementation. It took more than 6 months to completely resolve this issue. As of April 2016, all negative budget authority initially identified and targeted by the tiger team had been resolved. Certain budget lines established and adjusted in Oracle were populated with default values. In May and June 2016, we generated Oracle Discoverer status of funds reports for multiyear and no-year program funds and identified negative budget authority and balances within some accounts. When we could not reconcile the data between HUDCAPS and Oracle Financials for those funds, we met with Office of Chief Financial Officer (OCFO), ARC, and HUD contractor staff for an explanation. We were informed that a second data cleanup effort was required in Oracle Financials. In addition, we determined that the differences between the HUDCAPS budget and the general ledger were a known issue prior to implementation. HUD had not fully reconciled the data in the HUDCAPS budget and general ledger tables before the data conversion into Oracle Financials. HUD determined the differences to be minor enough to categorize them as “non-critical.” 6 HUD concluded that the issues identified did not severely impact HUD’s ability to transact in Oracle Financials upon implementation of the release and that some effort was required for post release cleanup and realignment to make a subset of the data conform better to Oracle Financials standards. HUD decided to proceed with the implementation of release 3 without fixing the problems to meet the October 1, 2015, implementation date. 5 A tiger team is a group of experts assigned to investigate and solve technical or systemic problems. 6 The data readiness group, made up of staff from HUD, ARC, and HUD contractors, defined “non-critical” error as errors that “could be fixed/remediated either before or after the October 1, 2015 implementation date.” 6 The analysis for this second data cleanup effort was in the preliminary stages in June 2016, and the estimated absolute dollar amount of the affected data was $9 billion. HUD staff believed that journal entries needed to be processed in Oracle Financials to correct the balances for the budget lines with default values. In addition, modifications to spending transactions in Oracle Financials might also be necessary when open commitments or obligations existed. HUD’s preliminary analysis indicated that this issue affected 181 funds and 1,417 budget line items. The estimated absolute dollar amount of the affected data was $9 billion. HUD’s estimated timeframe for resolving these errors is February 2017. The following table details the estimated value of the affected data. Type of fund Estimated absolute value Annual multiyear - unexpired $ 456,404 No year - unexpired 53,757,171 Expired – canceling in fiscal year 2016 1,862,489,081 All other - expired 7 7,221,203,383 Total 9,137,906,039 The data conversion errors created obligations containing miscellaneous vendors as opposed to valid vendors. Specifically, HUD also identified data cleansing issues in which obligations converted from HUDCAPS to Oracle Financials contained miscellaneous vendors as opposed to valid vendors and no invoice approvers. Type of vendor Obligations identified in error Non-Federal 257 obligations with invalid vendor information Federal 594 obligations with no invoice approvers 75 obligations with invalid vendor information The invalid vendor information for processing invoices was also due to missed business processing requirements. In HUDCAPS, it was an acceptable business practice to have a miscellaneous vendor at the time of obligation. The valid vendor was assigned at the time of payment. This is not an accepted business process in Oracle Financials; therefore, the system could not accommodate HUD’s legacy data during conversion. Because the process was not addressed during planning, the miscellaneous vendors in HUDCAPS were included in the conversion files given to ARC. As of June 2016, 130 obligations remained with invalid vendor information for non-Federal vendors, and for Federal vendors, 83 obligations had no invoice approvers and 33 remained with invalid vendor information. 7 Expired budget authority is budget authority that is no longer available to incur new obligations but is available for an additional 5 fiscal years for disbursement of obligations properly incurred during the budget authority’s period of availability. After the 5-year period has elapsed, all obligated and unobligated balances are canceled, the expired account is closed, and all remaining funds are returned to the general fund of the Treasury and are no longer available for any purpose. 7 Invoices submitted against the impacted obligations for non-Federal vendors could not be paid because ARC did not have valid vendor and banking information. Correcting obligations for invoices that appeared on the delinquent list was made the highest priority. Intra-Governmental Payment and Collection (IPAC) 8 requests submitted against impacted obligations for Federal vendors could not be paid because ARC did not know who to send the requests to for approval. IPACs could not be submitted against impacted obligations for Federal vendors with improper vendor classifications because it would have resulted in improper financial reporting (for example, intragovemental reconciliation and Governmentwide Treasury Account Symbol Adjusted Trial Balance System 9 reporting). These issues were caused by the New Core Project management team’s decision to not move the scheduled implementation date when development of management reports was not far enough along to allow for better validation during system testing and when issues were identified during system testing, to allow time to resolve them. In addition, the issues were caused by gaps in business processing that were not identified before implementation. Interface Performance Was Not Monitored Performance of the NCIS interface was not monitored, tracked, or measured. Although there were some forms of transaction monitoring, such as daily interface and exception reports and ARC’s quarterly performance metrics reports, these efforts were limited and did not include vital NCIS interface performance indicators pertaining to transaction processing and system performance. These indicators included processing times, transactions per day, number of processing errors, resolution times, and the number of affected users. Without accurate metrics for measuring system performance it is difficult to tell if the system is meeting the user needs and business process requirements. For example, we assessed NCIS processing from January through June 2016 and identified two transactions that were delayed 10 days and a delay in which it took more than 2 months for the funds to be available for obligation. According to the Processing Times Job Aid, 10 an action for establishing a budget for commitments or obligations should have taken 3 - 4 business days from budget template submission until the funds were available for obligation. Processing delays were encountered due to updates needed in the NCIS crosswalk tables, the budget filter table, and learning curves associated with the changing business processes. The condition described above occurred because the implementation of release 3 was rushed to meet the established October 1, 2015, date. Time did not permit the establishment of 8 IPAC is a way for Federal program agencies to transfer funds from one agency to another with standardized descriptive data. 9 The Governmentwide Treasury Account Symbol Adjusted Trial Balance System replaced the functionality of previous reporting systems as the primary means of reporting agency trial balance data. A single data collection system improves the quality of financial data by combining budgetary and proprietary trial balance reporting, enforcing the United States Standard General Ledger (USSGL), and implementing new edits and validations. 10 A HUD issued document designed to help users understand the time it will take for funds to flow through different HUD financial systems as HUD moves to Oracle Financials as its financial system of record. 8 performance metrics for use in monitoring, tracking, or measuring the NCIS interface’s performance before implementation. Without accurate metrics for measuring system performance, it was difficult to tell whether the system met the user needs and business process requirements. Controls Over Processing Errors were Bypassed Internal controls over processing errors 11 within Oracle Financials were routinely bypassed manually to avoid processing delays and allow transactions to process. We extracted Oracle Financials level 2 errors from NCIS from October 2015 to March 2016. Of the 126 files processed in that timeframe, 60 contained errors. There were multiple data files for some days, and we removed duplicate errors. For that timeframe, we determined that data files were created for 107 processing days and errors occurred on 49 of the days. Therefore, 46 percent of the days the process ran contained errors, and the internal controls were bypassed to allow transaction processing. We identified 55 funds that had a total of 47,799 errors when we summarized the errors by error code, fund code, and processing date. We requested additional information from HUD and ARC regarding the errors. We were informed that most of these errors occurred due to a business process that was overlooked before implementation. Adjustments were made to process these types of transactions correctly in the future. This condition occurred because procedures developed for error handling were designed to address individual infrequent errors and were not sufficient to address the number and frequency of errors that occurred. Due to the number of transactions failing, ARC was forced to routinely bypass the internal controls to allow transaction processing. The routine bypassing of internal controls, like the Oracle Financials cross validation rules, could lead to invalid data for managing day-to-day operations, an increased risk of Antideficiency Act 12 violations, and inaccurate financial reporting information. HUD Custom Reports Were Not Reliable Customized financial reports (Discoverer reports 13) provided to HUD staff to be used for the purpose of funds management 14 activities were not reliable or useful as they contained incomplete or inaccurate data. HUD chose not to use ARC’s standard suite of reports for funds management because it felt that some of the reports lacked the required degree of specificity to fully meet HUD’s needs. As a result, HUD’s subject-matter experts collaborated with ARC to replace some of the standard reports with customized reports in an effort to increase ease of use. 11 See appendix A for a description of the NCIS interface processing error resolution process. 12 The Antideficiency Act prohibits federal employees from making or authorizing an expenditure from, or creating or authorizing an obligation under, any appropriation or fund in excess of the amount available in the appropriation or fund unless authorized by law. 13 HUD BD Federal status of funds reports and HUD BD program budget Federal status of funds reports for program and program multiyear funds - Used to monitor budget status and remaining funds available at the fund level as of a specified accounting period. 14 Funds management function is the administrative control of HUD’s funding processes to gauge compliance with all laws, regulations, orders, and policies relating to funds control plans. 9 Users found these customized reports confusing and unreliable for performing funds management tasks. Since the implementation of release 3, ARC provided HUD two different sets of Discoverer reports. The first set of HUD custom Discoverer reports did not contain key data elements, lacked sufficient detail, and was inaccurate due to some of the data conversion issues. In May 2016, a revised (second) set of HUD custom reports was provided but also contained inaccurate data due to outstanding data conversion errors that had not been corrected. For example, the inaccurate data included negative budget authority, obligations that exceeded budget authority and negative available budgetary resources after obligations and expenditures. Although users found the second set of HUD custom reports more useful than the first, the reports still contained inaccurate data from the outstanding data conversion issues and did not meet all of the user needs and requirements 9 months after implementation. The Discoverer Viewer 15 status of funds reports, part of the HUD custom reports, are an essential component needed for the review, verification, and certification of general ledger data and financial reports. Users interviewed, who used Discoverer HUD custom reports to perform funds management, found the reports confusing and not useful. The lack of key data elements and presence of invalid data made it difficult to monitor budgetary resources and perform funds management before initiating spending transactions. OMB Circular A-123 (appendix A, II. Scope, part B) states that internal control over financial reporting should ensure the safeguarding of assets from waste, loss, unauthorized use, or misappropriation as well as ensure compliance with laws and regulations pertaining to financial reporting. Financial reporting includes annual financial statements of an agency as well as other significant internal or external financial reports. Other significant financial reports are defined as any financial reports that could have a material effect on a significant spending, budgetary, or other financial decision of the agency or that is used to determine compliance with laws and regulations on the part of the agency. To check the availability of program funds, users were instructed to review the Discoverer Viewer status of funds report and also check balances in the legacy systems. Some users said they did not find the Discoverer reports satisfactory as provided to perform these tasks and had to extract the output from the Discoverer reports to Microsoft Excel and then develop their own version of the report in Excel to present the information in a more useful manner. Having unreliable reports for funds management made it difficult to determine whether processing issues existed, the system data were in error, or the reports were inaccurate or incomplete. Providing unreliable reports to users for performing funds management increased the risk of noncompliance with laws, regulations, and policies relating to funds control plans. 15 Discoverer Viewer is the version of Discoverer most commonly used and accommodates users that only need to view preestablished reports and make minor changes to the report parameters and layout. 10 The NCIS Automated Reconciliation Tool Was Not Fully Functional The automated reconciliation tool within NCIS was not fully functional for the first 9 months of the fiscal year, and manual reconciliations were not performed. This condition occurred because the New Core project management team did not move the scheduled implementation date when development of the functionality required for the data reconciliation tool could not be completed by that date. Instead of delaying implementation until the tool was fully functional, HUD decided to implement on October 1, 2015 and rely on exception reports which were used to assist the operations team in resolving processing errors. The trial balance 16 reconciliation reports were not fully functional until April 7, 2016, half way through the fiscal year, because an accurate version of the beginning balances file was not available for use within the tool until that time. In addition, the implementation of the status of funds reconciliation report 17 was extended due to the excessive amount of time it took to reconcile the conversion activities. It took until the end of the third quarter of the fiscal year for HUD to produce this report. We received a copy of the June 27, 2016 report. The report showed differences for 954 accounts with an absolute value of approximately $4.5 billion. Manual reconciliations were not performed because the process was determined to be labor intensive and difficult to execute. Specifically, during the “Go/No Go” briefing for release 3 in August 2015, the New Core team informed OMB and HUD executive management that the development of the NCIS reconciliation reporting tool had been deferred until after “Go Live.” The New Core team further explained that a manual process was in place to reconcile balances during the conversion and processing cycles until the automated tool could be implemented. Since the manual reconciliation process was labor intensive to execute, the New Core team proposed a timeline for the automated solution to be available by late October 2015. When we questioned OCFO accounting officials on the manual processes used, they responded that they were not aware of any manual reconciliations or related procedures outside of NCIS. In addition, the Discoverer reports were not useful and reliable for performing manual reconciliations. It is critical to keep HUD’s financial data the same between the legacy HUDCAPS system, which is still relied upon for processing programmatic funds, and the Oracle Financials general ledger, which is now the official system of record. The intent of the tool was to identify the differences between the two systems and show that available budgetary balances are in agreement. As a result of the delay in fully implementing the tool, HUD had limited reconciliation functionality through the first 9 months of the fiscal year. 16 A trial balance is a list of all accounts (both revenue and capital) contained in the general ledger. This list will contain the name of each ledger account and the value of that ledger balance. Each ledger account will hold either a debit balance or a credit balance. 17 The status of funds report provides summarized balances of available budgetary resources, commitments, obligations, paid expenditures, and available balances for both HUDCAPS and Oracle Financials, along with the calculated differences between the two systems. 11 Prior Audit Work on the New Core Project During fiscal year 2015, we completed two audits 18 on HUD’s implementation of the New Core project. In the first audit, published in June 2015, we found that weaknesses in the planned implementation of release 3 of phase 1 of the New Core Project were not adequately addressed. We determined that HUD did not follow its own agency policies and procedures, the policies established for the New Core Project, or best practices. Because HUD is the first cabinet-level agency to use a Federal shared service provider, the transfer of its financial management to a shared service provider has been widely publicized. HUD’s previous attempt to use a commercial shared service provider to start a new financial management system failed after more than $35 million was spent. Our review of the previous project determined that OCFO did not properly plan and manage its implementation of the project. If HUD is not successful in this implementation, it could reflect negatively on OMB’s mandate to use Federal shared service providers. The weaknesses identified in this report related to requirements and schedule and risk management. These areas are significant to the project plan, and the effectiveness with which HUD manages them is critical to the project’s success. Our second review, published in September 2015, found that HUD’s implementation of release 1 of phase 1 was not completely successful. Due to missed requirements and ineffective controls, interface processing of travel and relocation transactions resulted in inaccurate financial data in HUD’s general ledger and ARC’s Oracle Financials. As a result, processing continued for more than 6 months with unresolved errors, leaving HUD’s general ledger and Oracle Financials with inaccurate financial data and discrepancies in the balances between HUD’s general ledger and Treasury’s Government-wide Accounting system. We concluded that the implementation of release 1 confirmed the concerns we cited when we reviewed release 3. Although HUD had taken action in its plans for release 3 to mitigate some of the problems that occurred with release 1, we were concerned that HUD could be moving too fast with its implementation plans and may repeat these weaknesses. Conclusion HUD rushed the implementation of release 3 and as a result, 9 months later, the implementation had significant data conversion, transaction processing and error handling, and reporting issues to correct. The lack of a fully functional automated reconciliation tool within NCIS for the first 9 months of the fiscal year to reconcile data between HUDCAPS and Oracle Financials and the failure to conduct manual reconciliations also significantly contributed to unresolved issues. Our prior assessments of the project expressed our concerns regarding a rushed implementation. HUD met its date but at the cost of inaccurate data, inaccurate reports, and unsatisfied customers. Recommendations We recommend that the Deputy Chief Financial Officer 18 Audit Report 2015-DP-0006, Weaknesses in the New Core Project Were Not Adequately Addressed, published June 12, 2015, and Audit Report 2015-DP-0007, New Core Release 1 of Phase 1 Implementation Was Not Completely Successful, published September 3, 2015 12 1A. Correct all of the values in Oracle Financials that are in error from the data conversion issues. 1B. Develop metrics and collect data on transaction processing for monitoring system performance. 1C. Stop the routine lifting of internal controls and improve the error handling procedures. 1D. Monitor and remediate processing delays in a more timely manner. 1E. Perform a review of all HUD custom reports, once the data conversion errors have been corrected, to ensure that the reports accurately reflect HUD’s financial situation. 1F. Verify that the NCIS trial balance and status of funds reconciliation reports function properly and resolve the differences. 13 Scope and Methodology The audit covered the period October 1, 2015, through July 15, 2016. We performed the audit at HUD headquarters in Washington, DC. Audit work was conducted from November 19, 2015, through July 15, 2016. Our audit was based on the U.S. Government Accountability Office’s Federal Information System Controls Audit Manual methodology and information technology guidelines established by the National Institute of Standards and Technology. We conducted the audit to determine whether adequate internal controls were in place for NCIS. To evaluate the internal controls, we determined • Whether New Core, release 3, financial management interface processing was adequately controlled; • Whether data reconciliations between HUDCAPS and Oracle Financials were accurate and complete; and • The impact of the release 3 implementation on the New Core Project. We conducted the audit in accordance with generally accepted government auditing standards. Those standards require that we plan and perform the audit to obtain sufficient, appropriate evidence to provide a reasonable basis for our findings and conclusions based on our audit objective(s). We believe that the evidence obtained provides a reasonable basis for our findings and conclusions based on our audit objective. 14 Internal Controls Internal control is a process adopted by those charged with governance and management, designed to provide reasonable assurance about the achievement of the organization’s mission, goals, and objectives with regard to • Effectiveness and efficiency of operations, • Reliability of financial reporting, and • Compliance with applicable laws and regulations. Internal controls comprise the plans, policies, methods, and procedures used to meet the organization’s mission, goals, and objectives. Internal controls include the processes and procedures for planning, organizing, directing, and controlling program operations as well as the systems for measuring, reporting, and monitoring program performance. Relevant Internal Controls We determined that the following internal controls were relevant to our audit objective: • Interface controls • Controls over the data reconciliation process We assessed the relevant controls identified above. A deficiency in internal control exists when the design or operation of a control does not allow management or employees, in the normal course of performing their assigned functions, the reasonable opportunity to prevent, detect, or correct (1) impairments to effectiveness or efficiency of operations, (2) misstatements in financial or performance information, or (3) violations of laws and regulations on a timely basis. Significant Deficiency Based on our review, we believe that the following items are significant deficiencies: • Weaknesses in controls over the data conversion, and report development processes resulted in unresolved data conversion errors and inaccurate funds management reports. (finding 1) • HUD is bypassing controls over interface processing errors. (finding 1) • HUD did not have a fully functional data reconciliation process for verifying the accuracy of data between its legacy applications and Oracle Financials. (finding 1) 15 Appendixes Appendix A Description of the NCIS Interface Error Resolution Process Error resolution occurs at two points, when NCIS encounters an error and when Oracle Financials encounters an error. For NCIS errors, there are daily exception reports distributed via emails for both the budget and general ledger interfaces, which indicate point-in-time errors held in NCIS. The OCFO systems staff review the errors, research the transactions held in NCIS and resolve the issues. Depending on the issue, these errors are typically resolved within 5 business days. After the HUDCAPS data are transmitted to Oracle Financials, there are three levels of errors that can occur. These errors are reported to HUD through NCIS, however, and ARC staff is responsible for resolving the errors encountered. Level 1 errors result from general file validations rules. Validation rules would include an invalid file nomenclature or corrupt file. Level 2 errors result from validations designed to mimic rules that are violated when attempting to enter a transaction using the Oracle application’s forms. The intent of these validations is to catch errors before the transaction is entered into Oracle. Level 3 errors typically occur when there is a funds reservation error in the Oracle general ledger. The error handling procedure for level 2 errors is to (1) identify the source of the cross validation rule failure, (2) request approval from the supervisory accountant for the cross validation rule to be turned off, (3) turn the validation rule back on after the data have interfaced with Oracle Financials, and (4) collaborate with HUD to determine actions to either send correcting and replacement entries from HUDCAPS or if a manual journal entry is required in Oracle Financials, to move balances from invalid accounting strings to valid ones. HUD staff and ARC collaborate to resolve the level 2 errors, along with obtaining approval from accounting, budget, or program budget officers. 16 Appendix B Auditee Comments and OIG’s Evaluation Ref to OIG Auditee Comments Evaluation Comment 1 Comment 2 17 Ref to OIG Evaluation Comment 3 Comment 4 Comment 5 Comment 6 18 Ref to OIG Evaluation Comment 7 19 OIG Evaluation of Auditee Comments Comment 1 We disagree with the OCFO’s comments that the report title and conclusions are misleading. This audit related to the OCFO’s implementation of release 3 and the functionality of the New Core Interface Solution. Based on the audit work we performed, we have concluded that the department rushed the implementation of release 3. We also do not agree with the OCFO’s classification of the discrepancies identified as minor. We also do not we agree with the statement that information provided during the audit or in response to the Notification of Findings and Recommendations were not considered. All information provided by the OCFO was assessed and documented in accordance with OIG policy. Comment 2 The OIG has not received documentation in support of the OCFO’s comments; therefore, we cannot make an assessment regarding them. We look forward to working with the OCFO to ensure that the actions proposed or taken are sufficient to address the weaknesses cited. Comment 3 The OIG has not received documentation in support of the OCFO’s comments; therefore, we cannot make an assessment regarding them. We look forward to working with the OCFO to ensure that the actions proposed or taken are sufficient to address the weaknesses cited. Comment 4 We disagree with OCFO’s response to this recommendation. According to the Federal Information Systems Control Audit Manual the objectives of interface controls include ensuring errors are rejected, isolated and corrected in a timely manner. Errors should be corrected in the source system and reprocessed through the next run. Comment 5 The OIG has not received documentation in support of the OCFO’s comments; therefore, we cannot make an assessment regarding them. We look forward to working with the OCFO to ensure that the actions proposed or taken are sufficient to address the weaknesses cited. Comment 6 We disagree with OCFO’s response to this recommendation. In June 2016, we were informed that some of the HUD custom reports still reflect inaccurate data due to additional data conversion cleanup that is required, and the estimated completion date for the resolution of those data conversion errors is February 2017. This recommendation relates to conducting another review of the reports following the completion of the data corrections to ensure the reports provide accurate information. Comment 7 The OIG has not received documentation in support of the OCFO’s comments; therefore, we cannot make an assessment regarding them. We look forward to working with the OCFO to ensure that the actions proposed or taken are sufficient to address the weaknesses cited. 20
HUD Rushed the Implementation of Phase 1 Release 3 of the New Core Project
Published by the Department of Housing and Urban Development, Office of Inspector General on 2016-09-20.
Below is a raw (and likely hideous) rendition of the original report. (PDF)