Business Processes

People ask, why is that in a process (or policy)?

All processes are designed with the following in mind: Applicable laws; regulatory agency requirements; sponsor requirements or guidelines; University policy; best business practices; systems requirements; impact on (and needs of) campuses, colleges, and departments; as well as addressing the need for equity, diversity, and inclusion.

Looking for Risk Management and Insurance content, including information on alcohol permits? That content has moved to the U Finance website (the unit's reporting lines changed and the content has been moved to another website).

Expand all

Featured Topic: Can employees purchase their old laptop or desktop computer after it has been removed from service/replaced? (Sale of used/excess equipment/supplies)

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.

Sale of used equipment, capital assets, or excess supplies/materials, additional considerations for recharge centers

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. 

Use of social media accounts to advertise items available for sale

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. 

Capital assets

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.

Additional considerations for recharge centers

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:

Accounting / General Ledger

General Ledger / General Accounting

General Ledger

There are many business processes that make up "accounting" or occur in/are related to the General Ledger module in EFS, such as accounting standards and controls, asset accounting, liability and fund balance accounting, audits, financial statements, the unclaimed property process, and certain tax procedures (see also the Tax Management Office page).

Carryforward Calculation Process

description of the carryforward balance calculation process in PeopleSoft Financials is available.

Cross Funds Transfer Matrix

Fund accounting enables the University to track and report on how different kinds of funds are spent. Best practice is to avoid inter-fund transfers on current funds. Inter-fund transfers between current funds should only occur when it is not possible to otherwise match expenses with revenues. View the Cross Funds Transfer Matrix.


Reconciling and verifying General Ledger accounts and other financial information, see the policy: Reviewing and Verifying Revenue, Expenditures, and other Financial Reports.

Accounting Periods and Accounting Period Closes

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.

Accounts Payable (AP)

Accounts Payable

These business processes involve making non-payroll payments to suppliers and employees, vendor maintenance for non-payroll payments, travel advances, emergency checks/payments, foreign payments, payments for withholding to the State, 1099 Miscellaneous Income reporting and payments to the IRS, data entry of payment and financial transactions, and payment corrections.

Accounts payable overview / AP 101 information.

Supplier/Vendor Information

Any supplier (vendor) who works with the University should have a supplier record set up in the financial system to expedite requisitions/purchase orders and payments, and to ensure we comply with any state/federal tax reporting guidelines or laws.

Voucher Specialists

Voucher specialists are the individuals with access in the financial system to enter payment transactions. There are a small number of these individuals who support each campus/college. If someone in a department receives an invoice that needs to be paid, it should be forwarded to the voucher specialist that supports your area as soon as possible.

Accounts Receivable and Billing (AR/Billing)


This business process includes billing and accounts receivable activity, customer maintenance, printing invoices, handling payments, collections, billing related correspondence (e.g., statements, dunning letters), applying inbound Electronic Funds Transfer (wire transfers) payments, and the recording of bank card transactions (related to merchant accounts).

Lockbox Info

If a department receives a check that is paying an EFS invoice, do NOT enter a departmental deposit. Instead send the check to the lockbox via US Mail. Use this Lockbox Label Template to print an entire sheet of labels or address your envelope to:

Regents of the University of Minnesota
NW 5960
PO Box 1450
Minneapolis, MN  55485-5960

Compliance issues


Courses and resources related to Accounts Receivable and Billing processes are available on the training page.

Assets (capital assets)

Capital Assets

The University of Minnesota partners with a third party to perform periodic inventories of capital assets systemwide. Our current partner is HCA Asset Management.


Capital assets are items that are used in the operations of the University of Minnesota but are not intended to be sold as part of such operations. Capital assets must have:

  • an acquisition value
  • a useful life greater than or equal to the capitalization threshold for the asset category to which they belong.

Capital assets are also known as "fixed assets" and "property, plant, and equipment." Examples of capital asset categories include land, buildings, capital equipment, library collections, etc. 

Capital Equipment Assets  

Capital equipment assets are tangible non-expendable personal property items with:

  • an acquisition value of $5,000.00 or greater per item
  • an estimated useful life of greater than one year.

A capital equipment asset must maintain its identity over the course of its useful life.

Custodial organizations (DeptIDs) are responsible for all of the capital and non-capital equipment assets in their custody.

Non-capital Equipment Assets

Non-capital equipment assets are:

  • non-expendable personal property items with an acquisition value of less than $2,500.00 per item
  • an estimated useful life of less than one year.

Custodial organizations (DeptIDs) are responsible for all of the capital and non-capital equipment assets in their custody.

Sponsor-owned Property

Material and equipment in the possession of, but not owned by, the University of Minnesota as part of a sponsored project. Material and equipment of this nature where the sponsor is the Federal government are referred to as Government Property. Government Property is classified as either:

  • Government-Furnished Property
  • Contractor-Acquired Property.

Government-Furnished Property is material and equipment acquired, funded, and owned by the Federal government that is made available to the contractor. Contractor-Acquired Property is material and equipment acquired and used by the contractor, but which is funded and owned by the Federal government.

The University of Minnesota is responsible for all sponsor-owned property in its possession. Accounting Services is responsible for verification and reporting of all sponsor-owned equipment that meets the University's definition of capital equipment assets.


Tagging identifies an equipment asset as a unique item and facilitates the periodic verification of equipment assets. The University physically "tags" capital equipment asset acquisitions so that the item can be identified and inventoried in the future. Sponsor-owned equipment that meets the University’s definition of capital equipment assets may be tagged with a sponsor tag and/or a University tag.

Periodic Verifications

The University maintains and tests the property control system by conducting periodic verifications of the existence, location, and use-status of each University capital equipment asset. Accounting Services is responsible for these verifications also include those sponsor-owned equipment items, which meet the University’s definition of capital equipment assets, in the possession of the University of Minnesota. Periodic verifications satisfy the federal requirements, support the annual production of the University's financial statements, support the computation of the University's negotiated Facilities and Administrative (F&A) cost recovery rates, and demonstrate the University's stewardship in controlling equipment assets in its possession. These verifications may be performed by a third party, through a contract managed by Accounting Services.

Policies & Forms

Policies related to managing assets can be found in the Policy Library. All forms can be found in the Forms Library.


The budgeting process involves a great deal of offline work and then annual entry of budgets into the system, all of which is overseen by the University Budget Office. That team prepares the University's budget and coordinates with Resource Responsibility Centers on the preparation of budgets for each campus, college, department, or administrative unit. 

Departments create line-item budgets from historical data using current year instructions and assumptions, and forecasts from the campus/college/administrative unit compact process. There are three types/pages of budgets in the financial system where departments enter budgets: a detailed budget, a position budget, and an asset budget. Once the entire budget for a fiscal year has been submitted, people will still be able to view the budget pages but no additional entry to the pages will be allowed.

Policy & Instructions

Policies related to budgeting are on Training on how to enter a budget in EFS for a department (FIN508) or at the RRC/designee level (FIN506) are on the Training Hub, and instructions for how to budget are available on the annual budget instructions web page.

Questions about budgeting for your area?

Discuss the matter with your RRC Contact.

Combination Edits (Combo Edits) (General Ledger)

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:

ErrorFundDeptIDProgramProjectAccountCF1CF2Fin EmplIDCS
X1000 20135 720101    
X 1000520135 720101    
X  20135 720101    
X    720101    


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 several strings that wouldn't pass this combination edit:

ErrorFundDeptIDProgramProjectAccountCF1CF2Fin EmplIDCS
X10001000520135 720101   CS
X100010005 00000006720101   CS


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 several strings that wouldn't pass this combination edit:

ErrorFundDeptIDProgramProjectAccountCF1CF2Fin EmplIDCS


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:

ErrorFundDeptIDProgramProjectAccountCF1CF2Fin EmplIDCS
X30001000520135 720101    


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:

ErrorFundDeptIDProgramProjectAccountCF1CF2Fin EmplIDCS
X10001000520089 720101    


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:

ErrorFundDeptIDProgramProjectAccountCF1CF2Fin EmplIDCS
X10001000520135 110011    


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:

ErrorFundDeptIDProgramProjectAccountCF1CF2Fin EmplIDCS
X100010005  720101    



There will be a new system-wide rule that 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:

ErrorFundDeptIDProgramProjectAccountCF1CF2Fin EmplIDCS
X100010005 00000006720101    


Cost Transfer Guidance (Late Cost Transfers)

Late Cost Transfer Implementation, issued September 2023 and updated January 2024

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 that are submitted within 180 days from the date the original expense posted (non-salary) or pay date (salary) will be considered for approval (if submitted September 13, 2023, expenses posted on or after March 17, 2023 will be 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) will be considered for approval (if submitted on January 2, 2024, expenses posted on or after October 4, 2023 will be 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.

Phase 3 - July 1, 2024
  • 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 will be 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.

Departmental Deposits & Desktop Deposit Resources

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


History of Endowments at the University of Minnesota

Between 1851 and 1857, the United States Congress granted 144 sections of land for use and support of a university. The lands granted by the United States are owned by the State of Minnesota and managed by the Minnesota Department of Natural Resources. The federal grant lands are often referred to as the “permanent university fund lands”.

The 1851 Charter for the University of Minnesota created a perpetual fund that is known as the Permanent University Fund (PUF). Revenue from the permanent university fund lands is deposited into the PUF.

In the early years, income from the investment of the revenue in the PUF was used to reduce debt incurred in establishing the university. In more recent years, the revenue from management of the permanent university funds lands has been split among the following accounts:

  • The Endowed Chair Account - Income used to provide endowment support for professorial chairs in academic disciplines.
  • The Endowed Mineral Research Account - Income allocated to the Duluth and Coleraine facilities of the Natural Resources Research Institute for mineral and mineral-related research.
  • The Endowed Scholarship Account - Income distributed through the Iron Range Scholarship Program
  • The Endowed Mesabi Range Account - Income used for operating a mining, metallurgical, or related engineering degree offered through the University of Minnesota at the Mesabi Range Community and Technical College, and for scholarships for students to attend the program.


The University has three investment pools in which University of Minnesota departments participate.

  • Group Income Pool (GIP) – Long-term operating reserves of the University created from auxiliary enterprises and departmental reserves. The funds support various capital and infrastructure needs.
  • Consolidated Endowment Fund (CEF) – All public and private gifts to the University of Minnesota. Most of the funds are gifts that were received prior to the establishment of the University Foundations in 1962. These funds are generally maintained in perpetuity and are spent according to the donor’s wishes.
  • Permanent University Fund (PUF) – A public endowment derived from sources such as state iron ore taxes, royalties, and federal land grants. By legislative mandate, PUF assets are used to match private contributions with the goal of providing substantial financial support for endowed chairs and professorships throughout the University.

What is a University of Minnesota endowment?

An endowment is a long-term investment in the University of Minnesota that provides benefits to students, faculty or programs year after year, generation after generation. For endowed funds, the donor stipulates that the principal must be invested and that all or a portion of the income be expended to carry out the donor's purpose. The goal is to ensure that the principal maintains its purchasing power over time to support future generations.

What is the University of Minnesota Foundation?

The University of Minnesota Foundation was established in 1962 by 21 alumni and friends. The Foundation advances the University's mission of teaching, research, and outreach to the community by raising and managing private dollars for scholarships, world-class faculty, leading-edge research, new facilities, and academic programs on all five campuses of the University of Minnesota. All new gifts to the University of Minnesota generally go through the University of Minnesota Foundation.

DMS/STARSAccess the University of Minnesota Foundation system. The foundation supports the U by raising & managing funds for scholarships, faculty, research, facilities, and academic programs on all five campuses.

University of Minnesota Fund: The University of Minnesota Foundation (UMF) is a key partner with the University in building and sustaining excellence among students and faculty, and fueling discovery in important areas on all University of Minnesota campuses. UMF accomplishes this by raising and managing gifts from individuals and organizations.

For more information about giving to the University visit

Training: See the Financial Training page for more information about the endowments business process.

What are the responsibilities of departments?

Departments are to be good stewards and follow the purpose of the endowment that was stipulated by the donor. Departments can view a summary description of the purpose of the endowment in PeopleSoft or can view all of the donor’s correspondence, which has been scanned into the Donor Management System (DMS).

What is the Donor Management System?

The Donor Management System (DMS) is used to manage alumni and development activities at the University of Minnesota. Access to DMS is for University-authorized personnel for purposes deemed appropriate by the University of Minnesota Foundation, the business owner of the system. DMS contains many tools to help department be good stewards. Some of the tools include: Fund statements, Scholarship tracking and reporting tool (STAR), gift transmittal online tool, executive reports and queries. Donor Management System.

How does a department get money from an endowment to spend according to the donor’s intent?

University of Minnesota funds – Endowments held by the University of Minnesota are generally old gifts that predate the start of the University of Minnesota Foundation. The funds are invested by the Office of Investment and Banking. Departments may choose to receive income from these endowments automatically on a quarterly basis or make a manual withdrawal from the PeopleSoft Cash Management module. Instructions are available in the Endowments Manual.

University of Minnesota Foundation (UMF) funds – All new gifts made to the University of Minnesota go to the University of Minnesota Foundations. UMF was established in 1962 to support the University of Minnesota. Departments can withdraw funds from the UMF endowments by creating an EFS invoice in PeopleSoft.

Funds that are at both the University and Foundation (PUF) – Legislative mandates that PUF assets are matched by private contributions and spent at a proportionate rate. In order to withdraw funds from PUF endowments, departments must create a manual withdrawal from the PeopleSoft Cash Management module AND create an EFS invoice in PeopleSoft. An automatic PeopleSoft withdrawal transaction and EFS invoice can be done by setting up the PUF endowment up to receive the quarterly income distribution.

Financial Reporting

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)

Gramm-Leach-Bliley Act

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.

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.

Identity Theft Prevention Program: Red Flags Rule

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.

Imaging Supporting Documentation for Financial Transactions

Financial Document Imaging

This page is for both end users of the imaging system and information technology support professionals. 

Email Method

Document TypeSubject Line must containSample subject Line FormatEmail Address
Chrome River, see Voucher------
Department DepositTwo pieces of text, always begins with "DeptDeposit" and the second piece is the barcode number in the bottom left on the Deposit Detail ReportDeptDeposit UMN01XXXXXX[email protected]
Expense Report (EFS, PCard)ER Document ID, including any leading zeros (ID obtained from cover sheet or EFS)0000777777[email protected]
Journal EntryUse the Attachments field on the JE itself----
PCard ApplicationTwo pieces of text, "PCard: " (for PCard applications) or "TCard: " (for Travel Card applications) and the applicant's employee ID, including any leading zeros (note that "[email protected]" is used by central staff to send information to imaging system). PCard Applications should only be emailed by officially recognized Department Card Administrators (DCAs).

PCard: 0123456


TCard: 0123456

[email protected]
Retro DistributionRetro Document ID, including any leading zeros [email protected]
Vendor RequestIf NEW request, subject line must be three characters only, "NEW". If requesting change, enter only the ten digit supplier ID number, including any leading zerosNEW


[email protected]
VoucherVoucher Document ID06702333[email protected]
Requisitions / POsUse the Attachments field on the Requisition itself----

Scanning using Perceptive Content/Perceptive Experience

  • Vouchers (invoices, payment transactions)
  • Vendor/supplier record setup or change requests
  • Chrome River expense reports or reimbursement requests
    • Images related to Chrome River Expense Reports and Travel Card reconciliations are automatically sent to Perceptive Content/Perceptive Experience by an interface process. If additional images need to be added later, use the Voucher email imaging process.
  • EFS expense reports or reimbursement requests
  • Cash advances
  • Department deposits
  • Retroactive distributions of payroll expenses ("retros" in HRMS)
    • See details in table below.
  • Journal entries (accounting adjustments)
    • Supporting documentation for Journal Entry activity is added within EFS, when entering the JE transaction (on the header of the JE using the "Attachments" link) but the Capture & Index process can also be used for JEs.
  • Cashed accounts payable checks
  • Procurement card applications
  • Procurement card reconciliation reports
  • Requisitions
    • Many requisitions do not require supporting documentation be attached in the financial system, as all relevant information for some is contained in the transaction itself. Which requisitions must have supporting documentation? Those for professional services or consulting, or those over certain dollar thresholds, require certain forms be completed and associated with the transaction in the financial system. These forms are "attached" to the requisition in the financial system itself, and not sent to the imaging system. Those with access to enter requisitions have instructions on how to attach supporting documentation or required forms within the financial system itself.
  • Purchase Orders
    • Purchase orders "inherit" images from requisitions in the financial system. Supporting documentation requirements are equivalent for the two transactions.

Current exception reports Imaging exception reports are now available for each unit to run at will in the reporting instance of EFS:

  • EX_IMAGE_EXCEPTION_RPT (PCard-related)

University policy requires that support documentation for all payment transactions must be retained. All documentation should be scanned and linked in the imaging system by the end of the month the payment transaction was approved in the system.

User guides for Perceptive Experience on the web

Retro Distribution imaging

People may image backup documentation for Retro Distribution transactions entered in HRMS. All backup documentation for Retros is stored in two imaging system drawers. The drawer for items from prior to August 21, 2022 is named for the old process, F GL HSA (HSA stands for "historic salary adjustments"). The drawer for Retros imaged after August 21, 2022 is F PA Retro. These drawers are accessible to anyone with regular EFS JE entry access or scan access in the imaging system for JEs. Those with view access for JEs in the imaging system are able to immediately view items related to Retro Distributions.

There are three methods for getting the backup documentation into the imaging system: via email (recommended), via the “print” to the imaging system feature, or via the Cluster scanning process. The email method may be used by anyone at the University who has backup documentation for a Retro transaction. The email process is the most efficient way to send backup documentation to the imaging system. For more information on the details of how each process works, see the instructions below.

Note that some job aids associated with Retro imaging may refer to the old name for the document, HSA, and to the old drawer name (F GL HSA), and to the old email address ([email protected] which is no longer in use). The steps for imaging have not changed, just the names of things.

Imaging Retro backup informationCluster scanning methodPrint to the imaging system methodEmail method
Imaging system desktop client required



No imaging system access required  


Getting access to image documentsAccess is granted via the EFS access request process (ARF is available in TDX). Includes view and scan access.Access is granted via the EFS access request process (ARF is available in TDX). Includes view and scan access.No special access request is needed to send images to the imaging system. Access to view images is granted via the EFS access request process (ARF is available in TDX).
Who is able to use this method to put items in the imaging systemAnyone with EFS JE entry access or imaging JE scan access can scan/view.Anyone with EFS JE entry access or imaging JE scan access can scan/view.Anyone with an email address can send items to the imaging system.

Your chief financial manager will decide if this option is required for your unit.

Uses the same processes as other cluster scanning activities.

Your chief financial manager will decide if this option is required for your unit.

Requires additional setup on individual desktops but otherwise uses the same processes as other cluster scanning activities.

This method is open for use at the discretion of the individual working with Retro activity.

The email option is only available for the Retro drawer and skips over the usual cluster scanning activities.

InstructionsInstructions for the cluster scanning method are available here.Instructions for the 'Print to the imaging system' method are available here.Instructions for the email method are available here.


How do I delete a document in the imaging system?

Contact [email protected] for assistance. Some activity can never be deleted, some requires special access, some can be deleted by a person with cluster level scanner access.


Units working with external auditors should contact [email protected] with the list of transactions the auditors have selected as their sample. Image requests related to an actual audit by an external audit firm will be acted on immediately.

About the imaging system, history

DocuWare (legacy system): DocuWare was the legacy imaging system for financial transaction backup documentation (for pre-July 1, 2008 activity). It is no longer available for inquiry.

In early 2016 ImageNow was upgraded and the product itself was re-named to Perceptive Content (the desktop client version) / Perceptive Experience (the web browser version). ImageNow, when first implemented, replaced the DocuWare system for the imaging of financial documents in July 2008. The ImageNow/Perceptive Content system has been in use at the University since 2000 as an enterprise-level document imaging solution.

In mid-May 2022, changes were made in Perceptive Content/Perceptive Experience to address the end of support date (June 15, 2022) for Internet Explorer 11. IE11 was required in order to use Perceptive Content's "gold key" functionality to link images in Perceptive Content to transactions in PeopleSoft. No specific feature-by-feature replacement was provided by Perceptive Content, so the U's Office of Information Technology implemented the "Capture & Index" process in Perceptive Content to replace the "gold key" linking functionality. With those changes came the loss of some nice-to-have features/functions in Perceptive Content. The required functionality (linking supporting documents to financial transactions) remains.

Internal and External Sales

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

JE Source Codes (General Ledger)

Journal Entry (JE) source codes

These lists are not necessarily complete lists, as new codes can be added over time. Some codes are not used or are used infrequently. When in doubt, contact the preparer or approver of the transaction for more information. See also the GL prefixes job aid from Financial Training. (pdf)

Which module or source did the JE come from?

JE Header SourceJE Header Source Description
AMAsset Management
APAccounts Payable
ARAccounts Receivable
ASAccounting Services
CFDCarryforward Balance
CLOInterim and Year-End Close
EXTGeneric External Journals
HRHuman Resources
HYPHyperiod Planning And Budgeting
IMPImport Spreadsheet Upload
LMEnterprise Learning Management
ONLOnline Journal Entry
ONNOnline Non-Sponsored Journal
ONSOnline Sponsored Journal
PCProject Costing
SAStudent Administration
SFRSponsored Financial Reporting
SLStudent Loans
TIPTIP Journals

Transaction numbering and JE line source codes

First three chars of JE ID
Journal Line Source
Long Name
Short Name
000PNLPS/GL Journal Entry PageGL JE Page
000SCESuspense Correction EntrySuspense
000SCPPS/GL - Copy JournalCopy Jrnl
000SCVSuspense Correction w/o VATSusp- xVAT
000SERSystem - Err Suspense ReversalErr Rvrsl
000SESSystem - Error SuspenseErr Susp
000SUPSystem - IntraUnit PayableIntraU P
000SURSystem - IntraUnit ReceivableIntraU R
109NVSPS/GL Spreadsheet JournalGL SJI
200NVSPS/GL Spreadsheet JournalGL SJI
200PNLPS/GL Journal Entry PageGL JE Page
200SUPSystem - IntraUnit PayableIntraU P
200SURSystem - IntraUnit ReceivableIntraU R
ACCGAPJrnlGen - Accounts PayableJGen-AP
ADDGAMJrnlGen - Asset ManagementJGen-AM
ADDPNLPS/GL Journal Entry PageGL JE Page
ADJGAMJrnlGen - Asset ManagementJGen-AM
ADJNVSPS/GL Spreadsheet JournalGL SJI
ADJSUPSystem - IntraUnit PayableIntraU P
ADJSURSystem - IntraUnit ReceivableIntraU R
ARBGARJrnlGen - Accounts ReceivableJGen-AR
ARBNVSPS/GL Spreadsheet JournalGL SJI
ARBPNLPS/GL Journal Entry PageGL JE Page
ARBSUPSystem - IntraUnit PayableIntraU P
ARBSURSystem - IntraUnit ReceivableIntraU R
ARDGARJrnlGen - Accounts ReceivableJGen-AR
ARDPNLPS/GL Journal Entry PageGL JE Page
ARMGARJrnlGen - Accounts ReceivableJGen-AR
ARRGARJrnlGen - Accounts ReceivableJGen-AR
AS0NVSPS/GL Spreadsheet JournalGL SJI
AS0SUPSystem - IntraUnit PayableIntraU P
AS0SURSystem - IntraUnit ReceivableIntraU R
ASTNVSPS/GL Spreadsheet JournalGL SJI
BDGALOPS/GL AllocationsGL Alloc
BDGNVSPS/GL Spreadsheet JournalGL SJI
BDGSUPSystem - IntraUnit PayableIntraU P
BDGSURSystem - IntraUnit ReceivableIntraU R
BI0GBIJrnlGen - BillingJGen-BI
BI0PNLPS/GL Journal Entry PageGL JE Page
BSCNVSPS/GL Spreadsheet JournalGL SJI
BSCSUPSystem - IntraUnit PayableIntraU P
BSCSURSystem - IntraUnit ReceivableIntraU R
CANGAPJrnlGen - Accounts PayableJGen-AP
CANNVSPS/GL Spreadsheet JournalGL SJI
CANSUPSystem - IntraUnit PayableIntraU P
CANSURSystem - IntraUnit ReceivableIntraU R
CAPNVSPS/GL Spreadsheet JournalGL SJI
CAPSUPSystem - IntraUnit PayableIntraU P
CAPSURSystem - IntraUnit ReceivableIntraU R
CASNVSPS/GL Spreadsheet JournalGL SJI
CASSUPSystem - IntraUnit PayableIntraU P
CASSURSystem - IntraUnit ReceivableIntraU R
CEFNVSPS/GL Spreadsheet JournalGL SJI
CEFSUPSystem - IntraUnit PayableIntraU P
CEFSURSystem - IntraUnit ReceivableIntraU R
CFDGOTJrnlGen - OtherJGen-Other
CFDNVSPS/GL Spreadsheet JournalGL SJI
CFDPNLPS/GL Journal Entry PageGL JE Page
CFDSCPPS/GL - Copy JournalCopy Jrnl
CFDSUPSystem - IntraUnit PayableIntraU P
CFDSURSystem - IntraUnit ReceivableIntraU R
CLNNVSPS/GL Spreadsheet JournalGL SJI
CLNSUPSystem - IntraUnit PayableIntraU P
CLNSURSystem - IntraUnit ReceivableIntraU R
CLOGAPJrnlGen - Accounts PayableJGen-AP
CNVEXTPS/GL External JournalExternal
CNVNVSPS/GL Spreadsheet JournalGL SJI
CNVPNLPS/GL Journal Entry PageGL JE Page
CNVSCPPS/GL - Copy JournalCopy Jrnl
CNVSUPSystem - IntraUnit PayableIntraU P
CNVSURSystem - IntraUnit ReceivableIntraU R
CONNVSPS/GL Spreadsheet JournalGL SJI
CONSUPSystem - IntraUnit PayableIntraU P
CONSURSystem - IntraUnit ReceivableIntraU R
CORNVSPS/GL Spreadsheet JournalGL SJI
CORSUPSystem - IntraUnit PayableIntraU P
CORSURSystem - IntraUnit ReceivableIntraU R
CPPNVSPS/GL Spreadsheet JournalGL SJI
CPPSUPSystem - IntraUnit PayableIntraU P
CPPSURSystem - IntraUnit ReceivableIntraU R
CSONVSPS/GL Spreadsheet JournalGL SJI
CSOSUPSystem - IntraUnit PayableIntraU P
CSOSURSystem - IntraUnit ReceivableIntraU R
CWSNVSPS/GL Spreadsheet JournalGL SJI
CWSSESSystem - Error SuspenseErr Susp
CWSSUPSystem - IntraUnit PayableIntraU P
CWSSURSystem - IntraUnit ReceivableIntraU R
DISNVSPS/GL Spreadsheet JournalGL SJI
DPRGAMJrnlGen - Asset ManagementJGen-AM
DPRPNLPS/GL Journal Entry PageGL JE Page
DSCNVSPS/GL Spreadsheet JournalGL SJI
DSCSUPSystem - IntraUnit PayableIntraU P
DSCSURSystem - IntraUnit ReceivableIntraU R
DSRNVSPS/GL Spreadsheet JournalGL SJI
DSRSUPSystem - IntraUnit PayableIntraU P
DSRSURSystem - IntraUnit ReceivableIntraU R
EACGEXJrnlGen - ExpensesJGen-EX
EACPNLPS/GL Journal Entry PageGL JE Page
ECNGEXJrnlGen - ExpensesJGen-EX
ECNPNLPS/GL Journal Entry PageGL JE Page
ENCNVSPS/GL Spreadsheet JournalGL SJI
EPYGEXJrnlGen - ExpensesJGen-EX
EPYPNLPS/GL Journal Entry PageGL JE Page
ESCGEXJrnlGen - ExpensesJGen-EX
ESCPNLPS/GL Journal Entry PageGL JE Page
FBTNVSPS/GL Spreadsheet JournalGL SJI
FBTSESSystem - Error SuspenseErr Susp
FMXSESSystem - Error SuspenseErr Susp
FY0NVSPS/GL Spreadsheet JournalGL SJI
FY0SUPSystem - IntraUnit PayableIntraU P
FY0SURSystem - IntraUnit ReceivableIntraU R
GFAGPCJrnlGen - Project CostingJGen-PC
GIPNVSPS/GL Spreadsheet JournalGL SJI
GIPSUPSystem - IntraUnit PayableIntraU P
GIPSURSystem - IntraUnit ReceivableIntraU R
GLRNVSPS/GL Spreadsheet JournalGL SJI
GLRSUPSystem - IntraUnit PayableIntraU P
GLRSURSystem - IntraUnit ReceivableIntraU R
GRTGCAJrnlGen - ContractJGen-CA
GRTGPCJrnlGen - Project CostingJGen-PC
HSAPNLPS/GL Journal Entry PageGL JE Page
HSASESSystem - Error SuspenseErr Susp
IC0CLOPS Batch ClosingClosing
IC0SUPSystem - IntraUnit PayableIntraU P
IC0SURSystem - IntraUnit ReceivableIntraU R
IMPNVSPS/GL Spreadsheet JournalGL SJI
IMPPNLPS/GL Journal Entry PageGL JE Page
IMPSUPSystem - IntraUnit PayableIntraU P
IMPSURSystem - IntraUnit ReceivableIntraU R
MC0GOTJrnlGen - OtherJGen-Other
MC0PNLPS/GL Journal Entry PageGL JE Page
PFLPNLPS/GL Journal Entry PageGL JE Page
PMTGAPJrnlGen - Accounts PayableJGen-AP
PYNNVSPS/GL Spreadsheet JournalGL SJI
PYNSESSystem - Error SuspenseErr Susp
PYPSESSystem - Error SuspenseErr Susp
PYRSESSystem - Error SuspenseErr Susp
PYSNVSPS/GL Spreadsheet JournalGL SJI
PYSSESSystem - Error SuspenseErr Susp
RETGAMJrnlGen - Asset ManagementJGen-AM
RETPNLPS/GL Journal Entry PageGL JE Page
REVNVSPS/GL Spreadsheet JournalGL SJI
REVSUPSystem - IntraUnit PayableIntraU P
REVSURSystem - IntraUnit ReceivableIntraU R
RV2NVSPS/GL Spreadsheet JournalGL SJI
RV2SUPSystem - IntraUnit PayableIntraU P
RV2SURSystem - IntraUnit ReceivableIntraU R
SAFGSFJrnlGen - Student FinancialsJGen-SF
SAFPNLPS/GL Journal Entry PageGL JE Page
SALNVSPS/GL Spreadsheet JournalGL SJI
SALSUPSystem - IntraUnit PayableIntraU P
SALSURSystem - IntraUnit ReceivableIntraU R
SFRNVSPS/GL Spreadsheet JournalGL SJI
SFRSUPSystem - IntraUnit PayableIntraU P
SFRSURSystem - IntraUnit ReceivableIntraU R
SL0GOTJrnlGen - OtherJGen-Other
SL0PNLPS/GL Journal Entry PageGL JE Page
STSNVSPS/GL Spreadsheet JournalGL SJI
STSSUPSystem - IntraUnit PayableIntraU P
STSSURSystem - IntraUnit ReceivableIntraU R
TAFNVSPS/GL Spreadsheet JournalGL SJI
TAFSESSystem - Error SuspenseErr Susp
TR0GTRJrnlGen - TreasuryJGen-TR
TR0PNLPS/GL Journal Entry PageGL JE Page
TR9NVSPS/GL Spreadsheet JournalGL SJI
TRAGAMJrnlGen - Asset ManagementJGen-AM
TRAPNLPS/GL Journal Entry PageGL JE Page
TRENVSPS/GL Spreadsheet JournalGL SJI
TRESUPSystem - IntraUnit PayableIntraU P
TRESURSystem - IntraUnit ReceivableIntraU R
TRSNVSPS/GL Spreadsheet JournalGL SJI
TRSSUPSystem - IntraUnit PayableIntraU P
TRSSURSystem - IntraUnit ReceivableIntraU R
UNANVSPS/GL Spreadsheet JournalGL SJI
UNASUPSystem - IntraUnit PayableIntraU P
UNASURSystem - IntraUnit ReceivableIntraU R
USVNVSPS/GL Spreadsheet JournalGL SJI
USVSUPSystem - IntraUnit PayableIntraU P
USVSURSystem - IntraUnit ReceivableIntraU R
YE0CLOPS Batch ClosingClosing

JE header "system source" codes

JE header system source
JE header system source short name
JE header system source long name
SCPCopy JrnlPS/GL - Copy Journal
SCRRound AdjSystem - Currency Round Adj.
SCVSusp- xVATSuspense Correction w/o VAT
SERErr RvrslSystem - Err Suspense Reversal
SESErr SuspSystem - Error Suspense
SIUInterUnitSystem - InterUnit From/To
SJEGL SJEPS/GL Standard Journal Entry
SNPInterU PSystem - InterUnit Payable
SNRInterU RSystem - InterUnit Receivable
SPAPos AcctSystem - Position Account
SUPIntraU PSystem - IntraUnit Payable
SURIntraU RSystem - IntraUnit Receivable
SVTVAT AcctsSystem - VAT Accounts
ALOGL AllocPS/GL Allocations
CLOClosingPS Batch Closing
CONGL ConsolPS/GL Consolidations
EQTGL EqitPS/GL Equitization
EXTExternalPS/GL External Journal
EXVExt. VATPS/GL External with VAT
GAEJGen-EEAPJrnlGen - Entry Event AP
GAMJGen-AMJrnlGen - Asset Management
GAPJGen-APJrnlGen - Accounts Payable
GARJGen-ARJrnlGen - Accounts Receivable
GAVJGen-AVJrnlGen - Student Advancement
GBIJGen-BIJrnlGen - Billing
GCAJGen-CAJrnlGen - Contract
GEXJGen-EXJrnlGen - Expenses
GGPJGen-GPJrnlGen - Global Payroll
GINJGen-INJrnlGen - Inventory
GKKJGen-EEBDJrnlGen-Entry Event GL Budgets
GLMJGen-ELMJrnlGen - Learning Management
GOTJGen-OtherJrnlGen - Other
GPCJGen-PCJrnlGen - Project Costing
GPEJGen-EEPOJrnlGen - Entry Event PO
GPOJGen-POJrnlGen - Purchasing
GREJGen-EEARJrnlGen - Entry Event AR
GSFJGen-SFJrnlGen - Student Financials
GTDJGen-TDJrnlGen - Promotion Management
GTRJGen-TRJrnlGen - Treasury
ICiClientInternet Client
IEiClient ExInternet Client Express
KOSOffsetCommitment Control Offset
KRPKReplaceCommitment Replacement
NVSGL SJIPS/GL Spreadsheet Journal
OTHOtherOther Source
PNLGL JE PagePS/GL Journal Entry Page
REVCurr RevalPS/FS Currency Revaluation
SASAmt SuspSystem - Amount Suspense
SBRBal RvrslSystem - Bal Suspense Reversal
SBSBal SuspSystem - Balancing Suspense
SCESuspenseSuspense Correction Entry
TRNCurr TransPS/FS Currency Translation
TWLTran w/LedPS/FS Curr Trans Within Ledger
GPKJGen-EEPCBJrnlGen-Entry Event PC Budgets

Payment Card Industry Data Security Standard (PCI DSS)

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.

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

Payment Card Account Forms & Documents

Payment Card Account Resources

SAQ and Compliance Documentation Guidance Guidance Documentation

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.

If your merchant account(s) integrates with an payment gateway to process credit card payments online, you will need to set up your access to the 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 payment gateway can be found on the website and the University’s Payment Card Industry Data Security Standards (PCI DSS) information on the Controller's Office website.


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 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.

Payments to Students or Student Groups

Payments to Students

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.

Payments to Student Groups

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).

