Chart of Accounts: Project

The Project chartfield is a 7-character alphanumeric value which assists in uniquely identifying and tracking charges to a discrete set of activities, initiatives or projects. The focus of a Project is tracking an activity or a specified purpose. The Project is often associated with a person that is responsible or accountable for the activity. It is a required field on revenue, expense, and transfer transactions.

Projects should not be confused with Funds. The Fund chartfield identifies the source, whereas a Project allows tracking for a particular activity or purpose (how a department uses funds). A Project usually has a specific beginning and ending date.

Generally, a new Project may be established:

• To track a discrete activity, initiative, or project that falls within a predefined list of uses
• Generally, for activities that have a specific beginning and ending date
• To track activities for contracts, grants, gifts, and endowment income

Multiple Separate Projects versus Single Shared Project

• Multiple Separate Projects

In many cases, the activity that is tracked by the Project is unique and assigned to an owner or person accountable or responsible. In this case, multiple separate Projects are utilized, and an owner is assigned to each one. For example, individual separate Projects are used with contracts, grants, gifts, recharges and discretionary projects. Multiple separate Projects have an expected end date, which can be changed.

• Single Shared Projects:

It is recognized that some activities are similar across multiple departments. The department chartfield can identify who is performing the activity and the Project itself is the same. For example, many departments have a need to track the fundraising activity within their department. In order to prevent a proliferation of projects which are essentially for the same Project (in this case, fundraising), a single shared “fundraising” Project is set up. Where possible, Projects representing a common activity are shared among multiple departments using a single Project. Because of the shared nature, shared Projects do not have owners and are not assigned to a person. They relate to a departmental activity which is shared across multiple departments. The PI/manager/owner for a shared Project is “Department/Division”. The end date for single shared Projects is 12/31/2099.

Materiality

A Project should be set up only for activities where there is a definite reporting need and where revenues and/or expenses are material.

Purpose/Use

A new Project chartfield may be established for the following purposes:

Project Use: Sponsored Projects (contracts and grants)

Description

A sponsored project is defined as any externally funded research or scholarly activity that has a defined scope of work or set of objectives, which provides a basis for sponsor expectations. This more specifically involves research, demonstration, professional development, instruction, training, curriculum development, community and public service, or other scholarly activity involving funds, materials, other forms of compensation, or exchanges of in-kind efforts under awards or agreements.

Sponsored awards are made to the University on behalf of the principal investigator (PI), who is primarily responsible for carrying out the requirements of the award. The PI may also be referred to as the project director. The few exceptions are certain awards that may be made to individuals, such as some faculty fellowships.

Sponsored projects include extramural grants, contracts and clinical trials. Sponsored projects will have multiple Project IDs.

Currently, sponsored projects (RAS) use the PeopleSoft Projects module to track award/grant setup, detail project activities, and billing activities. The PeopleSoft Projects module works in conjunction with the financial systems, but is focused on project management and billing. A RAS project is established in the PeopleSoft Project module first. Upon saving, its information will be synchronized with PeopleSoft General Ledger’s Project chartfield table. The user can use the Project chartfield page to view the RAS Project but not change its data.

Not all Projects generated in RAS fall into the sponsored projects (contracts and grants) project use category. Some of the Projects generated in RAS belong in the affiliation agreements and contracts or in other project use categories.

Examples

Project Use: Capital Construction Projects

Description

(See Section 4.1.9 on Capital Accounting)

Capital Accounting consists of Capital Projects and Capital Asset Management. Capital Accounting performs the accounting and reporting functions for capital projects and equipment, software and library collections that have service lives longer than one year.

The UCOP Accounting Manual specifies that new construction remains as construction-in-progress until the project is 90% complete. Twice per year the expenses of all new construction projects that are 90% complete and over $35,000 are capitalized as a capital asset. Thereafter, any additional construction expenses are capitalized semi- annually until the project is complete.

Capital projects will have separate Projects for each capital project.

Examples

Project Use: General

Description

General contains projects that do not fall into any of the other categories. General projects are divided into four main groups:

1. Gifts and endowments that have no specific intended use when received have separate Projects, one for each gift/endowment received.
2. A single shared General Project is for money received by a department (other than from than gifts and endowments) which has no specific project use. The General Project can also be used as a default when a project is required (see Mandatory Use). The single shared General Project will have a Project ID of “1111111”.
3. Where activities are similar across multiple departments, a single shared Project is set up and the same project is used by the different departments for that activity. The Department chartfield can identify who is performing the activity and the Project itself is the same. Some examples of single shared projects are:

