This document was contributed by the named institution to the 
CAUSE Information Resources Library. It is the intellectual 
property of the author(s). Permission to copy or disseminate 
all or part of this material is granted provided that the 
copies are not made or distributed for commercial advantage, 
that the title and institution that submitted the paper 
appear, and that notice is given that this document was 
obtained from the CAUSE Information Resources Library. To 
copy or disseminate otherwise, or to republish in any form, 
requires written permission from the institution. For further 
information: CAUSE, 4840 Pearl East Circle, Suite 302E, 
Boulder, CO 80301; 303-449-4430; e-mail 
info@cause.colorado.edu.


Indiana University
General Ledger Specifications for Software
May, 1992



Chart of Accounts

	Key Issues:

	1. The ability to have Multiple Charts of Accounts.  We 
are proposing that our major units, totaling under 30, shall 
have the ability to have their own chart of accounts which 
will map to the official university chart of accounts.  The 
mapping will follow the same structure as shown in #3 below.  
If a Responsibility Center (such as Hospitals)  has their own 
chart, it will have to map to the Indianapolis Campus' chart, 
and the Indianapolis chart will map to the University's 
chart.  This means we will need the ability to have three 
levels of charts, that can map up into different object codes 
and account numbers.

	2.  The university has done extensive data modeling to 
determine what our data needs for the new system will be.  
The data model for r the future Chart of Accounts is located 
in the back and marked "Attachment A".  This model includes 
full descriptions and sizes for each attribute.  A system 
will need to show how it can make this chart work with it's 
package.

	3.   The ability to have multiple levels of organization 
in the hierarchy is required.  An account can only relate to 
one organization and an organization can relate and report to 
one and only one other organization.  An example of the 
hierarchy is

	University
	^
 	Campus
	^
	Responsibility Center
	^
	Department
	^
	Units

This issue specifically speaks to the ability and ease of 
consolidating financial information and data up through the 
hierarchy.  

	4.  An additional item needed is the ability to maintain 
the historical hierarchies.  This way if a unit starts 
reporting to a new division, we will be able to easily change 
the information in the Chart of Accounts to the new division, 
yet maintain and be able to run reports utilizing the old 
hierarchy.  This is needed for historical reporting and 
comparison.  

	5.  Prior account number and future account number view 
must be possible.  By looking at the current number in the 
Chart, it must be easy to identify and run reports using 
fields of prior and future account number.   The 
functionality of a future account also requires that if a 
transaction is being processed against an expired account, 
the "future" account will automatically be booked with the 
journal entry instead.

	6.  The ability to define and track project related 
financial transactions and run reports utilizing a project 
code.  

Data Elements for General Ledger

	Key data elements that will need to be maintained in the 
