oversight

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)

   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