Coeus is an electronic research administration system originally developed by the Massachusetts Institute of Technology (MIT) and sustained by the Coeus Consortium. Kuali Coeus is also an electronic research administration system, largely based on the functionality and data model of Coeus, being developed under the umbrella of the Kuali Foundation.

The Coeus and Kuali Coeus projects are collaborating to merge their efforts such that, at some point in the future, institutions using Coeus will be provided with an upgrade path to Kuali Coeus. The Kuali Coeus sustaining partners will continue to development and enhance Kuali Coeus software under the Kuali Coeus Community.

The Kuali Coeus team, with generous assistance from the Huron Consulting Group and the Coeus Consortium, is preparing this RFP Response. This document details the functional requirements that Kuali Coesus and Coeus fulfill, including information on what is planned for the future. Although not complete yet, the document contains a wealth of information that will be a helpful initial step in evaluating KC.

A modular financial accounting system that will be developed using the Community Source development model. KFS will be a conversion of the Indiana University's Financial Information System (FIS) to the web with enhancements identified by the development partners. KFS will be available under the Educational Community License and can be adopted by colleges and universities without licensing fees.

In summary, the Kuali Financial System Development project organziation:

• Kuali Board, chaired by Brad Wheeler, IU, comprises of a votiing member from each Institution, NACUBO and rSmart (nonvoting) and extended board members from each partner.
• Project Manager, Jim Thomas, IU oversees developers from each institution and rSmart
• Functional Council, chaired by Kathleen McNeely, IU, and comprises of members from each Institution, NACUBO and rSmart and functional subcommittees for each module.

• $7.4 m total project cost
• 72+ person-year effort
• Core partners contributing $500,000 - $2,000,000 in cash or tendered personnel resources, depending on size and Carnegie Class
• $2.5m grant from the Andrew W. Mellon Foundation

Kuali is based on the overall design of the IU software, not on the software itself. If we started with a blank piece of paper, the project could not be completed at this price tag. We're moving the proven design from an old technology base to a new one. Of course, everybody has wish lists. So an impressive Functional Council is working on the requirements, from both public and private institutions, with a separate set of representative specialists who scrutinize each module. Our architects and senior developers from all the institutions have been meeting intensively to work out the Kuali nervous system, abstracting the business rules and deciding what should go in which layer. A strength of the project is having input from the seven founding institutions.

Business rules are the part of the application that validate transactions, for example, is this account valid; is this object code valid; is this object code allowable with this account. Routing rules, who needs to approve this document, where it goes next are handled by Workflow.

KFS' modular design includes a base system of Chart of Accounts, General Ledger, Transactions, Reporting, and Workflow. Additional modules that can be implemented as a school identifies a need include: Accounts Receivable, Budgeting, Capital Assets Management, Endowment, Enhanced Decision Support/Reporting, Labor Distribution, Purchasing/Accounts Payable, Pre- and Post-Award Research Administration.

The baseline modules became available for download October 13, 2006.

FIS is an acronym for Financial Information System. FIS is Indiana's accounting system. FIS has workflow and when a user creates a document in FIS, the document is validated (business rules), routed (workflow) and passed into the General Ledger that night for use in reporting the following day. Account balances are updated immediately.

The release version will run with MySQL and will be tested to work in this environment.

ER diagrams for the released modules can be found here: https://test.kuali.org/confluence/display/KULDOC/Entity+Relationship+Dia...

This is just a sample of the way this data might be presented. You could choose a different format to make this information available in.

The original disapproved document cannot be edited. However, it can be copied. Open the document through Document Search or from your Action List and click "Copy." This will generate a document that is identical to the disapproved document except that it will have a new document number assigned and will reference the original document number from which is was copied. Then you can make your changes on this copy and re-submit it for approval.

Yes. If a document involves accounts belonging to more than one Fiscal Officer it will route to all of those users at the same time.

On most KFS financial documents the determination of whether an accounting line debits or credits is made by the object code of that particular line in conjunction with the side of the document ("From" or "To") on which it appears. So normally you will not be able to specify whether a particular row in your source file is a debit or a credit. Instead you will need to import it into the proper side of the document bearing in mind that document's particular function. The exceptions to this are the Journal Voucher and Auxiliary Voucher documents, where it is possible to import debit and credit values directly from the import file. For more information on different possible formats for import files click the "Help" icon that appears in KFS when you click the "Import Lines" button.

