Business Processes

Many areas within the University do not allow employees to purchase old computers. If it is allowed in your area:

1. Check with/obtain approval from the campus or college chief financial manager.
2. Your unit’s IT professional support staff must perform media sanitization, Proper media sanitization is defined in the Media Sanitization Standard. This includes:
   • Removal of all University data.
   • Removal of all University-owned software (including the operating system).
   • Physical destruction of the hard drive.
3. Determine a fair market value for the remaining hardware.
4. Your cluster billing specialist enters a bill in the financial system to send the employee an invoice for the amount.
5. Sales tax must be collected. Departments should charge the appropriate sales tax rate based on where the buyer takes possession.
6. Employee pays the invoice/hardware can be collected by the purchaser.

The cost of preparing the item for sale likely will be greater than fair market value for the computer.

Occasionally departments inquire about where and how they may dispose of excess supplies/materials or used/excess equipment that was purchased for academic, research, general unit, or recharge center’s operations. 

Excess computers should not be resold. All computers/media should be disposed of following the media sanitization standards.

The Reuse Center is the only entity authorized to dispose of University property of any value online (for example, on eBay, Amazon) and has a special profit-sharing program for high value items (worth $1,000 or more). This helps ensure, no matter how well-intentioned, individual employees are not selling things using their personal accounts and depositing proceeds to their own bank accounts. 

Official University of Minnesota social media accounts may be used solely to advertise items available, if the post/tweet is not in violation of how the platform can be used. The actual transaction cannot take place on the social media site itself. An official University-sanctioned process must be used to actually make the sale (invoice from EFS, eStore, DestinyOne, etc.). Don’t use personal social media accounts for University business. 

Where the equipment to be disposed of has been capitalized as a capital asset, even if it is no longer of value, units must follow the policy and procedures for disposing of capital assets.

When a recharge center (internal sales or external sales organization) is involved, vigilance is required to ensure any sales of these items are conducted following an appropriate process. The proceeds from the sale of the excess supplies/materials/non-capital equipment or excess capital assets should be taken into consideration for the next rate development cycle. Internal sales units must ensure the proceeds (net gains or losses) go to the internal or external sales unit that purchased the supplies/equipment, to offset the original purchase. 

Any time a department wishes to dispose of used or excess items, these are the options:

• Capital assets, follow the appropriate procedures within policy based on the type of disposal. Capital assets purchased on sponsored funds must follow requirements of the sponsor.
• Reuse Center, 612-626-9152 or [email protected].
• Or contact the Controller’s Office if the above options don’t seem to fit, 612-624-1617 or [email protected].

Accounting periods in the General Ledger will be closed according to the schedule published below, on the morning of the 7th business day following the end of the month.

What time of day is the deadline? The time depends on which approvals are required:

• The morning of the scheduled close is reserved for final adjustments from Accounting Services. This means departments must be done with their entries by the evening before the period closes.
• Activity that meets the approval threshold for Accounting Services (where their approval is required) must be to Accounting Services prior to 2:00 p.m. the day before the scheduled close.
• Activity that does not require Accounting Services approval must be processed and fully approved by 10 p.m. the night before the scheduled close.
• The actual process used in the system to close an accounting period typically runs at about 9 a.m. the morning of the scheduled close (it does not run at a precise time for various reasons).
• Departments are responsible for monitoring manual journals they have created to ensure that they are fully processed (posted). Once a period is closed, it will not be re-opened to allow for further processing of a manual journal; the journal will need to be re-created with a date in an open accounting period.
• At fiscal year end, for any adjusting periods (913, for example), please consult with the fiscal year end procedures for times and dates of closings.

What is a workday/business day?

Monday through Friday, excluding University holidays. For purposes of the closing of accounting periods, the University follows the official Twin Cities campus holiday schedule. For example, the closing of December 2009 (period 6 of fiscal year 2010) took place January 12, 2010. January 12, 2010 was the 7th workday of the month due to the New Year's Day holiday.

What "number" are accounting periods?

The University's fiscal year begins July 1 and ends June 30. These are the accounting periods:

• Accounting period 0 (zero) is opening balances for non-sponsored accounts; for sponsored accounts it reflects pre-award spending (expenses incurred prior to the start date of the award).
• Accounting period 1 is July.
• Accounting period 2 is August.
• Accounting period 3 is September.
• Accounting period 4 is October.
• Accounting period 5 is November.
• Accounting period 6 is December.
• Accounting period 7 is January.
• Accounting period 8 is February.
• Accounting period 9 is March.
• Accounting period 10 is April.
• Accounting period 11 is May.
• Accounting period 12 is June.
• Accounting periods 900 through 912 are not used. (Some companies using PeopleSoft Financials use these for corrections to the corresponding accounting period, 901 for period 1 corrections, etc. The University of Minnesota does not use these periods.)
• Accounting period 913 is intended for adjustments at fiscal year end. Historically only non-sponsored activity has been allowed to take place in period 913, when the period is used (see the fiscal year-end procedures for details).
• Accounting period 914 through 999 are for central accounting adjustments (made by units within the Controller's Office only). If you see activity on your ChartField string for period 914, contact [email protected] to be referred to the appropriate resource to either explain the activity.
• Accounting period 999. When viewing sponsored activity, period 999 reflects expenses incurred after the end date of the award.
• Quarter 1 is July, August, September.
• Quarter 2 is October, November, December.
• Quarter 3 is January, February, and March.
• Quarter 4 is April, May, and June.

What is combination editing?

Combination editing is a set of rules used to improve integrity of accounting information as it is entered into the financial system.

Who needs to know this information?

All preparers of transactions need to be aware of updates made to combination editing. Anyone administering interfaced subsidiary systems will need to be mindful of new combination editing rules.

ACDPTFD_RQ (Account, DeptID, Fund required) (formerly known as ACCTDEPTFD)

The transaction is missing a required Fund, DeptID, or an Account code. This edit helps ensure the required Account, Fund, and DeptID are present for all accounting entries. All transactions require a Fund, DeptID, and Account code.

Sample of several strings that wouldn't pass this combination edit:

CS_RQ_PGPJ (Cost Share requires Program and Project) (formerly known as CS_VALID)

The transaction appears to be a Cost Share. The ChartField string requires both a Program and a Project code. If CS exists, then both Program and Project are required.

Sample of strings that wouldn't pass this combination edit:

CS_RQ_PGPJ (Cost Share requires Program and Project) (formerly known as CS_VALID)

The transaction appears to be a Cost Share. The ChartField string requires both a Program and a Project code. If CS exists, then both Program and Project are required.

Sample of strings that wouldn't pass this combination edit:

FDSPR_NOPG (Fund is sponsored, no Program) (formerly known as FUNDPROG)

The transaction appears to be sponsored. The ChartField string contains a sponsored Fund code (begins with 3xxx) but there is a Program code instead of a Project. If the Fund is sponsored, Program must be blank.

Sample of a string that wouldn't pass this combination edit:

PG_RQ_FEID (Program requires Fin EmplID) (formerly known as PRGFNEMPID)

The Program code being used also requires a Fin EmplID. A valid Fin EmplID ChartField value is required when using specific Program values.

Sample of a string that wouldn't pass this combination edit:

AC_NO_PGPJ (Account is cash: no Program or Project) (formerly known as ACCT_CASH)

The Account code being used does not allow the use of either a Program or Project. If Account is cash, Program and Project must be blank.

Sample of a string that wouldn't pass this combination edit:

PGORPJ_RQ (Program or Project required) (formerly known as ACTNONCASH)

The Account code being used requires the use of either a Program or Project. If Account is non-cash, then Program or Project is required.

Sample of a string that wouldn't pass this combination edit:

FDPJ_RQ_PG

The system prevents use of a string that contains a non-sponsored Fund, a Project, and no Program code. This rule requires a Program code when a current non-sponsored Fund (1XXX range) and Project are entered. 

The ChartField string contains a current non-sponsored Fund and Project. Either:

• Change the Fund to a sponsored Fund (3xxx) OR
• Remove the Project and use a Program instead OR
• This is Cost Share, include a Program code and CS value

Sample of a string that wouldn't pass this combination edit:

In July 2023, changes were implemented regarding late cost transfers as part of the revision of the Processing, Documenting, and Approving Financial and Accounting Transactions policy. Relevant changes included the following: 

• Late cost transfers were defined as those occurring 90 days after the initial incurrence rather than 60 days.
• A process was formalized for requesting an exception to University policy for late cost transfers that add costs to a sponsored project.

The following phased changes were effective September 13, 2023.

Phase 1- September 13, 2023 through December 31, 2023

Exception requests submitted within 180 days from the date the original expense posted (non-salary) or pay date (salary) were considered for approval (if submitted September 13, 2023, expenses posted on or after March 17, 2023 considered for approval). 

Phase 2 - January 1, 2024 through June 30, 2024

Exception requests that are submitted within 180 days (was 90 days in September 2023 guidance memo) from the date of the original expense posted (non-salary) or pay date (salary) considered for approval (if submitted on January 2, 2024, expenses posted on or after October 4, 2023 considered for approval). In addition, approval comments will include guidance regarding whether the transaction would be approved under full implementation of the policy or if additional documentation would be necessary.

• Full policy implementation.
• Exception approval will only be considered when extenuating circumstances exist outside of the unit’s control (if submitted on July 1, 2024 expenses posted on or after April 2, 2024 are considered for approval).

What do “effort to properly record” and “did not execute” mean? 

“Effort to properly record” means either charging a cost to the correct ChartField String when first made OR written evidence that a cost was identified as being charged to the incorrect ChartField String. “Did not execute” means that the unit was not able to take timely action to prepare and submit the cost-transfer.

What’s not changing?

Any late cost transfer that is processed outside of 90 days from the original expense  post will continue to route for additional review in EFS (journal entries over $50,000) or HRMS (retro distributions). 

Form UM1921 and supporting documentation are required to be attached to activity outside of 90 days from the original expense.  

What is good supporting documentation?

• Final, signed award notices or contracts and Notice of Grant Awards (NOGA).
• Pre-award account request and the date it was submitted to SPA.
• Correspondence among University staff or a sponsor.
• Calculations for the amount transferred via a retro distribution.
• Support that clarifies ChartField String usage, specifically the Project code. 

Additional Resources

A recording of the Late Cost Transfers Best Practice presentation can be accessed at Financial Training under Continuing Education Materials: Financial Continuing Education Video Channel.

Department Deposits

Where are the Depositories on campus located? Your UCard is required to gain access to the Depositories located on campus, you must swipe your UCard in order for the depository to unlock.

• East Bank: Phillips Wangensteen Bldg., next to Rm. 2-596
• St. Paul: Coffey Hall, main level near old Bursar location
• West Bank: Heller Hall, next to Rm. 55

Departments will need to monitor deposit transactions in PeopleSoft to ensure the deposit status reads "finalized". This means that your deposit has been processed by the bank. If there are any adjustments to your cash deposit, you will see a comment and an adjustment on the deposit. Cash deposit adjustments will be made against the first account string listed on the deposit.

Do not send any documentation with your cash deposit other than your Deposit Detail Report. Departments are responsible for scanning any documentation that they wish to keep into Perceptive Content.

Desktop deposit resources

• Preparing and approving
• Order ink, roller, deposit bags
• Order banking supplies
• Starting a desktop deposit
• Desktop deposit quick info
• Keying the MICR line 1
• Keying the MICR line 2
• Manual deposits
• Manual deposits off campus
• End-of-day balancing for desktop deposit
• Troubleshooting contact list for desktop deposit
• Approving desktop deposits in PeopleSoft
• Deposits requiring amount adjustments
• Preparing deposits in PeopleSoft
• Imaging via email
• Imaging via imaging system printer (see also the Imaging processes section)

There has always been a focus on delivering quality financial reporting at the University of Minnesota. A standard process is followed to enhance and deliver stronger financial reporting. Committees of University stakeholders from across the system help guide financial reporting strategy and theory for initiatives including new reporting development and reporting enhancements. These committees are made up of business process owners from central units and finance directors, business analysts, data analysts or accountants from various colleges across the University. Proposals for new reporting or reporting enhancements are typically vetted through two of the committees (the Finance Report Design Team and the Finance Strategic Reporting Committee). The third committee (the BPO Reporting Team) prioritizes work requests based on feedback from the first two committees. A fourth group (EFS Module Support-Reporting) takes the prioritized list as provided by the BPO Reporting Team and facilitates the technical builds required to meet reporting requirements.

Finance Report Design Team

The Finance Report Design Team, known as the FRDT, consists of people in the University community who create, process, and review transactions in our financial system on a daily basis as part of their normal job duties. The committee was created to provide tactical guidance for the University's central financial reporting units.

Finance Strategic Reporting Committee

The Finance Strategic Reporting Committee, known as the FSRC, consists of program and finance directors from the University community. The group was created to provide strategic guidance for the University's central financial reporting units.

Business Process Owners (BPO) and Reporting Support Team

The BPO Reporting Team consists of the business process owners (BPOs) for financial reporting, the team lead of the EFS Module Support's Reporting Team, and the Office of Information Technology (OIT) service owner for the technology we use for reporting.

• Mollie Viola, the systemwide Controller for the University (BPO)
• Lori Standafer, director of Accounting Services, part of the Controller's Office (BPO)
• Julie Tonneson, VP, University Budget Office (BPO)
• Nicole Pilman, director of Sponsored Financial Reporting, part of the Controller's Office (BPO)
• Rob Howieson (OIT service owner for reporting)
• Molly Koewler (EFS Module Support Reporting Team Lead)

The Gramm-Leach-Bliley Act (GLBA) Safeguards Rule requires the University of Minnesota to implement safeguards to insure the security and confidentiality of certain non-public customer information. The Safeguards Rule protects certain private information identifiable to individuals that is obtained when the University offers or delivers a financial product or service to them. The University must develop, implement, and maintain a comprehensive information security program containing administrative, technical and physical safeguards that are appropriate based upon the University's size, complexity and the nature of its activities. The following materials are provided for training and education purposes.

How does the University comply with the GLBA Safeguards Rule?

GLBA Information Security Program

This document describes how the University complies with the GLBA Safeguards Rule. All units that handle or maintain covered data must follow the Information Security Program.

How do I know if my unit handles or maintains information that is protected under the GLBA Safeguards Rule? If so, what am I required to do under the University’s Information Security Program in relation to this data?

The following documents can help you determine if you handle or maintain customer information protected under the GLBA Safeguards Rule, and if so, what steps you must take to safeguard that data.

• GLBA Safeguards Rule Decision Tree
  Use this chart to determine if your unit handles or maintains customer information that must be protected under the GLBA Safeguards Rule.
• GLBA Compliance Guidance and Certification Form
  To be completed annually by colleges and administrative units that handle or maintain covered customer information. Submit to the Controller’s Office.

Understanding more about GLBA Safeguards Rule, additional information and examples

The following documents provide an overview of the GLBA Safeguards Rule regulation as well as examples of financial services or products and a reference guide of in-scope and out-of-scope activities.

• GLBA: Implementation of the Safeguards Rule 
  This document provides information regarding current and future exposure to and compliance with the law.
   
• GLBA Safeguards Rule: Examples of Financial Services or Products 
  Most University departments will not have exposure to the Safeguards Rule. However, units should review this list of activities that can subject a department or program to the law, and examples of customer information that must be protected.
   
• GLBA Safeguards Rule: Reference Guide 
  This chart provides examples of in-scope and out-of-scope at the University.
• Complying with the Safeguards Rule
  Guidance document provided by the Federal Trade Commission.

The Red Flags Rule (RFR) requires the University to implement a written identity theft prevention program designed to detect the warning signs (or "red flags") of identity theft in day-to-day operations. Each unit that handles covered accounts must develop reasonable policies and procedures to identify, detect, and respond to red flags in their area. The regulation includes additional responsibilities for users of consumer reports and units that issue credit or debit cards (including certain declining balance cards such as Gopher Gold). Read more about Fighting Fraud with the Red Flags Rule in this information provided by the Federal Trade Commission (FTC).

The Controller’s Office provides oversight for the University’s Identity Theft Prevention Program. The following materials are provided in support of this role.

">How does the University comply with the Red Flags Rule?

• University’s Identity Theft Prevention Program
  This document describes how the University complies with the Red Flags Rule. All units that handle covered accounts must comply with the guidelines described in this Program.
• RFR Certification of Compliance Form Annual completion required
  Colleges and administrative units that must comply with one or more sections of the Red Flags Rule must annually complete and submit this form to the Controller’s Office.

How do I know if my unit handles accounts that are protected under the Red Flags Rule? If so, how do I comply with our Identity Theft Prevention Program?

• RFR Self-Identification Questionnaire
  This four-question form helps you decide quickly if your area is in-scope.
• RFR Compliance Guidance
  Use this document to determine which sections of the Red Flags Rule apply to your area and how to comply.
• RFR Department Identity Theft Prevention Plan
  This document offers a starting point for in-scope units to identify processes and procedures that assure compliance. It is a good business practice to document processes and procedures employees are expected to follow. Units are encouraged to build on or reference existing practices.
• FTC Examples of 26 Red Flags
  Guidance information provided by the Federal Trade Commission (FTC).
• Incident Log (Optional)
  This optional template may help you track identity theft attempts or incidents in your area that could suggest a need for changes to your processes or procedures. Completion is not required.

Visit this page to review the detailed materials available about the internal and external sales processes.

University of Minnesota departments that accept payment cards (credit or debit cards) as a form of payment for goods and services are contractually obligated to follow the Payment Card Industry Data Security Standard (PCI DSS). The PCI DSS is a multifaceted security standard developed and owned by the major payment card companies that includes requirements for security management, policies, procedures, network architecture, software design, and other critical protective measures. The standard comprises 12 requirements that are organized in 6 related groups or “control objectives” to protect cardholder data wherever it resides - ensuring that sensitive payment card information is handled safely and a high information security standard is maintained. A copy of the PCI DSS can be found on the Payment Card Industry Security Standards Council (PCI SSC) website. 

How does the University comply with the PCI DSS?

This document describes how the University complies with the PCI DSS. All units that handle or maintain customer's cardholder data must follow the Payment Card Program.

University Payment Card Program

How do I know if my unit handles information that should be protected by the PCI DSS? If so, how do I comply with the PCI DSS?

If your department or unit wishes to accept payment cards (credit or debit) as a method of payment from your customers, you must meet University policy, state and federal laws, contractual obligations, and rules of the University's banks and financial institutions. This includes meeting compliance with the PCI DSS. Additional information can be found within the policies and procedures below.

• Policy: Accepting Revenue Via Payment Cards
• Procedure: Managing Payment Card Acceptance
• Procedure: Obtaining Approval to Accept Payment Cards
• Procedure: Requesting Changes to Payment Card Accounts
• Procedure: Closing Payment Card Accounts
• Policy: Information Security

I’d like to understand more about the PCI DSS. Where can I locate additional training, examples and resources?

Payment Card Account Forms & Documents

• UM 1609 Payment Card Account (PCA) form
• UM 1623 Employee Non-Disclosure Form
• UM 1624 Department Payment Card Manager Form
• UM 1634 Incident Response and Continuity Plan
• Cardholder Data Flow Charts (zip)
• Payment Card Inventory List (Template)
• Payment Card Manager Compliance Certification form (docx)
• Payment Card Operational Procedures (Template)
• Payment Card Terminal Disposal Form
• Payment Card Terminal Loan Program Application Form
• Payment Card Terminal Order Form
• Payment Card Terminal Inspection Log

Payment Card Account Resources

• Keep It Secure
• Understanding PCI DSS Compliance Brochure
• Safeguard Against Skimming
• Quick Reference Guide - PCI DSS Version 3.2.1
• PCI DSS Glossary of Terms and Definitions Version 3.2
• PCI DSS Version 3.2.1
• Terminal Review - 6Ss

SAQ and Compliance Documentation Guidance

• SAQ and Compliance Documents Handbook

Authorize.net Guidance Documentation

• Getting Started Guide
• Video Tutorials

New Payment Card Manager Information

As a new Payment Card Manager at the University of Minnesota, you are the departmental staff person responsible for management of your payment card account(s). Payment cards include credit and debit cards used to pay for services offered by the University. Management of the payment card account(s) mean you must be knowledgeable about the payment card acceptance process in your unit, understand the Payment Card Industry Data Security Standards (PCI DSS) and how they relate to your payment processing, and be the first point of contact for all questions concerning your payment card account(s). You also must ensure that your departmental policy and processes are adequately documented to guarantee the following standards are maintained:

• Keep all customer cardholder information secure and confidential. The department will be responsible for any losses due to poor internal or inadequate controls.
• Restrict access to payment card data and processing to appropriate and authorized personnel only.
• Establish appropriate segregation of duties between payment card processing, the processing of refunds, and the reconciliation function. Supervisory approval of all payment card refunds is required.
• Complete an annual PCI DSS Self-Assessment Questionnaire (SAQ) along with other documents and forms, to ensure compliance with associated policies and procedures, and report the results of this assessment to Accounts Receivable Services within the Controller's Office.
• Contact Accounts Receivable Services prior to the implementation of any technology changes affecting payment card transaction processing, as all proposed changes to your payment card environment require University approval.
• Contact University Information Security (UIS) at [email protected] in cases of suspected security incidents or potential data breaches.

Ensure that you, and any other personnel with access to cardholder information, receive information security awareness training upon hire and at least annually thereafter.

If you haven’t done so already, make sure you have read and are familiar with University Policy Accepting Revenue via Payment Cards, as it outlines the operational and compliance responsibilities of Departments that accept credit and debit cards as a method of payment.

Authorize.net

If your merchant account(s) integrates with an Authorize.net payment gateway to process credit card payments online, you will need to set up your access to the Authorize.net Administrative Portal. If you are replacing a previous Payment Card Manager, this previous individual should be able to provide you with access by setting you up as a new user, and then you will be able to delete the previous Payment Card Manager once you log into the Administrative Portal. If this is a new account, you will soon receive an e-mail from David Laden, the Director of Accounts Receivable Services, containing your login credentials. Additional information and resources on the Authorize.net payment gateway can be found on the Authorize.net website and the University’s Payment Card Industry Data Security Standards (PCI DSS) information on the Controller's Office website.

Training

All new Payment Card Manager are assigned security awareness training videos which can be viewed using the Training Hub, the University’s online training management tool. These videos cover topics such as payment card manager duties, passwords, and data destruction.

“Bank Card Reconciliation” is an online training course available in the Training Hub. This course provides a process overview of reconciling point-of-sales bank card payments in EFS. This training should be viewed by the accountant(s) responsible for reconciliation of your payment card account(s). 

CampusGuard

CampusGuard is a security assessment company that contracts with the University to assist us with our payment card compliance activities. The CampusGuard Portal is the website used by all Payment Card Managers to complete your annual PCI DSS Self-Assessment Questionnaire (SAQ), and upload copies of required payment card compliance documents and forms. After assignment as a Payment Card Manager you will receive an informational e-mail from CampusGuard, providing you with information and login access related to your account on the CampusGuard Portal website.

Completion of Compliance Documentation

Once you receive the e-mail from CampusGuard with your login information, you can then log into the CampusGuard Portal website and complete your area’s PCI DSS Self-Assessment Questionnaires SAQ(s) and compliance documents. Guidance documents to assist you with the completion of your PCI DSS Self-Assessment Questionnaire(s) and compliance documents can be found on the University’s Payment Card Industry Data Security Standards (PCI DSS) content found on the Controller's Office website. You should complete these compliance documents within one month of your assignment as Payment Card Manager.

New Payment Card Manager Meeting

As part of the onboarding process for new Payment Card Account Managers, the Accounts Receivable Services will schedule a meeting with you to discuss payment card compliance and reconciliation, as well as answering any questions you should have. Make sure you have viewed the assigned training videos, and have reviewed and updated your area’s SAQ(s) and Compliance Documents in preparation for this meeting.

Tax Management Office Guideline #8 Payments to Students is helpful in determining what type of payment is being made and which is the correct process to use. Payments to students are complex. It is possible to pay a student through three different systems/processes: financial aid, accounts payable, and payroll. It is critical that the payment is done in the proper system, using the correct process. The University must comply with reporting requirements to the individual or Internal Revenue Service, such as 1098T reporting (financial aid), 1099 reporting (accounts payable), or W-2 reporting (payroll).

Payments to students is a complex area and not every situation has been covered in TMOG 8, available on the Tax Management Office website. The Tax Management Office is available to help analyze situations that are unclear or not addressed in the examples. Contact them for help determining the type of payment being made at [email protected] or 612-624-1053.

The student organization must be set up as a supplier in the financial system. Enter the transaction to pay the student organization just as you would an external vendor. Ensure you have back-up documentation for imaging, just as you would for any other vendor (an invoice, statement, or whatever other documentation is needed).

Unlike encumbering on non-sponsored funds, based on the University's fiscal year, payroll encumbering on Sponsored projects is based on the Project's budget period end date. Functionality is provided to override the budget/project period end date for encumbering purposes, should a department prefer to calculate their sponsored payroll encumbrances on a different basis. The systems logic for selecting the encumbrance end date is as follows, reflecting the order of precedence:

1. Project End Date Override, if it exists and is active;
2. Current Budget Period End Date, if no active Project End Date Override exists;
3. Project End Date, if the above two situations do not apply.

A budget period is determined to be current based on the day the encumbering run occurs. Encumbering runs always occur the night of a pay date. Encumbering may also occur on a daily basis for employee job records that have changed between pay cycles, for example, an existing employee was paid on two sponsored project and their payroll distribution was changed to reflect being paid on three sponsored projects.

The Project End Date Override page can be found in HRMS at: UM Payroll Accounting > UM Encumbering > UM Project End Date Override

View Sponsored Payroll Encumbering

A page is available in HRMS that displays all pertinent end dates of a project that could influence the encumbering end date. The page is called 'UM Project Budget Period'. Navigation: UM Payroll Accounting > UM Encumbering > UM Project Budget Period

The University provides a procurement card program for business-related purchases where the good or service is not available in U Market, or where the nature of the purchase does not require use of an official University purchase order. Using the PCard is one of the more expensive overall payment processes, both for the supplier and for the University.

Policies

Policies related to the PCard are in the Policy Library. 

Corporate Card Policy was updated in August 2024, highlights are available of changes.

Level III PCard Transaction Data from Merchants

The level III data on PCard purchases provides a more detailed description of the purchase, which may assist in identifying possible fraudulent activity when comparing the level III details to the details on the receipts. The level III detail should be compared to the receipts, when reconciling and approving PCard transactions. The number of merchants providing level III data is constantly changing.

Resources

• What to do if suspicious charges are discovered on a PCard (or a Travel & Expenses Card)
• Department Card Administrators: DCA list (Google Sheet)
• Questions about the PCard program, email [email protected].

A separate site related to purchasing is maintained by the Controller's Office. Visit purchasing.umn.edu for more information.

Ship-to Addresses / Shipping Locations and use of Amazon Business through U Market

There is a list of existing "P Locations" (ship-to addresses) available at z.umn.edu/ShipToLocationCodes and your requisition preparer or procurement specialist, or other finance support person, should be able to help get a new one set up if the location isn't already set up. (Note that shipping to employee's homes, if they live within commuting distance of their home campus, is not allowed.)