general ledger, separate from the chart of accounts is:

	Accumulated Information:

	1.    Account Number
	2.    Beginning Amount
	3.    Current Period Amount
	4.    Current Year-to-date amount
	5.    Ending Balance
	6.    Object Code (Income, Expense, Balance Sheet class)
	7.    Period
	8.    Position Number
	9.    Source Ledger where transaction came from
	10.  Multiple Fiscal Years
	11.  Chart of Accounts Identification (as referenced in 
Chart of Accounts, #1)
	12.  Base Budget
	13.  Current Budget
	14.  Total Encumbrances 
	15.  Total Commitments (salaries & benefits)
	
	Journal Entry:

	1.    Account Number
	2.    Amount
	3.    Description
	4.    Document Number
	5.    Indicator for debit or credit
	6.    Effective date
	7.    Object Code
	8.    Position Number
	9.    Source Ledger
	10.  Chart of Accounts Identification (as referenced in 
Chart of Accounts, #1)
	11.  Transaction Date
	12.  University Document Number	
	13.  Type of transaction (budgeting, accounting, 
commitment or encumbrance)
	
	See "Attachment B", Data Model on Ledgers.  The Budget 
Sub-Model is "Attachment C".   These models include full 
attribute needs with descriptions.


Accounting Processes

1.  Fund Accounting as defined in the AICPA guidelines for 
Colleges and Universities must be preserved.  This 
encompasses the ability to apply a function to each account 
called a fund group, plus the ability to break the fund group 
into sub components.  Listed below are the major issues of 
fund accounting that must be addressed:   

	a.  "Attachment D"  shows the hierarchy of fund  
accounting and specifically lays out what each of the fund 
groups are.

	b.  We must be able to identify if the funds in an 
account are restricted, unrestricted or temporarily 
restricted.

	c.  An account must relate to one and only one 
educational code and one federal code.  Examples of the codes 
are Institutional Support, Public Service, and Research.

	d.  Specific accounting rules need to be established by 
fund group.  An example is that the Endowment fund group is 
never allowed to have liabilities.  The establishment of a 
liability in this fund group has to be preserved.

	e.  Plant Fund is a category that includes four fund 
groups:  Contraction and Major Remodeling, Retirement of 
Indebtedness, Renewal and Replacement and Plant.  The final 
of the four, Plant, is an accumulation of all capital assets 
and corresponding liabilities.  Depreciation also takes place 
in only this fund group.  Plant is only fed by specific 
object codes which reflect transactions which have occurred, 
and expensed, in other fund groups.
 	
2.  The guiding principal on Balance Sheet items are that 
they at a minimum will be attributed to Responsibility 
Centers (RCM).  Asset and Liability items will be maintained 
at the following specified levels for each category:

	a.  Accounts Payables will be established and charged 
out of individual operating  accounts.

	b.  Indiana University has both monthly and bi-weekly 
payrolls.  The bi-weekly will need to be calculated by the 
system and automatically booked on a monthly basis down to  
operating account.

	c.  Inventories including work in progress, raw 
materials and finished goods will need  to be booked on a 
monthly basis down to the operating account level.

	d.  Accounts Receivable will be handled in two different 
ways.  Student Accounts 	Receivable for fees will be 
allocated at the campus level.  Other Receivables will need 
to be booked in the operating account.  

	e.  Capital assets and liabilities will be held at the 
campus level.  (see page  5,  	Required Modules, #1, for more 
detail).

	f.  Accrued Vacation Liability will only be calculated 
and booked at year end closing.  It will need to be allocated 
down to the RCM.

	g.  All transactions that occur at the operating account 
level will need to be easily consolidated up to the RCM 
level in order for ease in creation of a balance sheet.

3.  Transfers of funds, which are defined as transfers of 
cash between operating accounts, will need to be easily 
identified and marked as such in the system, down to the 
level of RCM.  "Attachment E"  goes into detail on how I.U. 
plans to handle transfers of funds, for both reporting and 
elimination purposes, by utilizing contra journal entry 
accounts..  

4.  The system will need to be capable of easily flagging tax 
requirements without specifically having to create object 
codes.  An example is prizes and awards that  would need to 
generate a 1099, 

5.  The ability to create a balance sheet utilizing all 
operating accounts for a unit, as well as identify via the 
Capital Asset Management System assets that relate to that 
unit.

NOTE:  "Attachment F" titled Recommendations for account and 
activity set-up covers all of the above points on Accounting 
Processes in detail.


Specific General Ledger Functionality

1.  13 month capability for multiple years.  We must be able 
to have two sets of books open at the same time without 
inhibiting timeliness of update.

2.  System Size.  Indiana University for the 1990-91 fiscal 
year had expenditures of $1.75 billion, a fund balance of 
over $1 billion and millions of journal entries.  We 
currently have over 12,000 active accounts.

3.  Protections on Cash.  Direct entries to cash cannot be 
allowable.  See "Attachment G" on how cash will be handled in 
the system.

4.  Multi-levels for organization.  We are a diverse and 
complex educational institution.  Our Chart of Accounts (and 
subsequently, general ledger) must reflect this.  Please 
refer back to Chart of Accounts, #1 on page 1 for Multiple 
Charts of Accounts.

5.  System Interfaces.  The new general ledger must be able 
to accept direct feeds from  current systems at I.U. that 
serve as sub ledgers.  These systems are:

		Human Resources (Payroll)
		TOPS (One-Line Purchasing System)
		Accounts Payable
		Bursars Accounts Receivable
		Student Loan System*
		Contract and Grant System*

*Systems are on servers.  All other systems listed are based 
on the mainframe.

6.  Contract and grant accounting and administration of 
accounts will need to be facilitated.  This includes the 
ability to build in restrictions and guidelines as to types 
of transactions that are allowed in a given account.

7.  The ability by fund group to build in controls and 
restrictions.

8.  The ability to automatically generate part, or all of a 
transaction.  An example is an expenditure.  The originating 
document will only give you an account number and object code 
for the expense.  The system will automatically book the 
effect on cash and fund balance.  Likewise, with capital 
purchases, the plant fund accounts are automatically updated 
from the expenditure taking place in an operating account.  
Because of the quantity of transactions and for control 
purposes, this feature is very important.

9.  Audit Trail/Drill Down Capabilities.  The ability to 
research a transaction all the way down to its source 
document, or source ledger.  

10.  Security Issues.  Only specified people should have 
access to the programming which would allow them to change 
the general ledger and update the data.  

11.  Security on Fund Balance (Equity).  Direct entries on 
Fund Balance cannot be allowable by everyone.  However, a 
control change by a small group of individuals must be 
allowable.  
	
12.  Reconcilement Issues.  

	a.  The reconcilement of the general ledger must be 
easily accomplished with standard reports verifying the 
reconcilement, or pinpointing exact problems in the 
	reconcilement down to the account, object code level.

	b.  Reconcilement of cash with bank statements must be 
facilitated with standard reports that show cash at a given 
point in time, a check register, and a reconcilement process 
to outstanding checks.  These reports must be standard on a 
monthly basis.  Daily reports are also desirable.  	

13.  How is the system updated and how often?

14.  Linked to the ability of a system to have multiple 
Charts of Accounts, is it's ability to have and maintain 
multiple ledgers.

15.  For ease in processing decision support (see below) , 
the ability to maintain consolidations, calculations and 
balances will probably be required.

16.  Ability to change reporting hierarchy and maintain the 
historical information on where the unit used to be located.  
This feature should encompass mergers, fragmentation of 
units, movements to different campus', etc.

17.  The ability to track various types of volumes by types 
of revenues and expenditures is a component that is 
important.   Although the University hopes to do activity 
based accounting by utilizing "project" as mentioned in the 
Chart of Accounts, page one, item four, we would like to 
facilitate this process and add to the ability by maintaining 
volume statistics.  

18.  The system be capable of basic budget administration 
features which includes automatic controls on overages.  The 
controls will need to be based on actual plus encumbrances 
less budget level for some areas by account, while for others 
be by organization.  Some areas will have different dollar 
amounts for overdrafts before the control stops the 
transaction.  So, the system will need to be flexible on 
different types of controls for different accounts, 
organizations, and campus'.  See "Attachment H" for Budget 
Sub-Model. 

19.  Project management is also a feature that is needed.  
The system will need to be able to track expenses related to 
a specific project and have a feature so that payroll expense 
distribution can take place to different projects.  An 
additional area of interest is any billing feature that might 
be a product of the process of tracking expenses and doing 
payroll distribution by project.

20.  The university has a wide variety of cost recoveries 
currently being calculated and processed at different levels 
of the organization.  We currently have:

	a.  Indirect Cost Recovery on Sponsored Research.  A 
different percentage by each award is charged in an account 
and the revenue charged to an RC account.

	b.  Central Systems Service Charge.  Campuses and 
auxiliary accounts are being charged a different sum of money 
based on a cost recovery chart which is currently manually 
done.  

	c.  Unit Charges.  Auxiliary Enterprises is charges it's 
units for central services and RC's are charging their 
departments for central services.

As much as possible, the system needs to facilitate the 
calculation of these kinds of charges, and automatically book 
the transaction so that manual work is eliminated.  These 
charges can occur on a  monthly, quarterly or annual basis.


Capital Asset Management System

The university has the need for a capital asset management 
system that is linked with the general ledger and serves as a 
subsidiary ledger.   The ledger needs to be capable of some 
of the following specific functions:

	a.  tracking the types of capital assets
	b.  calculating and accumulating depreciation
	c.  tracking work in progress
	d.  matching associated liabilities to each asset and 
         maintaining balances
	e.  utilizing of bar-coding for off site updating of 
         system with scanners
	f.  maintaining full accounting information on original 
         purchase
	g.  easy reconcilement tools and reports
	h.  as a subsidiary ledger to the general ledger, be in 
         a position to update the general ledger instead of
         the reverse
	i.  Maintaining full plant fund information 

The link between the general ledger and the Capital system 
must be such that the combination of the two can create a 
detailed balance sheet for each organization.  See 
"Attachment I", CAMS Data Model,  for complete data 
requirements for a capital asset management system.


Accounts Receivable System

The university is interested in reviewing the modules in a 
general ledger package associated with Accounts Receivable 
processing for non-student receipts.  This system would need 
to be fed by the University's electronic transaction 
processing environment.  Specific functional requirements are 
as follows:

	a.   automatically book the transaction in general 
          ledger
	b.   would need to create a generalized bill
	c.   automatically book reduction in receivable and 
          increase cash upon receipt 
	d.   automatically create late notices at given set 
          points
	e.   maintain historical information on the receivable 
          for fiscal year.

Budget Construction:

We need a system that can be used by hundreds of different 
locations in building annual budgets.  The following 
components are required:

	a.  budgeting by position
	b.  budgeting other expenditures down to level
	c.  incorporating prior years base budget for starting 
         point
	d.  forecasting
	e.  incorporating controls on parameter (percentage) 
         changes in budget
	f.  on line capability in doing the budgeting
	g.  link with personal computer spreadsheet applications
	h.  monthly budgeting as an option, or system 
         automatically strings out to 12 months
	i.  multiple year budgeting

See "Attachment J", Position Control Sub-model, for detailed 
information needs on position control.		




Indiana University

Financial Information System

Attachment F: Recommendations for account and activity set-
up

	The basic concept of Responsibility Center Management 
(RCM) leads to the conclusion that in developing a new 
Financial Information System, Indiana University needs to 
reevaluate the current Accounting processes.  Such an 
evaluation was undertaken by a group of individuals (General 
Ledger Forum) and this document is a result of their 
discussions.  The overall guiding principle of the group was 
that Responsibility Centers are the fundamental cost and 
revenue units.  

	The General Ledger Forum discussed the reporting needs 
of the Campuses, Responsibility Centers and departments.  The 
current accounting system was built around the concepts of 
fund accounting (i.e. general, designated,  restricted, 
auxiliaries, endowments, construction, etc.).  The objective 
of this group was to make recommendations on changes to 
current accounting processes that would facilitate RCM by 
enhancing the financial information available to the 
operating units, while maintaining fund accounting.

	It was the Forum's overall feeling and recommendation 
that Indiana University should follow the concepts of accrual 
accounting in the FIS while maintaining the integrity of fund 
accounting for reporting and decision making purposes.

	The specific recommendations, by category, are as 
follows:

Accrual Accounting Changes
 
	1)	All operating accounts will be capable of 
containing assets and liabilities.
This eliminates the current practice of one balance sheet 
account for each fund group.  Although the assets and 
liabilities will be maintained at the detail level, initially 
balance sheets will be created for Responsibility Centers.   
It is noted that many account managers will not need or want 
to deal with assets and liabilities, and therefore balance 
sheets will not need to be processed.

		Issues:   Revenues currently are distributed down 
to the RC level only.  Therefore, if  a balance sheet is 
created for a general fund account  that has expenditures and 
other assets and liabilities, it will always be in an 
overdraft without corresponding revenues.  A systematic 
procedure of addressing these issues will need to be written 
and enforced, or the current distribution process of revenues 
needs to be reevaluated.  
	  
		Impact:  This will give IU the ability for balance 
sheet reports at any level, but Responsibility Centers will 
be the prime focus.

	2)	Current Accounts Payable processing has an 
