Differences in Carry Over Encumbrances
- Former user (Deleted)
- Former user (Deleted)
- 1 Possible Differences
- 1.1 Account Deleted
- 1.2 Invoice Backdated to the Prior Fiscal Year
- 1.3 Invoices Defaulted to Future Fiscal Year Date
- 1.4 Invoice Modified/Deleted After New Fiscal Year Opened
- 1.5 Negative Invoices
- 1.6 Partial Invoices after Full Invoices
- 1.7 Prior Year Purchase Order Date Modified to Date in Current Fiscal Year
- 1.8 Purged Check
- 2 Unable to Locate Specific Transactions
When Classic's Carry Over Encumbrance amounts do not balance with Redesign's carry over encumbrance amounts, the Redesign's 'Classic Carry Over Reconciliation' report should be run to see the accounts involved and the carry over amounts adjusted. The 'Grand Total' on the report should match the difference between Redesign and Classic's carry over encumbrances. The Impact on Encumbrance report may be helpful in determining the positive and negative adjustments that were made. You can filter the report by entering the account code from the Classic Carry Over Reconciliation to find the Purchase Order transactions tied to that account.
Possible Differences
The following list may not include all possible causes of differences between Classic and Redesign carry over encumbrances.
Description | Positive or Negative on the Classic Carry Over Reconciliation | What to look at in addition to Impact on Encumbrance report | Solution |
|---|---|---|---|
Negative | Classic AUDITS report Archive of prior year files | No update needed - Budget Adjustment is Optional Document transactions for audit records | |
Negative | Classic AUDITS report Archive of prior year files | No update needed - Budget Adjustment is Optional Document transactions for audit records | |
Positive | Classic AUDITS report Archive of prior year files | No update needed - Budget Adjustment is Optional Document transactions for audit records | |
Positive or Negative | Classic AUDITS report Archive of prior year files | No update needed - Budget Adjustment is Optional Document transactions for audit records | |
Positive or Negative | Invoice in Redesign | Post Encumbrance Impact Adjustment & Budget Adjustment in Redesign | |
Positive or Negative | Activity ledger Invoice Status and Dates | Post Encumbrance Impact Adjustment & Budget Adjustment in Redesign | |
Prior year Purchase Order Date Modified to Date in Current Fiscal Year | Negative | Classic AUDITS report Archive of prior year files | No update needed - Budget Adjustment is Optional Document transactions for audit records |
| Positive | Date of PO and Invoice transactions vs. Classic Purge Date in USACON Compare PO Remaining Encumbrance amounts Classic v. Redesign | Delete PO and Invoice transactions in Classic using POAEDT, POHEDT, and INAEDT |
Account Deleted
This happens if an account with a prior year encumbrance is deleted.
Locate Transactions
Generally, these type of transactions will appear normal on the Impact on Encumbrance Report.
In Classic, run the AUDITS report. Search for the amount or the account code to determine if the account was deleted. The Classic ACTSCN will give the user a warning if there are FYTD amounts for the account, but will allow the account to be deleted if there are no associated transactions. The encumbrances that were carried over from the prior year may have been modified or there may have been an account change.
If additional confirmation is needed, review the account in Classic in the archive files of the previous fiscal year.
Solution
No update is needed but a budget adjustment is optional. Since the account is now deleted, the Redesign Carry Over Encumbrance figure is decreased. When the encumbrance transactions were changed in Classic, the encumbrances would have been moved to the new account and will now be included there in Redesign. After consulting with the district, if it is determined that the Appropriated amount should take this into account then a budget adjustment can be entered. If no adjustment is made, then the difference would reflect in the FYTD Expendable amount when balancing reports between Classic and Redesign.
Even if no adjustments are made, these transactions should be located and documented during the post import process for audit purposes.
Invoice Backdated to the Prior Fiscal Year
This happens when the Invoice date is modified or deleted and re-added in Classic from a current fiscal year date to a date in the previous fiscal year. When the fiscal year is closed in Classic (ADJUST is run), the Carry Over Encumbrance amount is set at that time. When these transactions are modified after the fact, the Carry Over Encumbrances are not decreased in Classic to account for the modification. When Redesign calculates the amount on import, that figure will now be included in (reduce) the Carry Over Encumbrance total because the Invoice is dated in the previous fiscal year. This causes the difference between the Classic and Redesign carry over encumbrances.
Locate Transactions
Run the Impact on Encumbrance Report for the Full Account Code in order to locate the transaction(s) associated with the amount of the difference. These transactions may appear normal on the Impact on Encumbrance Report and have no remaining encumbrance.
In Classic, run the AUDITS report. Select options to 'Report on all programs' and to 'Report on 1 file.' Choose option 3-INAMT file & enter a specific date range. If the transaction in question is dated in the previous fiscal year, then enter 7/1 of the current fiscal year to the current date. If the transaction in question is dated in an older fiscal year, then enter 7/1 - 6/30 for the fiscal year after Invoice date. Locate changes made to the Invoice in question. The AUDITS report will show if the Invoice Date was modified or if the Invoice was deleted and re-added with a different date. Compare the time of the change to when ADJUST was run to close the previous fiscal year.
Review the Invoice in Classic in the archive files of the previous fiscal fear to confirm the transaction did not exist at the end of the previous fiscal fear prior to when ADJUST was run.
Solution
No update is needed but a budget adjustment is optional. Since the Invoice is now dated in the previous fiscal year it will reduce the carry over encumbrance calculation and should not also reduce the encumbrance amount for the current fiscal year. After consulting with the district, if it is determined that the Appropriated amount should take this into account then a budget adjustment can be entered. If no adjustment is made, then the difference would reflect in the FYTD Expendable amount when balancing reports between Classic and Redesign.
Optionally, the Invoice can be modified to a date of 7/1 in the current fiscal year in Classic. This would require the data to be re-imported to Redesign. The difference will no longer show on the Classic Carry Over Reconciliation.
Even if no adjustments are made, these transactions should be located and documented during the post import process for audit purposes.
Invoices Defaulted to Future Fiscal Year Date
This happens if the Invoice date was left to default to the current system date (July) when the district was still in June processing. In Classic, this would have reduced the encumbrances prior to the Fiscal Year End close. When the fiscal year is closed in Classic (ADJUST is run), the Carry Over Encumbrance amount is set at that time. In Redesign, the calculation for the Carry Over Encumbrances from the prior year would take into account the transaction date so any Invoices with a July date would not be included.
Locate Transactions
Run the Impact on Encumbrance Report for the Full Account Code in order to locate the transaction(s) associated with the amount of the difference. These transactions may appear normal on the Impact on Encumbrance Report and have no remaining encumbrance.
In Redesign, review the Invoice Date and Created Date on the AP Invoices grid. If the transaction is for the current fiscal year, the Created Date can be compared to the Classic ADJUST Date/Time in the Classic Migration Configuration on the Redesign Configuration page to see if the transaction was created with a July date prior to when ADJUST was run.
In Classic, run the AUDITS report. Select options to 'Report on all programs' and to 'Report on 1 file.' Choose option 3-INAMT file & enter a specific date range. If the transaction in question is dated in the current fiscal year, then enter 7/1 of the current fiscal year to the current date. If the transaction in question is dated in an older fiscal year, then enter 7/1 - 7/31 for the fiscal year before the fiscal year of the Invoice date. Locate changes made to the Invoice in question. The AUDITS report will show when the Invoice was created or if the Invoice Date was modified. Compare the time of the change to when ADJUST was run to close the previous fiscal year.
Review the Invoice in Classic in the archive files of the previous fiscal fear to confirm the transaction did exist prior to when ADJUST was run.
Solution
No update is needed but a budget adjustment is optional. Since the Invoice is now dated in the current fiscal year it will reduce the encumbrance amount for the current year and should not also reduce the prior year carry over encumbrance amount. After consulting with the district, if it is determined that the Appropriated amount should take this into account then a budget adjustment can be entered. If no adjustment is made, then the difference would reflect in the FYTD Expendable amount when balancing reports between Classic and Redesign.
Optionally, the Invoice can be modified to a date of 6/30 in the prior fiscal year in Classic. This would require the data to be re-imported to Redesign. The difference will no longer show on the Classic Carry Over Reconciliation.
Even if no adjustments are made, these transactions should be located and documented during the post import process for audit purposes.
Invoice Modified/Deleted After New Fiscal Year Opened
This happens if an Invoice with a previous fiscal year date is modified or deleted after ADJUST has been run for that fiscal year.
Locate Transactions
Generally, these type of transactions will appear normal on the Impact on Encumbrance Report.
In Classic, run the AUDITS report. Search for the amount, account, or associated PO (if one has been located) to determine if the Invoice was deleted or modified. A difference in carry over encumbrances can happen if an Invoice previously existed (when the fiscal year was closed) but then was deleted after the start of the new fiscal year. A change to the date or amount of the transaction could also cause the difference.
If additional confirmation is needed, review the Invoice in Classic in the archive files of the previous fiscal year to confirm the details of the transaction prior to when ADJUST was run.
Solution
No update is needed. Since Redesign considers the current state of the transaction, the encumbrances will reflect accurately in Redesign. Based on what change was made, the impact to encumbrance would now show in the correct year based on the current transaction information. In Classic, the Carry Over Encumbrances would not have been accurately updated for these changes. After consulting with the district, if it is determined that the Appropriated amount should take this into account then a budget adjustment can be entered. If no adjustment is made, then the difference would reflect in the FYTD Expendable amount when balancing reports between Classic and Redesign.
Even if no adjustments are made, these transactions should be located and documented during the post import process for audit purposes.
Negative Invoices
When negative invoices are created, Redesign will not allow the encumbered amount to go negative. Depending on what has been invoiced for a transaction, this can cause a situation where the remaining encumbrance will be calculated differently in Redesign than it would be in Classic.
Locate Transactions
Run the Impact on Encumbrance Report for the Full Account Code in order to locate the transaction(s) associated with the amount of the difference.
In this particular example, the item was fully invoiced and credits were applied in the form of negative invoices. When the disbursement for a positive invoice is created, it creates a negative impact on encumbrance. When a disbursement for a negative invoice is created, it creates a positive impact on encumbrance.
Next, look up the Invoices associated with the Purchase Order on the AP Invoice grid. Filter the grid by entering "=" and the PO number located on the Impact on Encumbrance report.. Then sort the records in the grid by the invoice date. In this example, notice that the total amount encumbered on the Purchase Order was paid out on one of the Invoices/Disbursements. The two additional negative invoices would add to the remaining encumbrance.
Solution
After the final import in the Redesign, create encumbrance impact and budget adjustment to fix the encumbrance. This will not change the Classic Carry Over Reconciliation but it provides the audit trail explaining the changes made to fix the accounts.
Open the record for the Purchase Order. The PO will have a remaining encumbrance will not be invoiceable. Since this difference was caused by the negative invoices there are not true remaining encumbrances on the PO. You can verify by looking up the history of the PO in Classic. In order to remove the remaining encumbrance, click on the to the right of the account code on each PO item (only available for admin users).
Create an impact on encumbrance adjustment to negate the amount (enter as a negative). This will reduce the total remaining encumbrance on the PO and the current encumbered amount on the associated expenditure account. If possible, it is recommended to use the same date as the data was imported to Redesign.
The import also created a Carry Over Encumbrance on the Expenditure Account. Access the expenditure account under CORE and create a budget adjustment (negative amount) to reduce the Carry Over Encumbrance amount by the amount in order to place the Expendable figure back to where it was before the import.
Filter the Expenditure Account grid to locate the Account Code from the PO Item. Click the view icon for the account. Then, click on .
On the pop up window, click Create to create a new budget adjustment.
If possible, it is recommended to use the same date as the data was imported to Redesign. Choose 'Adjustment' as the transaction type. Enter the amount as a negative value.
Review the Expendable amount on the Expenditure Account to ensure it balances to the Classic Expendable figure. After all budget adjustments are created, the SSDT Budget Transactions report can be run to verify the entries.
Provide detailed information in the descriptions of both the impact of encumbrance and budget adjustment as to why these were created. This provides an audit trail and can be attached to the Classic Carry Over Reconciliation.
Partial Invoices after Full Invoices
In Redesign, once a Purchase Order item is invoiced with a 'Full' status you can’t post additional partial invoices to it but Classic would allow invoices to be entered with past or future dates. If partial invoices had already been posted, the full invoice then could have been backdated prior to the last partial invoice. Since the Redesign is a date driven system, when the imported transactions contain partial invoices dated after full invoices Redesign calculates the remaining encumbrance differently than it did in Classic. When the Classic data is imported the Redesign must post the transactions and calculate encumbrances based on the transaction dates. When it does not arrive at the same answer a Classic Carry Over Encumbrance adjustment is posted.
Locate Transactions
To determine the transaction associated with this amount, navigate to the PO grid and open the Advanced Query using the icon at the top right side of the grid.
Open the properties under Charges, then open properties under Account. Select Full Account Code and either drag it over or double click to add it to the query box. Select Equals for the Operation and enter the full account code (from the Classic Carry Over Encumbrance report) into the Filter Value. Then click 'Apply Query.'
If the Purchase Order grid does not already show a column for 'Total Remaining Encumbrance' use the 'More' option to add this column. Use the grid to filter the columns for Invoiceable is 'false' and Total Remaining Encumbrance is not equal to zero by typing .ne 0 into the filter. This will filter the PO grid to any POs against that account that have a Total Remaining Encumbrance not equal to zero.
If you are unable to locate the transactions using the Advanced query, run the Impact on Encumbrance Report for the Full Account Code in order to locate the Purchase Order(s) associated with the amount.
On the Activity Ledger, use the More option to add the 'Status' column. Sort by TYPE (first) and then Date. Filter the grid by the Purchase Order number. Look for any Partial invoices that have an Invoice Date that is after a Full invoice.
NOTE: These transactions can be located on the Classic Import Log. Not all Suspicious Invoices listed will cause a difference in the Carry Over Encumbrances. Navigate to the System menu and go to the Monitor page. Choose the tab for Admin Logs. Click the view icon for the Classic Import Log. The section labeled "InvoiceImportImpl: invoice" will contain warnings for any Suspicious Invoices that contain full invoice items with a date prior to partial invoice item dates.
Solution
After the final import in the Redesign, create encumbrance impact and budget adjustment to fix the encumbrance. This will not change the Classic Carry Over Reconciliation but it provides the audit trail explaining the changes made to fix the accounts.
Open the record for the Purchase Order. The PO will have a remaining encumbrance (which match the amount from the activity ledger) will not be invoiceable. Since this difference was caused by the full before partials from the import there are not true remaining encumbrances on the PO. You can verify by looking up the history of the PO in Classic. In order to remove the remaining encumbrance, click on the to the right of the account code on each PO item (only available for admin users).
Create an impact on encumbrance adjustment to negate the amount. If possible, it is recommended to use the same date as the data was imported to Redesign. This will reduce the total remaining encumbrance on the PO and the current encumbered amount on the associated account.
The import also created Carry Over Encumbrance on the Expenditure Account. Access the expenditure account under CORE and create a budget adjustment to correct the Carry Over Encumbrance amount by the amount in order to place the Expendable figure back to where it was before the import.
NOTE: If the remaining encumbrance amount on the purchase order is positive then both the impact on encumbrance adjustment and budget adjustment will be negative. In situations that involve Cancelled_Partial or Cancelled_Full transactions, the remaining encumbrance amount on the purchase order can show as negative instead. If the remaining encumbrance amount on the purchase order is negative then both the impact on encumbrance adjustment and budget adjustment will be positive.
Filter the Expenditure Account grid to locate the Account Code from the PO Item. Click the view icon for the account. Then, click on .
On the pop up window, click Create to create a new budget adjustment.
If possible, it is recommended to use the same date as the data was imported to Redesign. Choose 'Adjustment' as the transaction type. Enter the amount as a negative value.
Review the Expendable amount on the Expenditure Account to ensure it balances to the Classic Expendable figure. After all budget adjustments are created, the SSDT Budget Transactions report can be run to verify the entries.
Provide detailed information in the descriptions of both the impact of encumbrance and budget adjustment as to why these were created. This provides an audit trail and can be attached to the Classic Carry Over Reconciliation.
Prior Year Purchase Order Date Modified to Date in Current Fiscal Year
This happens when a Purchase Order date is modified or deleted and re-added in Classic from a previous fiscal year date to a date in the current fiscal year. When the fiscal year is closed in Classic (ADJUST is run), the Carry Over Encumbrance amount is set at that time. When these transactions are modified after the fact, the Carry Over Encumbrances are not decreased in Classic to account for the modification. When Redesign calculates the amount on import, that figure will no longer be included in the Carry Over Encumbrance total because the Purchase Order is dated in the current fiscal year which causes the difference between the Classic and Redesign carry over encumbrances.
Locate Transactions
Run the Impact on Encumbrance Report for the Full Account Code showing on the Classic Carry Over Reconciliation to locate the Purchase Order(s) associated with the amount of the difference. These transactions may appear normal on the Impact on Encumbrance Report and have no remaining encumbrance.
In Classic, run the AUDITS report. Select options to 'Report on all programs' and to 'Report on 1 file.' Choose option 8-POHIST file & enter a specific date range. If the transaction in question is dated in the current fiscal year, then enter 7/1 of the current fiscal year to the current date. If the transaction in question is dated in a previous fiscal year, then enter 7/1 - 6/30 for the same fiscal year as the PO date. Locate changes made to the Purchase Order in question. The AUDITS report will show if the PO Date was modified or if the Purchase Order was deleted and re-added with a different date. Compare the time of the change to when ADJUST was run to close the previous fiscal year.
Review the Purchase Order in Classic in the archive files of the previous fiscal year to confirm the encumbrance existed with the previous fiscal year date prior to when ADJUST was run.
Solution
No update is needed. Since the Purchase Order is now dated in the current fiscal year it will be included in this year's encumbrances and should not also be included in the carry over encumbrance amount from the prior fiscal year. After consulting with the district, if it is determined that the Appropriated amount should take this into account then a budget adjustment can be entered. If no adjustment is made, then the difference would reflect in the FYTD Expendable amount when balancing reports between Classic and Redesign.
Even if no adjustments are made, these transactions should be located and documented during the post import process for audit purposes.
Purged Check
In Classic, it is possible that the Check transaction was purged but Invoice and Purchase Order were not. The Classic Purchase Order transaction will show a status of 'Completely Paid' with no remaining encumbrance amount so it would not have impacted totals on an Outstanding PODETL or the carry over encumbrance amount on the Summary reports. In Redesign, the Purchase Order is not Invoiceable but it does show a Remaining Encumbrance amount. That amount is then added to the carry over encumbrance amount which causes the difference between Classic and Redesign.
Locate Transactions
Run the Impact on Encumbrance Report for the Full Account Code in order to locate the Purchase Order associated with the amount. The Disbursement transaction will show a reference number of PURGEDAMTSPAID.
In Classic, look at the following items:
Compare the Purge Date on the USACON screen to the date of the Purchase order and Invoice to see if the transaction date is prior to the Purge Date
Search for the related Check transaction in Classic to confirm it was purged and is no longer in USAS
Look at invoice status to see if it is marked as 'Filled'
Run INVLST for all Invoices to see if the transaction in question shows on the report
Confirm the Purchase Order has a Completely Paid status with no remaining encumbrance amount
Look up Check transaction in USASDW, if available, to confirm check previously existed prior to Purge
In Redesign, look at the following items:
Confirm the Purchase Order shows that it is not Invoiceable but does have a remaining encumbrance amount
Look at the Payable grid to see if the transaction shows
Use above to verify that check transaction did previously exist prior to purge date. If the Purchase order and Invoice transactions should have been purged this will justify that they can be removed.
Solution
Before final import this can be cleaned up in Classic using the POAEDT, POHEDT, and INAEDT programs to delete the Purchase Order and Invoice transactions. This would require the data to be re-imported to Redesign. The difference will no longer show on the Classic Carry Over Reconciliation.
INAEDT will delete the Invoice Item records (there are no header records in the Invoice files). Choose option D to delete and enter the PO number, Item number, and Invoice number.
INAEDT should be processed prior to POAEDT and POHEDT since the PO number and line items are used to look up the transactions.
POAEDT will delete the Purchase Order Item records. Choose option D to delete and enter the PO and Item number. Repeat for each item.
POHEDT will delete the Purchase Order header record. Choose option D to delete and enter the PO and Item number.
Unable to Locate Specific Transactions
While SSDT recommends locating transactions causing the difference on the Classic Carry Over Reconciliation in order to keep an audit trail, there may be situations where the district and/or ITC are not able to locate a specific transaction. In these cases, consider the following questions:
Does all or part of the difference impact the current encumbrance?
This can be determined by looking specifically at the Remaining Encumbrance amount on the Core > Account > Expenditure account vs. the Classic Account screen. There may be multiple types of transactions contributing to the difference shown on the CCOR so it is possible that the difference in Remaining Encumbrances is not the same amount as the difference on the CCOR report. In this situation, at least the transactions causing the difference in the current encumbrance must be located.
Run the SSDT Post Import Closed Purchase Orders with Remaining Balance for just that specific account code to attempt to locate transactions causing the difference. If unable to locate with this report, run a Purchase Order Detail Report from Redesign and a PODETL from Classic for the account code. Compare transactions to locate the difference. When comparing Purchase Orders on the Classic vs. Redesign report, verify that the Remaining Encumbrance amounts and transaction status are consistent in each system. Also, review for any transactions that may be missing from one of the reports if running for Outstanding only - this may indicate a transaction has a different status in Redesign than in Classic.
If the Purchase Order status is the same but the remaining balance is different:
Create an encumbrance adjustment to correct the remaining encumbrance amount. This will not change the Classic Carry Over Reconciliation but it provides the audit trail explaining the changes made to fix the accounts and corrects the current year encumbrance totals.
In order to adjust the remaining encumbrance, click on the to the right of the account code on each PO item (only available for admin users). Create an impact on encumbrance adjustment correct the amount. If possible, it is recommended to use the same date as the data was imported to Redesign. This will correct the total remaining encumbrance on the PO and the current encumbered amount on the associated account.
If the remaining encumbrance difference is positive then the impact on encumbrance adjustment will be negative. In situations that involve Cancelled_Partial or Cancelled_Full transactions, the remaining encumbrance amount on the purchase order can show as negative instead. If the remaining encumbrance difference is negative then the impact on encumbrance adjustment will be positive.
If the Purchase Order status is different in Classic vs. Redesign:
There are some cases where a Purchase Order may show a different status in Redesign vs. Classic. For example, the Purchase Order shows Completely Paid in Classic but is showing as Invoiceable (open) in Redesign so there is a remaining encumbrance on the transaction, causing the discrepancy. Since Redesign bases the PO status on whether or not a "Full" Purchase Order exists, this can happen sometimes for districts that create POs and/or Invoices with a third party software.
If the most recent Partial Invoice is in a posting period that is not archived, the period can be opened and then the status can be changed from "Partial" to "Full" when viewing the invoice.
If the most recent Invoice is in an archived posting period, create a Cancel_Full invoice for the remaining encumbrance.
In both of these situations, the difference on the CCOR will also impact the FYTD Expendable figure. A budget adjustment can also be added to the related expenditure account to update Expendable figure to balance with Classic. See additional information in the next section.
Does the district want the FYTD Expendable figure to match Classic?
If the amount is not causing a difference in the current encumbrance, then the PO is likely closed in both Classic and Redesign. This is most commonly seen when there were changes to transactions around or after the end of a fiscal year (date changes, account changes, deleted transactions). In these cases, there is no encumbrance adjustment needed, but the difference from the CCOR will impact the district's FYTD Expendable figure. (The Expendable figure is calculated by FYTD Appropriated + Carry Over Encumbrance = FYTD Expendable).
Even when unsuccessful at locating specific transactions, the district may still prefer to have their FYTD Expendable balance between Classic and Redesign. To accomplish this, a budget adjustment can be entered to the Core > Accounts > Expenditure account.
Filter the Expenditure Account grid to locate the Account Code. Click the view icon for the account. Then, click on .
On the pop up window, click Create to create a new budget adjustment.
Review the Expendable amount on the Expenditure Account to ensure it balances to the Classic Expendable figure. After all budget adjustments are created, the SSDT Budget Transactions report can be run to verify the entries.
If the CCOR difference is positive then the adjustment will be negative. If the CCOR difference is negative then the adjustment will be positive.