The SOX Control Gap Hiding in Your System-to-System Interfaces

Every SOX walkthrough eventually lands on IT general controls, and every ITGC test eventually sorts into the same three buckets: access, change management, and operations. Auditors sample who can log into the ERP, who approved the last production deployment, and whether backups and job scheduling ran the way the control narrative says they do. All of that is real risk, and it earns the attention it gets. None of it checks whether the data that moved from your CRM into your general ledger last Tuesday was actually correct.

What ITGC Testing Actually Looks At

A typical ITGC walkthrough samples a handful of changes from the quarter, traces each one back to an approval ticket, and confirms segregation of duties between whoever requested the change and whoever moved it to production. For access, auditors pull a user list, check it against an org chart, and look for anyone with rights they shouldn't have. For system-generated reports, the control usually asks whether the report's logic was reviewed when it was built and whether someone reconciles its output periodically. PCAOB AS 2201 treats controls over the completeness and accuracy of system-generated data as something that has to be tested, but in practice that test is almost always a test of the control around the interface, not a test of whether the interface is still moving the right data today.

The Assumption Baked Into Every Reconciliation Control

Once an interface reconciliation control is walked through and marked effective, it typically gets retested once a quarter or once a year. Between those windows, the control is assumed to keep working the way it did on the day it was tested. That assumption holds for the things ITGC testing is built to catch: unauthorized access, unapproved changes, a scheduler that silently stopped running a job. It does not hold for a source system quietly repurposing a field, renaming a status code, or changing what a date column means. None of those events touch access or change management. The interface keeps running, the reconciliation total keeps tying out at the level someone is checking, and the control stays marked effective on paper while the data underneath it drifts.

Where the Gap Actually Shows Up

Payroll-to-GL interfaces are a common place to find it. Workday gets reorganized, a cost center or department field gets repurposed for a new business unit, and the mapping table feeding the general ledger was never updated to match. Labor costs keep posting, the interface keeps reporting success, and the dollar totals can even keep tying out at the consolidated level for months while individual cost centers are quietly misclassified. Revenue recognition interfaces have the same shape. A CRM field like close date or deal stage gets relabeled or repurposed by the sales ops team, and the ERP's recognition engine keeps reading it, just not the way anyone intended. The deals still flow through. They just land in the wrong period, and nobody looks until a close process turns up a variance that doesn't have an obvious source.

Three Places This Tends to Hide

• Payroll-to-GL interfaces, where a cost center, department, or job code field gets repurposed upstream and the downstream mapping table is never told.
• Revenue recognition interfaces, where a CRM field tied to deal stage or close date changes meaning and the recognition engine keeps applying old assumptions to new data.
• Intercompany elimination interfaces, where a renamed entity or legal-entity code causes an elimination entry to miss a subsidiary, while the consolidated total still ties out because the error nets out elsewhere.

Why the Audit Doesn't Catch It Either

This isn't a story about lazy audit work. Auditors are testing what the control framework asks them to test, and ITGC frameworks were built around access, change, and operations because those are the failure modes that caused the scandals the framework was written to prevent. Semantic drift inside an interface, where the pipe keeps running and the numbers keep tying out but the meaning underneath has shifted, doesn't fit cleanly into any of the three buckets. It isn't an access issue. Nobody made an unapproved change to the integration itself. The job scheduler never missed a run. An auditor sampling a handful of interface executions per quarter and confirming the reconciliation was performed has no mechanism for catching a drift that started between two sample dates and never produced a reconciling difference large enough to flag.

The size of the sample makes this worse, not better. A controls team reviewing four interface runs out of the roughly ninety that happened in a quarter is testing that the control operated as designed on four days. It says nothing about the other eighty-six. A drift that starts on day twelve and runs quietly through day seventy will sail through a Q3 walkthrough that happens to land on days 3, 40, 65, and 88, because none of those four days individually produces a reconciling break large enough for anyone reviewing a variance report to stop and ask why.

What an Actual Interface Control Would Need

Closing this gap takes something that runs continuously, independent of whether the interface itself reports success, and watches whether the meaning of the data crossing the boundary is still what the mapping assumed. It has to produce a log an auditor can actually sample against, not just a reconciliation total, but a record of what was watched, what drifted, and when it was caught. That's a different kind of evidence than most controls teams are set up to produce, because most monitoring in this space is built to answer whether the job ran, not whether the data still means what everyone assumes it means.

mmune sits above the interfaces that feed your general ledger, payroll system, and consolidation process as a read-only overlay, watching for the kind of semantic drift that reconciliation controls are not built to detect and logging it to an audit trail your controls team can actually show an auditor. Find your blind spots before they show up in a close-process variance instead of a control test.