operating account being charged upon receipt of the invoice, 
with the cash and payable being established in a
clearing account.  We propose that the payable be established 
directly in the operating account and the subsequent payment 
at the time of disbursement of cash being made out of this 
same account, thereby reducing the payable.

		Impact:  This allows for detail at the account 
level.  It may require auditing  reconcilement procedures 
initially.   All entries will be taken care of by the system 
and no work required by the managers of accounts.
  
	3)	It is recommended that Student Accounts Receivables 
should be handled the way they currently are.  This is by 
utilization of the Bursar's Accounts Receivable
		System (BARS)  which automatically allocates the 
Student Fee Receivables at the campus level.   It is 
recognized that due to the complexity of student fees 
processing within  BARS, that it would be too complex to try 
and allocate the receivables to the RC level.  Halls of 
Residence receivables and other types of receivables handled 
through BARS will need to be booked in the individual 
operating accounts.  

		Other Receivables that are currently not handled 
via BARS will be booked directly into the operating accounts.

		Impact:  Indiana University does not currently have 
an Accounts Receivable System.
		Many of the current receivables are not being 
booked into the general ledger.  It is the forum's 
recommendation that in the review of general ledger software 
that the module for accounts receivable should be reviewed.  
The package should have the capability of creating invoices 
and late notices automatically.
    
	4)	Indiana University will start to accrue bi-weekly 