• Fundraising and development investments which are departmental use specific. This is not to be used by University Development and Alumni Relations.
• A single shared Project is used by multiple departments for continuing medical education.
• A single shared Project is used by multiple departments for SFGH professional clinical fees at SFGH which are not part of the SFGH affiliation agreement.
• A single shared Project is used by clinical service centers/labs (e.g. in Dentistry and Nursing) for professional clinical fees generated at UCSF.
• A single shared Project is used for UCSF clinic resident support (same parent/award ID as UCSF clinical.
• A single shared Project is used across multiple departments for earned income from consulting and expert witness fees.

4. Separate Projects which need to be tracked and reported separately from the General unspecific Project. These Projects are subject to Control Point and central review.

Examples

Project Use: Faculty/PI/Owner Activity

Description

A Project may be set up if it is decided to track the discretionary revenues and expenses of an individual faculty member or other owner of discretionary activities.

It is important to distinguish between faculty/PI/owner activity versus department discretionary. Each faculty/owner discretionary activity Project is assigned to an individual owner.

If substantial, a need may exist to create separate Projects for consulting revenues per faculty/PI name. Faculty/PI/owner activity includes discretionary research, allocation to an individual, clinical trial residuals, academic enrichment, royalty/inventor share or symposiums that an individual is accountable for. It also includes gift and endowment projects that an individual is accountable for.

Faculty/PI/owner activity projects have separate Projects with a unique Faculty/PI/owner name attribute.

Examples

Project Use: Recruitment/Faculty Start-up

Description

A reporting need often exists to track recruitment faculty start-ups. Typically costs are aligned with the offer letter or other formal or informal initial employment agreement. Expenses would include salary support that is part of the recruitment package. Endowed chairs should be captured as part of recruitment if they are assigned for that purpose. Capital is included in the recruitment project until the department is ready to spend on the capital, at which point these dollars are transferred to the capital project. Housing loans are part of recruitment / start-up packages.

Faculty recruitment start-up packages have separate projects with a unique Faculty/PI name attribute.

Examples

Project Use: Retention

Description

All junior faculty hired in a medical school have committed substantial time and effort in education and training and are recognized as having the potential to succeed in an academic environment on the basis of demonstrated excellence in research, clinical practice, and/or teaching. Given the long training periods for such faculty— often 15 years or more of higher education and training for clinical scientists—the societal investment in these individuals is substantial. Recruiting these individuals as junior medical school faculty represents a significant level of institutional commitment and resources. Facilitating success for such faculty represents a positive return on that investment. Faculty who fail or leave the institution represent a negative return and drain scarce resources when replacements need to be recruited.

Retention packages may be offered to a faculty/PI along with a retention letter. Expenses include salary support which is part of the retention package and bridge funding if for the purpose of retention.

Faculty/PI retention packages have separate projects with a unique Faculty/PI name attribute.

Examples

Project Use: Medical Center Activity

Description

There is a close relationship between the UCSF campus and the UCSF Medical Center. Campus clinical departments provide medical direction, out-reach services and extended coverage to the Medical Center. Because of the collaborative relationship, the Medical Center also provides strategic support to the campus and invests in clinical program development by paying for start-up - “back-stops” - costs including physician compensation and administrative costs. A reporting need exists to track the revenues and expenses between the campus and Medical Center.

Medical Center projects can be divided into three main groups:

1. Medical Center clinical care has a single shared Project. This includes Medical Center Professional Service Agreement revenues and expenses, Medical Center purchased services and Medical Center strategic support.
2. Medical Center residents have a single shared Project. This includes revenues and expenses related to training residents at the Medical Center.
3. Other special agreements/joint ventures between the Medical Center and independent clinical facilities have separate Projects for each special agreement.

Examples

Project Use: Affiliation Agreement/Contract

Description

Affiliation agreements and contracts can be for any material agreement with an entity outside of UCSF.

Affiliation agreement and contract Projects can be divided into three main groups:

1. Hospital affiliation agreements will have a single shared Project for each hospital (SFGH, VAMC, etc.). Hospital and the associated resident Projects will share the same award ID.
2. Agreements for residents will have a single shared Project for each hospital (SFGH, VAMC, etc.). Resident and the associated hospital Projects will share the same award ID attribute.
   • Other sales and service agreements and contracts will have multiple Projects for each affiliation agreement and contract.

Examples

Project Use: Recharge

Description

(See section on Recharges)

Throughout the campus, organizational units use a variety of products or services to perform their activities. When these products or services are provided by organizational units within the University, the units providing the products or services function as non-profit businesses, and charge for their products or services.

The University provides an internal mechanism for charging organizational units for support services wherein all allowable costs associated with providing these products or services are included. This mechanism is called a “recharge,” which is the activity used to recover expenses incurred in providing products or services based on an approved recharge rate. Recharges should not be confused with expense transfers or External Sales and Service of Education Related Activities (fee for service).

The Project chartfield will be used to uniquely identify each distinct recharge activity. The Project will be used to match all expenses directly attributable to providing the products, services, and management of the recharge activity with the revenue that is generated by charging internal and external customers. Recharge Projects can be set up for each recharge activity.

For recharges, if a decision is made to temporarily prevent a department from charging to a recharge revenue account, the recharge Project attribute can be temporarily changed from “Active” to “Inactive”. Once the recharge Project is available to recharges again, the attribute can be changed back to “Active”.

Award/parent ID is a Project attribute that enables linking of multiple related recharge Projects for different service lines within one recharge operation for reporting. Award/parent ID is an alpha-numeric field that will be assigned in PeopleSoft in the initial project setup process. For all Project uses except RAS-generated sponsored projects, if the user indicates this is a parent Project, the award/parent ID attribute is the same as the initial Project. If the user indicates this is a sub-project, the award/parent ID can be changed to that of the parent Project. This will allow for roll-up reporting of Projects which are grouped together through the award/parent ID. Below is an example of how a recharge may use parent and sub-projects that are linked together using the award/parent ID attribute. The user will use the same award/parent ID as the parent Project for the related sub-projects.

Examples

Project Use: Sales and Service Agreements

Description

Sales and service agreement Projects are for activities which provide products and/or services to external customers only.

Project Use: Programmatic Investment

Description

Departments may decide to put aside money for a specific program or initiative, such as for teaching support or program development. This project use may also include gifts or endowments that benefit a particular program or initiative. The PI/manager/owner could be an individual or Department/Division.

Programmatic investment projects can be divided into three main groups:

1. Programs that are shared across multiple departments will have a single shared Project. An example is the Grand Rounds program. The Department ID chartfield can identify the specific department.
2. Programs that are unique to a specific department will have separate Projects for each program.
3. Research funded by gifts and endowments will have separate Projects for each research activity.

Examples

Project Use: Costed Central Activity

Description

Costed central activities are basic central campus functions (e.g. HR, basic police services, internal audit services, payroll, ITS administrative computing) which are funded by allocation of costs to self-supporting auxiliary enterprises (e.g. Campus Life Services).

Project Use: Loan (student/faculty/staff)

Description

There are separate Projects for each loan to students, faculty and staff. Loan Projects are primarily set up centrally by Student Accounts.

Project Attributes:

Certain Project attributes apply to all Project uses, while other attributes are specific to a particular Project use.

The list of Sponsored projects (grants and contracts) attributes is maintained in the PeopleSoft Projects module and cannot be changed in the General Ledger chartfield table.

The Project attributes which apply to all Project uses include:

• Effective Status – A Project is either in Active or Inactive status at any point in time. It can be changed from Inactive back to Active.
• Start and End Dates –The start date is the date of setup and the end date is the estimated end date. The end date can be changed on a Project. The end date for shared Projects with no readily-determinable end date is 12/31/2099.
• Award/Parent ID – This field is used to report multi-project activities from the same original parent Project. In the initial Project setup, the award/parent ID is the same as the Project. When sub-projects of an existing Project are set up, the award/parent ID is the same as on the parent Project. This allows for the linking of related Projects.
• Parent Project – A Project is either a parent Project or a sub-project of an already existing one. If the Project is a sub-project of an existing Project, the person setting up the Project should use the same award/parent ID as the parent Project.
• Principal Investigator / Owner – This is the employee ID of the person who is has the principal responsibility and accountability for the Project. During the Project setup, validation of the employee ID with the use of a lookup table is recommended.

Some of the Project attributes which apply to sponsored projects and are optional for other types of project use are:

• Type of Lab – This is a whether a lab is a Wet, Dry or Other lab. It is used on sponsored projects in order to link a PI to the type of lab for ICR benchmarking.
• Lab Location – Building – This is the building or CAAN number of the lab and is used on sponsored projects in order to link a PI to the type of lab for ICR benchmarking.
• Lab Location – Room – Depending on the selection for the lab location – building attribute, there will be a drop-down box to select the room within the building.

The Project attributes are listed in the table below. Relevant Project attributes for each type of project are indicated. The Project category abbreviations are:

• SP – Sponsored projects
• CP – Capital Projects
• RC – Recharges
• G – Gift
• E – Endowment
• OT – All others

(O = Optional)

Numbering Convention

Careful consideration will be given to not duplicate any of the existing numbers used in RAS for sponsored projects.

Not all Projects generated in RAS fall into the sponsored projects (contracts and grants) Project use category. Some of the Projects generated in RAS belong in the affiliation agreements and contracts, or in other Project use categories.

Before the new COA, Project is a chartfield used solely by RAS. A RAS project id is generated by the system based on the Award ID. To allow multiple Projects for an award, the system uses the following numbering convention to generate the project ID for an award:

1. First 6-character of a project ID is the 6-digit of its Award ID. Award ID is a 7-character alphanumeric value. It always starts with A and follows by a 6-digit numbers, e.g., A117088. The first 6-character of the project id is its Award’s 6-digit number, e.g., 117088.
2. The last character of a project ID is always an alpha, starting from A to Z, but skips I and O (to reduce confusion with 1 or 0) for multiple projects associated to the same award. For example, 117088A, 117088B, 117088C … etc.
3. If an award has more than 24 projects, the 1^st character of the project id will be changed to B. If more than 48 projects, the 1^st character of the project id will be changed to C … etc. For example, B17088A, B17088B … B17088Z, C17088A, C17088B, … etc. So far, the award has the most projects is A106017 with 246 projects (106017A … L06017K).

A RAS project id will still follow the above numbering convention for sponsored projects only.

We will have a special numbering convention for project for the following project uses:

• Loan (student/faculty/staff) 6000000-6199999
• Gifts 7000000-7499999
• Endowment income, Regents 7500000-7699999
• Endowment income, Foundation 7700000-7899999
• Endowment principal 7900000-7949999
• Recharge 8000000-8499999
• Sales and Service Agreements 8500000-8799999
• Costed central activity 8800000-8999999
• Capital/plant 9xxxxxx

For all other Projects, the project id will be a sequential 7-character alphanumeric value.

Changes in Project Use

The Projects in the Project use categories of capital/plant, costed central activity, loan, or recharge will not be able to change to a different Project use category. Attempts by the user to make prohibited changes in Project use would be met with an error message: “This change in project use is not allowed.” If a user needs to initiate a change in these Project use categories, he has to inactivate the Project and re-journal any transactions which have already been made.

Project use can be changed for any other Project (but not to capital/plant, costed central activity, loan, or recharge).

For example, new gifts and endowments which have no specific intended use when received are put into the “General” Project use category, and then may be moved into another Project use category once they are designated for a specific purpose.

A gift or endowment project is received from the UCSF Foundation with the Project use General. The award/parent ID attribute is the same as the gift or endowment Project.

The department may then reclassify the Project use as appropriate.

In order to track the Project use for a gift or endowment, there is a Project attribute to indicate whether the project source of funds is a gift, endowment income (Regent or Foundation), endowment principal, or none of these. This attribute will not change during the life of the Project. Also the initial award/parent ID attribute on the gift or endowment project will not change during the life of the Project. This will allow for the tracking of how gifts and endowments are used.

The department may decide to keep some of the gift or endowment income in the general Project use category and create new sub-projects with various Project uses. The award/parent ID links the Projects together and allows the grouping of the related Projects for reporting purposes.

Project Initial Setup Workflow

Project initial setup rules:

* Currently, sponsored projects (RAS) uses the PeopleSoft Projects module to track award/grant setup, detail project activities, and billing activities. The PeopleSoft Projects module works in conjunction with the financial systems, but is focused on project management and billing. A RAS project is established in the PeopleSoft Project module first. Upon saving, its information will be synchronized with PeopleSoft General Ledger’s project chartfield table. The user can use the Project chartfield page to view but not change its data.

** Capital construction projects are set up centrally and department users can use the project chartfield page to view but not change its data.