Need to sell high-value equipment?

The ReUse Program will partner with you to sell high-value items to the public and profit share from the proceeds back to your department. The ReUse Program has established relationships with buyers and secondary markets and they are experts in finding homes for surplus or no longer needed materials. More information is available on the ReUse website. 

Planning an upcoming event and have questions on how to navigate the gift and non-gift eligible return benefits when developing the sponsorship packages? Don’t worry. Consult the policy/related procedures on Classifying and Recording Sponsorships for University-Hosted Events/Activities. Email [email protected] for guidance to units on classifying and handling sponsorship packages, including chart of accounts guidance and proper recording of transactions in PeopleSoft.

Accounting Services is responsible for certain portions of the process of reporting sales tax to the State of Minnesota and filing the University's sales tax returns but the Tax Management Office has overall responsibility for system-wide tax reporting, compliance, related policies, procedures, and reporting systems.

Centralized MN Sales Tax Filing Option (for departments conducting external sales)

Eligible University departments have the option of filing a centralized Minnesota Sales Tax Return on an annual reporting basis (calendar year) to the State of Minnesota through Accounting Services. Departments must average less than $100 in monthly sales tax collections to qualify for the annual filing. Departments that file quarterly or monthly sales tax returns must continue to file their own sales tax returns and are not eligible for the centralized filing option.