payroll on a monthly basis.

		Impact:  This will add just one step to central 
accounting's month end closing role. Adds value in 
information to the account managers with no work required on 
their part.

	5)	Payroll disbursements (deductions from payroll 
checks and benefits) will continue to be handled the way they 
are now by utilizing internal agency accounts.

		Impact:    NONE

	6)	Indiana University will require units who have 
major inventories and work in progress to keep track of them 
and update the general ledger on a monthly basis.  
	
		In the review of a general ledger software package, 
we will investigate the option of buying an inventory system 
that can be utilized by all IU departments who have
such a need.   This component of the review process will not 
be heavily weighted 	in choosing the correct general ledger 
for Indiana. 

		Impact:  This will mostly have an effect on 
auxiliaries.  Although these units currently keep track of 
these items and book them in the subsidiary auxiliary
system, they are not timely with their transactions.  The 
auxiliary and accrual processing time will have to be 
improved. 			

	7)	The ability to prepare full balance sheets with 
capital assets is very difficult with fund accounting.  The 
plant fund group will need to be preserved, yet at the
same time we will need to be able to assign ownership of 
these assets to a given unit so that balance sheets can be 
produced.  The recommendation on how we will make this work 
is as follows:

		Plant fund will be managed exactly as it is today 
in the general ledger.  This means we will have one account 
for each campus.  All of the detail will be kept in the 
Capital Asset Management System (CAMS).  This detail will 
include ownership by account, book value, accumulated 
depreciation and corresponding liabilities to that asset.  An 
interface will be established between CAMS and the general 
ledger so 	that a balance sheet can be run including any or 
all of the capital asset items.  This move will clearly 
establish CAMS as a subsidiary ledger to the general ledger.  

		The Auxiliaries are in a position of wanting to 
