Understanding Accounting for Projects

This topic discusses:

  • Accounting for Projects feature.

  • Revenue and cost sharing.

  • Accounting data flow.

  • Accounting for Projects setup steps.

  • Organizational hierarchies.

  • Project- and activity-owning organizations.

  • Sharing structure.

  • Accounting rules.

  • Process Project Accounting process.

The Accounting for Projects feature provides a flexible method for translating transactions into entries that you can send to PeopleSoft General Ledger. Using accounting rules, the system converts transactions in Project Costing to accounting lines that the Journal Generator Application Engine process (FS_JGEN) later converts into journal entries.

You can use the Accounting for Projects feature to:

  • Create project cost and revenue accounting entries from feeder systems for entries that have not been previously accounted for in journals.

  • Create accounting entries between different organizational entities when transactions are generated for a project or activity by a resource from a business unit or other organizational entity that differs from the project or activity's general ledger (GL) business unit or organization.

  • Specify how costs and revenue are shared among different departments and operating units, such as GL business units.

You must use the Accounting for Projects feature to generate accounting entries for project billing and transaction allocations.

In the services industry, employees may work on projects that are outside of their own organization. In such cases, the organization that owns a project and the organization that owns the human resource (the employee), may be two separate entities. To handle these scenarios, use the organizational-sharing method of project accounting to share costs and revenue that the project or activity generates between the entities. You can set up rules and accounting procedures that define the internal agreement between the organization that owns the project and the organization that owns the human resource.

Once you determine the organization and standard accounting procedures, you can assess whether sharing is needed. Use this table to determine if organizational sharing is necessary:

No Organizational Sharing Needed

Organizational Sharing Needed

All project and activity charges follow the resource. Project and activity charges are not shared between the organization owning the human resource and the organization owning the project. Charge backs are not used.

Project or activity charges are shared between the organization owning the human resource and the organization owning the project or activity, either as a rule or on a case-by-case basis.

All charges follow the project, and the accounting for these charges are simple and require little time to maintain.

It is preferable to have a centralized location for assigning a project to an organization. This organization then owns the project.

Accounting for revenue is fairly simple. All transactions of a similar type use the same revenue account.

The organization has complex revenue accounting requirements.

Reporting and visibility needs are simple. Revenue and costs are analyzed by the resource organization, or the project or activity organization, but not by both.

Reporting and visibility needs are complex. Multidimensional visibility of revenue, costs, and expenses are needed for the owners of the projects, activities, and resources.

Although revenue follows the resource, the accounting practices require that revenue be moved in and out of the project organization (or vice versa) for the purpose of visibility.

Revenue and costs are booked to different accounts based on the relationship between the employee and the project.

This diagram illustrates the flow of transactions from feeder systems to PeopleSoft Project Costing, and from Project Costing to PeopleSoft Billing and PeopleSoft General Ledger:

Flow of transactions from feeder systems to Project Costing and flow of transactions from Project Costing to Billing and General Ledger.

Flow of transactions in Accounting for Projects

