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

Options

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.

Reconciliations

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.

    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)

    About

    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

    Training

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

    Assets

    Capital Assets

    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
      AND
    • a useful life greater than or equal to the capitalization threshold for the asset category to which they belong.

    Examples of capital asset categories include land, buildings, capital equipment, library collections, etc.

    Capital assets are also known as "fixed assets" and "property, plant, and equipment."

    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
      AND
    • 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
      OR
    • 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
      or
    • 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

    Tagging identifies an equipment asset as a unique item and facilitates the periodic verification of equipment assets. Accounting Services' inventory team tags capital equipment asset acquisitions with bar-coded University ID number labels (asset tags). Sponsor-owned equipment that meets the University’s definition of capital equipment assets may be tagged with a sponsor ID label and/or a University ID number label as well.

    Periodic Verifications

    Accounting Services maintains and tests the property control system by conducting periodic verifications of the existence, location, and use-status of each University capital equipment asset. 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.

    Policies & Forms

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

    Budget

    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 policy.umn.edu. 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:

      Error Fund DeptID Program Project Account CF1 CF2 Fin EmplID CS
      X 1000   20135   720101        
      X   10005 20135   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:

      Error Fund DeptID Program Project Account CF1 CF2 Fin EmplID CS
      X 1000 10005 20135   720101       CS
      X 1000 10005   00000006 720101       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:

      Error Fund DeptID Program Project Account CF1 CF2 Fin EmplID CS
      X 1000 10005 20135 00000006 720101        

       

      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:

      Error Fund DeptID Program Project Account CF1 CF2 Fin EmplID CS
      X 3000 10005 20135   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:

      Error Fund DeptID Program Project Account CF1 CF2 Fin EmplID CS
      X 1000 10005 20089   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:

      Error Fund DeptID Program Project Account CF1 CF2 Fin EmplID CS
      X 1000 10005 20135   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:

      Error Fund DeptID Program Project Account CF1 CF2 Fin EmplID CS
      X 1000 10005     720101        

       

      FDPJ_RQ_PG

      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:

      Error Fund DeptID Program Project Account CF1 CF2 Fin EmplID CS
      X 1000 10005   00000006 720101        

       

      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

      Endowments

      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.

      Today

      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 give.umn.edu

      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 Owner (BPO) Reporting Team

      The BPO Reporting Team consists of the business process owners (BPOs) for financial reporting and the team lead of the EFS Module Support's Reporting Team.

      • Mollie Viola (BPO)
      • Suzanne Paulson (BPO)
      • Julie Tonneson (BPO)
      • Nicole Pilman (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 Type Subject Line must contain Sample subject Line Format Email Address
      Chrome River, see Voucher -- -- --
      Department Deposit Two pieces of text, always begins with "DeptDeposit" and the second piece is the barcode number in the bottom left on the Deposit Detail Report DeptDeposit 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 Entry Use the Attachments field on the JE itself -- --
      PCard Application Two 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

      OR

      TCard: 0123456

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

      OR

      0000234567
      [email protected]
      Voucher Voucher Document ID 06702333 [email protected]
      Requisitions / POs Use 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)
      • VOUCHER_IMAGE_EXCEPTION_RPT (Voucher-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 information Cluster scanning method Print to the imaging system method Email method

      Imaging system desktop client required

      x

      x

       

      No imaging system access required

       

       

      x

      Getting access to image documents

      Access 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 system

      Anyone 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 @umn.edu email address can send items to the imaging system.

      Notes

      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.

      Instructions

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

      Audit

      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 Source JE Header Source Description
      ALO Allocations
      AM Asset Management
      AP Accounts Payable
      AR Accounts Receivable
      AS Accounting Services
      BI Billing
      CFD Carryforward Balance
      CLO Interim and Year-End Close
      CNV Conversion
      EX Expenses
      EXT Generic External Journals
      GR Grants
      HR Human Resources
      HYP Hyperiod Planning And Budgeting
      IMP Import Spreadsheet Upload
      LM Enterprise Learning Management
      ONL Online Journal Entry
      ONN Online Non-Sponsored Journal
      ONS Online Sponsored Journal
      PC Project Costing
      PO Purchasing
      SA Student Administration
      SFR Sponsored Financial Reporting
      SL Student Loans
      TIP TIP Journals
      TR Treasury

      Transaction numbering and JE line source codes

      First three chars of JE ID
      Journal Line Source
      Long Name
      Short Name
      000 PNL PS/GL Journal Entry Page GL JE Page
      000 SCE Suspense Correction Entry Suspense
      000 SCP PS/GL - Copy Journal Copy Jrnl
      000 SCV Suspense Correction w/o VAT Susp- xVAT
      000 SER System - Err Suspense Reversal Err Rvrsl
      000 SES System - Error Suspense Err Susp
      000 SUP System - IntraUnit Payable IntraU P
      000 SUR System - IntraUnit Receivable IntraU R
      109 NVS PS/GL Spreadsheet Journal GL SJI
      200 NVS PS/GL Spreadsheet Journal GL SJI
      200 PNL PS/GL Journal Entry Page GL JE Page
      200 SUP System - IntraUnit Payable IntraU P
      200 SUR System - IntraUnit Receivable IntraU R
      ACC GAP JrnlGen - Accounts Payable JGen-AP
      ADD GAM JrnlGen - Asset Management JGen-AM
      ADD PNL PS/GL Journal Entry Page GL JE Page
      ADJ GAM JrnlGen - Asset Management JGen-AM
      ADJ NVS PS/GL Spreadsheet Journal GL SJI
      ADJ SUP System - IntraUnit Payable IntraU P
      ADJ SUR System - IntraUnit Receivable IntraU R
      ARB GAR JrnlGen - Accounts Receivable JGen-AR
      ARB NVS PS/GL Spreadsheet Journal GL SJI
      ARB PNL PS/GL Journal Entry Page GL JE Page
      ARB SUP System - IntraUnit Payable IntraU P
      ARB SUR System - IntraUnit Receivable IntraU R
      ARD GAR JrnlGen - Accounts Receivable JGen-AR
      ARD PNL PS/GL Journal Entry Page GL JE Page
      ARM GAR JrnlGen - Accounts Receivable JGen-AR
      ARR GAR JrnlGen - Accounts Receivable JGen-AR
      AS0 NVS PS/GL Spreadsheet Journal GL SJI
      AS0 SUP System - IntraUnit Payable IntraU P
      AS0 SUR System - IntraUnit Receivable IntraU R
      AST NVS PS/GL Spreadsheet Journal GL SJI
      BDG ALO PS/GL Allocations GL Alloc
      BDG NVS PS/GL Spreadsheet Journal GL SJI
      BDG SUP System - IntraUnit Payable IntraU P
      BDG SUR System - IntraUnit Receivable IntraU R
      BI0 GBI JrnlGen - Billing JGen-BI
      BI0 PNL PS/GL Journal Entry Page GL JE Page
      BSC NVS PS/GL Spreadsheet Journal GL SJI
      BSC SUP System - IntraUnit Payable IntraU P
      BSC SUR System - IntraUnit Receivable IntraU R
      CAN GAP JrnlGen - Accounts Payable JGen-AP
      CAN NVS PS/GL Spreadsheet Journal GL SJI
      CAN SUP System - IntraUnit Payable IntraU P
      CAN SUR System - IntraUnit Receivable IntraU R
      CAP NVS PS/GL Spreadsheet Journal GL SJI
      CAP SUP System - IntraUnit Payable IntraU P
      CAP SUR System - IntraUnit Receivable IntraU R
      CAS NVS PS/GL Spreadsheet Journal GL SJI
      CAS SUP System - IntraUnit Payable IntraU P
      CAS SUR System - IntraUnit Receivable IntraU R
      CEF NVS PS/GL Spreadsheet Journal GL SJI
      CEF SUP System - IntraUnit Payable IntraU P
      CEF SUR System - IntraUnit Receivable IntraU R
      CFD GOT JrnlGen - Other JGen-Other
      CFD NVS PS/GL Spreadsheet Journal GL SJI
      CFD PNL PS/GL Journal Entry Page GL JE Page
      CFD SCP PS/GL - Copy Journal Copy Jrnl
      CFD SUP System - IntraUnit Payable IntraU P
      CFD SUR System - IntraUnit Receivable IntraU R
      CLN NVS PS/GL Spreadsheet Journal GL SJI
      CLN SUP System - IntraUnit Payable IntraU P
      CLN SUR System - IntraUnit Receivable IntraU R
      CLO GAP JrnlGen - Accounts Payable JGen-AP
      CNV EXT PS/GL External Journal External
      CNV NVS PS/GL Spreadsheet Journal GL SJI
      CNV PNL PS/GL Journal Entry Page GL JE Page
      CNV SCP PS/GL - Copy Journal Copy Jrnl
      CNV SUP System - IntraUnit Payable IntraU P
      CNV SUR System - IntraUnit Receivable IntraU R
      CON NVS PS/GL Spreadsheet Journal GL SJI
      CON SUP System - IntraUnit Payable IntraU P
      CON SUR System - IntraUnit Receivable IntraU R
      COR NVS PS/GL Spreadsheet Journal GL SJI
      COR SUP System - IntraUnit Payable IntraU P
      COR SUR System - IntraUnit Receivable IntraU R
      CPP NVS PS/GL Spreadsheet Journal GL SJI
      CPP SUP System - IntraUnit Payable IntraU P
      CPP SUR System - IntraUnit Receivable IntraU R
      CSO NVS PS/GL Spreadsheet Journal GL SJI
      CSO SUP System - IntraUnit Payable IntraU P
      CSO SUR System - IntraUnit Receivable IntraU R
      CWS GHR JrnlGen - HRMS JGen-HR
      CWS NVS PS/GL Spreadsheet Journal GL SJI
      CWS SES System - Error Suspense Err Susp
      CWS SUP System - IntraUnit Payable IntraU P
      CWS SUR System - IntraUnit Receivable IntraU R
      DIS NVS PS/GL Spreadsheet Journal GL SJI
      DPR GAM JrnlGen - Asset Management JGen-AM
      DPR PNL PS/GL Journal Entry Page GL JE Page
      DSC NVS PS/GL Spreadsheet Journal GL SJI
      DSC SUP System - IntraUnit Payable IntraU P
      DSC SUR System - IntraUnit Receivable IntraU R
      DSR NVS PS/GL Spreadsheet Journal GL SJI
      DSR SUP System - IntraUnit Payable IntraU P
      DSR SUR System - IntraUnit Receivable IntraU R
      EAC GEX JrnlGen - Expenses JGen-EX
      EAC PNL PS/GL Journal Entry Page GL JE Page
      ECN GEX JrnlGen - Expenses JGen-EX
      ECN PNL PS/GL Journal Entry Page GL JE Page
      ENC NVS PS/GL Spreadsheet Journal GL SJI
      EPY GEX JrnlGen - Expenses JGen-EX
      EPY PNL PS/GL Journal Entry Page GL JE Page
      ESC GEX JrnlGen - Expenses JGen-EX
      ESC PNL PS/GL Journal Entry Page GL JE Page
      FBT GHR JrnlGen - HRMS JGen-HR
      FBT NVS PS/GL Spreadsheet Journal GL SJI
      FBT SES System - Error Suspense Err Susp
      FMX GHR JrnlGen - HRMS JGen-HR
      FMX SES System - Error Suspense Err Susp
      FY0 NVS PS/GL Spreadsheet Journal GL SJI
      FY0 SUP System - IntraUnit Payable IntraU P
      FY0 SUR System - IntraUnit Receivable IntraU R
      GFA GGM    
      GFA GPC JrnlGen - Project Costing JGen-PC
      GIP NVS PS/GL Spreadsheet Journal GL SJI
      GIP SUP System - IntraUnit Payable IntraU P
      GIP SUR System - IntraUnit Receivable IntraU R
      GLR NVS PS/GL Spreadsheet Journal GL SJI
      GLR SUP System - IntraUnit Payable IntraU P
      GLR SUR System - IntraUnit Receivable IntraU R
      GRT GCA JrnlGen - Contract JGen-CA
      GRT GGM    
      GRT GPC JrnlGen - Project Costing JGen-PC
      HSA GHR JrnlGen - HRMS JGen-HR
      HSA PNL PS/GL Journal Entry Page GL JE Page
      HSA SES System - Error Suspense Err Susp
      IC0 CLO PS Batch Closing Closing
      IC0 SUP System - IntraUnit Payable IntraU P
      IC0 SUR System - IntraUnit Receivable IntraU R
      IMP NVS PS/GL Spreadsheet Journal GL SJI
      IMP PNL PS/GL Journal Entry Page GL JE Page
      IMP SUP System - IntraUnit Payable IntraU P
      IMP SUR System - IntraUnit Receivable IntraU R
      MC0 GOT JrnlGen - Other JGen-Other
      MC0 PNL PS/GL Journal Entry Page GL JE Page
      PCD GHR JrnlGen - HRMS JGen-HR
      PFL GHR JrnlGen - HRMS JGen-HR
      PFL PNL PS/GL Journal Entry Page GL JE Page
      PMT GAP JrnlGen - Accounts Payable JGen-AP
      PYN GHR JrnlGen - HRMS JGen-HR
      PYN NVS PS/GL Spreadsheet Journal GL SJI
      PYN SES System - Error Suspense Err Susp
      PYP GHR JrnlGen - HRMS JGen-HR
      PYP SES System - Error Suspense Err Susp
      PYR GHR JrnlGen - HRMS JGen-HR
      PYR SES System - Error Suspense Err Susp
      PYS GHR JrnlGen - HRMS JGen-HR
      PYS NVS PS/GL Spreadsheet Journal GL SJI
      PYS SES System - Error Suspense Err Susp
      RET GAM JrnlGen - Asset Management JGen-AM
      RET PNL PS/GL Journal Entry Page GL JE Page
      REV NVS PS/GL Spreadsheet Journal GL SJI
      REV SUP System - IntraUnit Payable IntraU P
      REV SUR System - IntraUnit Receivable IntraU R
      RV2 NVS PS/GL Spreadsheet Journal GL SJI
      RV2 SUP System - IntraUnit Payable IntraU P
      RV2 SUR System - IntraUnit Receivable IntraU R
      SAF GSF JrnlGen - Student Financials JGen-SF
      SAF PNL PS/GL Journal Entry Page GL JE Page
      SAL NVS PS/GL Spreadsheet Journal GL SJI
      SAL SUP System - IntraUnit Payable IntraU P
      SAL SUR System - IntraUnit Receivable IntraU R
      SFR NVS PS/GL Spreadsheet Journal GL SJI
      SFR SUP System - IntraUnit Payable IntraU P
      SFR SUR System - IntraUnit Receivable IntraU R
      SL0 GOT JrnlGen - Other JGen-Other
      SL0 PNL PS/GL Journal Entry Page GL JE Page
      STS NVS PS/GL Spreadsheet Journal GL SJI
      STS SUP System - IntraUnit Payable IntraU P
      STS SUR System - IntraUnit Receivable IntraU R
      TAF GHR JrnlGen - HRMS JGen-HR
      TAF NVS PS/GL Spreadsheet Journal GL SJI
      TAF SES System - Error Suspense Err Susp
      TR0 GTR JrnlGen - Treasury JGen-TR
      TR0 PNL PS/GL Journal Entry Page GL JE Page
      TR9 NVS PS/GL Spreadsheet Journal GL SJI
      TRA GAM JrnlGen - Asset Management JGen-AM
      TRA PNL PS/GL Journal Entry Page GL JE Page
      TRE NVS PS/GL Spreadsheet Journal GL SJI
      TRE SUP System - IntraUnit Payable IntraU P
      TRE SUR System - IntraUnit Receivable IntraU R
      TRS NVS PS/GL Spreadsheet Journal GL SJI
      TRS SUP System - IntraUnit Payable IntraU P
      TRS SUR System - IntraUnit Receivable IntraU R
      UNA NVS PS/GL Spreadsheet Journal GL SJI
      UNA SUP System - IntraUnit Payable IntraU P
      UNA SUR System - IntraUnit Receivable IntraU R
      USV NVS PS/GL Spreadsheet Journal GL SJI
      USV SUP System - IntraUnit Payable IntraU P
      USV SUR System - IntraUnit Receivable IntraU R
      YE0 CLO PS Batch Closing Closing

      JE header "system source" codes

      JE header system source
      JE header system source short name
      JE header system source long name
      SCP Copy Jrnl PS/GL - Copy Journal
      SCR Round Adj System - Currency Round Adj.
      SCV Susp- xVAT Suspense Correction w/o VAT
      SER Err Rvrsl System - Err Suspense Reversal
      SES Err Susp System - Error Suspense
      SIU InterUnit System - InterUnit From/To
      SJE GL SJE PS/GL Standard Journal Entry
      SNP InterU P System - InterUnit Payable
      SNR InterU R System - InterUnit Receivable
      SPA Pos Acct System - Position Account
      SUP IntraU P System - IntraUnit Payable
      SUR IntraU R System - IntraUnit Receivable
      SVT VAT Accts System - VAT Accounts
      ALO GL Alloc PS/GL Allocations
      CLO Closing PS Batch Closing
      CON GL Consol PS/GL Consolidations
      EQT GL Eqit PS/GL Equitization
      EXT External PS/GL External Journal
      EXV Ext. VAT PS/GL External with VAT
      GAE JGen-EEAP JrnlGen - Entry Event AP
      GAM JGen-AM JrnlGen - Asset Management
      GAP JGen-AP JrnlGen - Accounts Payable
      GAR JGen-AR JrnlGen - Accounts Receivable
      GAV JGen-AV JrnlGen - Student Advancement
      GBI JGen-BI JrnlGen - Billing
      GCA JGen-CA JrnlGen - Contract
      GEX JGen-EX JrnlGen - Expenses
      GGP JGen-GP JrnlGen - Global Payroll
      GHR JGen-HR JrnlGen - HRMS
      GIN JGen-IN JrnlGen - Inventory
      GKK JGen-EEBD JrnlGen-Entry Event GL Budgets
      GLM JGen-ELM JrnlGen - Learning Management
      GOT JGen-Other JrnlGen - Other
      GPC JGen-PC JrnlGen - Project Costing
      GPE JGen-EEPO JrnlGen - Entry Event PO
      GPO JGen-PO JrnlGen - Purchasing
      GRE JGen-EEAR JrnlGen - Entry Event AR
      GSF JGen-SF JrnlGen - Student Financials
      GTD JGen-TD JrnlGen - Promotion Management
      GTR JGen-TR JrnlGen - Treasury
      IC iClient Internet Client
      IE iClient Ex Internet Client Express
      KOS Offset Commitment Control Offset
      KRP KReplace Commitment Replacement
      NVS GL SJI PS/GL Spreadsheet Journal
      OTH Other Other Source
      PNL GL JE Page PS/GL Journal Entry Page
      REV Curr Reval PS/FS Currency Revaluation
      SAS Amt Susp System - Amount Suspense
      SBR Bal Rvrsl System - Bal Suspense Reversal
      SBS Bal Susp System - Balancing Suspense
      SCE Suspense Suspense Correction Entry
      TRN Curr Trans PS/FS Currency Translation
      TWL Tran w/Led PS/FS Curr Trans Within Ledger
      UKN Unknown Unknown
      GPK JGen-EEPCB JrnlGen-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

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

      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.

      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

        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.

        Resources

        Purchasing

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

        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.
        Activity What SFR Does What Departments Do
        Financial Reports and Invoices Issue 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.
        Collections Follow 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 Closeout Close 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.
        Audits Coordinate 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.

         

        Activity What Departments Should Not Do Why
        Financial Reports and Invoices Create 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.
        Collections Make 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 Closeout Process small dollar/penny JEs to zero out budget lines. When lines are less than +/- $35, SFR will process the journal/write-off.
        Audits Respond to audit inquiries and provide requested documentation directly to the auditor. SFR accountants are trained and follow an established process for handling audits.

        Deadlines

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

        • USDA - Food and Nutrition Services - 81
        • NASA - 80
        • USDE - 55
        • Other federal letter of credit sponsors, including DHHS and NSF - 85
        • All other sponsors: 5 days before the 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.

        Taxes

        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 travel.umn.edu 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, 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?

        Please report the information to the Controller's Office [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
          Procedures
          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.