defer the total cost of an asset over a period of years.  
This is in contradiction to the university's current process 
of 
charging the total expense of a capital asset the year of 
purchase in the operating account, and then depreciating it 
over a number of years in Plant Fund.  With multiple charts 
of accounts both can be accomplished by the following:

		a.  Units will be able to utilize the asset code 
for a capital item (86XX) in their chart.  This code will set 
up the asset on their balance sheet and flow to the 
university's chart to establish the expense and update Plant.

		b.  Because they are using the asset code instead 
of the expense code, it will not show up on their operating 
statement.    Each year thereafter, they can expense
to a depreciation class in their chart the depreciation for 
the year.  This code will not flow to the university's chart, 
it will just drop out.  Again, the unit will be able to run 
their operating statement off their chart, reflect the 
depreciation expense, update accumulated depreciation and not 
affect the university's chart.

		Units are encouraged to utilize the lives 
established by the University for depreciation instead of 
having inconsistencies.

		Impact:   Provides additional financial information 
to the user without adding any undue hardship in the units.  
A new Capital Assets System will be  required to support this 
functionality.  It will be critical in the development of the 
general ledger.  

	8)	It is the recommendation of the group that Accrued 
Vacation Liability should be booked down to the operating 
account level for Auxiliaries, and the RC level for other 
current operating accounts.  It is also a recommendation that 
due to the lack of material change in numbers during the 
year, that the entry only be booked 	annually. 
	
		Impact:  This will provide the RC's with more data 
on their liability.  They currently are unaware of their 
exposure in this area.