Each row in the source file will be added as an individual accounting line. There is no limit on how many accounting lines can be added using the import feature.

Is there a limit to how many accounting lines you can have? You can have multiple accounting lines on any financial document. There is no system-imposed limit on how many lines you can add on a document.

There is no restriction on formats but documents cannot be larger than 5 MB. This is insitutionally determined - for Kuali Test Drive and KFS Development we agreed on 5 MB.

• Ability to handle complex reporting structures
• Campus charts are not required to contain object codes unrelated to their activities (i.e. Cost of Goods Sold, Inventory, etc.)
• Auxiliary Charts are not required to contain object codes unrelated to their activities (i.e. Tuition, State Appropriations)
• Increased Information and Knowledge at the Campus Level
• Easy Access to Campus Level or Auxiliary Reporting.

• multiple charts of accounts
• organizations and the organization hierarchy
• accounts and sub-accounts
• object code and sub-object codes
• object level codes and object consolidation codes

Reporting, both internal and external; Internal controls and document routing; Framework for budget construction.

To support and validate entries into a general ledger.

Yes. At year-end we activate a special set of "Year-End" e-docs. These documents continue to post to period 12 and 13 (June and Closing for us) of the old fiscal year, while the normal set of e-docs post to the new fiscal year. In essence we have two sets of books open simultaneously. We also take snapshots of key account and organization information at June 30 for year-end reporting purposes.

The balance inquiry screens provide an "include pending" option. This will allow users to pull in pending transactions and view them along with posted transactions to gain a more complete view of the financial well being of an account. Many of the balance inquiry screens also allow the user to drill down on the balances and pull up e-docs that support the balances.

Flexibility is being designed into the Kuali Financial System to allow institutions to determine where balancing offsets should post. For example, an Interdepartmental Billing unit may send in a charge and an income record without the necessary hit to cash. In this case the accounting cycle would generate the necessary hits to cash to balance both the expense and income transactions. Institutions will have the option to have balancing offsets post to the same account as the original transaction or identify an accounting string where the offset should post. For each account in the system you can set up an offset accounting string by object code (i.e., cash, accounts receivable, accounts payable, etc…), then if the scrubber determines a balancing offset is needed it will create it with the proper accounting string.

Indirect Cost Recovery (ICR) is calculated each time the accounting cycle runs. Information contained on the account (rate, exclusions, revenue accounting string) and certain maintenance tables are used to calculate ICR based on eligible expenses. The system then automatically generates ICR expense and ICR income ledger entries for posting. In the event that a correction to the calculated ICR needs to occur, users can submit an Indirect Cost Adjustment (ICA) e-doc to fix the amount.

There are two types of sub accounts in the system: expense and cost share. For cost share sub accounts, additional attributes are required that identify the source chart, account number, and sub account number that is to cover the costs incurred by the cost share sub account. Each time the accounting cycle runs expenses in a cost share sub account are automatically covered by a system generated transfer of funds. The transfer of funds moves money from the source accounting string to the cost share sub account for the amount of the expenses.

Capitalization occurs by organization. Each organization is set up with its own moveable and non-moveable plant fund account numbers. As expenditures occur in the General Ledger these items are capitalized in the appropriate plant fund account number for the organization incurring the expense. The capitalization process also relies on object code sub type mappings to determine which balance sheet object code to use when capitalizing an item. For example, object code 7000 has an object code sub type of CM (capital equipment moveable). CM maps to object code 8610 on the balance sheet. Setting up plant funds by organization and mapping expenditure object code sub types to balance sheet object codes lets us create balance sheets at various levels: by organization, responsibility center, campus, etc…

No. The primary responsibility of the de-merge process is to identify all of the transactions for a document found to have errors and put those transactions is a working table for later processing by the GLCP document. If one transaction on a document has an error the entire document is flagged and none of those entries post until the correction is made. This prevents an out of balance situation within the General Ledger.

