Application and Data Integrity Controls
General controls protect the environment. The business logic that decides whether a payment is valid, a rate is applied correctly or a total actually adds up lives inside the applications. Application controls are where automated processing either enforces the rules or quietly does not, and they are tested far less often than the infrastructure around them.
1
Scope
Which controls carry risk
2
Walkthrough
How processing works
3
Test
Input, process, output
4
Interfaces
Completeness between systems
5
Report
Findings and remediation
How We Test
01
Control Identification and Scoping
We identify the automated controls each significant process actually relies on. That means distinguishing genuine application controls from manual checks that happen to use a screen, because only the former can be tested once and relied on repeatedly.
- Automated controls mapped per financial process
- Distinction between automated and manual controls
- Reliance placed on system generated reports
- Scope agreed with management and external audit
02
Input Controls
Most data integrity problems begin at capture. We test whether the application prevents invalid entry rather than relying on the person entering it, using both valid and deliberately invalid test data.
- Validation, format and range checks
- Mandatory field enforcement
- Duplicate detection on payments and invoices
- Authorisation limits enforced at capture
03
Processing Controls
We verify that calculations, allocations and postings produce the result the business rules require. Rounding, effective dating and retrospective changes are common sources of error that only surface in aggregate.
- Calculation accuracy against documented rules
- Rounding and tolerance handling
- Effective dating and back dated transaction treatment
- Automated posting and allocation logic
04
Interface Completeness and Accuracy
Where data moves between systems, records get lost quietly. We test whether what left one system is what arrived in the next, and whether anybody would know if it were not.
- Record counts and control totals across interfaces
- Error and rejection handling on failed records
- Reprocessing controls and duplicate prevention
- Reconciliation between source and destination
05
Output and Master Data Controls
A report is a control only if it is reliable. We verify system generated reports against underlying data, and test the standing data that drives automated processing, because a wrong banking detail or tax rate scales instantly.
- System generated report reliability testing
- Completeness and accuracy of extracted data
- Master and standing data change controls
- Segregation between master data and transaction capture
What You Receive
- Inventory of automated controls per financial process
- Test results with evidence for each control tested
- Interface completeness and accuracy findings
- Assessment of system generated report reliability
- Master data control findings
- Remediation plan with owners and due dates
Indicative Timeline
Application control testing usually runs two to four weeks per major application. Availability of a test environment is the largest single variable, because testing invalid data against production is rarely acceptable.
- Scoping and control identification: three to five days
- Walkthroughs with process owners: one week
- Testing, including negative testing: one to two weeks
- Reporting and management comment: one week
What We Test
Application control testing covers the full path a transaction takes, not only the screen it is captured on.
Input Validation
Whether the application refuses invalid data rather than depending on the diligence of whoever is capturing it.
Calculation Logic
Whether automated calculations match the documented business rule, including rounding and tolerance behaviour.
Authorisation
Whether approval limits and segregation of duties are enforced by the system or merely written in a policy.
Interfaces
Whether records transferred between systems arrive complete, and whether failures are visible to anyone.
Report Reliability
Whether reports relied on for decisions and for audit evidence agree to the underlying data.
Master Data
Whether changes to banking details, rates and standing data are controlled, logged and independently reviewed.
Frequently Asked Questions
Can you test without disrupting our production system?
We test in a test or training environment wherever one exists, particularly for negative testing where invalid data is deliberately submitted. Where no such environment exists, testing is restricted to read only inspection and we say so in the report.
Why test application controls if the ITGC are clean?
Because they answer different questions. Clean general controls mean the environment is sound and the application has not been tampered with. They say nothing about whether the calculation inside it is correct.
What is a system generated report and why does it matter?
Any report the application produces that somebody relies on for a decision or that auditors use as evidence. If the report logic is wrong or the parameters are not controlled, every conclusion drawn from it is unreliable, including audit conclusions.
Do you test our custom developed systems too?
Yes. Custom systems usually warrant more attention than packaged ones because the logic is unique to you and has not been tested by thousands of other customers.
How does master data fit in?
Master data drives automated processing. A wrong VAT rate, a changed supplier bank account or an incorrect pay rate applies itself to every subsequent transaction, which is why change control over standing data is tested separately from transactions.
Will this satisfy our external auditors?
It supports their work but does not replace it. Where they intend to place reliance on automated controls, they will perform or review testing themselves. Our testing usually reduces what they find and therefore the time they spend.
Related Services
This sits inside our ICT Audit practice. Related work: IT General Controls Reviews, which application control reliance depends on, and Automated Reporting and Analytics where report reliability needs building rather than testing.