To have Accounting Services file a Minnesota Sales Tax Return for your department’s taxable activity, you must complete a Centralized Annual Sales Tax Reporting Form (UM1604). These forms are due to Accounting Services in January each year, contact [email protected] for information or assistance. Although Accounting Services prepares the Centralized Annual Filing for Minnesota Sales Tax and prepares the tax payment for this annual filing, University departments are responsible for retaining supporting documentation. The supporting documentation should include information on the items sold and where and when the sales took place. The information should be retained for four years. This applies whether departments use the centralized filing option or they file their own sales tax return.

The rate of tax that applies to a sale depends on the taxes imposed at the location of the sale. Generally, this means where a customer picks up a purchased item or where the item is shipped. If an item is shipped to a Minnesota destination, you must determine what the sales tax rate is for that address, and collect and remit the appropriate tax. If the item is shipped out of Minnesota, no tax should be collected since it is not considered a Minnesota sale.

Information about the University's tax exempt status and the current ST3 form are available on the Tax Management Office website.

A separate site related to travel and expenses is maintained by the Controller's Office. Visit travel.umn.edu for more information.

Ever wonder what happens with old uncashed checks or accounts receivable credits?

Non-payroll checks become unclaimed property after three years, and payroll checks become unclaimed property after one year. The University is required by law to report unclaimed property and each department needs to do their part to ensure the University complies with unclaimed property laws.

