Data Quality for Financial Reporting: What SOX Auditors Actually Check

The CFO signed off. The audit committee reviewed the numbers. The external auditors spent three weeks on-site and issued a clean opinion.

Six months later, a material weakness surfaced. Not because of fraud. Not because anyone fabricated numbers. Because the data feeding the financial statements had quality issues that none of the existing controls were designed to catch.

This happens more often than most finance teams expect, and for a specific reason: SOX compliance programs are built around process controls. Who approved this journal entry? Was the reconciliation reviewed before close? Did the right person sign off on the balance sheet?

These controls catch a lot of problems.

What they do not catch is data quality failures at the source. A GL account mapped to the wrong cost center. Duplicate transactions that passed the approval workflow because each one individually looked correct. A currency conversion that used the wrong exchange rate. These are not control failures in the traditional sense. They are data failures that sit underneath the controls, invisible to the people running the process.

SOX auditors are catching up to this. Modern financial audits increasingly include data analytics procedures that look directly at the data, not just the controls around it. When those procedures find something, it becomes a finding.

This guide covers what SOX auditors actually check at the data level, the five data quality issues that most commonly generate audit findings, and how finance and data teams can build a continuous financial data quality framework that keeps them ahead of audit season year-round.

What SOX Actually Requires from a Data Quality Perspective

SOX Section 404 requires public companies to establish and maintain adequate internal controls over financial reporting, with annual assessments by both management and external auditors. The law itself does not define data quality. But the PCAOB auditing standards and SEC guidance that govern SOX implementation make data quality implicit throughout the entire audit framework.

COSO and the Information Quality Standard

Most SOX compliance programs are built on the COSO Internal Control framework. COSO's Information and Communication component explicitly requires organizations to use relevant, quality information from both internal and external sources to support the functioning of internal controls. Quality information is defined across seven dimensions: accessible, correct, complete, current, protected, retained, and valid.

This matters because a well-designed approval workflow that runs on bad data is a control that cannot function effectively. When auditors assess whether controls are designed effectively, they are also assessing whether the information those controls rely on meets the COSO quality standard. Poor financial data quality is not just an operational problem. It is a control design problem that can result in a material weakness finding.

IT General Controls and Financial Data Integrity

SOX audits include an assessment of IT General Controls (ITGCs), which cover the IT environment that hosts and processes financial data. ITGCs address change management, access controls, computer operations, and data backup and recovery. ITGC deficiencies are among the most common SOX compliance findings, and they almost always carry a direct data quality implication.

If change management controls are weak, the financial reporting system can be modified without proper oversight. If access controls are inadequate, unauthorized users can alter the data that feeds the financial statements. The connection between IT General Controls and financial data integrity is direct, and external auditors test it every year.

Data Analytics as Audit Evidence

PCAOB standards allow auditors to use data analytics as formal audit evidence. In practice, this means external auditors now routinely extract full populations of journal entries, GL transactions, and sub-ledger data to run automated testing against them. They are looking for journal entries posted by unusual users, round-number entries that may indicate estimates or manipulation, entries posted outside normal business hours, transactions that bypass the normal approval workflow, duplicate transactions, and large entries concentrated in the final days of a reporting period.

If auditors find these issues in your data, they become findings. If you find them first and have documented remediation, they become evidence of effective controls. The difference is entirely in whether your team looked before the auditors did.

The 5 Data Quality Issues SOX Auditors Most Commonly Flag

1. Duplicate Journal Entries

Duplicate journal entries are one of the first issues audit data analytics identifies. A duplicate can represent an honest mistake (a batch that ran twice), a system integration issue (the same transaction posted by two different systems), or in rare cases an intentional manipulation.

Auditors flag duplicates regardless of cause. A duplicate entry means the financial statements include a transaction that should not be there. Even a benign duplicate that was later reversed is a control finding if the control environment did not catch it before the financial statements were issued.

Common sources include ERP integrations that do not use idempotency keys, manual journal entry uploads from spreadsheets where the same file was submitted twice, and period-end accrual entries posted by both an automated process and a manual process. Financial data integrity starts with ensuring every transaction appears exactly once.

2. Entries Posted Outside Segregation of Duties

SOX requires that the person who initiates a transaction cannot also be the person who approves and records it. This is segregation of duties (SoD). At the data layer, SoD failures appear as journal entries posted by users who should not have had posting access, entries that were self-approved, or entries that bypassed the normal workflow entirely.

