Independence Threats Hidden in Technology Services

 

---

Do you provide information technology services for your attest clients? Or does the firm that performs your attest work also provide information technology services? Those services may now cause independence concerns.

 

The AICPA Professional Ethics Executive Committee (PEEC) issued a revised independence interpretation for practitioners providing information technology services. The revised interpretation clarifies which aspects of providing information technology (IT) services could impair independence. After a COVID-19 deferral, we are now quickly closing in on the revision’s implementation date of Jan. 1, 2022.

This article highlights the changes and how to approach the new guidance.

 

Overview

ET Section 1.295.145 of the AICPA Code of Professional Conduct is a revised interpretation within the nonattest services section, specifically providing guidelines when performing IT services for an attest client. Thus, ET 1.295.145, Information System Services, supersedes existing ET 1.295.145, Information Systems Design, Implementation, or Integration.

The revised interpretation only affects practitioners and clients when the same firm provides a client with IT services and performs attest services, including audits, reviews, and other attest services that require the practitioner to be independent. If a firm provides IT services but does not perform an attest service, then this revised interpretation is not applicable.

Note that this is a revision to an existing Independence Rule interpretation. Much remains the same between the existing and the revised guidance. The substance of both is that independence is impaired anytime a practitioner assumes management’s responsibility (management participation threat) or performs work that will be subject to procedures performed during an attest engagement (self-review threat).

The changes, essentially, are in the level of detail. We now have an expanded set of guidelines covering current IT service offerings to aid the practitioner in ensuring that his or her work does not cross the line. The increase in detail is most notable in the definitions of key terms. These definitions aid in determining what is permissible, what is absolutely prohibited (no safeguards could reduce the threats to an acceptable level), and what is a gray area dependent on the facts and circumstances of the situation.

There are three main points in applying the interpretation. Keep these in mind to help identify the relevant section to consult:

• What type of system is the practitioner working on: is it a financial information system or a nonfinancial information system?
• Is the system a commercial off-the-shelf (COTS) system or a practitioner-developed system?
• In what phase is the service: design and implementation or maintenance, support, and monitoring?

If you are wondering “What qualifies as a financial information system?” or “What is included in the implementation phase?,” then knowing the terminology is the place to start.

 

Terminology

In reviewing the revised interpretation, terminology is a must for understanding and applying the guidance.

Financial information system – The key to evaluating any IT service is determining if it involves a financial information system. A financial information system is defined as a system that aggregates source data underlying the financial statements or generates information that is significant to either the financial statements or financial processes as a whole.

Think of a general ledger system or its related modules, such as accounts receivable or inventory. Those are clearly financial information systems, but the definition covers much more. The definition further states a financial information system includes a tool that calculates results, which seemingly covers a lot of applications. However, an exception exists: the financial information system includes a tool that calculates results, unless the tool performs only discrete calculations; the attest client evaluates and accepts responsibility for the input and assumptions; and the attest client has sufficient information to understand the calculation and the results.

Determining whether the service provided involves a financial information system is crucial because certain services are permitted for nonfinancial information systems while others would impair independence. Consequently, determining whether the service involves a system that meets the “tool exception” is also key.

Consider an application that simply calculates straight-line depreciation for fixed assets. Then consider an application that calculates and allocates overhead to work in process; incorporates intersecting rules for labor hours, machine hours, material costs, and type of job; and produces amounts and entries that are not practicable to recheck without the use of that tool. In evaluating each tool, how much of the tool’s work is “visible,” allowing the client to evaluate and take responsibility for the input and assumptions and easily understand the calculations and results? Whether either one of these examples meets the definition of a tool in practice depends on its particular situation, but they illustrate some of the difficulties in applying the definition.

COTS software solution – Determining if something is a COTS system is also key to determining permissible services. COTS refers to software developed, distributed, maintained, and supported by entities that are not the member or member’s firm (a third-party vendor), sometimes referred to as an “off-the-shelf” package or solution. The self-review and management participation threats are entirely different depending on whether the services provided involve a COTS or a firm-developed system.

Services – After determining the type of system (e.g., financial information system or nonfinancial information system and COTS or practitioner-developed), the next step is to determine what service is being provided:

