Chart of Accounts

1. Chart of Accounts Bill Overman, Indiana University

2. Multiple Charts • Multiple charts form a hierarchy • Advantages: • Separate distinct reporting entities • Routing to different areas of functional expertise • Institutional reporting rolls up data to use object codes, levels and consolidations at the top level chart • Disadvantages: • Maintenance of object codes, levels and consolidations on multiple charts • An object code can have different meanings on different charts • Institutional reporting rolls up data to use object codes, levels and consolidations at the top level chart

3. Top Level Reporting Chart • Levels and consolidations for financial reporting at top level chart • Levels and consolidations for management reporting at lower charts where accounts housed • Capital Gifts and Grants • On SRECNA, need to report separately • For management reporting want to report with all other gifts

4. Accounts • Additional accounts or sub-accounts on an existing account? • Transition… are feeder systems ready to support sub-accounting? Payroll, student, auxiliary units? • At IU, largely departmental preference • Recycling accounts? • It happens… faculty research accounts are a common place • Encourage that the account be inactive for one year-end cycle before recycling • Not for Contract and Grant accounts or where there is a specific reporting requirement • Requiring inactive accounts to be closed would be one way to prevent recycling

5. Accounts • Parameters define what fund group or sub-fund group represents a contract and grant account • At IU, represented by a fund group (CG) • Other schools want the fund group to be restricted funds and contracts and grants to be represented by a sub-fund group • Logic throughout the system based on if (sub-)fund group = contracts and grants • One parameter indicates if contract and grant accounts are represented by a fund or sub-fund (FUND_GROUP_DENOTES_CG_IND ) • A second parameter indicates the value of the fund or sub-fund that represents contract and grant accounts (CG_DENOTING_VALUE )

6. Accounts • Contract and grant account parameters

7. Accounts • Inception to date reporting • C&G Beginning Balance field populated with total of all activity for prior fiscal years • Using GL Balance table, add C&G Beginning Balance and Account Line Annual Balance for inception to date reporting or selected monthly buckets for inception to period reporting • C&G Beginning Balance field by default populated for accounts identified as contract and grant accounts • Can also optionally be populated for other sub-fund groups based on a parameter (SUB_FUND_GROUPS_FOR_INCEPTION_TO_DATE_REPORTING)

8. C&G account, monthly amount view: C&G account, accumulated amount view: Non-C&G account, monthly amount view:

9. Accounts • Income Stream Account • Balancing tool for budgets • One income stream account for all accounts where the budget must balance • When an budget adjustment crosses income stream accounts, balancing entries are created and a transfer of funds is generated • Reference information for contract and grant accounts • Parameter for release 3 to turn off balancing entries

10. Accounts • Object Presence Control Indicator • If this flag is set to yes, an object code must be budgeted for an account before it can be used on other transactions • Applies to kuali e-docs only, not batch feeds • Not a hard stop, initiator has the option to override the warning that the object code is not budgeted • Override appears on the document • Ability to establish routing rules based on the override

11. Accounts • Rules for closing an account • The account can not have a base budget • The account can not have balances in asset, liability or fund balance codes other than the designated fund balance code on the system options table • Closing income and expense to fund balance must take the designated fund balance code on the system options table to zero • The account can not have open encumbrances • The account can not have pending ledger entries • The Beginning Balances Loaded flag on the system options table must be set to Yes.

12. Sub-Accounts • Financial Reporting Code tab • Sub-Accounts are intended to stand-alone • Sub-account ABCDE on one account has no relationship to sub-account ABCDE on another account • Financial Reporting Code provides a method to link like sub-accounts • Chart and organization are part of the key to financial reporting code • Used to differentiate codes if multiple units choose to use financial reporting code

13. Sub-Accounts • CG Cost Sharing tab • Sub-accounts created on a contract and grant account to track cost share • Transactions posted to these sub-accounts will generate a transfer as part of the nightly batch cycle • If cost share is salary, appoint the position to the sub-account • Transfer from the Cost Sharing Account Number (and sub-account if entered) • Only members of CG_COST_SHARE_SUB_ACCOUNT_MAINTAINERS (KUALI_CGSACCT) can edit fields on this tab

