Every data interface poses a risk to the accuracy and completeness of financial reporting. After completing a risk assessment, each risk of material misstatement identified should be adequately controlled to reduce the risk of misstatement arising from the interfaces to an acceptably low level.
An organization using different software solutions might create centralized data repositories to make the user experience easier.
They may also have different software solutions that need to communicate and share data directly between software solutions. Organizations might automate repetitive processes of manual data transfers to boost efficiency, too.
Risk Assessment in Data Transfers
Companies with automations transferring data from one system to another need a framework to identify risks of material misstatement to financial statements.
All data transfers share a single objective—to be transferred without error. Auditing terms define these as assertions of completeness and accuracy.
- Completeness. No data lost during the transfer
- Accuracy. Data is unaltered in the transfer
When assessing the likelihood and magnitude of misstatements to identify risks of material misstatement, it’s important to understand how IT affects the flows of transactions.
Understanding the technical setup of an interface isn’t critical, but understanding the flow of data through your systems is.
With each data transfer lies a risk that the data will be inaccurate or incomplete. Partner with your IT group to identify and assess those risks.
The number of times data is handed off from one system to another represents an increase of likely sources of potential misstatements.
Data in the origination system could be in a format the system ingesting the data might not use. Just as a message in English would have to be translated for it to be understood by someone who only speaks Japanese, a percentage stored as 75% in the originating system might need to be converted to 0.75 in the target system.
Part of the data translation—conversion in audit terms—is dropping the percentage sign and dividing the number by 100. If the interface isn’t properly programmed, the target system may receive 7,500%.
To help you identify where these conversion risks originate, we suggest organizations diagram the flow of data and any conversion, calculation, or other manipulation points.
Translation Occurs in Either Origination System or Target System
Perhaps you have a more complex case. Sometimes, the conversions occur in intermediary systems, also known as middleware.
Multiple Handoffs and a Translation
An organization’s IT department should understand the technical nature of the data transfer and help identify where the data handoffs and translations happen.
Other Risk Assessments
Other sources of misstatement include precision as well as joining and data cardinality.
When data transfers are designed, data might be aggregated before it is transferred. For example, detailed sales records from a system can be batched and recorded as a single entry in a general ledger (GL) system. Data aggregation is a calculation that could be at risk for improper programming.
Joining and Data Cardinality
Sometimes, data from two different systems will need to be joined into one table. Databases allow for different join functions such as one-to-one or one-to-many. When writing a join function, the cardinality of data—the relationship of one record to other records—is at risk. An improperly programmed join function could cause duplicate records or missing records.
Data moving through an interface is only as reliable as data entered into the original system. Trace data back to its source input to capture all interfaces. Consider how data is input whether manually by a human or automatically via an external submission. There should be adequate controls of accurate entry of valid data at the input point.
Data transfers can consume resources. A table with many fields or columns might not need all fields transferred. Accordingly, a user may instruct the developer of a data transfer to only include certain fields of data. Thus, there’s risk that a necessary field isn’t transferred.
A simple diagram of the data flow might not identify all risks. Work with the IT group to understand the interface’s setup. The frequency at which the interface occurs is a factor in the risk of material misstatement. This typically breaks down into two categories.
Associated risks vary depending on the data.
Companies running reports from a report writer with its own database may have data coming into that database in real time from other sources. In these scenarios, the report user can’t specify the time period or point in time that the report presents and instead presents whatever is in its database at that time.
If the goal is to pull data specific from a past time period or a past point in time, the interface wouldn’t support such analysis and could pose a risk of material misstatement by using data from the current specific point in time.
Point in Time
If data is only interfaced once per day into a different database for a different report writer, there would be a risk that the data will become outdated if it isn’t refreshed frequently enough for the user’s needs.
When IT does maintenance on systems where the program logic for an interface is stored, the changes introduced could break an interface. Include this as part of your risk assessment for internal control over financial reporting (ICFR).
We’re Here to Help
To understand how risk assessment can support your organization, reach out to your Moss Adams professional.