The following procedures are included in this chapter:
- Account Correction Procedures for Current Fiscal Year
- Purchase order is completely paid
- Purchase order is partially paid or is a payroll purchase order
- Purchase order is completely or partially filled
- Purchase order is new
- Revenue transaction
- Account Correction Procedures for Prior Fiscal Year
- Refund of prior year's expenditure
- Refund of prior year's receipt
- ACTCHG vs. FNDCHG
- Aging Payables
- Bank Reconciliation Procedure
- Identifying reconciliation errors
- Balancing Programs
- FINDET and FINSUMM
- Carryover Project
- Change Fund Procedure
- Closing a Partially Paid PO
- Deleting Accounts/Vendors
- Establishing New Appropriation/Budget Accounts After the Start of the Fiscal Year
- Miscellaneous Expenditure Correction Procedures
- Performing a Fund to Fund Transfer
- Backing out a transfer
- Performing a Fund to Fund Advance
- Repaying or backing out an advance in the current fiscal year
- Repaying or backing out an advanced in the prior fiscal year
- Petty Cash Funds
- Miscellaneous Receipt Correction Procedures
- Resequencing Checks
- Procedures for Voiding Checks
- Voiding current fiscal year checks
- Voiding prior fiscal year checks
Account Correction Procedures for the Current Fiscal Year
These procedures are to be used to correct a situation where an expenditure transaction has been charged against an incorrect budget account number. Different procedures are provided depending upon the status of the purchase order.
- Completely-Paid Purchase Order: to be used in situations in which the purchase order originally making the transaction is completely paid.
- Partially-Paid PO/Payroll PO: to be used in situations in which the purchase order is partially paid, or the transaction is associated with a payroll purchase order.
- Completely/Partially filled PO: to be used in situations in which the purchase order has been completely or partially filled.
- New PO: to be used in situations in which the purchase order does not have any transactions against it.
- Revenue Transaction: to be used in situations to correct a revenue transaction.
If the PO which originally made the incorrect transaction has been completely paid, and the PO is from the current fiscal year, you can make the correction by using the procedure found in the USAS Reference Manual in the program ACTMOD. The option to use is option "D" labeled "expense/supplies distribution". Another option is to follow the procedure below for "Partially Paid or Payroll PO".
Partially-Paid PO or Payroll PO
- Using USASWEB/Receipts, write a "Reduction of Expenditure" for the amount of the incorrect transaction against the budget account to which the transaction was erroneously posted.
- Issue a Purchase Order to a MEMO vendor number whose vendor name is "CORRECTING ENTRY", (if one does not currently exist you must enter one via the program USASWEB/Vendors, or via the programs USASWEB/PO or POSCN). Enter an item on this PO to the budget account which should have been charged originally, for the amount of the transaction. The suggested item description is "TO CORRECT POSTING ERROR". You will use the program POSCN or USASWEB/PO to perform this step.
- Process this purchase order for payment using the program USASWEB/Invoices.
- Process a memo check using the CKPROC program to complete the correction procedure.
Completely/Partially Filled PO
If the PO is completely or partially filled, you may use VERINV option "5" to change the account charged.
If the purchase order does not have any transactions issued against it, you may use the "modify" option in POSCN or USASWEB/PO to change the account charged.
Depending on the option chosen within the modify function of POSCN, modifying the quantity, price or account code on a purchase order may constitute a change order.
Another option is to use VERINV to change the account charged.
Using the program USASWEB/Refund, post a "Refund of Receipt" for the amount of the receipt in error, using the revenue account to which the receipt was originally receipted.
Using USASWEB/Receipt, post a "Receipt" for the amount of the receipt in error, using the correct revenue account. The suggested item description is "TO CORRECT POSTING ERROR OF RECEIPT _______".
Account Correction Procedures for Prior Fiscal Year
This procedure is to be used to refund a prior year's expenditure or a prior year's receipt.
To refund a prior year's expenditure means the district wants to refund (take back) the amount that was issued on the warrant/memo check from the prior fiscal year and put it back into the district's fund used for the expenditure. A warrant check that was never processed through the bank or a warrant/memo check that contained the wrong amount are just a couple of examples why a district would need to refund a prior year's expenditure.
To refund a prior year's receipt means the district wants to refund money that was receipted to them in the prior fiscal year. Incorrect receipt amounts is just one example why a district would need to refund a prior year's receipt.
Refund of Prior Year's Expenditure
The following procedure is to refund a prior year's expenditure that involved a warrant check.
- Warrant check should NEVER be voided.
- Warrant check should be reconciled (as if it had cleared the bank) using the RCNCLE program
- Money should be receipted into the fund used for the expenditure using USASWEB/Receipt or ARF. When receipting the money in USASWEB/Receipt or ARF, use the 5300 receipt code - Refund of Prior Year's Expenditure.
- If the check needs to be reissued, do a USASWEB/Refund (select check option). When processing a refund, use the 5300 receipt code.
The following procedure is to refund a prior year's expenditure because the expenditure was incorrect (no check involved).
- Money should be receipted into the fund used for the expenditure using USASWEB/Receipt or ARF. When receipting the money in USASWEB/Receipt or ARF, use the 5300 receipt code - Refund of Prior Year's Expenditure.
Post a purchase order, invoice and memo check (using a correcting entry vendor) to the correct budget account.
YTD figures for 1099 purposes has not been reduced and may cause problems at the end of the calendar year if the person refunding the money doesn't manually make adjustments in USASWEB/Vendors.
Refund of Prior Year's Receipt
- Post a purchase order to the person, etc. who is to receive the money using POSCN or USASWEB/PO. If the company/person is not a vendor (i.e. student), create a vendor number for the person/company prior to creating a PO or in the case of receipting too much money, most districts have a "correcting entry" memo vendor number.
- Post an invoice and check to the vendor (or an invoice and memo check for a correcting entry vendor) using USASWEB/Invoice and CKPROC to the xxx 7500 9xx account code (refund of prior year's receipt).
ACTCHG vs. FNDCHG
A common situation that occurs in USAS processing is when to use ACTCHG and when to use FNDCHG. ACTCHG is used to change accounts within the same cash account. FNDCHG is used to change accounts from different cash accounts.
ACTCHG physically updates all transactions that utilize the "old" account and will show them under the "new" account.
The accounts must belong to the same cash account.
Examples of using ACTCHG include:
- Adding additional significance to the accounting structure (i.e. OPU, Subject, etc)
- Reducing account significance, including the ability to collapse multiple accounts into a single account
- Correct account coding structure after financial transactions have been posted against the account. For example, if you have expended money from an account and then realized the account had an incorrect object code, you can use ACTCHG to change the account using the correct object code. If the new budget account doesn't exist, then ACTCHG will add it automatically.
The FNDCHG program is a companion program to the ACTCHG program. It provides the user with the ability to change the fund number and SCC code of all accounts associated with a specific Fund/SCC combination. In FNDCHG, the SCC must equal all zeroes or begin with a 9 or the user will get an "invalid SCC" error. SCC's of 0001-8999 cannot be used to distinguish a cash account - they belong to the 0000 SCC.
In order to use FNDCHG, the new fund must not already exist.
For example, if a user wants to change fund 014 0000 and several of their 007 9xxx funds to agency funds 022 9xxx, they would use FNDCHG since the accounts are separate cash accounts and the 022 9xxx fund doesn't exist.
There are situations where ACTCHG and FNDCHG cannot be used to change account codes. These include:
- changing a cash account with an SCC between 0001 and 8999 to an SCC of 9xxx FNDCHG or ACTCHG won't allow you to change a partial cash account to another cash account. For example, an 009 5000 account is part of the 009 0000 cash account so in essence you would be trying to transfer part of a cash account into another cash account. In order to take just certain accounts from one cash account and charge them to a new cash account would require the district to manually enter the new account through ACTSCN and then either do an account correction transaction or transfer the appropriate amount to the new account.
- if the new account already exists. If you are trying to change one fund to another fund that already exists, you cannot use FNDCHG. Instead, you need to use the "Fund-to-Fund Transfer" option in ACTMOD to transfer the money from the old account to the "new" account.
Aging Payables via State Software
One of the needs users commonly express is the desire to be able to enter invoices into the computer system as soon as the item and invoice have been received, but delaying payment until close to the invoice due date. That way the data entry into the computer system can be spread over a greater length of time minimizing workload fluctuations, while at the same time enhancing the use of the district's available cash resources. This also has the advantage of making additional management reports available from the computer system that reflect the district's outstanding liabilities.
While the USAS OECN State Software does not currently allow you to enter an invoice due date, it does have the ability to enter the invoice issue date. By creatively utilizing this data item you can accomplish a great deal of the 'aging' features desired.
You can use the USASWEB/Invoice program to record all invoices as they are received, and instead of entering the invoice issue date you could enter the date that they wish to pay the invoice. For many districts this may not cause any inconvenience since a number of districts do not enter the invoice issue date at all in order to save data entry time. The CKPROC program has the ability to select a range of invoice dates. Thus, you could then use USASWEB/Invoice to enter all invoices upon receipt, and then use CKPROC at the desired times
As an alternative you could still enter the correct invoice date for invoices due within 30 days of issue and use appropriate date ranges CKPROC program to select the proper invoices. Under this scenario, only invoices due in a shorter time span would have to have their dates adjusted.
While it is recognized that this may only partially accomplish the stated goals, it may stimulate ideas on more creative use of the software to improve its value to you as a management tool.
Bank Reconciliation Procedure
Reconciliation, on a regular basis of bank statements, is imperative for good financial management of a school district. One method for performing a bank statement reconciliation is outlined below.
- Obtain bank statement(s) from banking institution(s).
- Sort cancelled checks into ascending sequence by check number if they are not returned in this order by the banking institution(s).
Using the USAS program RCNCLE or AUTOREC, reconcile all checks that have been cleared, (cancelled and returned), by the banking institution(s).
The RCNCLE program has both a single check and multiple check option.
When you have large numbers of sequential, (contiguous), checks that are to be reconciled the multiple check option should be utilized.
Please note that only the following check types need be reconciled with
W - Warrant
C - Clearance/Payroll
B - Refund
I - Investment
T - Transfer
- Using the USAS program CHEKPY, generate a check register report asking for only "Outstanding" checks and using the selection option selecting all checks through the current date. This report should show only those checks which are still outstanding, (i.e.-- checks issued, but not yet cleared through the banking institutions).
- Using the USAS program FINDET, generate a summary financial report.
- Add to the total current available balance, (from the FINSUMM report), the total of the outstanding checks from the outstanding check register report, (Step #4). Subtract from this total any deposits posted to the computer system that have not been credited to your account by the banking institution. (This last item would typically be due to a deposit made late in the month that was posted on the computer, but was not posted by the bank on the current bank statement).
- Compute the total of all bank statements, change funds, petty cash
funds, and investments.
- Compare the total from Step #6 with the total from Step #7. If they are identical, the banks statements agree, (i.e.---are reconciled), to the financial statement from the computer system. If this is the case, you are finished with this procedure.
Identifying Reconciliation Errors
If the statements do not reconcile, a number of conditions could be the cause of the problem. Listed below are steps which can be taken to identify the discrepancy.
- Using the USAS program FINDET, generate a detailed financial report for the accounting period in question. Compare the total available balance as shown on this report with the total available balance as shown on the summary financial report, (from Step #5 above). If the totals do not agree, attempt to isolate the problem to a particular fund, and from there to a particular transaction. The most likely cause of this phenomenon would be an inaccurate date entered on a transaction or series of transactions. Contact Computer Site personnel for assistance in making corrections when these two financial reports do not reflect identical totals.
- If the computer shows more money than the financial institution(s), the following items should be checked:
Check to insure that only those checks which have not yet cleared the bank(s) are reflected on the "Outstanding" check register report from Step #4, (above). Make certain that all "memo" transactions have been posted against the computer system, (e.g.---STRS Employer's Share).
Check to see that all deposits made are reflected on the bank statement. It is possible that a deposit made, and posted on the
computer system, was not credited on the bank statement(s), or was credited for a different amount.
Check to see that a deposit was not "double-posted" on the computer, (i.e.---entered twice on two different receipts).
- If the computer shows less money than the financial institutions(s), the following items should be checked:
Check to insure that a check that is still outstanding is not missing from the "Outstanding" check register report from Step #4, (above). If the reason for a check not showing up on the report is because it was mistakenly reconciled, use the program RCNCLE and reverse reconcile the check. If the check was never reconciled, but is still missing from the "Outstanding" check register report, you will need to obtain assistance from Computer Site personnel in correcting this situation.
Check to see that all Change Funds, Petty Cash Funds, and Investments have been accurately reflected in the total from Step #7, (above).
Check to insure that all deposits shown on the bank statement(s) have been posted on the computer system.
Make certain that all interest income has been deposited on the computer system.
The following are balancing programs that must be used on a regular basis in order to ensure the integrity of the USAS data files.
ACTBAL: an account balance program. It compares FTD & MTD amounts on each cash/appropriation/budget and revenue account with the total of the transactions on these accounts. If the totals
aren't equal, an error report is generated indicating the particular account that is out of balance.
Reasons why a district would get error messages:
- improper run of nightly ACTBAL
- district processing in USAS during the nightly ACTBAL run
- system crash or other error during transaction processing
user aborted out of a transaction incorrectly
We recommend the ITC run ACTBAL nightly because it will reduce the possibility of their districts being out of balance at the end of the month or other fiscal period. Please contact your ITC for further details.
BALCHK: creates a report that may be run at any time of the month to see if the current postings of receipts and expenditures are in balance. BALCHK gives you MTD, FYTD & YTD expenditures of the cash, budget and appropriation accounts; MTD, FYTD & YTD revenues of cash and revenue accounts. The totals are compared, and if they are in balance, you then know that all of the account totals are in balance. If they don't balance, you will receive an error message on the BALCHK.TXT report. BALCHK will also check to see that encumbrances on the PO files match encumbrances on the account
file and will generate an error on the report if they are out of balance. FIXENC program can be used whenever the amount from the PO files is incorrect and the encumbrances on the accounts are incorrect.
FINDET and FINSUMM: generate detailed and summary cash reports. If your ACTBAL is in balance, then your FINDET and FINSUMM reports should be in balance. The FINDET lists all of the detailed
transaction information for each cash account while the FINSUMM summarizes each cash account amount. By balancing FINSUMM to FINDET, you are ensuring expenditure/receipts that were posted match account totals during the day when other users are running programs. The ending balances on each of these reports can be compared on the screen without printing the reports. If they match, then the transaction information matches the cash account totals. If the totals are not in balance, refer to the "Identifying Reconciliation Errors" section in the USAS User Guide for a list of steps which can be taken to identify the discrepancy.
PODETL: generates a detailed purchase order report containing information on purchase order items. You may use the outstanding option to generate the total remaining encumbrance amount
and compare it with the "current encumbrance" total on the BALCHK report. They should be identical. If not, execute FIXENC to correct the encumbrances and then regenerate BALCHK and compare totals again.
Establishment of a Carryover Project
- The establishment of a carryover project can be performed in one of two ways depending upon whether the establishment of the carryover project is within the same fiscal year as when the project funds remaining were originally received.
- If the carryover project is not being established within the same fiscal year as when the project funds were originally received, then perform a Fund to Fund Transfer (see the procedure, "Fund to Fund Transfers") to move the monies to the carryover project. Please note that this may require a new "Amended Certificate of Estimated Resources". If the carryover project does fall within the same fiscal year as when it was established, then the following method is suggested.
- Establish the new Cash Balance, Revenue, Appropriation, and Budget Accounts needed by use of the program ACTSCN. Note that the only dollar amounts entered during account creation would be those dealing with the anticipated revenues and/or fiscal year-to-date appropriations/budgets.
- Using the program USASWEB/Refund, process a Refund of a Receipt in the existing (old) project for the amount of cash left in the existing project.
- Using the program USASWEB/Receipt, process a Receipt to enter the monies into the carryover project. It is suggested that you use a revenue account with an appropriate 4000 series Receipt Code that identifies the money as Federal money.
Change Fund Procedure
The procedure for starting or closing a Change Fund is structurally identical to that of a Petty Cash Fund (see the procedure, "Petty Cash Funds"). Responsibility for the funds is placed in an individual as with the Petty Cash Fund.
However, unlike a Petty Cash Fund, the funds to initiate a Change Fund may be taken from the fund needing it, (i.e.---Food Service, Athletics, etc.).
Change Funds, like Petty Cash Funds, must be closed at the end of each fiscal year. They should also be closed during extended periods of inactivity.
For a detailed procedure on opening or closing a Change Fund use the procedure outlined for Petty Cash Funds.
Procedure for Closing a "Partially Paid" PO
A common problem that occurs USAS processing is that a Purchase Order that should have been flagged as "Completely Paid" is erroneously flagged as "Partially Paid". This is caused by improperly responding to questions in the USASWEB/Invoice program, or is due to changing circumstances in the relationship with the vendor.
If the amount paid on the PO item is less than the amount issued for that item, you can make the correction using the program USASWEB/Invoice and indicating that you wish to process the PO containing the item in question. This will require that you use a new Invoice Number. When the item incorrectly flagged as "Partially Paid" is displayed, you should indicate that it is to be processed for payment. When prompted for the item amount you should enter the difference between the item issue amount and the item paid amount, (i.e.-- the amount of the remaining encumbrance). When prompted for the status, you MUST indicate "C" for Cancellation. This will cause the computer to cancel the item, and clear the remaining encumbrance. It will not cause a check to be generated for this amount.
However, if the amount paid on the PO item is greater than or equal to the amount the item was originally issued for, you MUST enter in $0.00 when prompted for the item amount. When prompted for the status, you MUST indicate "C" for Cancellation. This will cause the computer to flag the PO as closed.
DELACT will generate a report listing accounts that have no current activity. Accounts listed on the DELACT report may be deleted from the system using ACTSCN (refer to the ACTSCN chapter in the USAS Reference Manual for further details on how to delete one account or mass-delete accounts). The best time to use DELACT is at the beginning of the fiscal year in order to remove obsolete accounts but you can use it any time of the year when you would like to delete an account.
If any transactions are found relating to the account, the account WILL NOT appear on the DELACT report. This means any transactions from the current year or prior fiscal years (as many years as you have on your system).
Deleting accounts in ACTSCN that DO NOT appear in the DELACT report will generate an error report the next time DELACT is run.
The program also prompts the user for the number of years of historical amounts the user would like to check on the history record. The minimum number DELACT will search for is 3 years because of the 5-year forecast, which requires 3 years of history for general fund and related account. The accounts with history in the past three years (that are otherwise deletable) will show up in DELACT with an asterisk * next to them. The user may then decide whether to delete it or keep it on file for historical info. Accounts not used for at least 3 years will show up as deletable without the asterisk *.
Listed below are frequently asked questions on the DELACT program:
- How come my account isn't showing up on the DELACT report?* There could be several reasons but the most popular include:
- The account is found in the EIS acquisition record. This situation can be avoided by selecting the option in DELACT to exclude the search of the accounts on the EISACQ.IDX file. No need to worry, if you delete the account, no damage is done to the EIS files.
- The account is found on the USPS payroll side as a pay account or is referenced by current or future payroll records or a payroll .BATCH file.
- There are no transactions posted to an account, but money was appropriated and later deducted from one or more budget accounts.
- What does the DELACT error report mean? It means accounts were deleted that should not have been Such as:
- Transactions (REQs, POs, etc) were still on file for an account that was deleted.
- Orphaned account - budget and appropriation accounts still exist for a cash account that was deleted.
DELVEN will list vendors with no activity. Vendors are considered deletable if:
- YTD and FYTD amounts equal 0.
- There are no transactions on file that are associated with the vendor (POs, invoices, etc).
We recommend not deleting old vendors since this might destroy an audit trail. If the vendor is deleted, and then down the line, used again, reports from prior fiscal years will not match current vendor information. We recommend changing the status of the vendor from "active" to "inactive". An "inactive" status will restrict USAS programs from using this vendor.
A DELVEN error report will be generated at the end of the run if any errors were found. The DELVEN will contain vendor numbers found in transaction files (PO, invoices, investments) that do not exist on the master vendor file.
Procedure for Establishing New Appropriation/Budget Accounts
The establishment of new appropriations/budgets is handled with the program ACTSCN. Documentation on the usage of the ACTSCN program may be found in the USAS Reference Manual.
The area in which most users experience problems is when adding new accounts after the start of a fiscal year. The only real difference in adding a record in the middle of the fiscal year is that in appropriation and budget accounts, you do not enter an amount into the "Initial Appropriation" or "Initial Budget". Rather, you enter the desired budget amount into the "Fiscal YTD Additions" and "MTD Additions" fields.
The procedure outlined in the above paragraph would also be used to add ("new") monies to an existing appropriation/budget, (i.e.---When you are introducing previously unappropriated/budgeted funds as opposed to moving the monies from an existing appropriation/budget). The only modification to the above procedure is that you would add the amount of the ("new") monies being introduced to the current values of the Fiscal YTD and MTD Additions fields, rather than replacing the existing values.
Miscellaneous Expenditure Correction Procedures
The following scenarios address miscellaneous expenditure corrections:
I want a PO returned to "open" status but I have already invoiced it.
Use VERINV - Option 1 - to delete the invoice. This will reopen the purchase order.
I invoiced and paid the wrong vendor. The check has been voided. I want to delete the invoice but I can't because it's associated with a voided check. What do I do?
You can't delete an invoice or change a vendor on a purchase order once a check has been created. Use USASWEB/Invoice to cancel the purchase order and then create a new
purchase order to the correct vendor, and Invoice and CKPROC it as usual.
I need to delete several PO's created yesterday due to several purchase orders being out of order (we use pre-numbered PO forms). The purchase orders were created from requisitions, however, the
requisitions were deleted once they were converted to purchase orders. Do I have to re-enter all of the purchase orders or is there some kindof "short-cut" I can take.
You can use the "modify" option in POSCN or USASWEB/PO to modify the purchase order numbers to their correct sequence.
I paid a vendor from the wrong purchase order. The check's been reconciled. Is there still a way I can adjust which purchase order it should have been paid on? The correct PO is still open.
The following steps should be taken to correct this:
- Reverse reconcile the check using RCNCLE.
- Resequence the check to a dummy check number using CHKSEQ - Option 1.
- Void the dummy check. By voiding the check, the invoice associated with it has been cancelled and the purchase order set back to its status prior to invoicing it.
- Invoice and CKPROC the correct PO using the original check number (this amount may not be the same as the incorrect PO). You will have to either ask for credit or write another check if the first purchase order was for a greater amount. Please note that the PO number on the check stub will not be correct so the district should be making notes throughout this procedure for auditing purposes.
I handtyped a warrant check and forgot to enter it onto the system. I have closed for the month and need to process this check on the system.
It is not possible to add this to the system as an expenditure with a date from the previous month. Providing the number on the physical check is still open on the system, you should go through the normal expenditure process of creating a purchase order, invoice, and check in the current processing month. You should make sure to use the check number from the physical check when running CKPROC. You will also want to be sure to make a notation as to why the physical check has a date from a month prior to the date of the purchase order, invoice, and check on the system for auditing purposes.
I have a purchase order that has been invoiced and processed for payment. However, one of the items has caused a negative cash balance; thus, it was not included on the check. How can I get this item processed for payment prior to receiving money into this cash account?
Use VERINV, Option 5 - Change account, to change the account code on this one item. This will change the account code on the invoice as well as the purchase order. You can then re-run CKPROC to create a check for this item. Once the money has been received into the original cash account, an error correction can be processed through ACTMOD using the Expense/supplies distribution option to move the expenditure back to the correct account.
A warrant check was voided on the system under the assumption it had been lost. However, the check has since been found, cashed, and now cleared the bank. How can I "unvoid" the check in order to reconcile the check.
The following steps should be taken to "unvoid" a warrant check:
- Using CHKSEQ, Option 1, resequence the voided check to a "dummy" check number (i.e. a check number you will never use). This will open up the check number of the physical check making it possible to use that number again on the system.
- When the check was voided, the associated invoice was cancelled and the purchase order set back to the status prior to posting the invoice. You will need to enter a new invoice through USASWEB/Invoice for the amount of the check.
- Run CKPROC using the original check number. The check number is now back at a warrant status and can be reconciled as normal.
Performing a Fund-To-Fund Transfer
Fund-To-Fund transfers are made through the use of the program ACTMOD. Prior to posting a fund-to-fund transfer you must insure that sufficient funds are available in the "7200" function expenditure accounts of the donor fund. If sufficient funds are not available you should perform a budget and/or appropriation modification using the ACTMOD program. Documentation of the use of the ACTMOD program may be found in the USAS Reference Manual.
It should be noted that most transfers of this type introduce ("new") monies in the receiving fund which may require a new appropriation level for that fund, which in turn may require a modified "Amended Certificate of Estimated Resources".
Steps taken to perform a Fund-to-Fund Transfer include:
- Access ACTMOD's Fund-to-Fund Transfer option.
- Enter the transfer amount.
- Enter the transfer budget from which funds will be transferred. (the function code on this budget account must be a 7200 code).
- Enter the revenue account to be increased (the receipt code must be 5100 code).
- To complete the transfer, you are required to enter a purchase order and memo check.
The State's USAS Software does not currently handle advances and transfers in the manner now desired by the Office of the Auditor of State. This procedure, however, provides the method most closely conforming to the Auditor's guidelines currently available with the State's USAS Software.
Backing out of a Fund-To-Fund Transfer
To "back out" of a fund-to-fund transfer means the district wants to "take back" the money from the "transfer-in" account and put it back into the "transfer-out" account. An accidental transfer to the wrong account or incorrect amount transferred may be reasons why a district needs to back out of a fund-to-fund transfer.
Steps taken to back out of a Fund-To-Fund Transfer:
- Process a "Reduction of Expenditure" using USASWEB/Receipt on the transfer-out budget account using the 7200 910 account code (tranfers-out). This process puts the money back into the account that originally transferred-out the money.
- Process a "Refund of Receipt" using USASWEB/Refund on the transfer-in revenue account using the 5100 (transfers-in) account code. This process takes out the money that was receipted into the transfer-in account.
Performing a Fund-to-Fund Advance
Cash advances between funds are made with ACTMOD. Advances are performed using option "F" labeled as "Fund-to-Fund Transfer". When prompted for the function code of the account, you must use the code "74X0" as this signals the system that you are performing an Advance. If insufficient funds are available in the "74X0" function account, you should make a budget and/or appropriation modification prior to posting the Advance.
Steps taken to perform a Fund-to-Fund Advance include:
- Access ACTMOD's Fund-to-Fund Transfer option and enter the advance amount.
- Enter the advance budget from which funds will be transferred. (the function code on this budget account must be a 74X0 code).
- Enter the revenue account to be increased (the receipt code must be 52xx code).
- To complete the advance, you are required to enter a purchase order and memo check.
Repaying or Backing Out of an Advance in the Current Fiscal Year
Repaying or backing out of an advance follow the same procedure, as listed below, but they are quite different in their meanings. Repayment of an advance means the district wants to repay the account that originally made the advance. Backing out of an advance means the district wants to "take back" the money from the "advance-in" account and put it back into the "advance-out" account. An accidental transfer to the wrong account or incorrect amount transferred may be reasons why a district needs to back out of an advance.
If the repayment or backing out is being made in the same fiscal year the following procedure may be used:
- Using USASWEB/Refund, post a refund for the amount of the advance using the revenue account to which the advance was originally receipted (52xx - advances-in receipt account code).
- Using USASWEB/Receipt, post a "Reduction of Expenditure" for the amount of the advance using the budget account from which the Advance was originally made (74x0 92x advances-out budget account code).
Repaying or Backing Out of an Advance in the Prior Fiscal Year
If the district is repaying an advance originally made in a prior fiscal year, they should do an advance, using ACTMOD, back to the originating fund using a 7420 function code with a 922 object code. A revenue account utilizing a 5220 receipt code must be used for the "advance-in" account in ACTMOD.
The State's USAS Software does not currently handle advances and transfers in the manner now desired by the Office of the Auditor of State. This procedure, however, provides the method must closely conforming to the Auditor's guidelines currently available with the State's USAS software.
Procedure for Petty Cash Funds
Opening a Petty Cash Fund
- If one does not exist, create a vendor record of the form "Jane Doe, Custodian of Sample Local Petty Cash Fund".
- Issue a PO to the vendor (from step #1), charging a budget account from the General Fund, (the Auditor's Office indicates that Petty Cash Funds MUST be funded from the General Fund). Then, invoice and CKPROC the PO. Provide the check to the Petty Cash Fund custodian.
- Using USASWEB/Receipt, write a Reduction of Expenditure, using the amount of the Purchase Order and the budget account used in Step #2.
- You must now include the amount of the Petty Cash Fund as a reconcilable item when balancing at the end of each month, as it will show as available cash on the computer, but not appear on any bank statement.
Replenishing a Petty Cash Fund
- When someone requests petty cash, the petty cash custodian disburses the petty cash from the fund in exchange for receipts related to the purchases. No entry is made in the system at this point.
- When the fund requires more cash, or at the end of the fiscal year, the petty cash custodian requests a check for the difference between the cash on hand and the total assigned to the fund.
- The receipts should be verified, and a PO, invoice, and check should be issued to the vendor created for the petty cash custodian, charging all relevant budget accounts used for the related purchases.
Closing a Petty Cash Fund
- Obtain the monies from the Petty Cash Fund custodian and deposit them in the bank, posting a receipt using USASWEB/Receipt. The account used on the receipt should be in the General Fund, but its exact designation is not significant. A Miscellaneous Local Income account is recommended.
- Using USASWEB/Refund, write a Refund of Receipt, using the amount and account number from Step #1. When prompted, you should respond that a warrant check is not needed for this transaction.
- At this point, you no longer include the amount of the Petty Cash Fund as a reconcilable item when balancing at the end of each month.
The purposes of this procedure are two-fold. The first purpose is to provide a means of opening and closing petty cash funds while leaving a complete audit trail on the computer system, while the second purpose is to change the format of the monies involved in the Petty Cash Fund. It is recommended that all Petty Cash Funds be maintained in NOW checking accounts rather than as actual cash for purposes of safety. It is also recommended that the size of the Petty Cash Fund be set so that it will generally need to be replenished twice monthly.
The Auditor's Office requires that all Petty Cash Funds be closed at the end of each fiscal year. If a Petty Cash Fund will be inactive, (have no transactions), for several months, (such as during the Summer), it is recommended that it be closed for that period of time as well.
Miscellaneous Receipt Correction Procedures
The following scenarios address miscellaneous receipt corrections:
I processed a "refund of receipt" but forgot to say "Y" to creating a warrant check. How do I get the check?
After querying the refund in USASWEB/Refund, reverse the refund using the "Reverse" option. Then process another "refund" in USASWEB/Refund clicking on "Y" to creating a warrant check.
I entered the wrong account number on a receipt. How can I correct this?
After querying the receipt in USASWEB/Receipt, select Reverse to reverse the receipt or part of the receipt with the incorrect account code. Then receipt it in using the correct account.
I processed a "refund of receipt" but used the incorrect check number. How can I fix this?
Use CHKSEQ - Option 1 - to resequence the check to the correct check number.
The incorrect date and receipt number was entered on a receipt. How can I correct this?
You can modify the receipt number and date on an existing receipt using the MODIFY option.
CHKSEQ is used to change check numbers that are currently on the system, as well as regenerate the check form text file for checks already created and posted. Resequencing options include both a plain resequence (leaving the "old" check number unused - Option 1) or an option to resequence and leave the old check number on file as a voided check - Option 3.
Using Option 1
We recommend using Option 1 when you have entered the wrong check number in CKPROC or CHKUPD (with AUTOPOST).
Using Option 2
Use Option 2 whenever you need to regenerate the check form text file.
Using Option 3
We recommend using Option 3 when you need to resequence check numbers because the physical check was somehow destroyed (printer jam) or when a check is lost and must be reissued.
Example of using CHKSEQ - Option 3:
A district's printer jammed while printing checks 650-699, and physical checks 663 through 689 were destroyed in the jam (meaning they can't be used). Using CHKSEQ, (Option 3) we can void and resequence the checks that were destroyed and then reprint them (using Option 2). Using Option 3 will void the destroyed checks and resequence them to new check numbers.
--------------------------------------------------------------------------------------- | | | Enter your full name (First Middle Last): | | _________________________________ | | Sample User | | | | Enter your district name: | | _________________________________________ | | Sampleville City Schools | | | | Enter reason for changing check numbers (2 Lines) | | __________________________________________ | | Printer jammed when printing 650-699 | | | | __________________________________________ | | | | | | Enter the check numbers you wish to change and void that are currently on the | | Check-File. If you want to change just one check number, enter that number as | | the first and last number. | | | | Enter the first number: ______ | | 663 <-- enter first physical check # that was destroyed | | | | Enter the last number: ______ | | 689 <-- enter last physical check # that was destroyed | | | | | | | | Enter the new check numbers that will replace those check numbers currently on | | the Check-File | | | | Enter the new first number: ______ | | 700 <-- enter next available check # on the system | | | | Number of checks to change: 000027 <-- # of checks that were voided and resequenced| | New number of last check: 000726 <-- last check # assigned on the system | |_____________________________________________________________________________________|
Now, checks 663-689 have been resequenced to numbers 700-726 while the checks that printed OK at the beginning of the check run were left alone (650-662) and the checks at the end of the check run that were not physically destroyed have been left alone as well (690-699). However, the last 10 checks were never printed either.
Next, we need to regenerate the printable check file to include the checks that weren't printed yet (690-699) plus the checks we resequenced (700-726).
--------------------------------------------------------------------------------------- | | |*** Part 2 - Prepare check print format *** | | | | | | Please note: The written amount of the check can only be printed | | if less than $1,000,000 | | | | Do you want to print the written amount of the check ? (Y/N <Y>): _ | | | | If you district heading pre-printed on form? (Y/N <Y>): _ | | | | Enter the comment line for all checks for this run | | If no comments are wanted enter a <CR>. | | | | Enter comment now, if any: | | ________________________________________________________ | | Recreate check form file for #690-726 | | | | Enter the starting check number: ______ | | 690 <-- enter the next physical check to print | | | | Enter the ending check number: ______ | | 726 <-- enter the # from the "new number of | | last check" field in Option 3 | |**** Preparing custom forms **** | | | |Following are all the output file available for you to print. If you | |are not sure of which to print, please contact your system manager. | | | | | | Output files: | | | | Custom check forms: CHKSEQ_CHK.TXT <-- check form file to print | | | | Custom check items: CHKSEQ_STB.TXT <-- check stub page to print | | | |_____________________________________________________________________________________|
Procedures for Voiding Checks
Voiding a Current Fiscal Year Check
Checks should be voided only if the amount of the check is incorrect; the invoiced items were not to have been paid; it was issued to the wrong vendor; it was issued against the wrong bank; or the physical check form was ruined or lost.
If only the account(s) charged are incorrect, the Account Correction Procedure should be used to make the necessary correction.
Voiding a Check
- The actual voiding of the check is performed using the USAS program VOIDCK. This causes the check to be set to a "void" status, the associated invoice records are set to a "cancelled" status, and the associated purchase order is set back to a "new" status with the funds re-encumbered.
- If a check is to be re-issued to this vendor using this PO, you should use the USASWEB/Invoice program to indicate the amount of payment to be made. You would then run CKPROC to create a new check.
- If, for some reason, a check is not to be issued against the PO as it had been originally entered, you should use the USASWEB/Invoice program and "Cancel" each item of the PO. The bill should then be paid by using a newly created PO with a different number.
Message "You Cannot Void this Check"
The message, "You Cannot Void this Check" will be received if the status of the check indicates it cannot be voided. Checks with an original status of warrant, refund, or memo can be voided as long as they do not have a current status of either reconciled or voided. Any other combination of status codes cannot be voided and will result in the above error message.
Physical Check Form Ruined
If the physical check form was ruined, you have the option of using VOIDCK, as indicated above, or using the CHKSEQ program and selecting the option to change the check number(s) and void the old check(s). Consider the following example.
Suppose you used CKPROC to issue checks # 101 - 110. As the checks were being printed, check #105 was mangled. You could do the following:
- Re-align the physical forms in the printer and start printing with check #106. This will finish printing with check #110 and the correct check numbers will be printed on the correct physical forms.
- Use CHKSEQ with option 3 to resequence and void the "old" checks.
- Renumber check #105 to become check #111.
- Hand type the information on physical check form #111 or use CHKSEQ option 2 to create a check text file to print check 111.
Prior Fiscal Year Check
A check from a prior fiscal year should never be voided. Instead, the check should be reconciled (as if it had cleared the bank), and the money receipted into the fund used for the expenditure using a 5300 receipt code, "refund of a prior year's expenditure". If you need to re-issue the check, do a refund of receipt (with check) from the 5300 receipt account.
There may be a potential problem with the above procedure. By reconciling the check, the YTD figure for 1099 purposes has not been reduced, and may cause problems at the end of the year if the person voiding does not make adjustments via USASWEB/Vendors.
In a future version of USAS, the software will know what month and year of processing is in progress, and will likely be able to automatically handle this situation. Until that time, you may need to manually update the calendar YTD figure for the vendor.