GENERAL LEDGER Business Case Review

2 Journal Mover Owners Overall Process & Policy Change OwnersBelva White, Kerry Peluso Module OwnersDavid Giles Project Work OwnersDavid Giles OVERVIEW: This Journal Mover engine would dramatically simplify the process to perform a bulk reclass as the user could simply search and select the lines to reclass and enter the reclass destination. The engine would create all of the necessary debits and credits. This process would be easier than creating a traditional Journal Entry via the delivered Journal Entry pages. There are several areas where this process would solve existing problems: A lot of the data movement/reclass needs today result from Grant transactions that need to be reclassified due to: (1) Fund Codes corrections (2) cost transfers (3) cost sharing Grant Out of Bounds Corrections – this is another type of correction entry that originates due to transactions attempting to charge a grant after the allowable project close window. Details of current reclassification or correction entries are currently lost and are therefore not easily traceable in the data warehouse reporting. RECOMMENDATION: Create a new custom Journal application that has the ability to move/reclass Journal Lines using the transaction level detail from All Trans query results as the data source. All Trans contains details from certain accounting line tables all pulled together into one location with a one-day lag. Transaction level details including Vendor, Invoice, and Payment information from All Trans are necessary for the user to easily identify the transactions to reclass plus GL only holds summarized data from the accounting tables due to Journal Generation process. The tool should allow a User to (1) search for transactions that are candidates to move/reclass (2) have the ability to select specific lines to move/reclass (3) the ability to enter the reclass SpeedType location.

3 Journal Mover Impacts PeopleModule Support Central AdministrationGrants Administration would be able to more efficiently review cost transfers and adjustments due to the detail included in the proposed entry. Campus UsersThe engine would create all of the necessary debits and credits so accounting backgrounds for end users would be less than required for a regular journal entry. ProcessModule SupportAllows combo rules to be bypassed without turning them off system wide. Central AdministrationAllows for the correction of journals using an invalid chartfield string. Campus UsersSimplify the process to perform a bulk reclass as the user could simply search and select the lines to reclass and enter the reclass destination. SystemModule SupportEliminates the need for technical assistance for each GOOB journal. Central Administration Campus UsersAllows campus users the ability to move transaction lines at the detail level instead of the summarized level. TrainingModule Support Central Administration Campus Users

4 Journal Entry Engine Owners Overall Process & Policy Change OwnersNancy Mears Module OwnersDavid Giles Project Work OwnersDavid Giles OVERVIEW: Emory has a significant number (30-40) of external systems that must send financial entries to the Compass/PeopleSoft General Ledger (GL). The process to post these entries is known as the Journal Sweeper/Journal Entry Engine. An underlying assumption was built into the original Journal Entry Engine (JEE) process that all entries must post somewhere. This design assumption led to a larger than anticipated downstream cleanup effort that is more complex than expected and that also came along with unintended negative consequences. After living with the JEE over the last five years, we are proposing a series of changes based upon lessons learned to remedy some of the common issues that currently complicate the process to post these 3rd party entries and complicate the Month End Close process. The proposed change removes the assumption that all entries must immediately post somewhere as part of the JEE. Rather than posting immediately, the existence within the file of any of the following conditions would result in that line being removed from the file and the file being re-balanced using a default ChartField combination defined based upon Source: (1) invalid Account value (2) blank Account value (3) Any Journal line with a Project Status not set to Open or with a Project Status not set to Ended as compared with Current Date as opposed to the Accounting Date in the source file (4) Combo Edit errors. The line that is removed from the file will be placed in a “Hold” table and a reclass will be possible through an easy to use page. This reclass will result in the automated clearing of the default ChartField combination that was used to balance the original file. RECOMMENDATION: Take the lessons learned over the past five years and enhance the existing Journal Entry Engine customization. The process would remain the same on the front end but as bad or invalid lines are detected during processing they would be removed and placed on a HOLD table. The file would then be balanced using a default ChartField combination defined for each Source. This would allow valid accounting lines to post as intended but prevent invalid lines from posting to suspense or using a default SmartKey for accounting lines with project status issues (which results the need for a GOOB).

5 Journal Entry Engine ImpactsIf Approved PeopleModule SupportDramatically improve current state correction/suspense process. Central AdministrationA change in roles as the function moves from decentralized to centralized. Campus UsersPrevents the downstream issues with the data warehouse so reporting will be improved, which will help end users. ProcessModule SupportDramatically improve current state correction/suspense process. Central Administration(1) Prevents improper cost collection for Projects (2) Allows all valid lines to post as intended but prevents invalid lines from posting to incorrect chartfield strings. (3) The 3rd party source that originates the file will not get 100% of recharge revenue until all lines post to proper ChartField string. This may provide an incentive for the 3rd party sources to provide error free files in the future, they will have a vested interest. Campus UsersAllows all valid lines to post as intended but prevents (1) Combo Edit errors from posting to a Suspense Account and requiring a Suspense Correction (2) The need for a GOOB to reclass Project Status errors which result in the use of a default SmartKey SystemModule SupportDramatically improve current state correction/suspense process. Central AdministrationWill streamline the correction process. Today not all GOOBs are corrected from the default SmartKey. There is no central oversight to monitor and ensure that a correction was made to reclass the entry from the default SmartKey. Campus UsersWill lead to better data and reporting. TrainingCentral AdministrationRequires new business process to monitor and age items on the HOLD table. Please note: there is a desire to auto reclass items in the HOLD table if the item ages beyond a certain point, however, this is not yet defined. Campus UsersNo training required or needed.