Splitting

There are two ways to split costs incurred to a Major Program into the funding sources defined. One is real-time and the other is by later system processing. The real-time split is known as a Front End Split. Here the information entered on the accounting line of a transaction triggered the inference of a Funding Profile based on the reimbursement eligibility of the Program, Phase, Program Period, Object, and Activity chart of account codes used (Note: all are not required to be used). The information at the accounting line is then augmented by setup on the Funding Lines inferred as part of a system analysis of setup on the reimbursement budget structure defined to the Major Program. The other type of split – Back End Split – uses all the same setup but is not generated at the posting lines of the original transaction but with a separate Charge transaction created by the Reimbursement Selection system process.

A primary difference between front end and back end splitting is when and how the different spending budget structures are updated. With front end split, the spending budgets of the various funding sources recorded after chart of account augmentation based on the Funding Line setup for the Major Program are updated in real-time. Back end splits occur during regularly scheduled system processing to generate Charge transactions, which do not book expenditures to the various Funding Lines, but book a non-financial type charge instead. With this method, the only spending budget line updated was that of the single set of accounting line chart of accounts. If selected for an internal reimbursement, then there can be an expenditure credit or revenue for the Department of the Major Program in conjunction with an expenditure for the internal funding source.

Please note that although splitting tends to mean a 1:n relationship, it can also be a 1:1 relationship if a grant is 100% reimbursable by the grantor or a project is funded 100% by an internal or external source. As the Reimbursement section also mentions, reimbursement is not possible without a split.

In addition to splitting costs according to the reimbursement budget structure, there is an additional split that can occur based on Budget Fiscal Year using a spending or appropriation type of budget structure. This feature is known as Budget Fiscal Year Front End Split (BFY FES). This split is used when older funding should be consumed before newer funding (FIFO). The Use FIFO for Posting Line BFY indication must be set to true for a given Funding Line to use this feature.

The BFY FES functionality is best expressed in a simple example before looking at the various components and process flow. Assume that Program PROJ01 is funded from three Appropriations:

25% of the work is funded by Appropriation CP01 – a Capital (Continuing) Appropriation. Assume that the BFY being spent from is 2012 at the time of this example.
25% is coming from a second Capital Appropriation CP02, which is spending BFY 2011 at the time of this example.
50% of the work is funded by Appropriation OP06 – an Operating Appropriation. Assume that spending from this Appropriation is current BFY, and the current BFY is 2014.
Assume that the CP01 line only had $1K available in 2012, $0K available in 2013, and $100K available in 2014.

The three Appropriations would be defined on three Funding Lines within a Funding Profile/ Funding Priority for the Project’s Major Program. The Front-End Split fields for each line would show the Appropriation that should be recorded. The Funding Lines that hit CP01 and CP02 would have the Use FIFO for Posting Line BFY indication is true. The Funding Line that hits OP06 would not have the indication.

Now money is spent for the project (e.g. contractor costs). The payment Accounting Line points to the project, and invokes the Front-End Split. For space, only a limited number of COA are shown.

Accounting Line

Event Type	BFY	FY	APD	Dept	Fund	Appr	Program	Dollar Amount
AP01	2014	2014	5	25	1100	OP06*	PROJ01*	$12,000

*The Appropriation on the accounting line could have been any value and did not have to be OP06 for this split example.

Posting Lines

PL	BFY	FY	APD	Dept	Fund	Appr	Program	Funding Line	Posting Amount
1	2012	2014	5	25	1100	CP01	PROJ01	1	$1,000
2	2014	2014	5	25	1100	CP01	PROJ01	1	$2,000
3	2011	2014	5	25	1100	CP02	PROJ01	2	$3,000
4	2014	2014	5	25	1100	OP06	PROJ01	3	$6,000

Note that the Appropriation from the Accounting Line was overlaid on the Posting Lines based on Funding Line setup but also the BFY was set on posting lines 1, 2 and 3 by the BFY FES logic. Line 2 just happens to have the current year at the time of this scenario because the BFY FES logic applied only $1000 to 2012 (all the available amount according to the control ID), could not apply any to 2013 because nothing was available, and finally applied the remainder for that Funding Line to the current BFY of 2014.