Data analytics makes SoD violations much easier to find than they were in a purely manual audit environment. Auditors can identify every entry in a period where the preparer and approver are the same person, or where the posting user holds a conflicting role. These are direct SOX compliance findings and among the most commonly cited data quality issues in financial reporting.

3. Period-End Concentration of Large Entries

A normal business generates transactions throughout a reporting period. A disproportionate concentration of large journal entries in the final days of the period (last day of the quarter, day before close) is a statistical anomaly that auditors investigate.

Sometimes the explanation is legitimate: large accruals, depreciation runs, and intercompany eliminations are often posted at period-end. But when auditors see large, round-number entries with thin supporting documentation posted late on the last day of the quarter, it raises questions about whether revenue recognition or expense timing is being managed. Period-end data quality checks are a standard component of financial close process best practices.

4. Unusual Posting Users

Journal entries should be posted by finance users, not IT administrators, terminated employees, or service accounts. When data analytics identifies entries posted by user accounts that should not have journal entry access, it is an immediate finding regardless of whether the entry itself is correct.

This is primarily an access control issue, but it surfaces through data quality analysis. The finding is that the control environment allowed an unauthorized user to post to the GL, and the evidence is in the data. It is one of the clearest examples of how IT General Controls and financial data integrity are connected.

5. Incomplete or Stale Account Reconciliations

SOX requires that balance sheet accounts be reconciled regularly, that reconciliations be reviewed and approved, and that reconciling items be cleared within a defined timeframe. Account reconciliation best practices call for monthly reconciliation of all significant balance sheet accounts, with documented review before each close.

Data quality issues in this area include reconciliations that were prepared but never approved, reconciling items that have been open for 90, 180, or 360 days with no resolution, accounts that were not reconciled for one or more periods, and reconciliations where the balance on the form does not match the GL balance on the same date. All of these are identifiable through data analysis, and all of them are findings.

Journal Entry and GL Data Validation: What to Check and Why

The journal entry population is the most scrutinized dataset in a SOX audit. Auditors extract it in full and run pattern analysis across the entire period. Finance and data teams that run the same analysis before auditors arrive are in a fundamentally better position to manage findings.

Duplicate Entry Detection

The first check is for duplicate journal entries: transactions that share the same amount, account, date, and description and were posted within a short window of each other. The goal is to identify entries that appear more than once in the GL when they should appear only once.

Duplicates are flagged regardless of cause. The question auditors ask is not whether the duplication was intentional, but whether the control environment was designed to catch it. A strong financial data quality program detects duplicates as they are posted, not at period-end.

Round-Number Entry Review

Entries with amounts that are exactly divisible by large round numbers warrant scrutiny above a materiality threshold. Round-number entries are not inherently wrong. Standard depreciation, rent accruals, and subscription expenses are often round numbers. The check is whether each one has adequate supporting documentation.

What auditors look for is the combination: a large, round-number entry, posted late in the period, with minimal description. That combination is a pattern associated with estimates that may not have adequate support, or with amounts that were sized to achieve a particular financial result rather than to reflect an underlying transaction.

Period-End Concentration Analysis

A healthy distribution of journal entry activity should be relatively consistent across the days of a reporting period. When a disproportionate share of manual journal entry volume or dollar amount is concentrated in the last three to five days of the period, auditors investigate the specific entries.

Period-end concentration analysis compares the percentage of entries and total amounts posted each day against the period average. If the final days of the period account for more than 40 to 50 percent of manual journal entry volume or amount, the specific entries behind that concentration need to be reviewed and supported.

Posting User Anomaly Review

Every journal entry in the GL should be traceable to a finance user with appropriate posting access. Entries posted by IT administrators, terminated employees, or service accounts that were not intended to have GL posting access are immediate findings.

The posting user review cross-references the journal entry population against the user access list. Terminated employees who still appear in the GL as posting users are an access control failure. IT administrators who posted manual journal entries are a segregation of duties concern. Both findings require investigation and remediation of the access control environment.

Self-Approval Detection

SoD requires that the person who prepares a journal entry and the person who approves it are different individuals. When a single user appears as both preparer and approver on the same entry, that is a direct SoD violation.