There are two primary methods for error correction. For e-doc errors (very rare due to the on-line edits applied at document creation) and other enterprise level systems (Student, Travel, etc…), the General Ledger Correction Process (GLCP) e-doc is used to correct the error(s) and set the entries back up for processing during the next accounting cycle. The GLCP document provides an auditable trail and access is limited to a centrally controlled workgroup. Transactions originating outside the on-line environment from non-enterprise systems are handled differently. When errors are found from these feeds a notification is sent back to the originating department and they are then responsible for correcting the error. Typically these units are Interdepartmental Billing units.

Yes. The AR module can handle both payments received via lockbox and those received directly in the Bursar or deposited in the bank.

• Accounting entries are system generated
• Handles Non-Student Receivables - Billing to external customers by departments, includes aging reports
• Optionally, handles payments received via lockbox

Not now, but this is an essential enhancement identified by the AP/Purchasing Subject Matter Experts team, so it will be a part of KFS.

What if the user doesn't know it? There is a workflow level for this purpose, so that if a Requisitioner doesn't know the accounting information, the Req is routed to a workgroup who can add that information.

No. We had considered this but the investment was too great for the return. The current buyer assignment screen is very efficient.

If so, how? The Payment request can reflect the quantity received, or in the case of services, the amount to be paid. The encumbrances for just that quantity or partial payment are disencumbered.

Payments after the fact are done via Disbursement Voucher documents in KFS.

Yes, subcontracts can be set up as PO's and coded such that they can live over multiples years, have additional funds, etc.

Yes, this can be set by organizations within the institution, and PO's below that threshold do not require Purchasing approval.

Yes, this will be a part of the KFS infrastructure.

What happens to the encumbrance? The encumbrance will still be released against the original account so there are no dangling encumbrances.

The quantity on a PO can be null, which means as invoices come in the total cost is paid down over time.

It is booked once the PO is completely through workflow and approved.

Budget Construction is a special "document (eDoc)" within the Kuali system that:

• Budgets at detailed level
• Salary-setting - Integrated with IUs HR system for positions & jobs
• Security is built in that allows for the "push-down" and "pull-up" of budgets at various levels and during the budget process
• Extensive reporting within the document - Detail and summary reports and Salary statistics (pct chg for continuing employees

• Base budget (budget construction)
• Monthly budgets (used primarily for auxiliaries at IU)
• Current budget (for non-C&G accounts, loaded from base budget; includes carryforwards; for C&G, created by budget adjustment documents)

• Budget fully integrated with accounting – ability to budget and track at the most detailed level
• Balance "buckets" at chart, account, subaccount, object, subobject, object type record
• On-line balance reports include both budget and actual balances/transactions

• Capital Non-movable includes Art and Museum; Buildings & Building Improvements; Infrastructure; Land; Lease Purchases; Library books. They are created from a monthly summary report. These transactions are added manually using the Add Asset Document. Transactions are identified by the object sub type code which is generated from the object code.
• Capital Movable includes Movable Equipment; Movable Fabrications. Movable equipment transactions are processed in the Capital Asset Builder (CAB). Movable transactions are selected from a table that includes all of the object sub type codes that are loaded into CAB.
• Non Capital assets can be created by organization using the Add Asset Document.

• Capital Asset Builder
• Pre-Asset Tagging
• CAMS FIS Documents and Maintenance Screens
• Inventory Process
• Depreciation
• Reconciliation Reports

• Basic Tables: Labor Ledger Detail and Labor Ledger Balance
• Accounting Cycle and Reference Tables – Object Codes, Pooled Benefits, Rates for C&G Accounts, Accounts Not Accepting Fringes, Sub Funds Not Accepting Wages
• eDocs - Salary Transfers, Benefit Transfers, Labor Ledger Adjustment, A21 Re-Creates, Instructional Effort Reporting
• On-Line Labor Balance Inquiries Including Calculated Salary Foundation (CSF) as Basis for Budget Construction
• Decision Support – Data Direct, Pre-Defined Queries (PDQ's), & Standard Reports
• A21 Effort Reporting
• HR Interface

• ACCOUNT STATUS
• CONSOLIDATED ACCOUNT STATUS
• CONSOLIDATED OBJECT CODES
• ACCOUNT TRANSACTIONS
• TRIAL BALANCE
• EXTERNAL REPORTS
• BALANCE INQUIRY