These steps illustrate the flow of transactions to and from Project Costing:

  1. PeopleSoft applications such as PeopleSoft Time and Labor, Expenses, and Payables, feed data to PeopleSoft Project Costing, which triggers the Pricing Application Engine process (PC_PRICING).

    The Pricing process creates target rows in the Project Transaction table (PROJ_RESOURCE). The system uses the target rows to generate accounting and billing entries.

  2. If sharing rules are defined and activated, the Pricing process calls the Sharing Application Engine process (PSA_SHARING) to search for rows that are designated for sharing.

    The Sharing process analyzes a row for sharing if the organization that owns the project or activity differs from the organization of the transaction-generating resource, and an applicable sharing rule exists.

    After identifying the applicable sharing rule, the Sharing process identifies exceptions, which follow a priority hierarchy that you establish on the Organizational Sharing Options page. If there are no exceptions, the Sharing process applies the default sharing percentage that you established for the sharing rule, and creates new rows that are based on the specified sharing rules and options.

    Source transaction rows and target transaction rows are eligible for the Sharing process. Projects and activities that are associated with contracts that have a Government classification are not eligible for the Sharing process.

    Important! The Sharing process analyzes transactions only if the Billing Distribution Status field (BI_DISTRIB_STATUS) value for the row is P (priced), or the Revenue Distribution Status field (REV_DISTRIB_STATUS) value is C (created), or the Cost Distribution Status field (CST_DISTRIB_STATUS) value is C.

  3. The Process Project Accounting Application Engine process (PSA_ACCTGGL) selects previously undistributed rows in the Project Transaction table and matches them to the appropriate accounting rules that are set up to write journal entries into the Accounting Line for Contracts and Projects table (CA_ACCTG_LN_PC).

  4. The Journal Generator process creates the journal in PeopleSoft General Ledger.

    Additionally, the system uses accounting rules to send data to the Contracts Billing Interface Application Engine process (CA_BI_INTFC) to forward to PeopleSoft Billing. The accounting rules for as-incurred billing plans, not the accounting distribution that is defined in contract lines, determine the unbilled accounts receivable (UAR) accounting distribution.

You must define accounting rules to generate any accounting entries from Project Costing, even if you do not use an organizational hierarchy or sharing rules.

You can set up project accounting in one of three ways based on your need to track project costs and revenue. This table lists the purpose and setup requirements for each method:

Type of Accounting

Purpose

Setup Required

Straight

Use when transactions always follow the resource; for example, when transactions that a resource creates are charged to that resource's organizational entity.

Define accounting rules.

See Accounting Rules Page.

Transorganizational

Use to charge transactions to an organizational entity that differs from that of the resource; for example, when an employee is temporarily assigned to another office, but the company wants to charge the employee's expenses to the employee's original office.

1. Enable organizations on the Installation Options - Project Costing page.

See Installation Options - Project Costing Page.

2. Define the organizational hierarchy.

See Organization Hierarchy Page.

3. Define either the project-owning organization or the project activity-owning organization.

See Defining Project- and Activity-Owning Organizations.

4. Define accounting rules.

See Accounting Rules Page.

Organizational sharing

Use to share costs and revenue between a resource's organization and the organization that owns the project or activity.

Note: Contracts with a contract classification of Government are not eligible for organizational sharing.

1. Enable organizations on the Installation Options - Project Costing page.

See Installation Options - Project Costing Page.

2. Enable costs and revenue sharing on the Installation Options - Project Costing page.

3. Define the organizational hierarchy.

See Organization Hierarchy Page.

4. Define organizational sharing options.

See Organizational Sharing Options Page.

5. Define sharing rules (source criteria and target definitions).

See Organizational Sharing Rules Page, Organizational Sharing Rules - Target Page.

6. (Optional) Define sharing exceptions.

See Defining Sharing Exceptions.

7. Define either the project-owning organization or the project activity-owning organizations.

See Defining Project- and Activity-Owning Organizations.

8. Define accounting rules.

Complete this step if you want to send transactions to GL.

See Accounting Rules Page.

Note: In situations that require transorganizational or organizational-sharing accounting, the resource that generates the transaction is typically an employee or consultant. You can, however, use these methods to account for transactions that are generated by resources other than human resources.

The first step in setting up transorganizational accounting or organizational-sharing accounting is to define the organizational hierarchy, which you use to determine which rules apply to a given situation. The organization can be as simple as a GL business unit (which is the minimum required), or it can be broken down further into four additional groups and subgroups using ChartFields to designate each organizational entity. This enables you to apply different rules (for accounting across or sharing between entities) to organizational entities depending on their size.

This diagram shows an example of an organization that is defined first by GL business unit, and then by operating unit and department:

Examples of a three tiered hierarchy. General ledger business unit at the top, operating unit in the middle, and departments at the bottom.

