Computer programming to automate the transfer of data isn’t subject to breakdowns from human failure; interfaces that transfer data will operate the same way until changed. The downside is that if an interface is set up incorrectly it will incorrectly process the data transfer or fail to identify errors in data transfer.
Automating interfaces mitigates internal control risk related to data accuracy and completeness. Testing controls associated with automated interface setup baselines the interface’s ability to process data accurately, completely, and reliably.
Automated data transfers can affect financial reporting risks relating to completeness, such as data loss, inaccuracies, and integrity. Controlling these risks reduces the related risk of misstatement to an acceptably low level.
Manual Method
Manually checking data moving through the interface can help identify if an interface is set up incorrectly and, as a result, processes inaccurate or incomplete data.
A simple yet time consuming process, the manual method requires users of the data to reconcile data from the origination system to the target system at the correct level of precision each time the interface runs, or at least periodically when the data is used in financial reporting. Reconciliation frequency depends on risk assessment factors, such as:
- Volume of data transferred
- Interface complexity
- Requirements for timeliness of the data
- Frequency of interface runs
Often when using the manual method, specific transaction-level records and specific record fields should be reconciled on a test basis to verify detailed data is transferring accurately.
Automated Method
Automating internal controls via interfaces includes considering two implementation components:
- Controls over the setup
- Controls over the interface’s ongoing effectiveness
Both are necessary and complement each other but cannot operate independently.
These control activities combine information technology general controls and certain business process automated controls.
Controls Over the Setup
The interface setup must address the business’s financial reporting needs. It’s important to test the setup to evaluate if this objective is being met.
The financial reporting needs also define what data to move and how often. Setup controls must verify the interface’s ability to move data accurately and completely. In addition, setup controls must include error handling to detect errors in automated data transfer.
This is typically done by moving test data through the interface and comparing the expected results to actual results. At a minimum, data fields relevant to financial reporting should be tested.
The extent and precision of testing is dependent on the risk associated with the data transfer.
Case Study
ABC Company uses a billing system separate from its enterprise resource planning program (ERP). General ledger balances are updated via an interface of the customer-level balances. Accounts receivable analyses supporting the allowance for doubtful accounts are dependent on customer-level reports run from the ERP. Transactional detail as well as invoice level details are maintained only in the billing system.
Analysis
This example highlights the need to determine the right level of testing precision. Given the allowance for doubtful accounts is dependent on customer-level reports, testing that the total balances move from the billing system to the ERP only addresses data transfer completeness, not its accuracy. Determining if the interface setup results in accurate information at the correct level of precision is dependent on the customer-level reconciliation.
Other Setup Tests
Interfaces may include automated data validations, such as checking that only data approved through a workflow runs through the interface. If validations are part of the interface setup, those validations can be checked by feeding intentional errors into the interface to see if the validations catch them.
For example, using the information above, a reasonable set up test would be initiating a transaction not authorized through the workflow to test if the interface rejects it.
There are many types of validations. Another common one is to compare hash totals from an origination system to a target system. A mismatch (i.e., unreconciling comparison) may indicate that data is incomplete or inaccurate.
If validation programming exists, it’s important to validate the programming works as intended.
Controls Over Ongoing Interface Effectiveness
After verifying the interface reliably works as intended, the principle stands that automated controls, or program logic, isn’t subject to breakdown, as long as the program logic remains unchanged. A suite of IT general controls designed, implemented, and operating as intended can prevent unauthorized access and changes to the program logic.
Benchmarking is an audit theory allowing auditors to establish a baseline understanding that an interface transfers data accurately and completely.
Combined with evidence that the program logic is unchanged and IT general controls remain effective, auditors can conclude the interface still operates effectively. Benchmarking can be used to evaluate internal controls and determine a recertification cadence for interface controls.
Identifying Program Logic
Interface programs are often complex and can be dependent on files, tables, data, parameters, or secondary programs. It’s important to work with the individuals responsible for creating the interface’s program logic to identify all dependencies.
Case Study
ABC Company is aggressively growing through acquisition, adding new companies to the existing ERP. The company uses a consolidation tool which interfaces with the ERP. This interface obtains data from the ERP and imports it to the consolidation tool. The program must identify each trial balance to know what to import.
To use benchmarking, the company decides to stop manually identifying new trial balances. Identifying which trial balances should be imported is programmed in a separate program based on characteristics associated with each trial balance in the ERP. For example, after it acquired a subsidiary in the UK, ABC created a UK Statutory GAAP and a US GAAP trial balance. The automated program selects the US GAAP trial balance for import by the import program.
Analysis
This case study involves two programs—the primary program that interfaces the ERP to the consolidation tool, and the secondary program that checks for new trial balances.
Only identifying the interface logic as the relevant program logic misses the separate program that ensures the trial balances subject to import are complete. Imports of existing trial balances could be individually accurate and complete but failure to include a new company would lead to an incomplete consolidation.
If the secondary program fails to operate as designed due to an unauthorized change or a change that failed to process data accurately, the primary program can also fail due to that dependency.
Case Study
ABC Company interfaces prices from a price negotiation application to the price table in its ERP. Because the pricing software is made by a different developer than the ERP, a custom interface must be programmed.
At the time the interface is created, the pricing software required both ABC Company and its customer to click approve on the negotiated price. The custom price import program has a logic code instructing for the Agreed Price field to be imported from the pricing software.
The pricing software’s developer subsequently enhanced its software to build a workflow preventing prices from falling below certain price floors set in the pricing software without a secondary approval. In doing so, the vendor created a new field called Approved Price.
ABC added the price approval workflow control to its internal control over financial reporting.
Analysis
In this case study, there’s only one program, however, that program is dependent on a table with pricing information.
Historically Agreed Price was the correct field to import. Now Approved Price is the correct field. While the program logic for the interface was unchanged, the underlying table changed enough to cause unauthorized and potentially inaccurate data to be imported to the ERP.
This change to the underlying table can cause unreliable information to feed through the interface.
Identification of Program Logic
The two previous case studies illustrate why identifying the program logic for the interface is difficult. It’s important to have well documented program logic that identifies all dependencies so baseline conclusions can be rolled-forward from a prior testing date.
Why You Need Effective IT General Controls
The interface’s continued operating effectiveness relies on the program logic and its dependencies remaining unchanged and effective. It’s highly unlikely that controls can completely reduce risk to zero.
Internal controls can help reduce risks to acceptably low levels by bringing control mechanisms to the following business areas.
Change Management
Change management controls in your organization’s environment can help verify:
- Programs accurately process data (how data is processed)
- Programs process accurate data (which data is processed)
- Changes to programs are authorized
- Necessary changes are implemented correctly
Change management can help ensure that interfaces continue to work as the organization makes changes to its IT environment.
User Security and Access
User security and access controls can help mitigate risk by improving protocols that:
- Restrict unauthorized access that can result in destruction or improper data changes, including recording unauthorized or nonexistent transactions or inaccurate recording of transactions
- Prevent personnel from gaining access privileges beyond those necessary to perform their assigned duties, thereby breaking down segregation of duties
- Prevent inappropriate manual intervention or manipulation of data
Data interfaces can send data to an intermediary system. This can be as simple as the origination system exporting data into a file on a server that the target system can import. Protecting data when it’s in the intermediary system is important.
A programmed interface can’t ensure continued data accuracy and completeness once that data is imported to the target system. Having appropriate access restrictions to data in the target system is equally important to prevent or detect unauthorized changes after the import.
Operations
Operations controls in your organization can help address:
- Data accessibility
- Data recoverability
Controls ensuring data remains accessible to interface programs allows data to be accurate and complete in the target systems.
For example, if a program relies on a service account to execute, and that service account has an automatically entered password that executes the interface program, changing the password requirements may prevent the interface and program from executing.
Systems with multiple data sources can have these breakdowns obscured. Controls monitoring program execution successes and failures are particularly important for automated programs.
Increased automation is also increasing cybersecurity threats. For example, ransomware attacks can prevent data from moving from system-to-system automatically and lock up an intermediary system preventing an interface from completing. It’s important to be able to access prior data in case you need to rebuild and reprocess information.
Additional Key Control Points to Include
Interfaces can be designed to alert users of unprocessed data that requires manual intervention, putting them in suspense or exception files. In these cases, it’s important to design, implement, and maintain effective manual controls addressing the continued accuracy and completeness of the data transfers.
Include controls that:
- Monitor the suspense files
- Facilitate timely resolution of exceptions or suspended items
- Authorize data adjustments to clear the exceptions
Be aware of how often an interface runs. Changes to accounting processes can result in reliance on data that is stale or no longer accurate or complete.
For example, an interface supporting consolidation only runs the first 10 days of the month because the close process is scheduled for 10 days. If the close schedule changes to a span of 15 days with consolidation work occurring in the final five days, the interface will need to be adjusted to run an additional five days.
Understanding the interface’s design as it relates to business processes is an important element of monitoring your internal controls over financial reporting.
We’re Here to Help
To learn how implementing or improving the internal controls can benefit your organization, contact your Moss Adams professional.
Additional Resources