Self-approval detection is one of the highest-value data quality checks in financial reporting because it goes directly to the control design question auditors are asking. A clean SoD analysis covering the full period provides strong evidence that the control environment is functioning as designed.

Account Reconciliation Data Quality: What Auditors Actually Test

Account reconciliations are a core SOX control. They verify that the balance in the GL matches the supporting detail (sub-ledger, bank statement, vendor statement) and that any differences are explained and tracked to resolution. Account reconciliation best practices are well-established, but the data quality around the reconciliation process is where many organizations fall short.

Reconciliation Coverage

The first question auditors ask is simple: were all required accounts actually reconciled for the period? A balance sheet account that is flagged as requiring reconciliation but has no reconciliation record for the period is an immediate control gap.

This is a data completeness issue. The reconciliation program defines which accounts are in scope. The data quality check confirms that every in-scope account has a reconciliation record for each period, before the audit team identifies the gap for you. Missing reconciliations for even one significant account can generate a finding.

Approval Status at Close

A reconciliation that was prepared but never formally approved before the period closed is not a completed reconciliation for SOX purposes. The approval step is part of the control. A reconciliation sitting in "prepared" status at the time the financial statements are issued means the control did not function.

Approval status tracking is a key component of financial close data quality. The goal is to confirm that every reconciliation for the period was both prepared and approved before close, with the approval documented by the right person.

Stale Reconciling Items

Reconciling items represent differences between the GL and the supporting detail that have not yet been resolved. Some differences are expected and short-lived. But reconciling items that remain open for 90, 180, or 360 days with no resolution notes are a significant audit concern.

Most SOX programs define a maximum age for open reconciling items, typically 90 days for significant amounts. Items exceeding that threshold need to be escalated and resolved. A large reconciling item open for three quarters with no documented resolution path is exactly the kind of item that generates a finding. Stale reconciling items are one of the most common account reconciliation issues in SOX compliance programs.

GL Balance vs. Reconciliation Balance

The reconciliation form captures the GL balance at the reconciliation date and reconciles it to the supporting detail. If the GL balance recorded on the reconciliation form does not match the actual GL balance on that date, the reconciliation was prepared against the wrong number.

This mismatch means the reconciliation, however carefully prepared, is not actually reconciling the balance that appears in the financial statements. Auditors test for this by comparing the balance on the reconciliation form against the GL extract for the same account and period. A mismatch is one of the most significant financial data integrity issues in the reconciliation process and is tested routinely in modern SOX audits.

Access Controls and Segregation of Duties in the Data Layer

SOX access control testing is typically framed around the ERP: can this user approve a journal entry they also prepared, can an AP clerk release a payment, can a system administrator modify transaction data without leaving an audit trail? These are the right questions. But there is an additional layer that often goes unchecked: access to the data layer underneath the ERP.

Direct Data Access as a SOX Risk

In most organizations, the financial data that feeds reporting lives in a database or data warehouse that sits behind the ERP. If a user has direct access to that database with write permissions, they can potentially modify financial data in ways that bypass every ERP control.

Auditors increasingly test for this. The question is not just whether the ERP has proper access controls, but whether the underlying data store does too. Users who can directly modify the financial tables that feed the general ledger or financial reporting system need to be specifically identified, and their access needs to be justified and documented. Any user with direct write access to financial data tables who is not an approved service account is a potential SOX finding.

Privileged Access to ERP Configuration

Beyond data access, auditors test whether users with ERP configuration access (the ability to change account mappings, approval thresholds, or reporting rules) are separated from the users who process transactions. This is the configuration-level SoD test.

For data and finance teams that use a data warehouse, the equivalent question is whether users who can modify ETL pipelines or data transformation logic are separated from users who can approve the financial reports those pipelines feed. If the same person can change how revenue is calculated in the data warehouse and also approve the revenue report, that is a data-layer SoD gap. It may not show up in the ERP access review, but it will show up in a modern SOX IT controls assessment.

Audit Trail Completeness

SOX requires that changes to financial data be traceable. For ERP transactions, this is typically handled by the ERP's built-in audit log. For data warehouse transformations and downstream financial reporting tables, it often is not.

If financial data in a downstream system can be modified without leaving a trace in an audit log, that is a control gap regardless of whether the modifications were authorized. Auditors test for the existence and completeness of audit trails on financial data tables as part of ITGC assessments. Organizations that have not implemented change logging on their financial data warehouse tables are exposed to this finding.