Example of an organizational hierarchy

The GL business unit is always first in the organizational hierarchy when you apply accounting rules to a human resource who is working on a project or activity in another part of the company. A human resource from one GL business unit working in another GL business unit always follows interbusiness unit rules, regardless of the departments and operating units that are involved.

The human resources system defines which organization owns a particular human resource. The system automatically attaches both the GL business unit and the department to a human resource. You must populate other ChartFields that you include in an organizational definition in transactions that are sent to the Project Transaction table.

You can configure organizational sharing at the project or activity level.

If you specify an owning organization at the activity level, the Sharing process determines whether to create sharing rows based on this criteria:

  • If a transaction enters Project Costing with an owning organization that differs from the ChartField values entered on the Activity Organization page, the system creates sharing rows based on the defined sharing rules.

  • If a transaction enters Project Costing that matches the ChartField values entered on the Activity Organization page, the system does not create sharing rows.

  • If an owning organization exists at the activity level, the system disregards the project-level owning organization even if no transactions match the ChartField values entered on the Activity Organization page.

If no owning organization exists at the activity level, the system uses the project-level owning organization to determine whether to create sharing rows based on this criteria:

  • If a transaction enters Project Costing that differs from ChartField values on the project Organization page, the system creates sharing rows based on the defined sharing rules.

  • If a transaction enters Project Costing that matches the ChartField values on the project Organization page, the system does not create sharing rows.

If no owning organization exists at the activity level or the project level, the system does not create sharing rows.

The sharing structure consists of sharing options, rates, and exceptions.

Sharing Options

Organizational sharing options define which elements of an organization trigger charge backs. The organizational sharing options that are available for selection are based on the organizational hierarchy that you set up at the system level.

For example, assume that you set up an organizational hierarchy that consists of multiple levels. Level 1 is required and is always the GL Business Unit ChartField BUSINESS_UNIT_GL. Levels 2 through 5 are optional. In this example, level 2 is the DEPTID ChartField. As a result, on the Organizational Sharing Options page you can select the GL Business Unit and Department, or just the GL Business Unit, to trigger organizational sharing. If you select both fields on the Organizational Sharing Options page, the system triggers organizational sharing if a project activity's owning organization business unit or department differ from that of the transaction. If the activity does not have an owning organization, the system triggers organizational sharing if the project's owning organization business unit or department differ from that of the transaction.

Sharing Exceptions

You can set up exceptions based on employees and employee attributes, project teams, projects and project attributes, and organizations. Use the Organizational Sharing Options page to establish the exception type priorities.

The system stops processing when it finds the first valid exception. For example, assume that you set up three exception types with priority 1, 2, and 3 on the Organizational Sharing Options page. If the system encounters an exception while processing the first priority exception type, it stops immediately and does not proceed to the subsequent exception types.

Example of Sharing Process

This section provides an example of sharing revenue between two organizations by using the Sharing process.

Assume that you want the project activity-owning organization to share half of the revenue generated for an activity with the resource-owning organization. When expense rows, which have an ACT (Actual Cost) analysis type, and labor costs, which have a PAY (Time and Labor Actual) analysis type, enter Project Costing from feeder systems, the rate set for this activity instructs the Pricing Application Engine process (PC_PRICING) to create BIL (Billable Amount) rows. For each BIL row that contains a different GL business unit than the owning organization, you want the Sharing process to create two new rows—one with an analysis type of SHR (Shared Revenue) for 50 percent of the billed amount, and another row for 100 percent of the billed amount with an analysis type of OFA (Offset Revenue).