Other Current Processes

	 1)	The group discussed transfer of funds and the need 
to identify transfers without inhibiting units in their quest 
to more accurately produce an operational statement.  It was 
determined that the university object code list would not 
include transfer of funds codes.  The transaction processing 
environment can have logic built in that will  identify 
whether a transaction is a transfer of funds based on the two 
accounts involved in the transaction.

		Impact:    It is critical that the logic is 
imbedded in the transaction so that "users" do not need to 
understand the mechanics.   For historical reporting, this 
will be a more easily understood process.  Currently, after 
the fiscal year is over it is hard to 	 determine what the 
transfer totals represent unless recoding by type of 
transaction 		 was occurring on spreadsheets.  

	2)	The group recommends that the transaction 
processing environment include the capability to flag journal 
entries for pertinent tax information, instead of creating 
separate object codes for each tax situation.

		Impact:  The Transaction Processing environment 
will need to make the decision process of whether to flag the 
entry or not an easy one.  

	3)	It was determined that the current way of handling 
refunds by utilizing contra income 	and expense codes was 
confusing.   The forum therefore recommends that the 
university eliminate special refund object codes and allow 
cash receipt vouchers to have expense object codes and check 
requests to have income object codes.  It was acknowledged 
that we will have a need for a prior year code for 
reimbursement of income and expense.

		Impact:   This process will be much easier to use 
and add more value to financial reports and analysis.

	4)	Fund balance is a calculation of assets less 
liabilities.   If the new system solely 	worked off a 
calculation, and did not allow transactions against an object 
code for fund balance, the integrity of the fund balance 
amount would be very high.  This will
limit some of the things we need to do (i.e. adjustments to 
Plant), and will force us
to manipulate other transactions in order to hit fund 
balance.

	5) 	Although an object code for cash will exist, it 
cannot be used for direct journal entries.  The system itself 
will be the only generator of cash entries by creating 
entries from other transactions.  This is necessary in order 
to safeguard cash.

Cost Accounting

		The issue and importance of cost accounting was 
discussed.  The recommendation is that volume (number of 
items, number of hours, etc.)  is an important component to 
cost accounting and therefore the FIS will have the ability 
to record 	volume statistics.    It was also determined that 
the "project" attribute in the Chart of  Accounts could be an 
efficient tool for cost accounting, but that more than one 
project field was required so that information could be 
sliced more than one way.  Therefore, the Forum recommends 
that a revenue and expenditure transaction may be assigned to 
two project numbers.

		Impact:   This will assist business units in 
tracking costs.  Since it is a new feature, it 	will not 
affect the old accounting system, but does have implications 
for linkage with payroll, accounts payable and TOPS.  Many 
units are currently keeping track of  these kinds of costs on 
separate systems.  This duplicate data entry will be 
eliminated for those who utilize the system.

IU Foundation

		In many of the presentations of the Chart of 
Accounts Data Model, the issue of access to IU Foundation 
financial data through the FIS was brought up by users.  For 
legal reasons, the forum recommends that the separation of 
the Foundation and the University be preserved, but should 
not inhibit the gathering of  data by our units on their own.  

		Impact:  Financial Management Support will need to 
develop and distribute new 	procedures for processing 
transactions for Foundation accounts.

Cost Recoveries

		The complexity and variety of our cost recoveries 
was discussed.  It was determined that the current way of 
handling these charges is archaic with the exception of 
Indirect Cost Recovery which is automatically processed 
through the Chart of  Accounts.  We determined that the 
transaction processing environment should 	include the 
ability to establish a standard charge that can automatically 
be billed for a set period of time, for a set number of 
periods.  We also encourage the criteria for the selection of 
a general ledger to include its ability to manage cost 
recovery of charges.

		Impact:  Since most cost recoveries are handled 
centrally, this will have minimal impact on units.


		April 22, 1992
		General Ledger Forum:

		Beth Beckman
		Larry Butcher
		Jennifer Foutty
		Don Grinstead
		Bill Keller
		Steve Keucher
		Kathleen T. McNeely, Chair
		Larry Polley
		Terry Radke
		Paul Sullivan
		Barry Walsh
		Maggie Whitlow


Updated on July 24, 1992  by Kathleen McNeely
12