The Quaestor - Volume 17, Issue 1

The year-end closing activities are performed to ensure all financial transactions for the fiscal year are recoded and the University’s financial records are complete. The preparation of accurate and timely financial statements is a collaborative effort and a responsibility that we all share.  Employees throughout the University who are responsible for accounting processes are integral to the closing process and as such it is important they understand and follow the year-end closing deadlines and processes.

Year-End Resources

• The Year-end Accounting Workshop is available online through the RIT Talent Roadmap.

• Additional resources including a list of important dates for year-end close deadlines, transaction examples, and a list of subject matter contacts can be found on the Controller’s Office website under “Year-End Closing Processes and Procedures".

• Two year-end close virtual open lab sessions will be hosted by the Accounting and Financial Reporting team. These sessions are designed for ad-hoc user questions after they have reviewed the online year-end accounting workshop. There is no formal presentation as part of these sessions.

Important Reminders

Accrual-based accounting is recognizing an economic event at the time the transaction occurs, rather than when cash is exchanged. The RIT financial statements are prepared on the accrual basis of accounting. We need your help to ensure that the University’s financial statements are prepared accurately. The transactions described below require special handling during the year-end process.

• Accrue goods or services received/rendered by June 30, 2022 that have not been invoiced using a journal entry.
  • Review department expense encumbrances compared to actual charges to determine if anticipated fiscal 2022 transaction activity has not yet been recorded.
  • Refer to Controller’s Office year-end closing materials to determine if you need to prepare a journal entry to record a fiscal-year expense.

• Ensure any fiscal 2022 Oracle travel expense reports (TER) have been completed, approved and submitted prior to year-end. If the TER expense is not reflected in your department’s preliminary statements, that transaction will need to be accrued using a journal entry.

• Defer income for revenue (payments) you received that are taking place in the following fiscal year (FY23, July 1, 2022 – June 30, 2023).

• Record a prepaid expense using a journal entry for expenses paid in the current fiscal year (FY22, July 1, 2021 – June 30, 2022) for goods that will be received or services that will be rendered in the following fiscal year (FY23, July 1, 2022 – June 30, 2023).

• It is also important to prepare documentation that explains and supports accounting transactions recorded, including accruals, deferred income, and prepaids.

Important Dates (Controller's Office monthly closing schedule)

The exact dates for year-end closing deadlines change from year-to-year, for additional information on FY22’s closing timeline visit the Controller’s Office website.

• Thursday, July 7^th – Preliminary general ledger close
• Friday, July 8^th – Preliminary department statements available
• Tuesday, July 12^th – Posting resumes
• Friday, July 15^th – Final general ledger close
• Monday, July 18^th – Final department statements available

Thank you in advance for your attention to financial accounting transactions throughout the fiscal year and your efforts to prepare for the fiscal year-end close. Your help is essential to ensure the University’s financial statements are prepared timely and accurately.                                                   

We strongly encourage you to use these Year-End Resources to familiarize yourself with year-end processes and timelines. If you have any questions or need additional information please contact the RIT Service Center at help.rit.edu or (585) 475-5000.

There are pros and cons to why organizations (“user entities”) utilize third party service providers (TPSP), specifically, cloud computing or service organizations.  According to IBM.com, here are “Five ways cloud is enhancing higher education.”

1. Streamlining operations “Like many other businesses, colleges and universities have limited funds to deploy and maintain enterprise information technology systems, so they turn to cloud for lower costs and improved efficiency.”
2. Improving student productivity, conferencing and collaboration.
3. Extending the reach of higher education.
4. Enhancing and scaling delivery of course material.
5. Personalizing education and improving learning outcomes.

Per Verizon.com “The cloud also grants institutions the ability to shift resources—curricula, tools, whatever—onto third-party providers' hardware. This cuts spending, reduces maintenance costs and frees up IT staff for more innovative work that can further enhance teacher and student experiences.”[ii]

Nevertheless, there are risks to using the cloud.  In addition to risks that the solution is not delivering what it was purchased to offer the user entity, if private data is involved, there is risk that sensitive data is not being protected as required by applicable laws, industry standards, and/or policy.  Private data, as defined by RIT’s Information Security Office, is “information that is confidential and which could be used for identity theft.”  Examples include: Social Security Numbers (SSNs), Individual Taxpayer Identification Numbers (ITINs), or other national identification numbers; Driver’s license numbers; Financial account information (bank account numbers, checks, credit or debit card numbers), etc.[iii]

Data protection is the responsibility of both the service organization and the user entity (e.g., RIT department purchasing and “owning” the service).  When it comes to data protection, the service organization or TPSP is responsible for certain controls and the user organization is responsible for certain controls.  Organizations that receive System and Organization Controls (SOC) reports will typically find the listing of controls, that the user entity is responsible for, in the Complementary User Entity controls (CUEC) section of a SOC Report.

There are different types of SOC Reports.  The American Institute of Certified Public Accountants (AICPA) lists three (3) types of SOC reports as follows.

SOC 1 – SOC for Service Organization: ICFR.  Report on Controls at a Service Organization Relevant to User Entities’ Internal Control over Financial Reporting (ICFR).  There are two types of reports for these engagements:

• Type 2 - report on the fairness of the presentation of management’s description of the service organization’s system and the suitability of the design and operating effectiveness of the controls to achieve the related control objectives included in the description throughout a specified period.
• Type 1 – report on the fairness of the presentation of management’s description of the service organization’s system and the suitability of the design of the controls to achieve the related control objectives included in the description as of a specified date.

SOC 2 - SOC for Service Organizations: Trust Services Criteria.  Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy

SOC 3 – SOC for Service Organizations: Trust Services Criteria for General Use Report 

SOC 3 reports are designed for the public.  Refer to https://www.ellucian.com/assets/en/ellucian-soc3-report-2020-21.pdf for an example of a SOC 3 report.  SOC 1 and SOC 2 reports are confidential in nature and are distributed only to user entities or customers of TPSPs. 

Within the SOC reports CUEC section (see page 7 in the SOC 3 report example link provided above), the TPSP identifies the controls that it assumes the user entity has in place, relative to their relationship or to the service.  Below is an example of what a TPSP has identified as being the responsibility of the user entity.

​

. . . and so on. 

While the SOC reports contains the TPSP’s controls (as identified by the TPSP and tested by an independent party) and the TPSP’s assumptions as to what is in place at/with the user entity, how can the user entity ensure that appropriate CUEC’s are in place?

An example of a best practice that has been implemented by the Payment Card Industry (PCI) Security Standards Council is the “Third Party Security Assurance” template that clearly defines the responsibilities between the TPSP and user entity.  Below is an excerpt.[v]

​

Although completion of the template is not required for PCI Data Security Standards (DSS) compliance, and not all PCI DSS requirements apply to the user entity’s relationship with a TPSP, the processes for arriving at a completed template helps ensure there are no gaps in controls and might be a way to determine whether duplication of effort exists.  Note: a control may apply to both the TPSP and the user entity due to different environments, users, processes, etc.  Moreover, this is not a one-and-done exercise.  People, processes, and tools at both the TPSP and user entity change.  Therefore, a review of the controls and responsibilities needs to account for such changes, and be reviewed over the life of the relationship.

• [ii]https://www.verizon.com/business/resources/articles/s/edge-computing-vs-cloud-computing-benefits-in-higher-education/ 
• [iii]https://www.rit.edu/security/information-access-protection-standard   
• [v]https://www.pcisecuritystandards.org/documents/ThirdPartySecurityAssurance_March2016_FINAL.pdf?agreement=true&time=1649345969767 - refer to Appendix B.