Payroll Accounting Encumbering

Additional Encumbering Method for Sponsored Projects

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

Procurement Card / Purchasing Card (PCard)

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 related to the PCard are in the Policy Library. Pay special attention to Using the University Procurement Card.

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.



A separate site related to purchasing is maintained by the Controller's Office. Visit 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 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.)

Selling High Value Equipment

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. 

Sponsored Financial Reporting

Sponsored financial reporting is both a business process and the name of a unit within the Controller's Office. Both must be considered together, since the primary responsibility for providing reports to sponsors rests with Sponsored Financial Reporting, the department.

SFR's Responsibilities

  • Prepare and submit the institution's official financial reports and invoices to sponsors.
  • Apply payments from sponsors and follow up on those that are past due.
  • Close out awards in PeopleSoft Financials (also called the Enterprise Financial System, or EFS).
  • Handle all audits related to sponsored projects.
ActivityWhat SFR DoesWhat Departments Do
Financial Reports and InvoicesIssue required financial reports and invoices to sponsor.Review and confirm draft reports and invoices from SFR accountant within established deadlines (listed on this page). Instructions for running UM Transaction Detail by Invoice/Report Number.
Payment Application (Revenue)Ensure revenue is applied to the appropriate sponsored award when payments arrive.Review expenditures on a regular basis and remove unallowable expenses and/or overdrafts; contact SFR accountant with updates/alerts about pending payments.
CollectionsFollow up with sponsors on the status of past due payments.Assist/provide any updates/alerts or additional contact information for sponsor as requested by SFR.
Award CloseoutClose out awards in EFS after they have ended, and all payments are received.Use the Post Award Management Dashboard, ensure all items noted have been completed; respond requests/directions from the SFR accountant.
AuditsCoordinate all aspects of the audit including serving as the University's primary contact with auditor.Alert the SFR accountant assigned to the sponsored award upon receipt of an audit notification; assist/provide additional information as requested throughout audit.