What is Unclaimed Property?

Unclaimed property is any form of abandoned property, such as uncashed checks or remittances, or other tangible financial property that the University is not able to return to the rightful owner. Every state requires that the abandoned property be turned over to the state of last known residence where it is held until the rightful owner can be located. When property is turned over to the state, it is considered escheated.

Who is responsible for complying with state laws on Unclaimed Property?

The unclaimed property function is a service performed for the entire University by Accounting Services, a unit within the Controller's Office. The escheatment process includes sending out due diligence letters in an attempt to find the rightful owners before funds are turned over to the state of last known residence.

The unclaimed property function automatically reviews unclaimed items recorded in the former legacy systems and the current Enterprise Financial System (includes vendor and employee reimbursement payments, payroll checks, student financial aid refunds, contingent and research payments, Preferred One and Patient Choice payments, and EFS accounts receivable credits).

Any non-payroll related payments or credits greater than two years old that are recorded outside of the former legacy systems and EFS are incorporated into an unclaimed property function once reported to Accounting Services by the respective department.

Unclaimed property does not handle checks/credits less than two years old, with the exception of payroll checks, or unclaimed incoming wire transfers. Unclaimed property also does not handle payroll checks less than one year old.

Am I obligated to report to the Accounting Services any unclaimed property tracked outside of PeopleSoft Financials?

Yes. Any check payments or non-payroll credits two years old or older as of June 30th of the current fiscal year, tracked by departments outside of the former legacy systems or EFS, must be reported. For example, accounts receivable credits or accounts payable-related over payments. Three years is measured by check issuance date, or in the case of credit balances, it is the last owner generated contact on account.

How does the University know if something is Unclaimed Property?

A credit on account or non-cashed check is considered unclaimed property if there has been no owner generated activity on the account or the check has remained uncashed for two years or longer. In the case of payroll checks or balances, one year or older is considered unclaimed.

Who do I call if I am aware of Unclaimed Property?

Report the information to the Controller's Office [email protected].

Have you received an Unclaimed Property letter and are wondering if it is legitimate?

Some information is available for letter recipients, or contact the Controller's Office at [email protected].