After you enable organizations and sharing on the Installation Options - Project Costing page, these are the steps to set up this example:

  1. On the Organizational Sharing Options page, select only the GL Business Unit option in the Sharing Organization group box.

    The organizational hierarchy is established for the system at the GL business unit and department level; however, this example evaluates only the sharing options for the GL business unit.

  2. On the Organizational Sharing Options page, select the Copy original/create discount option in the Process Results group box.

  3. On the Organizational Sharing Rules - Source Criteria page, specify a BIL analysis type as the source transaction.

  4. On the Organizational Sharing Rules - Target Definition page, enter these values for the Sharing process to use to create new rows from each BIL row:

    • Percentage: 50

      The Sharing process applies this percentage to the row with the discount analysis type.

    • Target Analysis Type: OFA

    • Discount Analysis Type: SHR

The Pricing process, which triggers the Sharing process, sends the resulting rows to the Project Transaction table. The following table lists the original BIL row, the new target OFA row (at 100 percent of the original BIL row), and the new discount SHR row (at 50 percent of the original BIL row):

Analysis Type

Quantity

Unit of Measure

Source Amount

Source Currency

BIL

8

EA

1,200.00

USD

OFA

8

EA

1,200.00

USD

SHR

8

EA

600.00

USD

You define standard accounting entries, or rules for project-based transactions, based on a combination of these data elements:

  • Project business unit.

  • Analysis type.

  • Contract.

  • Project.

  • Project GL business unit.

  • Resource GL business unit.

  • Activity.

  • Other project-related ChartFields.

  • Other project-related identifiers, such as project type, project transaction type, and project transaction code.

  • GL ChartFields.

These rules are necessary to process any accounting from project transactions. You must enter values for the project business unit and resource GL business unit. You must also enter a value for the project GL business unit when you use transorganizational accounting. You can minimize the rules by entering a wildcard (the percent symbol) in all of the other listed fields. Alternatively, you can make the rules more specific by entering values for the listed fields.

For example, assume that a time sheet is priced and generates a billable row with a BIL analysis type and a cost row with an analysis type of CAC (Cost Sharing Actuals). These two rows (BIL and CAC) may require different accounting entries using two accounting rules—one for the BIL analysis type and one for the CAC analysis type. You can copy accounting rules to the various project business unit-and-resource GL business unit combinations that you require by clicking the Copy Accounting Entries To link on the Accounting Rules page and entering the new header criteria.

Note: If you use the Government Contracting feature that is available with PeopleSoft Contracts, and you select the Separate Billing and Revenue option on the Installation Options - Contracts page, transactions with a Revenue (REV) analysis type use the accounting rules that are set up for the BIL analysis type. This ensures that the system uses same UAR for all billing and revenue accounting entries that are associated with cost plus contract lines.

The Process Project Accounting process selects transactions from the Project Transaction table based on accounting rules, and translates transaction amounts into the appropriate base currency that is specified for the GL business unit. If necessary, the central processor in PeopleSoft General Ledger creates interunit entries.

Use the Process Project Accounting process to apply accounting rules and generate:

  • Cost entries from transactions with analysis types that belong to the Accounting Costs analysis group (PSCST).

  • Revenue entries from transactions with analysis types that belong to the System Revenue analysis group (PSREV) or the GC (Government Contracting) System Revenue analysis group (PSRV2).

    Additionally, the transaction line must be linked to a contract line where the revenue plan is in a status of Ready or In Progress.

  • Purchase/sold time, shared discounts, and shared revenue entries with analysis types that belong to the Sharing analysis group (PSTDR).

Note: The Contracts to Project Costing Application Engine process (PC_CA_TO_PC) picks up the revenue accounting rows for amount-based contract lines with associated project activities. The amount-based revenue rows in Project Costing are for project tracking and comparison purposes and are not sent to PeopleSoft Billing or PeopleSoft General Ledger.

If the transaction currency is different than the GL base currency when performing currency translations for:

  • Cost transactions, the system uses the currency effective date that is specified on the transaction.

  • Revenue-related transactions, the system uses either the accounting date or the transaction date as the currency effective date, based on the Currency Conversion Date option that is specified on the Installation Options - Contracts page.

  • Billing-related transactions, the system uses the invoice date as the currency effective date.