ActivityWhat Departments Should Not DoWhy
Financial Reports and InvoicesCreate and send financial reports or invoices to the sponsor.This task is delegated solely to SFR through the University's delegation of authority policy.
Payment Application (Revenue)Make cost transfer entries for charges that are more than a year old or 90 days past the award end date.If the award ended more than 90 days ago, the final financial report/invoice have been submitted to the sponsor and SFR will have to adjust them.
CollectionsMake any agreements with sponsors related to past due amounts.There are certain thresholds that require varying levels of institutional signatory authorization on such agreements.
Award CloseoutProcess small dollar/penny JEs to zero out budget lines.When lines are less than +/- $35, SFR will process the journal/write-off.
AuditsRespond to audit inquiries and provide requested documentation directly to the auditor.SFR accountants are trained and follow an established process for handling audits.


Number of days following award termination that departmental review of financial reports and financial draw/invoice submissions received from SFR are due back to SFR:

  • USDA - Food and Nutrition Services - 81
  • NASA - 80
  • Other federal agencies, including USDE, DHHS, and NSF - 85
  • All other sponsors: 5 days before the financial report/invoice due date stipulated in the award's terms and conditions

Resources and Forms

Frequently Asked Questions

Sponsorships (event sponsorships)

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.


Sales Tax Returns (departments conducting external sales activities)

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.