14. Sub-Accounts • CG ICR tab • Only allowed on a Contract and Grant Account • ICR attributes on this tab override ICR attributes for the account for transactions posted to this sub-account • On-campus vs. off-campus rates • Only members of CG_COST_SHARE_SUB_ACCOUNT_MAINTAINERS (KUALI_CGSACCT) can edit fields on this tab • Not in Release 2

15. Object Codes • Reports to Chart Code and Reports to Object Code • If your implementation has multiple charts, the object code must report to an object code one level up • An object code at the top level chart will report back to itself • If your implementation has only one chart, an object code will report to itself

16. Object Types • Default object type assigned on object code table • Documents and batch jobs may assign a different object type for the general ledger entry • Transfers of Funds, Auxiliary Voucher, Payroll Accruals • Why four income and four expense types • Separate transfers • Controls when ICR is charged • Separates purchases of capital equipment

17. Transfer Object Types • Unique transfer codes vs. allowing any code to be used as a transfer • Using any code provides flexibility for departments • Unique codes separate transfers when budgeting • Using TI or TE as a default object type • Allowing any code to be used as a transfer – allow TF document to reassign • Dedicated codes for transfers – then it’s a possibility • TI and TE or only TE and contra TE • Using both shows income and expense totals for individual units as they expect • Using only one allows transfers to net without additional work for the institution as a whole

18. Budget Recording Level Indicator/Budget Aggregation Code • Budget Recording Level Indicator is an attribute of account • Budget Aggregation Code is an attribute of object code • Set this code to ‘O’ for object in both cases • Originally intended to allow budgeting by consolidation, level or object code • Parameter in release 3 to control which budget recording level indicators allow an account to be used in budget construction

19. Reporting Using Reports to Object Code • Top level chart has a set of object codes • May or may not have accounts in top level chart • Need to roll up activity in lower level charts and report using a common set of object codes • Example

20. Budget • Budget has to balance by account? Sub-fund? Fund? Org? • Attributes on fund group and sub-fund group tables control how budget adjustments are allowed to cross accounts

21. Sufficient Funds Checking • Hard stop with no override • Sufficient Funds Code populates sufficient funds balances table • TP SF Check controls whether application does sufficient funds checking • What isn’t checked • Internal, External, Pre-encumbrance check boxes on the account document • Beginning Balances Loaded flag on the system options table

22. Sufficient Funds Checking • Different levels of checking and the formulas • Budget checking (4 options) current budget – actual – open encumbrances +/- pending ledger entries • O (object) – checks for the specific object code on the document • L (level) – combines activity for all object codes in the same level as the object code on the document • C (consolidation) – combines activity for all object codes in the same consolidation as the object code on the document • A (account) – combines activity for all expense object codes • Cash checking – H • Current cash balance – open encumbrances – current liabilities +/- pending ledger entries • Current liabilities object codes controlled by parameter (SUFFICIENT_FUNDS_CURRENT_LIABILITIES_OBJECT_CODES) • No checking – N

23. Sufficient Funds Attributes on an Account Document

24. Plant Fund Accounts • On the Organization document • Any capital expenditures on an account in this organization will create capitalization entries in the designated plant fund account • Org Plant Fund account for moveable equipment • Campus Plant Fund account for land/buildings • Which object codes create capitalization entries in which account controlled by object sub-types on capital object codes and parameters: • (PLANT_FUND_CAMPUS_OBJECT_SUB_TYPES ) • (PLANT_FUND_ORGANIZATION_OBJECT_SUB_TYPES)

25. Higher Education Function Code • AICPA, Federal and UBO function codes are all attributes of Higher Ed Function Code • Higher Ed Function Code associated with an account Academic Support Instruction and Unsponsored Research

26. Global e-docs • Global Account – update existing only • Global Account Delegate – inactivates existing delegation and replaces with delegation on document • Global Object Code – create new or update existing • Global Sub-Object Code – create new or update existing • Global Organization Reversion – update existing only

27. Organization Reversion • Controls how budget balances in general fund accounts are handled at year end • Carry forward all • Revert all • Carry forward positives, revert negatives • Carry forward negatives, revert positives • Each with an option to cover open encumbrances first • Example

28. Decision Support • Year-End snapshots • Or more frequent? • Adding object codes from top level chart to general ledger balance and general ledger entry datagroups