The Chart of Accounts
This chapter addresses the Chart of Accounts. It contains the following topics:
The MARS codes defined at your installation are used to identify and classify all financial data stored in MARS. For standard accounting transactions, codes defining a fund, agency, appropriation and either a revenue source or object of expenditure are required. Balance sheet transactions require fund, agency, appropriation, and balance sheet account. Optional codes, such as Organization, Activity, Function, Sub-Object, Termini, and Reporting Category, may also be specified. The complete account code distribution used with a transaction is stored with the transaction code in a ledger file, where it is available for reporting purposes.
All types of financial transactions (such as budgeting, accounting, planning, job costing, and fixed assets) use the same set of valid codes in MARS. This single set of codes integrates the various functions of MARS into one system. It ensures that all of MARS data is compatible, so that data gathered for one function can be used by other functions to perform meaningful comparisons and computations.
Flexible Account Code Structure
The account code structure provides user flexibility; it enables managers to enforce detailed coding for some agencies while allowing minimal coding for others. Through various system options and internally-enforced office procedures, the account code structure is used to achieve reporting in exactly the level of detail desired for various situations. The following items summarize the flexible aspects of the account code structure:
- Budget vs. Accounting Level of Detail. Accounting transactions may be entered at a more detailed level than budgets by using Activity, Function, Sub-Organization, Sub-Revenue, Sub-Object, Reporting Category, Termini, and Job Number codes. Each agency can develop its own budget, at the desired level of detail, and still use additional codes on accounting transactions for cost accounting and reporting.
- Plans. Each agency can develop its own plans, at the desired level of detail.
- Organization, Activity, and Function Enforced Coding Options. Through options selected for each fund/agency combination, Organization and Activity codes can be required on revenue budget transactions; Organization, Activity, and/or Function codes can be required on expense budget transactions.
For example, one fund/agency requires an Activity code, while another agency using money from the same fund makes the Activity code optional. These Organization, Activity, and Function code options are selected on the basis of reporting requirements of individual agencies, or tracking requirements for particular funds. These options are controlled by the Expense Budget Organization, Activity, and Function options, and the Revenue Budget Organization and Activity options entered on Fund Agency (FGY2).
- Other Enforced Coding Options. Through the Reporting Category option selected for each balance sheet account, a reporting category can be required on transactions for selected balance sheet accounts.
- Reporting Category code. The meaning and use of this code is defined by each installation. It provides one more level of detail for cost accounting purposes. Reporting categories may be used to describe the contributors to balance sheet accounts; for example, to identify the debtors to a billed receivables account. A different use would be for defining reporting categories to indicate special projects.
- Optional codes. Any agency or organization can require that its transactions include certain codes that MARS considers optional. For example, the Job Number and Sub-Organization codes may be mandatory for certain activities or organizations, but optional for others.
- Hierarchies. Roll-up reporting hierarchies (the class, category, type, and group codes) within the account coding structure may be defined. These hierarchies summarize and group transactions for reporting purposes. They are discussed later in this chapter.
Chart of Accounts - Issues and Concepts
All MARS codes are defined in master tables. Before a code is used as a default in the system, it must be defined in the appropriate window. For example, Fund codes must be listed in Fund (FUND) for each fiscal year that they are used.
Defining the Chart of Accounts
Once a code structure is set up for a given year, MARS provides an automatic facility to roll forward the same coding structure for the next year.
MARS clients sets up their own account codes and chart of accounts in a manner that takes advantage of system features. To satisfy specific reporting and accounting requirements, management participation is required when setting up the master tables. Once the master tables are set up, specific offices or individuals should be assigned the responsibility of keeping each master table complete and current.
Mid-year adjustments are handled centrally on a case by case basis. If you want to change the coding structure for a new fiscal year, the appropriate time to do it is before the budget preparation begins for the new year. Unless extensive changes are needed, the easiest procedure is to roll over the previous year's code structure using the facility discussed earlier and making the desired changes online.
Account codes are used with transactions in two ways; some are explicitly entered on the documents, and others are inferred. Inferred codes are looked up by the system in the tables based on other codes typed on various windows. Inferred codes can be grouped as follows:
A list of inferred codes follows. The account code from which each inferred code is derived is also listed.
Other information can also be inferred for reporting purposes; any data recorded in a master table can be inferred for use on reports.
The Termini code is primarily used on some transactions in order to capture expenditure and revenue information by highway mileposts. In cases where the Termini is used to record transaction information by milepost, the Termini element is validated against the Termini Validation (TERM) to determine if the value is valid for Agency, Program Budget Unit, Function (County), and Project (Route). This validation may be turned off via the Termini Required indicator on the Project/Grant Management Master (PJ) when a Project is established. For cases where the Termini Required indicator is set to No for a given Project, or there is no Project entered on a transaction, the Termini code is available to record non-validated data.
Some codes in the MARS account code structure are used to establish roll-up type hierarchies. These hierarchies imply a tree type relationship among a series of codes, as shown below.
Hierarchies may be established for the following coding elements:
- Fund
- Agency
- Organization
- Agency/organization/sub-organization
- Activity
- Function
- Object
- Sub-Object
- Revenue source
- Balance sheet account
Most hierarchies are optional in MARS and do not affect processing. They are used to make reports more meaningful in their organization and to summarize data in varying degrees. The example below illustrates a simple hierarchy.
Partial hierarchies can be implemented, but should not skip levels in the simple hierarchical structure. For example, the simple hierarchy shown in Figure 6 may be used through class, ignoring category. However, in this example, categories should not be used without classes. This would cause disorganized reports with gaps and blank spaces.
Multiple hierarchies within one element can be implemented. Many code elements can be associated with different levels of the hierarchy, each independent of the other. This concept is demonstrated in Figure 7 where several schools are grouped into either public or private as well as by county.
Multiple Hierarchies in One Element
The decision to implement the various hierarchies, and to what extent, depends on how you use reports. The number of levels to implement in each hierarchy depends on who will use the reports (which offices) and the type of information they need. The actual headings used in establishing the structures should be meaningful to those who frequently use the reports.
The following sections describe each of the MARS reporting hierarchies and provide some examples of how they are used. The naming convention used in the various structures is similar. The sub-level is the most detailed, while group reporting is at the highest summary level of detail.
You may classify funds up to five levels, as shown. The Fund code (the lowest level in the hierarchy) is the level of detail used on transaction lines and recorded in the ledgers. Fund is one of the few coding elements that has a predefined hierarchy. The fund type hierarchy normally does not require maintenance and is used for classification purposes on financial statements. See Fund Type for a list of pre-established fund types.
The fund hierarchy, shown above in Figure 8, is helpful in organizing and summarizing reports, to break up and sub-title a long list of funds.
To implement the fund hierarchy:
- Define Fund Category, Class, Type, and Group codes, if desired, in Fund Category (FCAT), Fund Class (FCLS), Fund Type (FTYP), and Fund Group (FDGP).
- Assign the Category, Class, and Group associations for each fund in Fund (FUN2).
Whether the Fund code is used on a transaction or inferred from another master table, MARS obtains the hierarchy associated with it from Fund (FUN2).
Agencies are classified up to five levels, as shown below. The Agency code (the lowest level in the hierarchy) is the level of detail used on transactions. Usually, only large entities or those having special reporting requirements need to use all levels in this hierarchy. Agencies are system-wide, with the same meaning in all agencies and funds. The agency hierarchy is shown in Figure 9.
Implementing Agency Hierarchies
The agency hierarchy (shown above) is implemented by:
- Defining the hierarchy roll-up codes in Agency Class (AGCL), Agency Category (AGCT), Agency Type (AGTP), and Agency Group (AGGP).
- Coding the entire roll-up structure for each agency in Agency (AGC2) (by entering the codes for the Class, Category, Type, and Group of the agency).
When an Agency code is used on a transaction, the entire associated hierarchy is obtained from Agency (AGC2) when a report is produced that calls for the hierarchy.
Agency codes are used in various ways. One example of how the agency hierarchy might be used aligns Agency codes with budget development. In the example below, the agency called General Services was created for specific organizations. The budget analyst assigned to this agency may be assigned to all internal services agencies. By establishing a group called Internal Services Budgets, additional agencies, such as Motor Pool or Airports could be grouped together for budget development purposes.
Agency Group: Commonwealth of Kentucky
Agency Category: General Government
If Agency codes are used in this manner, it is a good practice to set up the higher levels of the hierarchy on an entity-wide basis, and leave the last two levels (agency and agency class) for the various agencies and organizations to use as necessary.
The organization hierarchy is directly below the agency level in the MARS accounting structure. Organizations are the operational entities. Usually, expense and revenue budgets are established at the organization level and expenses and revenues are recorded at this level.
The organization structure is optional within MARS. You are not required to establish organizations if all budgeting and accounting can be performed without organization classification. MARS allows the option of establishing organization structures from agency to agency. However, standard reports that use the organization attribute become less meaningful if it is not consistent.
The organization structure is required for a fund/agency if either the Expense Budget Organization or Revenue Budget Organization options on Fund Agency (FGY2) are set to Required on Budget and Accounting . In this case, an Organization code is required on all appropriation, allotment, expense budget or revenue budget transactions posted to the fund/agency.
Within a set of organizations reporting to a single agency, the organizations can be structured into a reporting or functional hierarchy. MARS lets you establish up to 12 reporting levels. Given these reporting levels, the various budget structures are defined to specific organizational reporting levels while accounting transactions are posted to the same or lower reporting levels. Different organizational reporting levels may be selected for expense budgets and revenue budgets.
MARS lets any organization, regardless of reporting level, establish sub-organizations. Only expenses and revenues are recorded to the sub-organization level; budgets cannot reference sub-organizations.
Figure 10 illustrates a possible organization hierarchy. In this organizational chart, each large box represents an organization that is defined in Organization (ORG2). The shaded boxes are sub-organizations that are defined in Sub-Organization (SORG).
MARS provides the capability of defining expense and revenue budgets at various organization levels. While using an organizational budget hierarchy is optional in MARS, it does provide flexibility in defining your budget structure.
It is often important that an organizational structure best reflect all lines of managerial authority or reporting relationships. However, the budgeting hierarchy for an organization may differ from the managerial or reporting hierarchy, thus requiring two views of one structure. The organization roll-up feature of MARS achieves both of these views.
By using organization roll-up fields provided in Organization (ORG2), an agency can define its managerial and reporting hierarchy and tie to it the appropriate budgeting hierarchies. This allows an agency to capture the organization detail required for managerial reporting, while also allowing the budgets to be defined at the organization level appropriate for them -- typically a summary of the reporting organizations.
Organizational Roll-Up: An Example
The following example shows how rolling up expenses to higher-level organizations allows an agency to set up expense budgets to the level it finds most appropriate to its spending needs.
Sample Organizational Reporting Hierarchy
Figure 11 shows a sample organizational reporting hierarchy. In this example the Fire Department (organization code 1000) has a reporting hierarchy five levels deep. This provides the necessary amount of detail for tracking accounting transactions, while providing several roll-ups to satisfy different managerial reporting needs. The agency in which the Fire Department resides, agency code 000, requires budgeting at only two levels of this hierarchy: the highest (level 1) for revenue budgeting, and the next level down (level 2) for expense budgeting. Therefore, the Fire Department's management reporting and summary budgeting needs are met.
Whenever an accounting transaction relating to an expenditure (payment voucher, requisition, purchase order, etc.) references an agency/organization combination on Organization (ORG2), the expense budget organization level on Organization (ORG2) is retrieved. This is the organization to which the transaction posts on the expense budget table. It can be the same organization or a higher level organization, but it cannot be a lower level organization.
Suppose the Finance Office in Figure 10 wants to generate a purchase order for $1,000. The organization on the transaction (4100) is written to the Organization field of the open item tables and organization field of the general ledger. The expense budget organization (1100) is written only to the expense budget organization field of the general ledger. The general ledger now has the detail organization for the expense and also the budgeted organization to which the actual expense was applied. With this information, various reports are available that show the expenses at the detail accounting level.
The Detail Listing of Obligations vs. Budget (A103 and A104) reports are examples that roll up amounts to the expense budget organization. The Management Summary of Obligations vs. Budget (A180) and Detail Transaction Listing for Accounting Transactions (A601) reports on the other hand do not roll up but show detail level information instead. This example shows that the organization roll-up feature provides the agency with the reporting detail needed at the expense level as well as the budgeted level without coding expense budget table entries for each organization.
- It is important that Organization (ORG2) be changed only when starting a new budget fiscal year. Changes to Organization (ORG2) during the budget fiscal year may produce misleading results on reports.
Like the expense budget, revenue budget organization levels can be established at any level in the organizational hierarchy. The organizational level at which revenue budgets are defined is established in Organization (ORG2). On each organization record, a Revenue Budget Organization is established. Budget authority for an organization is established for its corresponding Revenue Budget Organization. The revenue budget and the expense budget organizational levels are independent and are not required to be equivalent.
Organizational Reporting Hierarchies
Regardless of the organizational reporting levels used for budget purposes, the complete organization structure/hierarchy should be defined to reflect all lines of managerial authority or reporting relationships. This structure is the basis for choosing budgetary levels and capturing accounting information according to responsibility, that is, to support responsibility reporting. Using this structure, MARS can generate budgetary reports that roll up accounting activity to succeeding higher organizational levels.
You can define up to twelve levels for a reporting hierarchy. The reporting hierarchy does not affect the establishment of the various budgets or the posting of accounting transactions. This hierarchy is used for report generation purposes only.
The example shown in Figure 13 illustrates twelve organizations arranged in a six-level report hierarchy.
Organizational Reporting Hierarchy
Each organization can be assigned one or more sub-organizations that are defined in Sub-Organization (SORG). The sub-organization defines a distinguishable division of the organization. Separate budget lines cannot be established for a sub-organization, regardless of the organization level. However, accounting transactions may be recorded by sub-organization that allows expense or revenues to accumulate at the sub-organization level.
Implementing Organization Hierarchies
The organization hierarchy and budget levels are implemented by entering the various codes and reporting levels in Organization (ORG2). The following points may help you transfer your organizational structure to MARS.
- Draw a tree like the one in the example provided, distinguishing the levels of responsibility among organizations reporting to a department and the relationships between organizations.
- Assign a code to each box (each organization) in your tree. Each box represents a separate entry on Organization (ORG2). While MARS does not require structured codes, you may want a structured or "blocked" coding scheme so that users can infer information, such as level, from the code. MARS does require that each Organization code be unique for a given Agency.
- Determine to what level budgeting will be performed. Assign the proper Expense Budget and Revenue Budget Organization level codes to each organization. Note that the selected budget levels must be valid for all funds for the department.
- Starting at the top of the organization chart, assign a level (1-12) to each line of boxes (this assigns a reporting level to each organization). The maximum number of levels is 12.
- The sample shown in Figure 14 illustrates the proper coding for the first six levels of the sample tree in Figure 13.
- Figure 14
Sample Coding Structure for Organization Reporting Hierarchy
Agency/Organization/Sub-Organization Hierarchies
Organizations may be classified into three levels, as displayed on the following page. Agency is required on most transactions and the other two levels are optional. The organization code can be made a requirement for individual fund/agency combinations with the expense and revenue budget organization options (specified in Fund Agency (FGY2)).
If the budget is maintained at the organization level of detail, then various reports will be summarized at that level. In the standard reports, the sub-organization codes are used for cost accounting reporting only, and totals are not computed for them.
Most governments have management organizational structures that can be adapted to this structure. However, it may not always be beneficial to strictly follow the organizational structures when assigning agency and organization codes. All organizations within an agency are governed by the same set of budget options. Therefore, it may be more realistic to assign a separate agency code to each organizational unit in the government that controls its own budget. Then, agency codes would reflect budgetary and expenditure authority lines in the government, even if this means creating more "agencies" than the government's organizational structure indicates.
For example, Health Department may seem like a good choice for an agency code, with Hospital Administration, Environmental Health and Safety, and Public Clinical Services as organizations. Since it is probable that all three of these groups have their own budgets, with separate requirements (one may want to control spending based on appropriations, while another may want to control spending based on the line item budget), it would be better to make each one a separate agency in the coding scheme.
Budgets cannot be established at the sub-organization level, although actuals can, at the option of the user, be recorded at the sub-organization level. Sub-organizations may be useful to management in tracking costs below the budget level. For example, sub-organization codes can be useful in helping a particular budget authority track how (or by whom) each of its budget lines is being obligated. Management in individual organizations can decide whether they have a use for sub-organization codes.
A specific example using sub-organization is:
Organization: Collection Division
Sub-Organization: Collection Division Management
Sub-Organization: Property Tax Receipts Office
Sub-Organization: Income Tax Receipts Office
For this example, budget lines would be set up with the proper agency and organization codes indicating the Collection Division. If internal office procedures were established to enforce the coding of sub-organization codes on all expenditure transactions, the Collection Division would have records for determining how much of its expenditures can be attributed to its management.
This organizational unit hierarchy is implemented by:
- Defining organization codes and assigning agency/organization relationships in Organization (ORG2).
- Defining sub-organizations and assigning agency/organization/sub-organization relationships in Sub-Organization (SORG).
- Establishing internal office procedures enforcing the use of organization and sub-organization codes on transaction input forms.
- MARS can enforce the use of organization codes if the organization budget options are used. Use of the sub-organization code can also be controlled by an option on Organization (ORG2).
No part of this hierarchy is inferred from master tables; all three levels are coded on transactions.
Activities, like agencies, are classified into up to five levels, as shown below. The Activity code (the lowest level in the hierarchy) is the level of detail used on transactions. Usually, only large entities or those having special reporting requirements need to use all levels in this hierarchy. Activities are agency specific, with unique meaning in each agency. An activity hierarchy is shown in Figure 15.
Implementing Activity Hierarchies
The activity hierarchy (shown above) is implemented by:
- Defining the hierarchy roll-up codes in Activity Class (ACLS), Activity Category (ACAT), Activity Type (ATYP), and Activity Group (AGRP) by Agency.
- Coding the entire roll-up structure for each activity in Activity (ACT2) (by entering the codes for the Class, Category, Type, and Group of the activity).
When an Activity code is used on a transaction, the entire associated hierarchy is obtained from Activity (ACT2) when a report is produced that calls for the hierarchy.
Activity codes are used in various ways within a given agency. One example of how the activity hierarchy might be used aligns Activity codes with `General Services' tasks for an Agency. In the example below, the activity class called `Building Maintenance' was created as a lower level grouping of `General Services' tasks for an Agency. With the hierarchy shown below established, when an Activity code representing `Painting' is coded on a transaction, the transaction can be grouped in the roll-ups `Building Maintenance' and, ultimately, `General Services'.
Activity Group: General Services
Activity Type: Operation and Maintenance of Plant
Activity Category: Building and Equipment Maintenance
Activity Class: Building Maintenance
Functions are classified up to five levels, as shown below. The Function code, the lowest level in the hierarchy, is the level of detail used on documents. Usually, only large entities or those having special reporting requirements need to use all levels in this hierarchy. In general, Functions are agency specific, with unique meaning in each agency. The exception to this statement is the Function Class. Function Class is entity-wide and is used to store the County when one is associated with a transaction. The Function hierarchy is shown in Figure 16.
Implementing Function Hierarchies
The function hierarchy, shown in Figure 16, is implemented by:
- Defining the hierarchy roll-up codes in Function Category (FCCA), Function Type (FCTP), and Function Group (FCGR) by Agency:
- Function Class (FCCL)
- Function Category (FCCA)
- Function Type (FCTP)
- Function Group (FCGR)
- Defining the hierarchy roll-up codes in Function Class (FCCL) for each County.
- Coding the entire roll-up structure for each function in Function (FUNC) (by entering, for each function, the codes of the Class, Category, Type, and Group of the function.)
When a Function code is used on a transaction, the entire associated hierarchy is obtained from Function (FUNC) when a report is produced that calls for the hierarchy.
Objects are classified up to six levels, as displayed in the following example. The Object code is the level of detail used in the budget and used to control expenditures, if desired. The object hierarchy is shown in Figure 17.
The most common use of Object codes is for classifying expenditures into groups such as personnel costs, equipment, supplier, and expenses. An example of how the object hierarchy can be used is illustrated below:
Object Group: Personnel Services
Object Type: Full-Time Employee
Object Category (OCAT) lists all Object Categories by Fiscal Year and provides the Name and Short Name of each value. Following is a list of the Object Category names and their corresponding values.
Implementing Object Hierarchies
The object hierarchy is implemented by:
- Defining object Category, Class, Group and Type codes in Object Category (OCAT), Object Class (OCLS), Object Group (OGRP) and Object Type (OTYP)
- Assigning the Category, Class, Group, and Type associations for each object in Object (OBJT)
Sub-objects are unique within Agency and are classified by up to five levels, as shown below, and provide the capability of tracking data at a lower level than the budget. The sub-object hierarchy is shown in Figure 18.
Sub-objects provide the capability of tracking objects of expenditure at a level lower than the budget. This data is useful for preparing future budgets, or for isolating one item to track costs. When sub-objects are used, they appear on the line level in the detail reports; summary totals are not computed at this level in standard reports. The Sub-Object Required option on the Expense Budget (EB) transaction can be used to enforce the use of Sub-Object codes on accounting transactions. The option is recorded in the expense budget table for individual budget lines.
Implementing Sub-Object Hierarchies
The Sub-Object hierarchy is implemented by:
- Defining the hierarchy roll-up codes in Sub-Object Class (SCLS), Sub-Object Category (SCAT), Sub-Object Type (STYP), and Sub-Object Group (SGRP).
- Coding the entire roll-up structure for each sub-object in the Sub-Object (SOBJ) by entering, for each Sub-Object, the codes for the associated Class, Category, Type, and Group.
- Optionally, Coding Expense Budget (EB) transaction with a Sub-Object Required indicator value.
When a Sub-Object code is used on a transaction, the entire associated hierarchy is obtained from the Sub-Object table (SOBJ) when a report is produced that calls for the hierarchy.
An example of how to use Sub-Objects is shown below:
Sub-Object Group: Work Education
Sub-Object Type: Industrial Education
Sub-Object Category: Technical Education
Sub-Object: Biomedical Electronics
Revenue sources are classified up to five levels, as displayed below. The Revenue Source code is the level of detail used in the revenue budget. The revenue source hierarchy is shown in Figure 19.
Using Revenue Source Hierarchies
Revenue groups, types, categories and classes are helpful in organizing and setting up the revenue budget. It is easier to classify items if they can be organized under headings. Reports are also easier to read, and meaningful summary statistics can be produced using classes, categories, and groups. An example of how the revenue source hierarchy can be used is illustrated below:
Revenue Type: Contracted Services
Revenue Category: Sales and Services
Revenue Category (RCAT) lists all Revenue Categories by Fiscal Year and provides the Name and Short Name of each value. Following is a list of the Revenue Category names and their corresponding values.
Implementing Revenue Source Hierarchies
The revenue source hierarchy is implemented by:
- Defining revenue source Category, Class, Group and Type in Revenue Category (RCAT), Revenue Class (RCLS), Revenue Group (RGRP) and Revenue Type (RTYP)
- Assigning the Category, Class, Group and Type associations for each revenue source in Revenue Source (RSR2)
- Defining Sub-Revenue Source codes in Sub-Revenue Source (SREV)
Sub-Revenue Sources are defined by Agency and provide the capability of tracking data at a level lower than the budget. For example, it may be helpful to know how much of the cash receipts for a state park are attributed to museum sales versus boat dock rentals. The Sub-Revenue Source Required indicator is used to enforce the use of Sub-Revenue codes on each accounting transaction. The option is selected in Revenue Source (RSR2) for each Revenue Source code. Sub-Revenue Source Required is defined centrally. Special care should be used when setting this option to ensure that the use of the Sub-Revenue Source by the Agency may be linked to a Revenue Source code. If an Agency establishes Sub-Revenue Source codes and the Sub-Revenue Source Required is set to no, then there is no referential integrity between the Revenue Source Code and Sub-Revenue Source code. Special attention must be paid when coding documents for this reason.
Balance Sheet Account Hierarchies
Balance sheet accounts are classified up to four levels, as displayed below. The Balance Sheet Account code (the lowest level in the hierarchy) is the level of detail used on transaction lines and recorded in the ledgers.
The balance sheet account hierarchy, shown above in Figure 20, is implemented by:
- Defining Balance Sheet Category, BS Class and BS Group codes, if desired, in Balance Sheet Category (BCAT), Balance Sheet Class (BCLS), and Balance Sheet Group (BGRP).
- Assigning the Class, Category and Group associations for each balance sheet account in Balance Sheet Account (BAC2).
This hierarchy is helpful in organizing and summarizing reports, or to break up and sub-title an otherwise long list of account numbers.
MARS uses the Balance Sheet Account code entered on the transaction (or inferred from another window) to obtain the associated balance sheet account hierarchy from Balance Sheet Account (BAC2).
Default codes are processing codes that the system automatically uses in the absence of other applicable codes. These codes make it easier to enter transaction documents, eliminating the need for coding some attributes. All default codes are inferred from master tables at the time of transaction processing and are stored in the ledger along with the rest of the transaction. Some can be overridden on documents.
The Bank Account code relates cash transactions to the appropriate bank account. The Bank Account code refers to both depository and checking accounts.
On cash receipt transactions, the Bank Account is a required code on the header part of the document. This is the depository account. The Fund code is a line level attribute on the cash receipt document that makes it easy to deposit multiple funds in a single bank account.
On payment voucher transactions, the Bank Account code is inferred from Fund (FUN2). Each fund has one corresponding default Bank Account code in the window. The automated disbursements are drawn from this checking account. The default Bank Account code is then used by the automated disbursement process to write the check. Manual warrants and payroll vouchers may override the default bank account.
On manual warrant transactions, Bank Account is a required code on the document header. This is the account that provides the check used to write the check being recorded.
MARS accommodates any type of bank account-to-fund relationship. Journal vouchers are used to transfer funds between bank accounts. Multiple funds can use the same bank account, allowing transfers from a central account, or a one-to-one relationship may be established between funds and bank accounts. It is also possible to administer one fund from several bank accounts. For example, the general fund may have one (or several) depository accounts and one (or several) checking accounts. In order to take advantage of automated disbursements, a checking account should be the default bank account for the fund.
The following shows an example of the General Fund set up with several bank accounts.
All cash receipts specify bank account 01 or 02. The general checking account (04) is automatically inferred for all payment vouchers. Housing grant payments are paid using manual warrants with the Bank Account code 03 explicitly entered on the window. Likewise, payroll vouchers are entered with the Bank Account code 05.
When multiple depository accounts apply to a single fund, you can follow one of the following procedures.
- Internal office procedures can be established to enforce the correct use of Bank Account codes on transactions.
- All revenue can be deposited in a single account initially (entered on each receipt transaction), and then journal vouchers can be used at month's end to transfer amounts to the desired bank accounts. The Bank Account code is a line item attribute on the journal voucher document.
The Bank Account code identifies a bank account; it has no relationship with the balance sheet accounts and is not a part of the Balance Sheet Account code hierarchy. The Bank Account code is a separate attribute and does not distort cash audit trails.
Balance Sheet Account codes for cash are required for all cash-related transactions. Default codes are assigned to bank accounts on Bank Account (BANK). The defaults recorded in the window can be overridden for manual warrants, payroll vouchers, cash receipts, and cash journal voucher transactions on the transaction documents. (On journal voucher transactions, the override cash account is entered in the Balance Sheet Account field.)
The Cash Account code cannot be specified on automated disbursements. This means two things:
- Default Cash Account codes must be provided in Bank Account (BANK) for every bank account used for automated disbursements.
- Although a bank account can keep funds belonging to multiple cash accounts, only one of those cash accounts may be used for automated disbursements. It is this Cash Account code that must be the default in Bank Account (BANK).
For example, suppose Bank Account code 01 keeps funds for the following cash accounts:
The default cash account entered for the bank account is 0012, Cash - General, assuming that the automated disbursement cycle is used to write checks against this account. Internal procedures at this installation specify that manual warrants are used to write against restricted cash, and users are instructed to write 0014 in the cash account field on manual warrant documents. Funds in the restricted cash account must be moved to another bank account before the automated disbursement cycle can be used to write checks against it.
All cash receipts specified for bank account 01 are credited to the general cash account unless 0013 or 0014 is specified on the cash receipt window. Either users in the accounts receivable office must know where to record cash receipts, or all cash receipts are credited to General Cash initially, and transferred into the other cash accounts later using journal voucher transactions.
If a cash account is not entered on a cash transaction, it is inferred from Bank Account (BANK). This inference occurs using the bank account entered on the transaction, or, if none is entered there, using the bank account that was inferred from the fund.
An Activity code can be assigned to an organization on Organization (ORG2). The default code can be overridden on any transaction by using another Activity code on the document.
Default Activity codes are useful in helping to enforce the use of Activity codes on accounting transactions. This default facility can be used in conjunction with the Expense Budget or Revenue Budget Activity option Required on Accounting . (Expense Budget or Revenue Budget Activity options are found on Fund Agency (FGY2).) Activity codes would then be required on all accounting transactions, but be precluded on budget lines.
The option Required on Accounting requires that Activity codes be used on accounting transactions but not on budget transactions. This option is generally used when cost accounting on a programmatic basis is desired for a fund/agency. It provides a means for tracking activity costs and revenue and for summary level reporting by activity.
Assigning default Activity codes is also useful when the Expense Budget Activity Option is Required on Budget and Accounting , which requires an Activity code on both budget and accounting transactions. However, since Organization codes may only be entered on budget transactions if the Expense Budget Organization Option is Required on Budget and Accounting , Activity codes can be inferred from Organization codes on budget transactions only if both the Expense Budget Activity and Expense Budget Organization options are set to Required on Budget and Accounting .
When default Activity codes are assigned to organizations, it reduces the number of codes that the user has to input. However, default activities must be assigned to organizations carefully. They should be used only when a direct relationship exists between an organization and an activity, since the default Activity code (when it exists) is selected any time the activity column is blank on a transaction. Assigning default codes too freely can cause too many undesired associations.
When an activity is assigned to an organization as a default, it does not prevent other organizations from also using the same Activity code.
When no direct relationships exist between an activity and organization, organizations may decide to assign default codes specifying "suspense" activities, such as overhead, administration, trouble-shooting, or training, to minimize the coding burden on users. Then, when expenditures/revenues obviously apply to specific activities, other Activity codes can be explicitly entered on transactions. This procedure may be particularly useful for organizations with strict programmatic costing or reporting requirements.
A Function code can be assigned to an organization on Organization (ORG2) or to an activity on Activity (ACT2). The default code can be overridden on any transaction by using another Function code on the document.
Default Function codes are useful in helping to enforce the use of Function codes on accounting transactions. This default facility can be used in conjunction with the Expense Budget Function option Required on Accounting . (Expense Budget options are found on Fund Agency (FGY2).) Function codes would then be required on all accounting transactions, but be precluded from budget lines.
The option Required on Accounting requires that Function codes be used on accounting transactions but not on budget transactions. This option is generally used when cost accounting on a programmatic basis is desired for a fund/agency. It provides a means for tracking function costs and for summary level reporting by function.
Assigning default Function codes is also useful when the Expense Budget Function Option is Required on Budget and Accounting , which requires a Function code on both budget and accounting transactions. However, since Organization codes may only be entered on budget transactions if the Expense Budget Organization Option is Required on Budget and Accounting , Function codes can be inferred from Organization codes on budget transactions only if both the Expense Budget Function and Expense Budget Organization Options are set to Required on Budget and Accounting .
When default Function codes are assigned to organizations, it reduces the number of codes that the user has to input. However, default activities must be assigned to organizations carefully. They should be used only when a direct relationship exists between an organization and a function, since the default Function code (when it exists) is selected any time the function column is blank on a transaction. Assigning default codes too freely can cause too many undesired associations.
When a function is assigned to an organization as a default, it does not prevent other organizations from also using the same Function code.
When no direct relationships exist between a function and organization, your site may decide to assign default codes specifying "suspense" functions, to minimize the coding burden on users. Then, when expenditures obviously apply to specific functions, other Function codes can be explicitly entered on transactions. This procedure may be particularly useful for organizations with strict programmatic costing or reporting requirements.
Every fund listed in Fund (FUN2) should be assigned a fund Type. Fund types are pre-established to correspond to the fund types recommended in GAAFR. These fund types and their associated codes are listed below.
The fund type code is required by MARS for producing some of the financial statements (the F series of reports).
Every fund listed in Fund (FUN2) should be assigned a fund group. Fund groups are pre-established to correspond to the fund groups recommended in GAAFR. These fund groups and their associated codes are listed below.
MARS users only have to code one side of most accounting transactions. MARS automatically generates the offsetting balance sheet account entry. (Journal voucher masters require the user to code both sides of the transaction.) MARS obtains the Balance Sheet Account codes to perform this double entry accounting function from master tables, and in some instances, directly from the transaction input document.
At the beginning of each fiscal year, various special Balance Sheet Account codes must be stored in System Special Accounts (SPEC). MARS usually infers account codes from this window when it generates an offsetting entry. However, some of these account codes may be overridden, either on the transaction document or by storing an account code in some other master table.
A sample System Special Accounts (SPEC) window is shown in Figure 21. It lists special payable and disbursement accounts.
System Special Accounts (SPEC) Payable and Disbursements View
Figure 22 lists the override features available for the accounts on System Special Accounts (SPEC).
System Special Accounts Override Features
The Account Type codes are fixed in MARS. They are defined in Account Type (ACCT), and are listed in the example that follows. The following sections explain how MARS uses the Account Type codes.
Every balance sheet account listed in Balance Sheet Account (BAC2) is identified with one of the following Account Types. Although only the name is listed in the Account Type field, the corresponding code is used in other windows.
These Account Type codes are related to the basic accounting equation in the following way:
In balance sheet account terms, this equation is represented as:
When balance sheet transactions are entered (on payment vouchers, manual warrants, and cash receipts), the associated Account Types are automatically inferred from Balance Sheet Account (BAC2). These account types appear on the trial balance reports (A600 series) as part of the transaction.
Various other temporary account types also exist in MARS, for internal system use. These temporary accounts are really sub-accounts of the fund balance. They are used to identify individual expenditure, expense, and revenue transactions for the current year.
The temporary accounts are listed in the following table.
Accounts labeled as memo accounts do not affect the accounting equation.
These temporary account types are automatically assigned to the system-generated balance sheet entries and they appear on the trial balance reports as part of the transaction.
When you enter journal voucher masters, the Account Type must be entered on the document for both sides of the transaction.
Budget, Plan, and Other Accounts
Because of internal processing procedures, budget offsetting entries are assigned account types. Plans are also assigned account types, but in reality, they are one-line, memo type entries. These account types are automatically assigned by MARS and appear on trial balance reports as part of the budget or plan transaction.
Budget, plan, and other account types are listed in the table below. Although the account types are shown in the Account Type field, the corresponding codes are used in other windows throughout the system.
MARS applies debits and credits to the above account types in the following manner:
Although Account Type 20 makes debit and credit entries on the General Ledger, they are removed during annual closing.