Building or verifying the audit trail for financial data should be part of any financial data quality and SOX readiness program. The audit trail is both a control in itself and evidence that the controls around data access are functioning as designed.

How to Build a Continuous Data Quality Framework for Financial Reporting

Running validation checks once before an audit is better than not running them at all. Running them continuously throughout the year is what transforms data quality from an audit response into a control. The difference between being audit-ready and being perpetually at risk is whether your financial data quality monitoring runs on a schedule or runs in a panic.

Tier 1: Real-Time Transaction Checks

Some data quality issues need to be caught at the moment a transaction is created, not after the period closes. Real-time checks are the first tier of a continuous financial data quality framework.

They include:

Duplicate detection that flags any journal entry matching an existing entry on amount, account, date, and description before the transaction is finalized. Self-approval prevention that rejects or flags any entry where the preparer and approver are the same user. Unauthorized posting user alerts that surface immediately when a journal entry is posted by a user outside the finance department or by a terminated employee.

These checks can be implemented as ERP workflow rules or automated controls at the transaction level. The goal is to prevent bad data from entering the GL rather than finding it after it already has.

Tier 2: Nightly Close Monitoring

Some financial data quality issues accumulate over the course of the period and need to be caught before they compound. Nightly monitoring is the second tier. It covers accounts with large movements that have no corresponding reconciliation update, access control anomalies such as new users granted financial data access outside the normal provisioning process, data pipeline issues that may have left financial reporting tables incomplete or stale, and round-number entries posted after business hours.

Nightly monitoring is the difference between finding a problem on day two and finding it on day thirty. By the time a nightly check surfaces a stale reconciliation or an access anomaly, there is still time to resolve it before the financial close process begins in earnest.

Tier 3: Period-End Validation Suite

The pre-close validation suite runs before the CFO certifies the financial statements. This is where the full set of financial data integrity checks applies: complete reconciliation coverage and approval status, period-end concentration analysis, stale reconciling item report, full SoD conflict analysis, and GL balance versus sub-ledger balance comparison.

The period-end suite is not a last-minute scramble. It is a systematic confirmation that everything the continuous monitoring caught has been resolved, and that the financial statements the CFO is about to certify reflect data that has been validated against each of these dimensions.

Documenting Results as SOX Control Evidence

The difference between data quality checks and SOX controls is documentation. Checks you run but do not document are process improvements. Checks you run, document, and use as the basis for remediation actions are control evidence.

For every check in your validation framework, record what was checked, when it ran, and who reviewed the results. For any items found, document the investigation and resolution. Retain the documentation in your SOX evidence repository with the same retention schedule as other control evidence.

When auditors ask how you know there are no duplicate journal entries, the answer should be "we run this check every period-end, here are the results for the last four quarters, and here is what we found and resolved." That answer, backed by documentation, is what transforms a data quality program into a SOX control.

Integration with the Financial Data Pipeline

For teams with a data warehouse or financial data pipeline, these checks should be automated as part of the pipeline rather than run manually before close. Scheduled monitoring that runs the validation suite and alerts on failures is more reliable than a spreadsheet someone has to remember to open.

The goal is continuous financial data quality monitoring where findings are surfaced and resolved before the period closes, and the documentation of that monitoring is available as SOX audit evidence without additional effort at audit time. That is the standard that separates organizations that breeze through audits from organizations that spend the two weeks before the auditors arrive fixing things.

Stop Finding Audit Issues During the Audit

SOX findings are expensive. Remediating a material weakness costs time, resources, and credibility with investors and the audit committee. The findings that make it into an audit report are almost always findable before the auditors arrive, using the same data analytics and financial data integrity checks that auditors run.

The five issues covered in this guide (duplicate journal entries, SoD violations, period-end concentration, reconciliation completeness, and unauthorized access) appear on audit findings lists year after year, across every industry. They are not edge cases. They are the standard audit data analytics playbook, and they surface something in almost every organization that has not proactively monitored for them.

The finance and data teams that do not get these findings are not the ones with perfect data. They are the ones who run financial data quality checks routinely, fix what they find, and document that they did. That documentation is what turns a data quality program into a SOX control.

If your team wants to automate the data quality validation layer for your financial reporting pipeline, Vexdata runs continuous checks on your financial data and surfaces integrity issues before the period closes. See how finance teams are using it at the data quality financial reporting page.