Sales Tax on Purchases

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

Travel and Expenses

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

Unclaimed Property

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].

Workflow Administration

Approvers have been delegated authority to say yes or no to financial transactions. They are expected to review and approve using University policy, applicable laws, and sponsor requirements as guides. Activity is subject to management review, central review, internal audit, external audit, and public scrutiny. Many transactions processed in the financial system (PeopleSoft Financials, also known as the Enterprise Financial System or "EFS") require that online approvals be applied. This handy PDF describes the most common routings. There is an Approval WorkCenter within PeopleSoft Financials that brings together all of the financial approval tasks within EFS. This WorkCenter can be accessed from MyU > U Finance > find the section "EFS Quick Links" > select Approval.

Questions about workflow and approvals functions, access roles, and transactions may be sent to [email protected].

What if I have an emergency and need a transaction approved?

The simple absence of an approver or backup approver (or both) does not in and of itself constitute an emergency. What is truly urgent? If this transaction isn't reviewed immediately, is there is a realistic chance or certainty that it will result in:

  • Potential loss of life.
  • A situation that endangers safety of those studying at, working at, or visiting the University.
  • Loss of research.
  • Legal action.
  • Loss of reputation of the University.
  • Loss of a significant discount.
  • Etc.

A finance leader from your college or administrative unit (chief financial manager, RRC contact, cluster director) must contact the University Financial Helpline via [email protected] with the transaction number that needs attention and the Internet ID of the person that should review the activity, if known. The staff there will work with you to ensure appropriate action is taken in a timely manner by the responsible parties or delegates. In the event that the situation is not considered an emergency, but the transaction is still fairly urgent, some transactions may be re-routed. 

