Reimbursement Reclassification

Changes in reimbursement rules, for example, funding percentages, funding amounts, and cost eligibility rules, are classified into two categories:

• Retroactive Changes - Changes that require all previous activity against the program be reprocessed and adjusted to conform to the new funding rules

• Standard Changes - Changes that affect any new activity against the program.  Prior activity does not need to be adjusted

The Reclassification process supports retroactive changes to Reimbursement rules.

The Reclassification process modifies previously processed transactions and applies new reimbursement rules.  

Transactions processed against the old Funding Profile undergo a two-step process.  The two-step process will be performed for Cost Accounting programs, for example, grants and projects, that use Front-end Split for reimbursement, (transactions are split at the time of entry), as well as Back-end Split (transactions are not split until the reimbursement calculation process executes).  These steps are:

• Back Out

  The original reimbursement information will be backed out exactly as it was originally created, for example, using the 'old' funding rules.

• Re-Process

  After being backed out under the old rules, the transaction is then reprocessed using the 'new' funding rules.

Although the Reclassification process and the overall Reimbursement process perform similar activities, there is no processing duplication because the overall Reimbursement process will perform all additional processing for Reclassification such as adjustment of receivable amounts, adjustment of inter-governmental transfers, and adjustment of external interface files, for example, FHWA Electronic File.

The Cost Accounting reclassification functionality is divided internally into the following processes:

• Normal Reclassification

  During the life of a Cost Accounting entity (for example, project, grant, or job), the financial structure of the reimbursement funding and cost eligibility will require modification.  These modifications are due to a variety of factors to include: changes in the agreement amounts with an external funding source, changes in the eligibility of certain types of reimbursable expenditures, or setup errors of a cost accounting program.

• Automatic Overflow Recapture

  Changes to funding or eligibility may free up monies, which can be applied against transactions that were previously not eligible for reimbursement due to exceeding the funding limitations.  These amounts would have been applied to the “overflow” priority in a Funding Profile and, with the new funding rules established, may now be eligible for reimbursement.

It is important to note these two processes are independent of each other and must be executed separately.  In addition, when the reclassification process is executed in the normal reclassification mode or automatic overflow recapture mode, the reclassification process identifies the original transactions required to be reclassified and creates the appropriate adjusting transactions to affect the changes.  The reclassification process can be done against cash expenditures, charges, or internal transactions.

The Reclassification process uses three sources of information for transaction selection:

• Funding Split Log

  The Funding Split Log stores information about how a transaction was split, and provides the detail needed to back out the transaction’s original reimbursement postings. This information is available for each transaction that has been processed and selected by the Reimbursement Selection and Calculation process, regardless if the transaction was Front-end Split, or will be Back-end Split. It is updated and maintained during the Reimbursement Selection and Calculation process. The Funding Split Log information is vital since it provides the results of applying the old funding rules under which the transaction was originally processed. The information currently in the database for the Funding Profiles, Funding Priorities, and Funding Lines represent the new rules. The Funding Split Log also stores receivable transactions that have to be excluded from Reclassification.  These excluded records are included in the Funding Split Log for reporting purposes only.  Through a view of this Transaction Log, a user can identify specific transaction to include or exclude from the Reclassification process to allow more specific criteria. Hence the process will check for the Reclassification Exclude flag in the Funding Split Log set by the Front-end Split process. Transactions are selected from the Funding Split Log according to the parameters specified for the Reclassification process.  The Reclassification process will always reclassify the latest version of the document and if the latest version is cancelled the document will be ignored (after including it in the exception report).

• Reclassification Parameters

  The Reclassification Parameters page provides the ability to specify several Reclassification process options.  Please see "Reclassification Process Parameters" section for more information.

• Reclassification Exclusion Flag

  The Reclass Exclusion flag indicates that the Reclassification process should skip any transactions related to that Cost Accounting entity. This flag can be set at the Major Program, Program, Program Phase, and Program Period levels.  If the Reclassification Exclude flag is set at any level will apply to all levels.

The Reclassification process is a batch program, which modifies previously processed transactions and applies new reimbursement rules.  It should always run after the Reimbursement process.

The Reclassification process does not differentiate between Front-end Split (FES) and Back-end Split (BES) output.  The selection process creates a Charge transaction corresponding to the Back-end Split disbursement document to facilitate Front-end Split routine to split the back-end split records.

The Reclassification process corrects original disbursement postings because the disbursement amount is a key element for Front-end Split.  Therefore, for Front-end Split transactions, a Disbursement Correction Transaction will be used to back out the original postings, and to re-process the transaction.  It also creates modified versions of the reclassified documents be it an Automated Disbursement (AD), Manual Disbursement (MD), Charge Transaction (CH), Internal Exchange Transaction (IET), Internal Transaction Agreement (ITA), Payroll (PYRL) Transactions, Cash Receipts (CR) and Inventory transactions which impact cash (for example, OC, CI, TR, SN and IA documents).  The Reclassification process cannot create modified versions of any document with a document type of JV.  In addition, any other document type can have a cost accounting impact depending upon the posting code (for example, Fixed Asset Documents or ABS Documents) and thus are included in the Exception Report similar to how the current JVCs are posted to this report. These documents are all skipped and are written to an exception report explained below.

In addition, the Reclassification process creates reports containing failed transactions created by the process during document submission and removes failed modified documents version created from the system.  Documents with a document type of JV are also written to the exception report generated in the first job of the chain.  These documents need to be corrected manually via a JVC document to reclassify the charges.  Cancelled documents will be skipped.

The Reclassification process creates no new transactions for Front-end Split; instead a modified version of the transaction is created. Both the requirements of back out to zero and performing the new split are handled by the Front-end Split common routine when the modified document version is created and submitted by the process.

Over and above the calculation of the funding split for a transaction, all or part of the reimbursement request may be at various stages in the Reimbursement process.  These stages complicate the Reclassification process and must also be considered. Examples of these stages include:

• Reimbursement Suspense

  One or more providers may be held out of reimbursements due to reimbursements status.

• Reimbursement Frequency

  For a given transaction, certain providers may have had reimbursement request submitted, while other providers have not because of their invoicing cycle, for example, weekly vs. annual.

• CMIA Calculations

  All or part of a reimbursement request from a Federal Agency may not yet have been submitted due to Cash Management Improvement Act (CMIA) calculations. This means that any single transactions may have been partially requested for Federal reimbursement during the most recent cycle, while the remainder will be requested in subsequent reimbursements – possible in several more parts over several future Reimbursement runs.

• Reimbursement Reductions

  Expenditure credits and revenue credits net themselves against reimbursable amounts to reduce the requested amount.  If the credits exceed the amount that has been requested for reimbursement, the excess credit amount is not stored for consideration in future reimbursements.  Instead it will create negative Receivable transactions or negative internal documents for the credits.  Negative Receivable documents are created because Reclassification considers very old records as well, and the user may not be dealing with the customer any more or the profile might have changed in the meantime. Thus, waiting for reimbursable amount to net against may never happen.