At RECONNECT, David Laden, Director of Accounts Receivable Services at the University of Minnesota, spoke about how to leverage the PeopleSoft Accounts Receivable module for processing your organization’s receivables. During his presentation, Laden discussed design considerations, tips and tricks, and methods to monitor payment processing and open receivables.
About the University of Minnesota
David Laden currently serves as the Director of Accounts Receivable Services at the University of Minnesota. In his position, he oversees customer maintenance, billing, receivables, collections, and credit card operations and compliance. He previously served as the Accounts Receivable and Billing functional lead for the university’s implementation of PeopleSoft Financials. Laden has also previously held positions as Management Information and Business Analyst and as an Information Systems Consultant.
The University of Minnesota is a land grant university that was founded in 1851. Its five campuses include Twin Cities, Crookston, Duluth, Morris, and Rochester. Additionally, there are over 20 off-campus locations including extension offices, research, and outreach centers. The University of Minnesota is comprised of 66,880 students and 20,389 faculty and staff. In the 2018 fiscal year, the total operating expenses amounted to $3.7 billion.
The University of Minnesota’s relationship with Oracle and PeopleSoft Financials began in July 2008 when they implemented PeopleSoft 8.9. In April 2015, they upgraded to PeopleSoft 9.2. The university is currently on Image 25. The university leverages General Ledger, Billing, Accounts Receivable, Treasury, Grants, Contracts, Project Costing, Procurement, Accounts Payable, Expenses, and Commitment Control. The University of Minnesota currently runs PeopleTools 8.56.16 and Oracle Database 12.2. There are approximately 3,750 financial system users.
Leveraging PeopleSoft Accounts Receivable
There were three major learning objectives of this presentation:
- Learn how the use of PeopleSoft Accounts Receivable can improve efficiency and internal controls
- Learn about design considerations for the use of the PeopleSoft Accounts Receivable module
- Learn how you can monitor activity in the PeopleSoft Accounts Receivable module
There are several aspects to consider when addressing customer maintenance, including:
- Design consideration of single file versus multiple customer files
- Distributed vs. centralized maintenance function
- The level at which the customer is set up
- Several attributes (i.e. collector, credit analyst, statement group, and dunning group) to set up at the customer level
- It is important to remember that attributes are optional at the customer level
- AR parameters to consider are Collector, Credit Analyst, Statement Group, Dunning Group, Groups, Attachments, and Payment Predictor Method
The University of Minnesota used a single customer file for the entire university system. The single customer file contained sponsored research and non-sponsored activity for all campuses, colleges, and administrative units. The set up was maintained by a single central group. The customer was typically set at the highest organizational level and address locations were used for subsidiaries and divisions. The university built a bolt-on page in PeopleSoft to address a communication need for the customer request process.
When looking toward the future, there are several items that the University of Minnesota is considering. The team is also rethinking the level at which customers get set up and utilizing the hierarchy that is built into PeopleSoft. They want to consider proactive maintenance and its benefits. The university also wants to incorporate additional features into the custom customer request screen (automatic assignment of tax code, validate address earlier in process, and systematic duplicate checking).
In regard to Accounts Receivable for payment entry, there are several items to consider. The business will want to address what types of payments they will accept (i.e. cash, check, EFT, credit/debit card, virtual payment, direct debit). You will also need to consider distributed check payments and centralized check receiving/depositing vs. outsourcing check processing to a lockbox service. Will the EFT payments load via bank statement processing, separate bank file, or manually key? Will the credit and debit card payments be received via PeopleSoft delivered functionality, eBill Pay, or will you capture credit card payments via another means? Will credit card fees be absorbed centrally, allocated to colleges/departments, or will a convenience fee be charged?
The University of Minnesota decided to accept cash, check EFT (SCH and wire transfer), and credit/debit card (non-sponsored only). Cash payments are an exception. They utilize a bank lockbox service for check processing and receive a daily data file and image file. They also load a separate EFT file from the bank into the Accounts Receivable module. The university uses a locally developed web application to accept credit/debit card payments, and the credit card fees are allocated back to the departments.
There are several future considerations that the University of Minnesota has in regard to Accounts Receivable. Throughout the community, the university will continue reinforcing sending checks to the bank lockbox. EFT payments represent a big opportunity for improvement, and the university needs to decide whether to continue its own web application in regard to credit card payments. The university will also implement direct debit functionality.
There are also several design considerations for applying payments within Accounts Receivable. Is it going to be distributed or centralized? Will the payment go towards the oldest item or will you follow the payment directions? Will you manually apply via the payment worksheet? Will you utilize payment predictor for automated payment application?
The University of Minnesota decided to utilize payment predictor with basic rules. They made minor modifications to pre-process payment data and fixed the problem with invoice numbering. They also manually apply remaining payments via payment worksheet and always apply payments based on customer’s directions.
There are two considerations that the University of Minnesota has for the future:
- Refining the payment predictor methods
- Investigating using MICR information to identify Customer ID for use on payment worksheet
There are also a couple of design considerations for unidentified payments, including:
- Whether to leave as unapplied payment on the worksheet
- Whether to create On Account item (OA entry type)
- Will you place all on a control customer record or identify customer and place on that customer’s account?
- If the item referenced is already closed, will you apply to other items or refund?
The University of Minnesota chose to leave unidentified payments as unapplied for a short period of time. They move all unapplied payments to “on account” by the end of the month. On accounts are placed on customer records. There is a separate process through queries that monitors on accounts.
There are also a couple of design considerations for refunds. Will you keep balances on the account, and if so, for how long? What is the trigger to refund to customer?
The University of Minnesota chose to always take direction from the customer on how to handle the payment. They utilize delivered integration with AP through modification to capture additional fields for AP vouchers.
The University has several future considerations for Collections. They are going to make greater use of WorkCenters and develop additional monitoring queries. They will also learn how Condition Monitor could assist in monitoring past due accounts and on account payments.