• Design – Designing an information system means determining how a system or transaction will function, process data, and produce results (such as reports, journal vouchers, and sales and purchase orders) to provide a blueprint for the development of software code (programs) and data structures.
• Development – Developing an information system entails creating software code for individual or multiple modules and testing such code to confirm it is functioning as designed.
• Implementation – Implementation services are provided after the design and development of the system. Implementation ceases when the system is available on a regular basis to the client for its intended use. Implementation services include activities such as installing, configuring, interfacing, customizing, and data translation.
• Maintenance, support, and monitoring – These activities are provided after a financial or nonfinancial system or network is implemented.

 

Application of the Guidance

In this section, let’s look at what a practitioner can and cannot do based on what’s been outlined so far. We can categorize application into three areas:

• Nonfinancial information system software solutions
• Financial information system software solutions
• System and network maintenance, support, and monitoring

Nonfinancial information system software solutions – Assume a practitioner is providing design, development, or implementation services for a nonfinancial information system to an attest client. In this case, since a nonfinancial information system is involved, any threat to Independence Rule compliance would be at an acceptable level.*

Financial information system software solutions – Assume a practitioner is engaged to design or develop a financial information system for an attest client. This logically creates an independence conflict since the practitioner would be working on the very system that would be subject to the attest engagement. Consequently, this is a definite no: threats to compliance with the Independence Rule could not be overcome with safeguards.

The deciding factor in whether design and development services can be performed while maintaining independence is whether the system is a financial information system or nonfinancial information system. It is imperative that you make the correct determination.

This is not always easy. Often, it may appear as if an application is a nonfinancial information system because it doesn’t involve the general ledger system or directly affect any key financial information system modules. However, that deduction is not always correct. Additional factors for consideration are provided in the revised interpretation.

A practitioner needs to consider all relevant factors, such as whether the nonattest service will affect any of the following:

• System controls or outputs that will be subject to attest procedures
• A system that generates data used as input to the financial statements, including disclosures, or used in determining financial statement amounts and disclosures
• A data-gathering system, such as an analytical or reporting tool, that is used in management’s decision-making about matters that could significantly affect financial reporting
• A system that is part of a client’s internal controls over financial reporting – information systems used only in controlling the efficiency and effectiveness of operations are considered unrelated to the financial statements and accounting records

A “yes” to any of the above indicates a financial information system is involved; therefore, independence cannot be maintained if design and development services are performed.

What about implementing a COTS financial information system software solution? By definition, a COTS solution is designed and developed by a third party, therefore any service offerings for a COTS financial information system start with implementation.

Implementation can include installation, configuration, customization, interfacing, and/or data translation.

Installing a COTS financial information system is the initial loading of software on the client’s designated hosting site. In performing this service, threats to compliance with the Independence Rule could be at an acceptable level.*

Configuring and customizing are often used interchangeably, but within the terminology of the interpretation they represent separate and distinct services. Configuring a COTS financial information system means inputting the client-selected features, functionality options, and settings within the third-party vendor’s software. Configuration options may also include selecting the predefined format of certain data attributes and the inclusion or exclusion of such attributes. These selections are permissible if they are within the COTS functionality. Configuring would not include the practitioner designing or developing code or features to modify or alter the functionality of the COTS. Designing or developing a client’s financial information system in any way will impair independence. Any threat to compliance with the Independence Rule would be at an acceptable level when a practitioner configures a COTS financial information system based on the client’s selections within the parameters of the third-party vendor’s software.*

Customizing a COTS financial information system means modifying or enhancing the features or functions in ways that go beyond the options provided by the third-party vendor when configuring the COTS software solution. Modification involves altering the COTS software solution code to change or add to the functionality provided by the third-party vendor; enhancement involves developing new code external to the COTS software solution that works in concert with the COTS software solution to provide altered or additional functionality.

If a practitioner customizes a COTS financial information system, the threat to compliance with the Independence Rule would not be acceptable and independence would be impaired. The application of safeguards could not reduce the threat to an acceptable level.

Providing a COTS financial information system interface service means connecting two or more systems by designing and developing software code that passes data from one system to another. Once again, we are up against the barrier of designing and developing a client’s financial information system, which cannot be done while remaining independent. However, with interface services, there is an exception. If a practitioner uses a third-party vendor application, such as an application programming interface (API) to connect two or more systems or applications, threats to independence would be lowered to an acceptable level, provided the practitioner is not designing or developing code for the API to work.*

