Projects, Grants, and Project Billing
This chapter discusses MARS project, grants, and project billing. It covers the following topics:
Project Billing's primary function is to establish grants or projects and the related budgets. "Project" is used in this chapter to describe both grants and projects. When a project is established, an indicator can be set to show what type of project it is (i.e., grant or project), but both are treated identically in MARS.
The user can group activities and expenditures by project and view them separately from appropriation and allotment budgets. Project Billing is capable of specifying the sources of funding for projects. These sources of funding are termed programs or providers. For reporting and billing/reimbursement purposes, the program/providers are grouped into four funding types: federal, state, bond and other. Each funding type has different processing requirements and billing restrictions.
Project Billing can associate a specific project, sub-project and phase with the program/providers and their contribution amounts. It can then bill each program and provider according to the billing and reimbursement criteria.
Federally-funded projects that fall under the Cash Management Improvement Act (CMIA) of 1990 can utilize Project Billing's Draw Process to stay CMIA-compliant. The Draw Process utilizes the Composite Clearance funding method, which must be accepted via a State-Treasury agreement between the State and the U.S. Department of Treasury.
Project Billing also provides the capability to automatically generate invoices to the Federal Highway Administration (FHWA) for Federal highway projects. The invoices are produced in electronic or printed format following the required FHWA format.
Project Billing tracks transactions processed against projects in the Project Ledger (PRJLED) and the Inception-to-Date Project Ledger (ITDPROJ). The Project Ledger is a detailed audit trail of all accounting transactions that contain valid project numbers for the current fiscal year. The Inception-to-Date Project Ledger carries the same information to cover the life span of all active projects. It is in the same format as the general ledger from MARS.
The project ledger contains all revenues, receipts, and direct costs related to projects. All accounting transactions recorded in the project ledger are also posted to the general ledger (GENLED). The accumulator bill file (BILLFILE) contains detail data for use by the Federal Highway Administration (FHWA) billing Process. This file is a subset of the project ledger.
The Billing Process updates three permanent files in which all the billable transactions are stored. These include FEDPERM, federal billing; TPPERM, third party billing; and BFPERM, bond fund billing. The Draw Process extracts records recorded against projects using CMIA-compliant funding methods and stores them in the CMIA ledger, PRJCMIA.
Finally, the Project Memo Ledger (PRJMEM) records memo transactions to facilitate ad hoc report generation. The Project Memo Ledger has the same record format as the project ledger. All project transactions, including Project/Grant Master (PJ), Project/Grant Participation (PZ), Project Charge (PX), and Project Memo (P3) transactions, are stored on PRJMEM.
Project Billing consists of the following tables and corresponding windows.
Project Billing includes several reports that exhibit different views of Project Billing. These reports are identified by a report ID. Project Billing reports are normally run monthly or semi-monthly, although they may also be run on request. You can obtain any of these reports by providing the report ID and Application Dates (LDAT) parameters to your system administrator. See the System Administration Guide for information on report parameters.
The various processes involved are identified with circled numbers in Figure 126 and are explained below:
- Transaction processing. Transactions, or documents, are entered by the user community to establish projects, project billing attributes, and to post expenditure and revenue transactions to those projects.
- Nightly Project Split. This component executes each night to copy project-oriented expenditure and revenue transactions to the Billing Accumulator File.
- Memo Billing. This process can be run any time to compute a billing cycle and related reports, based on the current Billing Accumulator File. No "final" processing is done (i.e. no tables are updated, no transactions are created, etc.), so this process can be run over and over again as adjustments are made to the billing parameters until the user is satisfied with the billing reports.
- Review Billing. This process is identical to the Memo Billing, except that any transactions added to the Billing Accumulator File since the last execution of Memo Billing will not be considered. This allows the user to continue to review and revise a billing over several days, without having to incorporate additional transactions picked up by the Nightly Project Split.
- Final Billing. Once the user is satisfied with the Memo/Review Billing, the Final Billing process is run. Permanent billing files, ledgers, and system-maintained tables are updated, draw calculations are performed by the Draw Process, billing and receipt transactions and summary reports are generated, and, if applicable, the FHWA billing file is produced.
- Figure 126
The following are terms used throughout this chapter.
Extended project accounting is used in MARS to plan and control project activity as budget and accounting documents are processed. The budget and accounting documents are associated with individual projects by an eight character project number. The Project number consists of a five character Project code, a two character Sub-Project code, and a one character Phase code. The user has the option to code the Project number directly on accounting documents or to have the system automatically infer it from a Job Number.
Since budgetary and accounting updates are completed online, the status of a project can be reviewed by the user at anytime through online windows or reports. In addition, given the online budget status windows, the user has the option to apply budgetary controls at the sub-project/phase level.
Within the Project Accounting module of MARS, projects are treated as unique entities apart from the organizational structure. Certain complex projects do not fit into an organization structure because of the necessity for project-specific detailed budgets, multiple funding sources, or, in the case of grants, the necessity for primary recipient/sub-recipient relationships. Project Billing provides the capability to accommodate such projects.
The extended project accounting capabilities of MARS provide a project planning and control structure that is available for online query and project reporting through Agency Project Inquiry (AGPR), Project Budget Line Inquiry (PRBL), and Entity-Wide Project Inquiry (ENPR).
As discussed in the section about Project Accounting, MARS provides a four-level hierarchical structure for project planning and accounting. The key component of this hierarchy is the Project Number . The Project Number is a five-character code which must be unique within an organization.
MARS also provides the means to break a project into sub-projects. Sub-Projects, in terms of number and description, are defined by agency. In order to facilitate processing, however, MARS requires that every project have at least one sub-project.
Projects and sub-projects, in turn, can be broken down into phases. Phases represent distinct stages in the project life-cycle. For construction projects, they can be fairly well defined such as site acquisition, preconstruction engineering, site preparation, construction, etc. Due to the limited number of possible phase codes, only one phase code is usually set aside for use with grants.
Project numbers must be defined within a single agency. MARS also provides a higher level attribute to link together multiple projects for reporting purposes, called the Entity-Wide Project Number . Entity-Wide Project Number can be used, for example, with a block grant where multiple agencies within the government are earmarked as recipients of grant dollars. An Entity-Wide Project Number can also be used for a construction project where one agency constructs the building and another agency builds the adjacent parking lot. When this model is followed, the system will account for the separate use of project budget dollars by all agencies (within individual projects) as well as tie them together for central monitoring and reporting.
Figure 127 depicts a typical project hierarchy consisting of two projects under the same Responsible Agency and Entity-Wide Project Number. The first project has at least one sub-project/phase combination, while the second has at least six.
The Project/Grant Master (PJ) document is provided for the user to enter project and budgetary information, including Federal identifiers and codes for Federally-funded grants and projects. This Federal information includes descriptive information such as grantor, start and end dates, and data for the Cash Management Improvement Act (CMIA) of 1990.
The project budget amount is defined for both the project as a whole and for each sub-project/phase within a project. The budget amount can be used to control the acceptance of encumbrance, expenditure, expense, and project charge documents coded with the project, sub-project/phase. Available funds checks for project spending are performed at the sub-project/phase line level. Documents that exceed available funds are rejected or accepted based on the control level assigned.
The budget amount can be increased or decreased anytime during the life of the project. The sum of the budgets for all the project, sub-project and phases must equal the total project budget. The budget for each sub-project and phase must in turn equal the total funding agreement amount for that segment of the project.
Project Billing records the total amount authorized to be spent from federal, state, and bond funding sources for each fiscal year. It also allows for additional funding sources such as local and private parties to participate in financing projects. These local and private contributions in addition to the federal, state and bond funding amounts constitute the total budget for projects undertaken in a fiscal year. Project Billing provides the mechanism to obligate these funds to each project, sub-project and phase established in the system.
Federally-funded grants and projects are generally associated with a letter of credit. MARS allows users to specify the amount of a letter of credit, assign an identifier to that letter of credit, and associate three-character Funding Source codes with the letter of credit to specify the sources of Federal grant or project funds. These Funding Source codes are established with one of four Funding Types :
- Federal (used for Federal programs),
- State (used for providers of matching funds, including both General funds and Agency Revenue funds),
- Bond (used for bond funds), or
- Other (used for local and private parties who will actually be billed to reimburse project expenditures).
Funding Sources identified as Federal must be associated with an 11-character Letter of Credit Identifier , while those identified as State, Bond, or Other are not associated with a letter of credit. Funding Source codes may be used to identify the Federal or State agency providing the funds (for instance, FHW is used as the Funding Source code for all monies from the Federal Highway Administration).
These sources of funding are broken down into programs or providers, and are identified by an 11-character Program/Provider code. For reporting and billing/reimbursement purposes, the Program/Providers are also grouped into the four Funding Types: Federal, State, Bond and Other. Each funding type has different processing requirements and billing restrictions.
Project Billing can associate a specific Project, Sub-Project and Phase with the Program/Providers and their contribution amounts. It can then bill each Program and Provider according to the billing and reimbursement criteria. Program/Provider codes may be used to identify money from a Funding Source that is identified for a specific program (for instance, the three-digit Federal appropriation codes from the FHWA are used as the Program/Providers for Federal highway projects).
Funds are obligated at the Program/Provider level, and Program/Provider codes essentially identify a breakdown of the funding from each of the Funding Sources. Thus the authorized ceiling amount for each funding source is specified as the sum of authorized amounts for the Program/Providers associated with that Funding Source. Figure 128 depicts a sample funding structure using these elements.
Project Billing extracts daily from MARS all billable documents coded with a project, sub-project and phase. It takes as additional input, non-accounting project charge documents also coded with the project number. Based on Activity and Object of expenditure eligibility for sub-project/phase, the billable amount is split among the funding sources. For every sub-project and phase, a priority can be assigned to each program and provider to control the sequence in which they are billed. Project Billing then bills the program/providers according to their eligibility to fund objects and activities, their percentage of participation in the sub-project/phase, and their billing priority.
Major Functions of Extended Project Accounting
The major functions of the extended project accounting feature include:
- Establishment of projects and budgets
- Aggregation of all project-related data
- Funds control against project budgets
- Multi-year inception to date budgeting
Establishment of Projects and Budgets
The Project/Grant Master (PJ) document is used to define valid Project, Sub-Project and Phase codes. It establishes budgets at the project and sub-project/phase level, provides control information such as the status of the project and sub-project/phases, and defines the date when documents may be charged to a sub-project/phase. Projects may be added or dates or statuses changed by the submission of additional project master documents. Once a sub-project/phase has been established, the system is ready to begin accepting accounting documents entered with the project information.
Aggregation of All Project-Related Data
One of the primary functions of extended project accounting is to identify and collect all project-related financial and descriptive information. All descriptive and financial information pertaining to a project is handled apart from the organization structure and is maintained in the various project tables. Documents entered with project numbers are extracted from the memo and general ledgers and collected in both the project ledger and the billing accumulator file. Extended Project Accounting also creates various project tables to provide alternate views of the project data. The project information is available to support a wide variety of inquiry and reporting options. Budget versus actual inquiries exist at each of the following levels:
- Sub-Project/Phase detail on Project Budget Line Inquiry (1 of 2) (PRBL)
- Project within Agency detail on Agency Project Inquiry (AGPR)
- Entity-wide project detail on Entity-Wide Project Inquiry (ENPR)
- Agency and Fund Type by Revenue Source detail within Agency, Project and Fund Type on Agency Project Revenue Budget Inquiry (AGPB)
Financial reports can also be produced on any combination of project attributes needed to support project reporting requirements.
Funds Control against Project Budgets
Extended Project Accounting also provides the capability to reject spending documents which exceed project budgeted amounts. Available fund checks for project spending are performed at the sub-project/phase line level. Documents that exceed available funds can be rejected or a warning message can be issued.
Multi-Year Inception to Date Budgeting
Frequently, projects are not bound by the same fiscal year as the organization and often extend over more than one year. The system addresses this issue by specifically providing for a "fiscal year" which is independent of the organization's fiscal year. This "fiscal year" is treated separately at annual closing, which is therefore appropriate for controlling the processing of projects which span more than one fiscal year on an inception-to-date basis. This allows for the preparation of project lifetime budgets. Thus, budgets can be established which are not closed at the end of the organization's fiscal year, but rather, continue into the new year with remaining balances and expended amounts intact.
Because MARS retains the actual date associated with each transaction, project reports rather than organizational fiscal year reports can be produced by multi-year projects.
Project documents are subject to four types of controls:
Budgeting and referenced document controls that apply to general accounting documents remain in effect for accounting documents that contain project numbers, such as payment vouchers, journal vouchers, and cash receipts. These types of controls are discussed in other chapters of this manual.
Batch controls also apply to the project charge document when batching is used. The same principles described for the accounting modules apply.
All project documents are subject to project controls. First, the project is set up on the project tables with a project master document before any accounting documents containing the project number are accepted by MARS. If the Revenue Budget Editing indicator is set to Yes on the project master document, a Project Management Budget (PB) document is entered. Next, the documents must postdate the starting date of the project and, with the exception of revenues and receipts, must be dated earlier than the expiration date of the project. In addition, if project budget control has been established for the project (using the Project/Grant Master (PJ) document), expenditures may not exceed the budget amounts recorded for the sub-project/phase on Project Budget Line Inquiry (1 of 2) (PRBL).
Key Concepts of Project Billing
The major functions of Project Billing include:
- Establishment of project contributors
- Automation of project billing/reimbursement from participating funding sources
- Collection of CMIA-specific data
- Automation of Federal draws
Establishment of Project Contributors
The Project/Grant Participation (PZ) document is used to associate the valid program/providers and their contribution amounts with each project, sub-project/phase. It has the capability to assign a priority to each program/provider to control the sequence in which they are billed. The Project/Grant Participation (PZ) document also defines the invoicing cycle (or CMIA-compliant funding method) for each program/provider. This information is used to bill and obtain reimbursement from the funding sources.
Automation of Project Billing/Reimbursement from
Participating Funding Sources
Once the projects and funding sources are set up, Project Billing is ready to initiate the billing process. Expense and charge transactions are taken from the billing accumulator file and automatically split among the participating funding sources. The billing sequence and amount is determined by the priority assigned to each program/provider and its contribution percentage. The amount to be billed is based on activity and object eligibility. The periodicity of billing is based on the invoicing cycle entered in the Project/Grant Participation (PZ). Before the actual billing documents and fund transfers are effected, the system produces trial billing reports for management approval.
Collection of CMIA-Specific Information
MARS integrates the ability to comply with the provisions of the Cash Management Improvement Act (CMIA). Projects are identified as CMIA-eligible when they are entered on the Project/Grant Master (PJ) document. The federally funded percentage of each sub-project/phase and the method used by the State to request Federal funds are determined on the Project/Grant Participation (PZ) document by selecting either Composite Clearance or Zero Balance as the Billing Cycle . Expenses related to CMIA-eligible projects are posted to the Project Billing CMIA Ledger (PRJCMIA) each time the Draw Process is run.
After CMIA-related expenses are accrued, States must issue timely requests to the Federal Government for monies to cover those expense and deposit those monies into the State's account. For projects using Composite Clearance as the Billing Cycle, MARS calculates these draw requests and creates draw request documents automatically. Each week, after Project Billing splits the expense and charge transactions, the Draw Process picks up any Composite Clearance data on the resulting files for Federal providers, calculates the draw date and amount, and generates the transactions to record the draw request and receipt. The Project Billing Draw Request (PBDQ) window provides the opportunity for monitoring the Draw Process.
Several steps are required to implement Extended Project Accounting and Project Billing:
- Extended Project Accounting
- Set Control Options
- Establish Project Structures
- Process Accounting Documents
- Project Billing
- Establish Funding Structures
- Establish Project Participation
- Set Billing and Draw Parameters
The following sections describe each step in detail. Additional information is provided in the User's Reference .
Setting Up Extended Project Accounting
In order to implement extended project accounting you must first set certain indicators on the following MARS tables:
- System Control Options (SOP2). The Project Accounting option on System Control Options (SOP2) must be set to Yes .
- Fund Agency Index (FGY2). The Job/Project Precedence field must be set to indicate whether the Job Number field on accounting documents are validated first as a job or as a project. Since either a job number or a project number can be entered in the Job Number field, this indicator is used to tell the system which table to validate the code against first. Select Validate as Job First to have this field validated first as a job and, if not a job, then as a project. Select Validate as Project First to have this field validated first as a project and, if not a project, then as a job.
- If Project/Sub-Project/Phase Required is selected on the Fund (FUN2) table, then Validate as Job First must be selected for Job/Project Precedence on Fund Agency (FGY2).
After the appropriate indicators in MARS have been set, you must enter a Project/Grant Master (PJ) document. The Project/Grant Master (PJ) document establishes new projects and allows the user to change basic information on existing projects.
Prior to processing a project master document, the user must first establish valid Phase codes in Project Phase (PRPH) and valid Drawdown Group codes in Project Billing Drawdown Group (PBGR).
When the PJ document is processed, the valid Project codes are established, and Agency/Project Inquiry (AGPR), Project Budget Line Inquiry (1 of 2) (PRBL), Sub-Project Description (SPDT), Entity-Wide Project (ENPR), and Project Fiscal Year Inquiry (PFYT) are updated with the project information entered on the Project/Grant Master (PJ) document.
Before accounting documents may be processed using a project number, valid accounting codes must be associated with the project number on Project Appropriation (PAPR). Refer to the User's Reference for a description of this window.
When an accounting document is entered with a code in the Job Number field, the system uses the Job/Project Precedence indicator (on FGY2) for the fund/agency combination to control validation and updates. If both Job Costing and Project Accounting are installed (selected on SOP2), you can set the Job/Project Precedence indicator on Fund Agency (FGY2). If only Project Accounting is installed, the system will first check to see if the data in the Job Number field is a project number.
Set the Job/Project Precedence indicator on Fund Agency (FGY2) to Validated as Project First and enter the project number into the Job Number field on accounting documents. The system validates this as a project and the project tables are updated. In addition to updating the project tables, the job number associated with the project is inferred and updated.
Set the Job/Project Precedence indicator on Fund Agency (FGY2) to Validated as Job First and enter the job number into the Job Number field on accounting documents. The system validates this as a job and the Job Inquiry windows are updated. In addition to updating the Job Inquiry windows, the project number associated with the job is inferred and updated.
Note that if Project/Sub-Project/Phase Required is selected on the Fund (FUN2) table for a particular fund, all Fund Agency (FGY2) entries for that fund must be made with the Job/Project Precedence indicator set to Validated as Job First .
Before the funding participants for Projects/Sub-Projects/Phases can be established, you must set up the funding data structures previously described. First, determine the Funding Source codes and Letter of Credit Identifiers to use for any Federal sources of funding. Enter the Letter of Credit Identifiers on Letter of Credit Summary (LOCS), and associate the Federal Funding Sources with the Letter of Credit Identifiers on Project Billing Funding Source (PBFS). Similarly, determine the Funding Source codes for State, Bond, and Other sources of funding and enter them on Project Billing Funding Source (PBFS).
For each Federal Funding Source, determine any Program/Provider codes to use when establishing funding participation for projects and the amounts authorized for each Program/Provider. Make entries in Federal Appropriation (FAPP) and Customer (CUST, by processing a Customer (CU) document) for each Program/Provider code. Make an entry in Federal Obligation Budget Ledger (FOBL) for each Federal Fiscal Year , Funding Source , and Program/Provider combination to specify that authorized amount (including any amount rolling over from a previous Federal Fiscal Year).
Similarly, for each State and Bond Funding Source, determine any Program/Provider codes and the amounts authorized for each one. Make entries in State Program (SPRG) and Customer (CUST, but processing a Customer (CU) document) for each Program/Provider code. Make an entry in State Obligation (SOBL) for each State Fiscal Year , Funding Source , and Program/Provider combination to specify that authorized amount (including any rollover from a previous State Fiscal Year).
For each Other Funding Source, determine any Program/Provider codes and make entries in Customer (CUST, by processing a Customer (CU) document).
Finally, make entries in Program/Provider (PGPV) to specify valid Program/Provider and Funding Source combinations. For State, Bond, and Other Program/Providers, specify the accounting codes to be used on generated billing documents. (Federal billing and draw documents are generated using codes from the expenditure documents being reimbursed, so no accounting codes are specified for them on Program/Provider (PGPV).) Each of these tables is described in detail in the User's Reference .
Establish Project Participation
After the Funding Sources and Program/Providers are set up in MARS, you must enter Project/Grant Participation (PZ) documents for each Project/Sub-Project/Phase that will utilize obligation ceilings or participate in the billing/draw process. The Project/Grant Participation (PZ) document is used to associate the valid Program/Provider codes and their contribution amounts with each Project/Sub-Project/Phase. It has the capability to assign a priority to each program/provider to control the sequence in which they are billed. The Project/Grant Participation (PZ) document also defines the invoicing cycle (or CMIA-compliant funding method) for each program/provider. This information is used to bill and obtain reimbursement from the funding sources.
Prior to processing a Project/Grant Participation (PZ) document, you must establish valid Sponsor codes in Sponsor (SPSR) and, if desired, valid Obligation Programs for Federal Programs in Obligation Authority Status (OBAS). Refer to the User's Reference for more information.
Acceptance of the Project/Grant Participation (PZ) document results in entries being made in Funding Source Summary Ledger (FSSL), Project Funding Source (PFST), Obligation Authority Status (OBAS, if Obligation Programs are specified), Federal Obligation Ledger (FOBL), State Obligation (SOBL), and Project Budget Line Inquiry (PRBL).
Set Billing and Draw Parameters
Prior to running the batch billing and draw process, entries must be made in the following tables:
- Project Billing Parameter (PBPT). An entry must be made for any currently active state Fiscal Year. This will ensure that when the Draw Process executes, it can locate the correct parameters and update dates to indicate when it was executed.
- Composite Clearance (CCLR). Day of Clearance information must be entered for each agency from the CMIA State-Treasury Agreement onto the Composite Clearance (CCLR) table for any currently active state Fiscal Year. This will ensure that when the Draw Process calculates the drawdown date, it will obtain the correct Day of Clearance from this table.
- Suspense Reason Code (REAS) - if entries will be made in the Transaction Exception (TREX) table to make exceptions, valid reasons for those exceptions must be entered in Suspense Reason Code (REAS).
Changing the Status of a Project
As previously mentioned, a user processes a Project/Grant (PJ) document when setting up a new project or grant. There are two Status fields on this document: one in the header and the other in the line. While the status value in the header is used for inquiries and reports, it is the status flag in the line that actually controls whether users can spend against a sub-project/phase.
Status in the header of the Project/Grant Master (PJ) document indicates the current standing of the entire project. However, no system logic is affected by the value of the status. Valid status codes must be set up on the Project Status Code (PRST) table. Once the Project/Grant Master (PJ) document is processed, the value entered in the status field will be automatically validated against the Project Status Code (PRST) table.
Status in the line of the Project/Grant Master (PJ) document applies only to the sub-project/phase on that line. Valid values are No Change , Open , and Closed . The status of the sub-project/phase can be selected as Open or Closed on a new transaction while the No Change status may be entered on a modification transaction if no change to the status is desired.
A project is closed by closing all of the sub-projects/phases that are associated with it. This is done by changing the status of each sub-project/project from Open to Closed in the line of the Project/Grant Master (PJ) document. Status in the header of the Project/Grant Master (PJ) should be set to a value indicating the reason that all sub-projects/phases have been closed (e.g., A = Adjustment Period or C = Project Closed).
Additionally, an entry may be made in the Project Grant Text (PGT2) table to further explain the change in status. This inquiry table provides explanations for modifications and updates made throughout the history of the project. All projects with text entered on Project/Grant (PGT2) table are listed on the Project/Grant Text Index (PGTX).
Status Values for Program/Providers on the Project Funding Source Inquiry (PFST)
When a Project Participation (PZ) document is accepted, records are automatically added to the Project Funding Source Inquiry (PFST) and Project Summary (PSUM) tables. Likewise, records on these table are updated when a Project Participation (PZ) transaction is modified. Status values for Program/Provider codes change as PZ documents are processed. The following bullets describe the various changes in Program/Provider status values:
- A user sets up a project/sub-project/phase by processing a Project/Grant Master (PJ) document. Funding is established by processing a Project/Grant Participation (PZ) document. Once the Project/Grant Participation (PZ) document is accepted, records are created for Program/Provider on the Project Funding Source Inquiry (PFST) table with status Active .
- If the funding has to be changed to use a new Program/Provider code, the user processes a Project/Grant Participation (PZ) document to modify the original Project/Grant Participation setup. The user enters the new setup without entering records for any Program/Providers no longer providing funding. On the Project Funding Source Inquiry (PFST) table, the record for the original Program/Provider is changed to status Inactive , whereas the new record for the new Program/Provider is created with status Active .
- In the situation where more funding is received for the same grant/project, the user processes a Project/Grant Master (PJ) document to modify the original amount of the budget for the project/sub-project/phase to reflect the correct funding. From the time that the PJ document is accepted until a PZ document is processed to make the corresponding change in funding, all records for the sub-project/phase on the Project Funding Source Inquiry (PFST) table that had status Active are changed to Deactivated . All expenditures against the project/sub-project/phase will be unbilled the next time the project billing cycle is run.
- To correct the funding, the user can process a modification Project/Grant Participation (PZ) document to increase the funding for the project/sub-project/phase. Consequently, the records on the Project Funding Source Inquiry (PFST) table for the Program/Provider on the modified Project/Grant Participation (PZ) document are changed to reflect the updated funding amount with status Active .
There are four main processes used to handle project-related data:
- Processing project management transactions
- Processing accounting transactions
- Processing project participation transactions
- Processing project charge and project memo transactions
- Processing billing of the funding sources
To support these processes, Project Billing uses the Project/Grant Master (PJ) document and the Project/Grant Participation (PZ) document. Each of the processes and the corresponding documents are explained in the section that follows.
The Project/Grant Master (PJ) document must be processed before any other project-related document can be processed.
Project/Grant Master (PJ) Document
The Project/Grant Master (PJ) document allows the user to establish project numbers and project budgets. Once valid projects, sub-projects, and phases are established, the system is ready to accept or reject the other documents coded with a project, sub-project, and phase. Funding sources can only be established for valid projects, sub-projects, and phases. The billing process needs all the project, expense and funding information to produce bills for reimbursement transfer documents.
The Project/Grant Master (PJ) document is used to establish a new project, complete with budgetary and descriptive information, or to change the basic information pertaining to an existing project. A Project/Grant Master (PJ) document must be accepted by the system before any accounting documents that reference that project will be accepted. The following information is entered on the Project/Grant Master (PJ) document:
- Whether the project represents a part of a Project or a Grant ,
- The agency responsible for project reporting in Responsible Agency , and the agency who will expend against the project in Agency
- Valid Project , Sub-Project and Phase codes
- Project descriptive information such as start and end dates, description, project manager, etc. and whether or not the project is CMIA-eligible
- Project budgets for both the entire project and for each sub-project/phase
- A Funds Edit control option indicating whether funds control outside of the normal appropriation control will be placed on the project/sub-project/phase
- The Status for the project and each sub-project/phase
- The Authorization Date when cost accumulation may begin for a project/sub-project and phase
The Project/Grant Master (PJ) document results in entries being made in Agency Project Inquiry (AGPR), Project Budget Line Inquiry (PRBL), Sub-Project Description (SPDT), Project Fiscal Year Inquiry (PFYT) and, if an entity-wide project number is specified, Entity-Wide Project Inquiry (ENPR).
The Project/Grant Master (PJ) documents are stored on the Project Memo Ledger (PRJMEM) to facilitate ad hoc report generation. The Project Memo Ledger has the same record format as the project ledger.
A project is established in the system by entering a five-character project number, unique within the agency. The overall project budget is established by entering the amount to be received from the various funding sources for the project as a whole. The Sub-Project and Phase codes for the project are entered as line items and have their own budgeted amounts which, added together, must equal the total project budget amount.
The Funds Edit control option, also present at the sub-project/phase line level, is used to indicate the degree of control the user desires in monitoring project spending. If Funds Edit is set to Yes , the system will check for available project funds before expenditure documents can be accepted. If the spending document causes the project budget to be exceeded, the document will be rejected. If Funds Edit is set to No , the system will still check available funds, but will only issue a warning message to the user if the project budget will be exceeded.
In order to be able to charge against a project, the referenced sub-project/phase must have a Status of Open . As particular phases of a project are completed or suspended, the user will want to close or suspend the sub-project/phase line to prevent additional expenditures and receipts from erroneously being recorded.
Project/Grant Master (PJ) Document (General View)
For Federally-funded projects, additional information must be captured, such as Federal identification numbers and agreement information. In particular, the Federal Catalog Number (i.e., CFDA Number) must be entered. Note that the first two characters of the Federal Catalog Number identify the Federal agency providing funding for the project, and must be a valid Federal Agency code on the Federal Agency (FEAG) table. If a Revenue Source code is entered, it will be used for Federal draws and billings instead of the default Revenue Source code on the Project Billing Parameters (PBPT) window.
Project/Grant Master (PJ) Document (Federal View)
The Project/Grant Master (PJ) document is also used to modify existing project data. In addition to changing non-key project information such as the description or project manager, a modification document can be used to include a project in an government-wide project or to transfer a project budget from one government-wide project to another. If this is done, all accounting actual data will also be transferred.
Key information, including agency and project number, must be entered on the document to provide the system with the means for locating the project to be modified. Then, only the information to be changed need be entered, as described below:
- Data fields which are input will overlay existing data.
- Data fields which are left blank will remain as they exist on the database.
- Data fields entered with an asterisk (*) will result in that field on the database being set to spaces.
The Project Budget (PB) document enables the user to budget and record the collection of revenue by funding type and revenue source. If the Revenue Budget Editing indicator on a project master document is set to Yes , a project budget document must be processed. A warning is issued when the project master (PJ) document is processed reminding the user to code the project budget (PB) document. This document is not currently used in MARS.
The project budget document establishes revenue budgets by funding type and revenue source for each project. Enter the Agency, Project Number, and the Total Revenue Budget Amount for the project in the header. Revenue Source Description and Budget Amount are entered on the document lines. The line totals are accumulated and compared to the total revenue budget. If they are not equal, the document is rejected. The revenue source is validated against Revenue Source (RSRC) and the funding type is inferred. As the revenue budgets are entered, the funding type totals are validated against the appropriate total on Agency/Project Inquiry (AGPR).
Revenue budgets may be modified as often as necessary. However, in order to increase or decrease the project revenue budgets (project budget document) the Total Project Budget (project master document) must be increased or decreased first. See Modifying a Project for more information on processing a modified transaction.
Figure 131 shows the sample Project Management Budget (PB) documents.
The Project Budget (PB) Document
The second important group of processes are the general accounting documents which record direct expenditures and receipts against a project (including requisitions, purchase orders, receivables, payment vouchers, journal vouchers and cash receipts).
Before accounting documents may be processed using a project number, valid accounting codes must be associated with the project number on Project Appropriation (PAPR). Refer to the User's Reference for a description of this table.
Each accounting document is edited by the appropriate system editor and, once validated, is posted to the general ledger. In addition, the other applicable ledger and tables such as open payment voucher ledger and the agency project table are updated. Indirect (non-accounting) expenditures entered on project documents are also edited, and once validated, are posted to the memo ledger.
The other applicable tables such as the agency project and the project fiscal year table are also updated. Additionally, the general and memo ledgers are read during nightly processing and all the project related documents are posted to the project ledger to facilitate project reporting requirements.
Project Participation Documents
The third process involves the Project/Grant Participation (PZ) document; it establishes the participating federal, state, bond programs and other financial providers for the sub-project/phases set up in the system. The documents are edited and, once validated, are posted to the project memo ledger. Acceptance of a Project/Grant Participation (PZ) document sets a flag record on Project Budget Line that allows the billing to proceed for the specified project/sub-project/phase.
Project/Grant Participation (PZ) Document
The Project/Grant Participation Document
The Project/Grant Participation (PZ) document is used to establish the financial participants in a project/sub-project/phase. For each project/sub-project/phase, the Project/Grant Participation (PZ) specifies the participating programs and providers (programs for federal, state and bond funding types and providers for the "other" funding type), and their agreement amounts. The sum of the agreement amounts across all the program/providers must equal the budget established for the project/sub-project/phase in the Project/Grant Master (PJ) document. The Project/Grant Participation (PZ) document can be modified at any time. New program/providers can be added, old program/providers removed or their agreement amounts modified.
The following information is defined on the Project/Grant Participation (PZ) document:
- The Program/Providers associated with a sub-project/phase
- The amount each program/provider has agreed to contribute to the project
- The Agreement Date
- The Billing Priority for each program/provider
- The Obligation Program code for the federal programs within FHWA. This is the code that groups the FHWA federal programs into entities for which the obligation authority ceilings are specified.
- The valid Billing Cycle for each program/provider. This may be a regular billing cycle such as Weekly , Monthly , or Annually ; or it may be a CMIA-compliant funding method such as Composite Clearance or Zero Balance .
Acceptance of the Project/Grant Participation (PZ) document results in entries being made in Funding Source Summary Ledger (FSSL), Project Funding Source (PFST), Obligation Authority Status (OBAS), Federal Obligation Ledger (FOBL), State Obligation (SOBL), and Project Budget Line Inquiry (PRBL).
The Project/Grant Participation (PZ) documents are stored on the project memo ledger to facilitate ad hoc report generation. The project memo ledger (PRJMEM) has the same record format as the project ledger.
Coding the Program/Provider Information
The Project/Grant Participation (PZ) document for a specific project, sub-project and phase combination is accepted only after it has been established by the Project/Grant Master (PJ) document. The first time a Project/Grant Participation (PZ) document is entered, the Action against each program/provider must be New . The total of all the agreement amounts in the Project/Grant Participation (PZ) document must equal the budgeted amount from the Project/Grant Master (PJ) document. When accepted, the Project/Grant Participation (PZ) processor switches the Expenditure Reimbursement indicator on Project Budget Line Inquiry (PRBL) to Participate . This will allow the billing process to bill the various program/providers.
If a Billing Priority is specified for one program/provider, it has to be specified for all of them. Enter I (ineligible) to indicate that the line amount is currently unfunded. The same priority can be assigned to more than one program/provider. The priority assigned determines the billing sequence. The program/providers with the highest priority (lowest number) will be billed first. When their total agreement amounts are completely exhausted, the program/providers with the next priority are billed.
The Obligation Program code is entered only for FHWA programs. Valid program values ( DIS (discount), SPC (special), or FRM (formula)) can only be entered on lines with a provider that is on Obligation Authority Status (OBAS). The same FHWA program can be entered more than once on the Project/Grant Participation (PZ) document, if the amounts being obligated to the project/sub-project/phase come from different obligation authority ceilings. This is done by entering the obligation program code that corresponds to the obligation authority.
Modifying the Project/Grant Participation (PZ) Document
The Project/Grant Participation (PZ) document is also used to modify a program/provider's agreement amount and to add or delete program/providers as contributors to the sub-project/phase. Each time a Project/Grant Participation (PZ) document is modified, all the original program/providers that are still participating in the sub-project and phase have to be re-entered with a Modification action. New program/providers are added with a New action. For a modified Project/Grant Participation (PZ) document to be accepted, the sum of the new agreement amounts must still equal the budgeted amount for the project/sub-project/phase.
This section discusses the following documents:
The Project Charge (PX) document is used to record indirect (non-accounting) charges against a project. Examples include an allocated charge for computer usage or a per hour charge for use of a vehicle. This information is posted to a memo ledger only and does not update the general accounting ledgers, but charges entered using a Project Charge document will be split and billed just like expenditures.
There are two different ways to enter a charge on this document. Both methods can be used on the same document. The two charging methods are:
- Computed Amount
- You can enter a charge class code from Charge Class (CHRG) and a unit quantity, such as number of hours, number of pages, etc.
- The system will infer the appropriate dollar rate from Charge Class (CHRG) and multiply the units you supply on the document by the inferred dollar rate to compute the chargeable amount.
- Entered Amount
- You can enter the exact amount that is to be charged against the grant directly in the amount column of the document. If you do this, you must also provide either an object code or a charge class code on the line.
- If a charge class code, units and an amount are entered, the entered amount will override the computed amount.
When Project Charge documents are accepted by the system, the full charge amount will update the Agency Project Inquiry (AGPR), the Project Budget Line Inquiry (PRBL), and the Project Fiscal Year Inquiry (PFYT) windows. If the project is linked to an entity-wide project, the Entity-Wide Project Inquiry (ENPR) window will also be updated.
The Project Memo (P3) document is used to record third-party activity against a project that has no accounting impact for the State. For example, if a third-party recipient is given a portion of a grant to spend on the condition that they provide matching funds, that third-party's expenditure and earned income can be recorded using the Project Memo document. This document can also be used to record performance statistics for a performance-based grant.
Project Memo documents can only be processed for sub-project/phases that are established as Not Participating in the billing process. A Program/Provider code is entered to identify the third party for charges and income. Information entered on a Project Memo document is posted to a memo ledger only and does not update the general accounting ledgers. Charges entered using a Project Memo document are not billed to the providers of funds for the project.
There are three different types of lines on Project Memo documents. All three types of lines can be entered on the same document. The three types of lines are:
- Third-Party Charges
- You can enter these lines to record expenditure activity on the part of a third party.
- Be sure to select No for the Performance Indicator, enter Agency, Project/Sub and Phase to identify the project, and minimally enter an Object and Amount to identify the charge (the Computed Amount method described in the previous section may also be used).
- When the Project Memo document is processed, the Amount on the Third-Party Charge line will update the Third-Party Charges field on the Agency Project (AGPR), Project Budget Line (PRBL), and Project Fiscal Year (PFYT) windows.
- Third-Party Income
- You can enter these lines to record revenue activity on the part of a third party.
- Be sure to select No for the Performance Indicator, enter Agency, Project/Sub and Phase to identify the project, and minimally enter a Revenue Source and Amount to identify the income (the Computed Amount method described in the previous section may also be used).
- When the Project Memo document is processed, the Amount on the Third-Party Charge line will update the Third-Party Income field on the Agency Project (AGPR), Project Budget Line (PRBL), and Project Fiscal Year (PFYT) windows.
- Performance
- You can enter these lines to record performance statistics that can later be used for reporting to support draws for performance-based grants.
- Be sure to select Yes for the Performance Indicator, enter Agency, Project (and optionally Sub-Project and Phase) to identify the project, and minimally enter Activity and Charge Units to identify the activity and measurement of performance. You can optionally enter Charge Class if there is a rate associated with the units. Amount may also be entered or calculated.
- When the Project Memo document is processed, whatever is entered on Performance lines will be stored in the memo ledger, but no inquiry windows will be updated.
- Figure 134
Billing of the Funding Sources
The billing process is designed to be run periodically at the user's discretion. The billing process involves several sequential steps, which are:
- Create the Billing Accumulator (AFINPBSP) file.
- Calculate billing overhead.
- Check eligibility.
- Split billable costs among eligible funding sources.
- Check construction engineering (CE) cost.
- Process CE cost overrun for FHWA programs.
- Conduct preliminary review run of the billing reports.
Step 1: Create the Billing Accumulator File (AFINPBSP)
AFINPBSP is a nightly process that updates the Billing Accumulator File (BAFILE), the project and the project memo ledgers. AFINPBSP extracts all project related billable transactions from the daily general and memo ledgers and writes them to a BAFILE. The exception to this is when the project status for the agency/project/sub-project/phase coded on the Project/Grant Master (PJ) transaction is "restricted". In this case, the transaction is flagged and written into a Suspense File (RESTRICT) which is processed by AFINPBSP during the next nightly cycle. AFINPBSP also appends other project related and billing related information from reference tables to the extracted records. For example, it appends the federal route and section from Agency Project Inquiry (AGPR).
Step 2: Calculate Billing Overhead (PBOH)
Each time the billing module is run, the labor additive charges for transactions stored in Billing Accumulator File have to be calculated. A transaction which requires labor additive calculation is recognized by its object code. These object codes are maintained in Project Billing Parameter (PBPT). The overhead rate is stored on Project Billing Parameter (PBPT). The calculated charges are recorded as project charge transactions which are automatically loaded into the BAFILE, and included in the current billing cycle. They are also put into the suspense file for posting to the daily memo ledger. These transactions in the suspense file are flagged so that they are not extracted by AFINPBSP and written into the BAFILE in the next billing cycle.
Step 3: Check Eligibility (PBEC)
This next step determines which funding types can be billed for each transaction and assigns an eligibility status accordingly. State and bond programs are always eligible. The funding types are listed below.
The Activity and Object codes on the transaction records determine the eligibility status for the transaction. Both Activity (ACT2) and Object (OBJ2) carry eligibility indicators used for this purpose. However there may be exceptions for certain agencies//projects/sub-projects/phases. Those which have a different activity eligibility from that coded in Activity (ACT2) are entered in Activity Eligibility Exception (ACEX). Those which have a different object eligibility from that entered in Object (OBJ2) are entered in Object Eligibility Exception (OBEX).
The verification procedure for each transaction follows.
- Check to see if the Agency/Project/Sub-Project/Phase/Activity exists on Activity Eligibility Exception (ACEX). If it does and the eligibility indicator is I , then enter the status of I in the transaction. If the indicator is E , go to Step 4.
- If the Agency/Project/Sub-Project/Phase/Activity is not in Activity Eligibility Exception (ACEX), go to Step 2.
- Check the eligibility indicator on Activity (ACT2). If it is I , then enter the status of N in the transaction.
- If the indicator is E then go to Step 4.
- Check to see if the Agency/Project/Sub-Project/Phase/Object exists in Object Eligibility Exception (OBEX). If it does, then use the corresponding indicator maintained on this table for the transaction status.
- If it does not, go to Step 4.
- Check the eligibility indicator in Object (OBJ2) and enter this as the eligibility status for the transaction.
The eligibility indicator is appended to each transaction. The transactions are put into a new file called BILLFILE.
Step 4: Split Billable Costs among Eligible Funding Sources (PBBP)
The first stage of PBBP creates PBIL. Based on the priority grouping and the fund types of program/providers within agency/project/sub-project/phases, the processor calculates each program or providers contribution percentage for each of the four eligibility categories ( F , O , B and N ). These percentages are stored in PBIL.
Stage two of PBBP reads each transaction from the BILLFILE and based on the eligibility indicator, the processor identifies the PBIL records with the appropriate eligibility. It identifies the program/providers within the eligibility grouping with the highest priority. It then calculates the amount to be charged to each program/provider based on PBIL percentages. If the available amount falls below the calculated amount for a program/provider, and if there are other eligible contributors within the same priority group with positive balances, PBIL is recalculated using the available balances. After all the available balances within a particular priority group are exhausted, the next priority group is used.
A separate record is created for each program/provider identified to be billed for the expense transaction. The record contains the billable amount for that program or provider. Based on the funding source of each program/provider, these records are placed into the relevant filling files: FEDSUSF (for FHWA billing), TPBILL (for third party and non-FHWA federal billing), and BFBILL (for state and bond funding).
If there is no available money in any priority group, or if the program/providers for a project/sub-project/phase have not been established, the transaction is put into the UNBILL file. A report is created from the UNBILL file for the users to review. Steps have to be taken to ensure that these unbilled transactions are billed. Once additional funding is found for the project/sub-project/phase, a new Project/Grant Participation (PZ) transaction can be submitted to increase the funding availability and allow these transactions to be billed.
Step 5: Check Construction Engineering Cost (PBBC)
This program reads the FEDSUSF file, which contains all FHWA transactions with the FHWA billable amount. The CE indicator on each transaction is examined to see if it indicates an engineering expenditure. If so, the billable amount is put into the engineering cost accumulator corresponding to the agency/project/sub-project/phase/program coded on the transaction. This total is compared to the ceiling engineering amount estimated for that agency/project/sub-project/phase/program. The ceiling engineering amount is estimated as follows:
where A is the agreement amount for each FHWA program while an agency/project/sub-project/phase, and CE is the construction engineer percentage. A default of 15 percent is used if no CE percentage is entered on the Project/Grant Master (PJ) transaction. If the CE percentage on the PM transaction is coded as 999.999 , the system will allow all CE charges to pass.
All non-engineering transactions and accepted construction engineering transactions are put into the FEDBILL file. If the engineering cost total has exceeded the ceiling amount, then the construction engineering charge transaction is put into the FUNBILL file.
In the next billing run, all rejected construction engineering transactions stored in the CONFUNB file are reprocessed by AFINBCALC. These transactions are marked recycled (RECY). If an incoming transaction is marked RECY and is accepted in this run, in addition to being put into the FEDBILL file for billing, it is also put into the accepted file (ACPFILE). This allows the PBRC process to reduce the suspended amount for the FHWA program by the amount of the accepted transactions.
Step 6: Process CE Cost Overrun for FHWA Programs (PBRC)
The memo billing run creates the FUNBILL file which contains those transactions which are unbilled due to CE cost overruns for FHWA programs. Some of the records in the FUNBILL originate in the CONFUNB which contains CE overruns from the previous (final) billing run. These records carry a recycled indicator RECY. PBRC is run in the final billing mode. PBRC processes the records in FUNBILL in the following manner. All records that are identified as being overruns for the first time (i.e., those that do not carry the RECY indicator), are marked with the RECY indicator. The billable amounts on these records are then suspended. The available balance for billing each program/provider is calculated as:
Available Balance = Agreement Amount - Billed - Suspended
All records in FUNBILL that are marked RECY have amounts that have been suspended. When all the records have been processed, they are put into the CONFUNB file for processing by the next billing cycle.
PBRC also processes the records in ACPFILE. ACPFILE contains those records that have been identified as a CE overrun in a previous (final) billing run, but which have been accepted for invoicing in the current run. PBRC reads through ACPFILE and backs-out all previously suspended amounts. Refer to step 5 for a further description of the AFINBCALC process which creates the ACPFILE.
Step 7: Conduct Preliminary Review Run of the Billing Reports, Inquiries, and Project Setup
This step is comprised of programs which read the bill files for all the funding types (FUNBILL and FEDBILL for FHWA, TPBILL for third party providers and non-federal funding sources, and BFBILL for state and bond fund programs). They create separate reports for each listing the amount billed to each program/provider within an Agency/Project/Sub-Project/Phase. In the case of state and bond program, the report provides fund transfer information.
These reports can act as turnaround transactions. As a result of reviewing the billing reports, several actions may be taken to charge the outcome of the final billing run:
- Change the agreement amount or priority of a program/provider on the Project/Grant Participation (PZ) transaction
- Change the CE percentage for a FHWA program on a Project/Grant Master (PJ) transaction
- Change the eligibility indicator on the Activity, Activity Exception, Object, or Object Exception
- Change the billing cycle for a program/provider on Project Participation Invoice Cycle (PPIC)
Other programs update the Project Anticipated Billing by Program Budget Unit (PABP) and Project Anticipated Billing by Allotment (PABA) inquiries (based on the FEDBILL, TPBILL and BFBILL results). These inquiry windows are described in detail in the User's Reference .
Finally, the Project Billing Setup Assurance program verifies that all Projects in Drawdown Groups are set up with the codes required for the Draw Generation process. It also verifies that each Program/Provider code is set up with an EFT/Check flag that is consistent with the one specified for the Funding Source code associated with the Program/Provider. This is essential to ensure that billing and draw calculations are performed correctly.
Steps 2 and 7 can be run as often as required to make the necessary changes and to assure that the final billing run will be acceptable.
The Draw Process is run as part of final billing to calculate the amount to be drawn from any Federal provider of funds established to be billed according to the Composite Clearance funding method. This step is comprised of programs which read the final billing files (FEDPERM for FHWA, and TPPERM for non-FHWA providers). It uses the formulas associated with the Composite Clearance funding method to calculate the date and amount of Federal draws and stores these results for use in the next step. For a description of Composite Clearance formulas, See Understanding the Draw Processes.
Step 9: Produce FHWA Invoice and Create Receivable, Cash Receipt and Journal Voucher Documents (PBFI, PBTI, PBFT)
Receivables (RE) documents and associated cash receipts documents are generated after the draw process (when the billing process is run in final mode). These documents are loaded into the document suspense file for future processing by document processors. The generated receivables for draws will be loaded and held in suspense, while receivables for other providers will be loaded and processed. When a draw request is actually made, the appropriate receivable is updated with the request date and scheduled for processing. The cash receipts will be loaded and held in suspense. When payment is received, the appropriate cash receipt is updated with the deposit date and scheduled for processing.
For state and bond programs and other providers, journal vouchers will be created transferring money out of the funds to which these programs pertain, and into the funds from which they were originally taken.
When the receivables and journal vouchers are processed, the billed/reimbursed fields in Project Funding Source (PFST) and Project Summary (PSUM) are updated. Upon receiving payments for reimbursement and processing the cash receipts, the corresponding collected amount field is updated on the same tables.
During the final billing, the FHWA invoices are printed in FHWA format and also provided in electronic format.
Project documents are subject to four types of controls outside the project accounting module: budgetary controls, referenced document controls, batch controls and project document controls. Budgeting and referenced document controls apply to general accounting documents on which project numbers have been coded, such as payment vouchers, journal vouchers and cash receipts.
Batch controls apply to both accounting and non-accounting documents whenever batching is used. The same principles described for the accounting modules apply. The net amount field on the batch ticket must be coded for batches of accounting documents, but must be omitted for non-accounting documents.
All project documents are subject to project document control. First, the project must be set up on the project tables before any documents containing the project number will be accepted by the system. Second, the documents must postdate the starting date of the project and, with the exception of revenues and receipts, must be dated earlier than the expiration date of the project.
The Cash Management Improvement Act of 1990 (generally referred to as "CMIA") was enacted to improve the transfer of funds between State and Federal Governments. All Federal fund transfers to State Governments are covered by the act, but only major assistance programs (large dollar projects or grants) are included in a written Treasury-State Agreement which specifies how Federal funds transfers will take place. MARS supports CMIA compliance using either the Zero Balance or Composite Clearance funding methods.
Projects do not have to be established as CMIA-eligible in order to use CMIA-compliant funding methods for draws. That is, the Zero Balance and Composite Clearance funding methods may be used for either CMIA-eligible or non-CMIA-eligible projects.
This section describes MARS capabilities for CMIA-compliance, as well as the process by which draws can be calculated according to the Composite Clearance funding method. The setup required for automatic generation of draw documents to record the draw request and receipt is also described.
MARS includes features that allow a site to:
- Identify CMIA-eligible projects and set up necessary accounting information to track monies associated with the project.
- Automatically collect draw information and produce draw requests for projects established to use the Composite Clearance funding method.
Figure 135 illustrates the basic features of the Draw Process and how these features relate to each other.
Basic Features of the Draw Process
Setting Up a Project to Follow a CMIA-Compliant Funding Method
Setting up a project to follow a CMIA-compliant funding method consists of identifying certain characteristics of the project so that monies associated with the project can be appropriately handled by MARS. Most set up tasks are done on the Project/Grant Master (PJ) and Project/Grant Participation (PZ) documents previously described. In addition, "Dollar-Weighted Days of Clearance" may need to be set up to represent check clearance patterns. These are used when calculating draw requests so that the State can request Federal funds in a timely manner.
To capture all of the information needed for CMIA, you must be able to identify all CMIA-eligible projects within MARS. The CMIA-Eligible indicator on the Project/Grant Master (PJ) document indicates CMIA-eligibility for a project. If a project is not CMIA-eligible, it can still be set up to be included in the Draw process, but you should not mark the project as CMIA-eligible.
If a project's expenditures are to be combined with the expenditures from other projects for draws, all of those projects should be established with the same Drawdown Group . In other words, Drawdown Group is used to group projects for which draw amounts can be combined and requested from the same Federal provider of funds.
Projects that are established as part of the same Drawdown Group must share certain attributes in order for the Draw Process to correctly calculate draws. Specifically, they must share the same Responsible Agency . Additionally, the Funding Source associated with all Federal providers of funds must be the same.
Funding methods are strategies used by states to request funds from the Federal Government for CMIA-eligible projects or grants. MARS allows you to specify one of the following funding methods when you enter lines on a Project/Grant Participation (PZ) document for Federal providers of funds:
Each funding method is described in more detail later in this chapter.
For projects that are not 100% Federally funded, it is necessary to identify exactly how much of each sub-project/phase is covered by Federal funds, state funds, bond funds, and/or other sources. You can use the Project/Grant Participation (PZ) document to define the amount covered by each provider of funds.
Draws are calculated based on an agency's check clearance activity throughout the course of the fiscal year. This check clearance activity is factored into a single value called the Day of Clearance . Each fiscal year, new Day of Clearance values are calculated and entered into Composite Clearance (CCLR).
MARS also provides the Business Day Calendar Build (CLWE) process which generates a business day calendar in Calendar Date (CLDT). This calendar is used to ensure that draw requests are always made on a business day.
Calculating Draws and Generating Draw Documents
Draw calculations are performed for projects established to use Composite Clearance as the funding method, regardless of their CMIA status. Draws are calculated and documents are generated as part of the Final Billing process. See The Billing Process for a description of this process. See Processing Draws for a description of the setup required.
Setting Up CMIA and the Draw Process
To set up the Draw Process for CMIA-compliance using the Composite Clearance funding method, you must perform certain annual and per project activities. Each year you must:
For each Federally-funded project established to use the Composite Clearance funding method, you must:
- Identify CMIA Eligibility
- Determine the Funding Method
- Create Drawdown Groups (Optional)
- Identify Eligible Objects and Activities
On an annual basis, you must perform the activities explained in this section to affect all of the projects which are part of the Draw Process.
Defining the Weekend and Holiday Schedule
The Draw Process relies upon being able to distinguish between business days, weekends, and holiday. The reason for this is simple: draw requests cannot occur when the government facilities are closed, and generally State and Federal Government facilities are closed on weekends and holidays.
At the beginning of every new fiscal year, the New Year Table Initialization (NYTI) process runs. This process updates Calendar Date (CLDT) with all of the dates for that fiscal year, but it does not distinguish between business days, weekends, and holidays. To add all of the holidays observed at your site, you must enter the holiday schedule into Holiday (HDAY). A complete description of Holiday (HDAY) with field descriptions is supplied in the User's Reference .
After Holiday (HDAY) is updated, run the Business Day Calendar Build (CLWE) process. This process updates the Weekend/Holiday field on Calendar Date (CLDT) with all of the appropriate H (holiday) and W (weekend) entries for a given fiscal year.
Draws are calculated based on an agency's check clearance activity throughout the course of the fiscal year. This check clearance activity is factored into a single value called the Day of Clearance for the agency. Each fiscal year, new Day of Clearance values are calculated for all agencies and entered into Composite Clearance (CCLR).
Entering Project Billing Parameters
Project Billing Parameters (PBPT) stores a number of parameters that control the Billing and Draw Process. It is also updated each time the Draw Process is run to indicate the date on which draw calculations are performed. Each year you should make a new entry in Project Billing Parameters (PBPT), including all codes required for the billing process.
Setting Up a Federally-Funded Project for the Draw Process
For each grant that participates in the Draw Process, you must perform each of the activities explained in this section.
The CMIA-Eligible indicator on the Project/Grant Master (PJ) document must be set for every new project entered into MARS. Valid entries for the CMIA-Eligible indicator are:
Indicates that the project is covered by CMIA.
Indicates that the project is not covered by CMIA.
In order for a project to participate in the Billing and Draw Process, the Participating field must be set to Participating .
Funding methods are strategies used by States to determine when to request funds from the Federal Government. MARS allows for the following funding methods:
Funding methods are established for Federal providers of funds on the Project/Grant Participation (PZ) document in Billing Cycle . For projects that are CMIA-eligible or are not participating in the Billing and Draw Process, there are other values for Billing Cycle, but valid funding method values are: Composite Clearance and Zero Balance .
When using the Zero Balance funding method, the State's financial institution requests and receives Federal funds on the same day that electronic funds transfer (EFT) payments are settled or checks are presented for payment.
Check clearance activity does not factor into this funding method because the receipt of funds is based on an actual date instead of an estimated or averaged date.
When this method is properly applied, there are no interest liabilities for either the State or the Federal Government. On the other hand, because it is impossible to capture the appropriate draw request information (i.e., the check or EFT clearance date) in a timely fashion, the Draw Process cannot generate draw requests for projects that use this method. Draw requests for projects using this method must be manually entered into the system.
However, as long as the project is established as Participating in the billing process, journal vouchers will still be created for state and bond providers of funds to transfer money out of the funds to which they should be billed and into the funds from which they were originally expended. Additionally, Receivable (RE) and Cash Receipt (C1/CR) documents will be generated for other providers, along with the accompanying journal vouchers.
When using the Composite Clearance funding method, the State's financial institution requests funds one day prior to the anticipated settlement of EFT payments or the presentment of checks, according to calculations that factor in historical check clearance patterns.
Each year, the State calculates the average number of days (dollar-weighted) that checks required to clear the bank during the previous year for each agency. This calculation is based on historical check clearance patterns, which can be obtained from the Federal Government or developed by the State. The calculated Day of Clearance values are entered in the Composite Clearance (CCLR) table.
The Draw Process selects all eligible expenditures against projects established to use the Composite Clearance funding method and generates draw requests with the anticipated draw request date and amount. For more information on how the Draw Request logic selects documents and calculates draw request information, See Draw Request Logic.
When this method is properly applied, there are no interest liabilities for either the State or the Federal Government.
- The State expends $45,000,000 from a CMIA-eligible project with 100% Federal funding over the course of a week as shown in the table below. Based on this information, the draw process run on Day 8 would calculate a "Weighted Days Elapsed" value as follows:
If the Day of Clearance value for the agency expending against the project is 6.000, the $45,000,000 will likely clear the bank 6 days from the "dollar-weighted midpoint" of the week. However, the calculation above indicates that 4 days have already elapsed from that dollar-weighted midpoint, so the cash must be in the bank in 2 days (i.e., on Day 10 ). Therefore, the State requests a $45,000,000 draw on Day 9 . (to allow one business day for the Federal Government to make the deposit). The Federal Government deposits $45,000,000 on Day 10 to coincide with the expected presentment of the payments associated with the expenditures.
If on Day 10 only $35,000,000 in checks are presented for payment at the State's banks, the State will not incur an interest penalty on the balance of Federal funds left in the account. Over the long term, the amounts drawn down and the amounts of checks paid converge to match the historical check clearance pattern.
Use of Project Billing Drawdown Group (PBGR) is optional. This table allows your site to group grants together during the Draw Process. Drawdown groups are generally composed of related projects. For example, all projects sharing the same sub-account number in the Federal PMS system could be organized into one drawdown group, or all projects associated with a single letter of credit could be organized into a drawdown group, etc.
If your site decides to use drawdown groups, you must first create a list of valid drawdown groups on Project Billing Drawdown Group (PBGR). Once a valid list of drawdown groups has been established, if a project's expenditures are to be combined with the expenditures from other projects for draws, all of those projects must be established with the same valid Drawdown Group on the Project/Grant Master (PJ).
Projects that are established as part of the same Drawdown Group must share certain attributes in order for the Draw Process to correctly calculate draws. Specifically, they must share the same Responsible Agency . Additionally, the Funding Source associated with all Federal providers of funds must be the same. In order to ensure that Drawdown Groups and Program/Providers are set up correctly, the Project Billing Setup Assurance program should be run prior to the Draw Process. If it detects any errors in set up, they should be corrected before the Draw Process is run.
Identifying Eligible Objects and Activities
In order to ensure that only eligible expenditures are included in draw calculations, you must select Eligible for Reimbursement Billing on Activity (ACT2) and Object (OBJ2). If a certain project requires eligibility settings other than those on Activity (ACT2) and Object (OBJ2), exceptions can be entered on Activity Eligibility Exception (ACEX) and Object Eligibility Exception (OBEX). Expenditures entered for Objects or Activities with Eligible for Reimbursement Billing selected (or set on one of the exception tables) will be included in draw calculations and billings.
A draw is the request for Federal funds for State projects. Under the Cash Management Improvement Act (CMIA) of 1990, if the requested funds are not deposited in a timely manner to the State's bank account(s), interest penalties are assessable to the Federal Government. In the same manner, if a State does not disburse funds received from the Federal Government immediately, the State is liable for interest penalties to the Federal Government. MARS provides the capability to calculate and track draw request and receipt dates and amounts for CMIA-compliance purposes.
The Anticipated Draw Date is the date when Federal funds must be deposited into the State's bank account. The Draw Amount is the portion of the project funding to be received from the Federal Government on the Anticipated Draw Date. The Draw Request Date is the date on which the Federal funds are requested (usually one business day prior to the Anticipated Draw Date). The Draw Receipt Date is the actual date on which the Federal Government deposits the funds into the State's bank account.
Using the Project Billing Draw Request Window
The Project Billing Draw Request (PBDQ) window displays the Draw Request Dates and Amounts for a given Drawdown Group. Projects not associated with a Drawdown Group are displayed using ** as the Drawdown Group code. The entries displayed on this window are built when the Draw Generation Logic in the Draw Process is run.
Understanding the Draw Processes
The Draw Process in MARS consists of programs that follow logic to perform three types of calculations and processing:
Prior to execution of the Draw Process, the Project Billing Setup Assurance program must have been run as part of Memo Billing, and any resulting errors must have been corrected. For technical information on this program or any of the programs that comprise the Draw Process, refer to the System Administration Guide.
The Draw Request logic selects transactions, based on transaction date, from the Project Billing CMIA Ledger (PRJCMIA) and uses these transactions to calculate Draw Request Dates and Amounts. The procedure through which the Draw Request logic makes these calculations is outlined below:
The date stored in Draw Request Calculation Date on Project Billing Parameters (PBPT) is used as the "from date." The date stored in the To Date field for the entry in Application Dates (LDAT) for the draw process is used for the "to date." All expenditure transactions (and Project Charges (PXs)) against projects using the Composite Clearance funding method with a transaction date greater than the "from date" and less than the "to date" are selected when the process runs.
For projects not associated with a Drawdown Group, the Draw Request logic accumulates all expenditures against the project since the last run of the Draw Process. The total amount of these expenditures is the Draw Amount.
Draw Request logic then calculates a "Weighted Days Elapsed" value to indicate how many days have elapsed since the "dollar-weighted midpoint" of the time period represented by the "from date" and the "to date" using the following formula:
Weighted Days Elapsed = ( Expenditure Amount for one day x % of Total Expenditures represented by Expenditure Amount) for each day between the "from date" and "to date"
The following formula is then used to calculate an Anticipated Draw Date for all selected transactions associated with the project:
Anticipated Draw Date = "to date" + ( Day of Clearance - Weighted Days Elapsed )
The Day of Clearance is obtained from Composite Clearance (CCLR) for the agency expending against the project.
For projects that are part of a Drawdown Group, essentially the same formulas are used but a Dollar-Weighted Day of Clearance must be calculated, since more than one agency may have expended against the projects in the Drawdown Group. The following formula is used to calculate the Dollar-Weighted Day of Clearance for the Drawdown Group:
Dollar-Weighted Day of Clearance = ( % of Total Expenditures represented by expenditures against one project) x ( Day of Clearance associated with the agency for that project) for each project in the Drawdown Group
Again, the Day of Clearance is obtained from Composite Clearance (CCLR) for the agency expending against each project. Therefore, for Drawdown Groups, the following formula is used to calculate the Anticipated Draw Date:
Anticipated Draw Date = "to date" + ( Dollar-Weighted Day of Clearance - Weighted Days Elapsed )
The following formula is used to calculate the Draw Request Date that is later stored on the Project Billing Draw Request (PBDQ) window:
Draw Request Date = Anticipated Draw Date - 1 business day
Note that the Draw Request Date may be calculated to be a date in the past. If the Draw Request Date falls on a date earlier than the "to date," the "to date" will be used as the Draw Request Date . Additionally, if the Draw Request Date is calculated to be a weekend or a holiday, the next business day will be used as the Draw Request Date . The Draw Request Date is always a business day.
- Store information for later use in Reduction Request calculations and Draw Generation logic.
- Update Project Funding Source Inquiry (PFST) and Project Billing Parameters (PBPT).
For each Federal provider of funds from whom a draw will be requested, the corresponding Project Funding Source Inquiry (PFST) entry is updated by setting Draw Request Calculation Date to the "to date." Once the Draw Request logic has successfully executed, the Draw Request Calculation Date on Project Billing Parameters (PBPT) is updated with the "to date" used by this run.
An extract file containing all records selected from the input file is generated. It can be used for queries and reports. Additionally, a statistical report summarizing the selected expenditure and charge records by Drawdown Group is generated.
Sometimes it is necessary for the State government to refund all or part of a draw received from the Federal Government. Additionally, there are times when revenue recorded against a project should be divided among the funding sources (e.g., program income), and thus part of that revenue must be given to the Federal Government. In MARS, many such refunds or payments to the Federal Government are handled by reducing the total amount of future draws for the project in question. The MARS Reduction Request is designed to automatically adjust the amount of future draws to account for refunds or program income.
The Reduction Request logic selects transactions, based on transaction date, from the Project Billing CMIA Ledger (PRJCMIA) and uses these transactions to calculate the amounts of reductions to future draws. In the case where a Reduction amount exceeds the amount of future draws, the Reduction is not applied, but instead is stored on Reductions to be Applied (REDA). An attempt is then made to apply the Reduction each time the Reduction Request logic is executed. Entries on Reductions to be Applied (REDA) may be changed if necessary to ensure that the Reduction is applied appropriately to a draw.
The procedure through which the Reduction Request logic makes these calculations is outlined below:
The date stored in Refund Calculation Date on Project Billing Parameters (PBPT) is used as the "from date". The date stored in the To Date field for the entry in Application Dates (LDAT) for the draw process is used for the "to date". All transactions against projects using the Composite Clearance funding method that credit Expenditures/Expenses (Account Type 22), Expenditures (Account Type 23), or Revenue (Account Type 31) and have a transaction date greater than the "from date" and less than the "to date" are selected when the process runs.
A Reduction is calculated for each accounting line represented by the selected transactions. The Reduction amount is calculated as the total of the amounts on expenditure and revenue credit transactions selected from the PRJCMIA ledger, plus any outstanding Reduction amounts on Reductions to be Applied (REDA).
To apply the Reduction, a decrease is made to an existing Draw amount. This is done by subtracting the Reduction amount from the corresponding Draw amount(s) stored when the Draw Request logic was executed. Since a draw is not allowed to be negative, a Reduction may have to be applied to several Draw amounts. If any portion of a Reduction is not applied, an entry will be written to Reductions to be Applied (REDA) to be picked up by the next execution of the Reduction Request logic.
For each Federal provider of funds associated with a draw that is reduced, the corresponding Project Funding Source Inquiry (PFST) entry is updated by setting Reduction Calculation Date to the "to date." Once the Draw Request logic has successfully executed, the Reduction Calculation Date on Project Billing Parameters (PBPT) is updated with the "to date" used by this run.
An extract file containing all records selected from the input file is generated. It can be used for queries and reports. Additionally, a statistical report summarizing the selected expenditure and revenue credit records is generated.
After draw dates and amounts have been calculated and stored, the Draw Generation logic automatically creates draw request documents (receivables) and receipts (cash receipts). These documents are generated for all draws stored by the Draw Request logic (and potentially modified by the Refund Request logic) that fall on the date specified in Application Dates (LDAT) for the Draw Generation process.
The Revenue Source code used on the generated documents is obtained from Agency Project (AGPR) if possible. If no Revenue Source code is specified on Agency Project (AGPR), then the Third-Party Revenue Source code specified on Project Billing Parameters (PBPT) for the fiscal year is used.
For each line on the generated documents, a corresponding record on Project Billing Draw Request (PBDQ) is generated. Once the documents have been generated, amounts on Letter of Credit Status (LOCS) are updated to reflect the draws. Temporary Construction and Construction Engineering numbers on Project Funding Source Inquiry (PFST) are moved to their permanent fields. For Federal Highway Projects, an extract file reflecting the FHWA invoices is also generated. Finally, the Draw Generation Date on Project Billing Parameters (PBPT) and on each affected Project Funding Source Inquiry (PFST) record is updated.
A statistical report provides information about the generated Cash Receipt documents and the Receivable documents they reference.
Receivable (RE) Documents Generated
One Receivable (RE) document is generated for each Federal Program/Provider associated with the projects for which draws are being generated. Draw amounts for projects that are part of a Drawdown Group are combined on the Receivable documents. Input records that result in one Receivable document must share the following codes:
One document line is generated for each distinct accounting line.
Document numbers for the generated Receivable documents are obtained using Automatic Document Numbering (as described in System Control Tables ), however the first two characters of the generated document numbers will always be CM. The Date of Record for the generated documents will be the draw request date that was calculated and stored by the Draw Request logic.
- When generating a Receivable document, if the number of lines on the generated document exceeds the maximum number of lines per document set for the site, multiple documents will be generated, but they will be batched.
Cash Receipt (C1/CR) Documents Generated
One Cash Receipt document is generated for each Drawdown Group (or for each project that is not a member of a Drawdown Group). Input records that result in one Receivable document must share the same Responsible Agency code.
A Simplified Cash Receipt (C1) document is generated for Program/Providers specified on Program/Provider (PGPV) as using Electronic Funds Transfer (EFT) for their payments. A Cash Receipt (CR) document is generated for Program/Providers using checks to make the payment. One document line is generated for each distinct accounting line.
Document numbers for the generated Cash Receipt documents are obtained using Automatic Document Numbering (as described in System Control Tables ), however the first two characters of the generated document numbers will always be CM. Each line on the generated Cash Receipt document will generate the corresponding line on a generated Receivable document. The Date of Record for the generated documents will be one business day prior to the draw request date calculated and stored by the Draw Request logic (to allow the Federal agency one day to make the payment).