Approvals Policy

Appendicies to policy
Highlights for cluster directors
  • Individuals may not be the transaction "initiator" and the approver. That is, they may not direct staff to create a specific transaction and then act as the approver. Examples of this unallowable activity:
    • The approver for Department X may not tell someone to enter a transaction to transfer funds from account A to account B and then act as the approver for that transaction.
    • The approver for a PCard may not direct the cardholder to make a specific purchase, and then approve the PCard reconciliation report.
  • Individuals holding Certified Approval and DeptID Approval roles in EFS may not approve transactions that they have initiated.
  • It is strongly recommended that one individual not hold both the Certified Approval role and a DeptID approval role for the same DeptID.

Approver roles in the financial system

There are several approval roles within a department. It is recommended that units not establish one individual as both the primary and only alternate approver for any "level" of approval, to avoid transactions getting stuck in pending status when one individual is absent or unavailable.

  • Primary and alternate Certified Approver
  • Primary and alternate requisition approver, under $10,000
  • Primary and alternate requisition approver, over $10,000 (an additional approval is required; this is not "in lieu of" the under $10,000 approval but in addition to it)
  • Primary and alternate vendor payments approver, under $10,000
  • Primary and alternate vendor payments approver, over $10,000 (an additional approval is required; this is not "in lieu of" the under $10,000 approval but in addition to it)
  • Primary and alternate travel and reimbursement approver (only the primary approver for a DeptID is sent to Chrome River)
  • Primary and alternate Journal Entry approver
  • Primary and alternate PCard approver
  • Primary and alternate Credit Invoice approver (related to accounts receivable and billing activity)

Contact Us

Financial Helpline: 612-624-1617
[email protected]

1300 2nd Street S Minneapolis, MN 55454 (WBOB)
Campus Mail Code: 7529

Controller's Office units are housed in the West Bank Office Building (WBOB) and in the McNamara Alumni Center on the Twin Cities campus.