An example of an interface service would be connecting a client’s payroll system to its general ledger system so payroll-related data can pass from the payroll system to the general ledger system, avoiding manual input. If the practitioner designs and develops the code for this interface to work, independence has been impaired. If, however, the practitioner uses an API to accomplish the interface between the payroll and general ledger systems, the practitioner’s services meet the requirements for the exception and independence has not been impaired.*

A part of every new system implementation is data translation: moving an organization’s current and historical data from its legacy system to its new system. Data translation services for a COTS financial information system software solution involves designing and developing the rules or logic necessary to convert legacy system data to a format compatible with that of the new system. Data translation services that involve designing and developing would impair a practitioner’s independence. However, there is an exception for data translation services similar to interface services. If a practitioner uses a third-party vendor’s application, such as an API, to perform the data translation services, threats to independence would be at an acceptable level, provided the practitioner is not designing or developing code for the API to work.*

Most general ledger software solutions include vendor-developed APIs that enable an organization’s data to be passed from its legacy system to its new system.

System/network maintenance, support, and monitoring – After a system is operational, additional services such as maintenance, support, and monitoring may be needed. In determining if post-implementation services impair independence, the key is if they are performed on an ongoing basis. Independence is impaired if a client outsources an ongoing function, process, or activity to the practitioner because the practitioner would be in the position of assuming a management responsibility.

Under the revised interpretation, providing continuous software support or network maintenance undoubtebly impairs independence. The guidelines for post-implementation services apply to both financial information systems and nonfinancial information systems. There is no differentiation because the overall threat is “management participation.” It is not dependent on the type of system.

Firms that provide attest services for a client could still provide post-implementation services in a limited capacity if they adhere to strict guidelines:

• The services are individually separate, distinct, and not ongoing engagements.
• The attest client has not outsourced any function, process, or activity to the practitioner.
• The practitioner has not assumed any management responsibility.

Here are some examples of acceptable post-implementation services* listed in the interpretation:

• Analyzing a network and providing observations or recommendations
• Applying virus protection solutions or updates that the practitioner did not design or develop
• Applying certain updates and patches that the practitioner did not design or develop
• Providing advice, training, or instruction on a software solution
• Assessing the design or operating effectiveness of an attest client’s security over information technology systems
• Assessing the attest client’s information technology security policies or practices

The interpretation also includes examples of post-implementation services that would impair independence:

• Operates the attest client’s network, such as managing the attest client’s systems or software applications
• Supervises client personnel involved in the operation of the attest client’s information systems
• Has responsibility for monitoring or maintaining the attest client’s network performance
• Operates or manages the attest client’s information technology help desk
• Has responsibility to perform ongoing network maintenance, such as updating virus protection solutions, applying routine updates and patches, or configuring user settings
• Has responsibility for maintaining the security of the attest client’s networks and systems

The prohibition on providing ongoing services is an area where practitioners will need to carefully evaluate existing service arrangements. It is typical for clients of a certain size to not have full-time IT service personnel, and they may look to their CPA for assistance. Firms can provide value for clients in fulfilling maintenance, support, and monitoring activities, but they cannot provide these as ongoing services for their attest clients.

 

Conclusion

This revised interpretation is substantial. It provides more in-depth guidance than the existing interpretation and has been expanded to cover typical IT service offerings. With a Jan. 1, 2022, implementation date, practitioners and clients must become familiar with the revised interpretation to determine if any changes are needed to service arrangements prior to Dec. 31, 2021.

For additional guidance, keep an eye on the PEEC, which has an IT Services Task Force assigned to develop guidance to assist practitioners with implementing the new interpretation. 

* Assuming all of the requirements for providing nonattest services (subtopic 1.295) have been met. Note: the attest client cannot outsource any function, process, or activity to the practitioner. The practitioner must be free of assuming any management responsibility.

---

Sheila A. Border, CPA, is a senior manager at Wipfli LLP in Radnor and a member of the Pennsylvania CPA Journal Editorial Board. She can be reached at sborder@wipfli.com.