When there is a spending credit being applied because of a credit memo or other similar transaction, the BFY FES logic does not ‘walk the credit forward’ but rather applies it all in the earliest BFY found that is active. Should the credit be applied differently, the Cost Accounting Journal Voucher (JVC) has to be used.

This active budget line concept is important in the management of continuing budget lines. Once funding has been exhausted in a BFY and no further activity should occur against that BFY, the budget line should be deactivated with a budget transaction. Failure to do so could result in the BFY being re-opened for further activity.

BFY FES can use the Start and End Dates found on budget lines. The Record Date of a transaction being processed is compared to any Start or End Date specified for a budget line read in the process. If equal to either date or between them (note either could be blank), then the process will look to see if the budget line is active. If so, the feature considers the budget line. If not active, the feature skips the record.

There are several setup considerations when using the BFY FES feature:

There has to be a BFY Staging Profile that has states that extend further out into where FY > BFY as many postings from this feature will be of that type. The BFY=FY rule that many apply to most activity will only exist is a subset of cases with this feature.
Cross year payment logic cannot be used so that the Spending BFY Stage Definition page always has Not Applicable for the Accounts Payable Period field.
Automated Accrual feature cannot be used, the ACCA and ACLA transactions, as those transactions have conflicting logic to set the BFY at the posting line level. If this accrual feature is desired for the non-continuing appropriations, the continuing ones should be excluded with the Automated Accrual / Accrual Clearing Exclusions (ACRE) page.
Manual Accrual transactions (ACC and ACL) cannot be used with any event types that belong to the ACC and ACL event categories because conflicting logic exists in those to set the BFY at the posting line.
When entering vendor refund receivables on the Receivable (RE) transaction, the AR31 event type for that purpose should be used and not the AR30 event type. The former does not have an expense budget impact where the later does. In the event that the Application Parameter for AR Reference Option is set to 3, there would be conflicting logic to set the BFY at the posting line.
When rolling open encumbrances and pre-encumbrances, the Parameters for Roll Process (RLPA) entry used should exclude all continuing appropriations.
The automatic budget line generation feature on the Required Budget (REQBUD) page should not be turned on for the budget structure that controls BFY FES as the BFY FES logic needs to budget lines to exist prior to transaction validation.
BFY FES logic assumes that the same Appropriation (and other budgeted COA defined for a Funding Line) be used across years and mean the same each year. If the budgeted COA change then there has to be a good deal of manual interaction with Funding Line setup as older budget lines are ‘used up.’
The BFY FES Control ID cannot be one that has a pending budget amount defined directly in the control formula. The control cannot have a < or > operand. The control can only have budget amounts in either the left or right-hand side field so that the other is zero.
Finally, the amounts in the budget control (directly or indirectly from a calculated amount) all have to exist on the BFY FES Budget Structure.

Besides the primary setup mentioned above, there are a number of other configurations used in splitting:

Front End Split Requirements
Application Parameters

Perform BFY Logic in FES (BFY_FES) – Turns on or off BFY FES.
BFY FES Budget Structure (BFY_FES_STRU_ID) – Defines the spending or appropriation budget structure used for BFY FES.
BFY FES Budget Level (BFY_FES_LVL_ID) – Defines the budget level within the BFY FES budget structure.
BFY FES Budget Control ID (BFY_FES_CNST_ID) – Defines the budget control that is used to evaluate how much funding is available on a BFY FES budget line.
Reimbursement Budget Availability (REIM_BUD_AVAIL) – Defines the budget control that is used to evaluate how much funding is available on a reimbursement budget line. As delivered controls 13, 14, 29 and 41 are available. Controls that use a < or > are not allowed.
Reimbursement Budget Total Costs (REIM_BUD_TOT_COSTS) – Defines the budget amount(s) that represents the total amount of costs that can be applied to a reimbursement budget line. As delivered, the Awarded amount (21) is the only amount but Revenue Credits (28) can also be listed.