9.2 Processing Escheated Payments
Purpose: Use this document as a reference for how to Process Escheated Payments (unclaimed property) in ctcLink.
Audience: Accounts Payable Staff
You must have at least one of these local college managed security roles:
- ZZ Payment Processing
You must also set these User Preference Definitions:
If you need assistance with the above security roles or User Preference Definitions, please contact your local college supervisor or IT Admin to request role access.
This topic demonstrates how to process escheated payments. Occasionally, an organization issues a check to a vendor, but the vendor does not deposit it. Perhaps the vendor goes out of business. Whatever the reason, the check becomes stale-dated.
When users identify a check as stale-dated, it is informational only. When users decide to escheat a stale-dated check, they must return to the Payment Escheatment page and select Escheated instead of Stale-Dated Payment.
Stale-date should be done when a check is first selected to be worked. In order to escheat a check, the school must first make an effort to contact the person the check was written to. This usually happens sometime between 12-18 months from the date of the check. Stale-dating a check does not create any GL entries and is reversible.
Payables enables you to reclassify the stale-dated check to an escheat liability account by debiting cash and crediting escheatment liability. When users escheat payments, they enter an escheatment date. The system uses the date to control the accounting date for the escheatment entry.
Payment posting treats an escheated payment like a voided payment except that there is no option to close or restate the voucher liability.
Escheating happens when the check is going to be remitted to the state. So, first you escheat the check and second you create a new voucher for that payment to be sent to the state. The new voucher would be coded the same as the escheatment, but in reverse as it clears out this account. Escheating a check creates GL entries and is not reversible.
When you escheat a payment, you then select options to run just the Payment Posting process (AP_PSTPYMNT), or both the Payment Posting and Journal Generator process (FS_JGEN).
It is recommended to establish each user with the specific access associated with their job duties and is not recommended to simply copy one user's access to another user as this could lead to overallocation of access. However, there are situations where a group of staff within a single department all require the same access to perform similar work. In that case, the COPY function provides the ability to apply all Process Group definitions from one user to another without having to search and enter each Source Transaction and Process Group combination.
Please refer to the QRG 9.2 FSCM Security - Process Groups
Escheat the Check
NOTE: Currently Escheatment functionality is not working for Travel & Expenses. The enhancement to include this functionality for Travel checks are in progress by Oracle and will be release with FIN Image 48.
Navigation: Accounts Payable > Payments > Cancel/Void Payments > Escheat Payment
- The Payment Escheated page displays.
- Enter Bank SetID.
- Enter the appropriate information into the Bank Code field. Example: enter "BOFA" for Spokane.
- Enter the appropriate information into the Bank Account field. Example: enter "CHCK".
- Enter the appropriate information into the Payment Reference field. Example: enter "0000005004".
- Select correct Payment Method. Example: for this Payment, the method was “System Check”.
- Select Search.
- The Payment Escheatment page displays.
- Select the Escheated Check radio button. Date Escheated will default to current date. You may change this date. Remember Date Escheated is the Accounting Date for Escheatment Process.
- Enter the appropriate information into the Description field. Enter "Verified with bank contact that this check has not been cashed".
- Select Save.
- To update the payment escheatment status, it requires to run the payment post process. To run this process, please follow QRG Posting Payments.
- You have just completed the Processing Escheated Payments topic. Below is a summary of the key concepts of this topic:
- Escheated payment processing gives users the ability to reclassify stale-dated payments.
- Escheating payments transfers the payment from a cash account to an Escheated liability account.
- Payment posting treats an escheated payment like a voided payment except that there is no option to close or restate the voucher liability.
Validation and Verification
After Payment is Escheated and Payment post process run, you can check the payment tab in Voucher. It will say 'Escheated Payment'.
You must have at least one of these local college managed security roles:
- ZD Accounts Payable Inquiry
- ZZ Voucher Approval
- ZZ Voucher Entry
- ZZ_AP_MANAGER
- ZZ_AP_SPECIALIST
If you need assistance with the above security roles, please contact your local college supervisor or IT Admin to request role access.
Navigation: Accounts Payable > Vouchers > Add/Update > Regular Entry
Notice the Payment is now listed in the Schedule Payment section as an 'Escheated Payment'.
You may also check the Accounting Entries for Escheatment Process.
By using the Escheatment process, it offsets the existing Liability Accounts/Unclaimed Property. Run a query on GL Account 2001080 and summarize to view the total amount of unclaimed property.
- Process complete.
0 Comments
Add your comment