Indirect burdens

Use Indirect burden codes to create indirect expenses for administration and overhead fees based on project direct costs.

If you use front end split functionality, then generate front end split distributions after posting to the global ledger and before indirect burdens are generated. Use finance dimension 2 to generate indirect burdens and journalize indirect burdens from the originating GLTransactionDetail.

General ledger transactions are the driver and the source for selecting expenditure transactions. The general ledger transaction is queried by the posting date and the project. Expense transactions are skipped in certain circumstances and no indication is displayed if a transaction is skipped. This list shows the circumstances in which expense transactions are skipped:

  • The dates of the originating expense are not valid for the posting project
  • The transaction is not posted
  • The transaction is not a part of the selection group for the indirect burden code
  • The system code is PS

Each GLTransactionDetail is read, verified, and summarized to that record. This list contains information that is verified:

  • The Indirect Burden field to verify that it is unprocessed..
  • The general ledger transaction contains a project, project amount, and valid date.
  • The To Accounting Entity field on the GLTransactionDetail record is compared to the run-time parameters.
  • The selection group is verified and the include or exclude field are verified for all active Project Indirect Burden records for the project.
  • Indirect burdens do not inherit the auto reversing status from the originating transactions. The auto reversing field is false for any transactions that are generated in Project Ledger.
  • If the project is part of a contract where front end split is enabled, the FD2 field must contain a value. The value must be included in the Selected Sources list if the Selected Sources Only flag is true.

The indirect burden amount is calculated and stored in a table that is sorted in ascending order by transaction date. Then it is sorted alphabetically by project order. All credit transactions are created first.

Indirect burdens for front end split with funded amount

The generation of indirect burden transactions can have limits, and amounts can be allocated to a different funding source or skipped. If the project is excluded from front end split, then the indirect burden is generated as usual.

Use this list for validation:

  1. The remaining FES amount on the project funding source is validated because the remaining amount must be greater than or equal to the calculated burden amount. If the remaining FES amount is greater than the burden amount, then the burden transaction is generated as usual.

    If the remaining FES amount is not greater than the burden amount, then a burden transaction is created for the remaining amount. The remainder of the calculated amount is reallocated to the next available funding source for the project contract. To find the next available funding source, view all active project funding source records in priority order. This includes where the remaining FES amount is greater than the remaining calculated amount of the burden.

  2. To qualify as an available funding source, the original expense transaction date must be within the date range of the finance dimension 2 record.
  3. If the indirect burden only applies to selected sources, then the Finance Dimension2 value must be included.
  4. If the Include Selected Projects Only field on the project funding source is true, then the project must be included.
  5. If the project funding source includes an FES eligibility group and FES eligibility group option, then the original expense transaction must meet that criteria.
  6. If no funding sources meet these conditions, then the remaining calculated burden amount is skipped. The Partial Status field is Limited on the Project Indirect Burden Transaction record for the partial amount.
  7. If an available next funding source is available, the Partial Status field is changed to Reallocated. A second Project Indirect Burden Transaction record is created for the excess amount. The OverrideFD2 field on that record is the value of the replacement funding source.

Alerts are displayed on the indirect burden records on the burden transaction list if the calculated burdens were limited:

  • Red alert: Burden amount is limited by a lack of available funds. The remainder cannot be overridden to a different funding source.
  • Yellow alert: The project funding is overridden to the next available funding source. The full amount is applied to a different funding source.
  • Green alert: A partial burden amount is reallocated to override the project funding. The limit is reached on the original funding source, but the remainder can be reallocated. Two lines are displayed for the transaction. The first line with the green alert and the second line with a yellow alert and an indication of where it was reallocated.

AP hold for billing

Indirect burdens that are created from transactions that are on AP hold for billing are also created with the AP Hold for Billing. After the AP transaction is paid and the Update AP Hold job is run, the original AP transaction is removed from AP hold for billing. The Indirect Burden remains on AP Hold for billing.

The Remove Burden AP Hold action is used to find ProjectIndirectBurdenTransaction records where this information is true:

  • The AP Paid field on the generated GLTransactionDetail field is Hold For Billing
  • The AP Paid field on the original expense is Eligible
  • The generated transaction is updated to Eligible

When the originator is held, the generated burden is skipped, regardless of its AP status.