Orphaned records, invalid foreign keys, and the audit finding nobody wants
Referential integrity violations are the silent rot of enterprise data. An SAP Finance document referencing a company code that no longer exists in T001. A sales order pointing to a customer account marked for deletion in KNA1. A material record linked to a storage location that was removed from the plant configuration two years ago. None of these violations prevent daily operations — until they do, suddenly and painfully, during a period-end close, a regulatory audit, or a system upgrade.
Regulatory pressure is intensifying. SOX compliance in the United States, GDPR in Europe, and IFRS 17 for insurers all require demonstrable data integrity across financial and operational records. External auditors increasingly request evidence that the organization’s SAP data is internally consistent — not just that transactions were posted correctly, but that the underlying configuration and master data referenced by those transactions is still valid. A referential integrity finding on a key financial table can escalate from a management letter comment to a material weakness in a single audit cycle.
“Data integrity failures in ERP systems are among the most frequent findings in IT general controls audits — and among the most difficult to remediate retroactively.”
DVH’s Consistency Checker addresses exactly this risk. Given any SAP table, it resolves the foreign key relationships defined in the ABAP Dictionary (DD05S and DD03L), fetches the distinct values present in each FK field across client 100, and cross-checks every value against the corresponding check table. Records that reference non-existent entries in the parent table are surfaced as INVALID, with the specific field, the invalid value, and the check table clearly identified. Valid records are confirmed as such, giving the compliance team positive evidence rather than silence.
The engine operates without modifying a single byte of production data. It is read-only by design: the OData service on the ABAP side performs SELECT operations only, and the BTP-side Node.js application has no write path. This matters in regulated environments where even read access to production tables requires a formal access control justification — the audit trail of DVH showing a read-only, controlled tool is far easier to justify than an ad-hoc RFC comparison report.
Deutsche Telekom’s SAP Centre of Excellence ran a proactive data quality programme ahead of a group-wide S/4HANA transition, using automated consistency checking across more than 200 customizing and master data tables to identify orphaned entries before they became migration blockers. The programme identified over 14,000 invalid cross-references in logistics and finance master data that would have caused errors during the conversion. DVH’s Consistency Checker replicates this capability for any organization — without requiring a bespoke programme or a specialist data-quality team.
For internal audit teams, DVH provides something the manual approach cannot: a repeatable, schedulable check. Rather than a point-in-time audit exercise conducted once a year, the Consistency Checker can be run on demand before any significant system event — a transport release, a period-end close, a new subsidiary go-live. The results are stored in the run history, creating a longitudinal view of data health that satisfies both internal governance requirements and external auditor inquiries.
Business analysts also benefit directly. Rather than discovering a referential integrity error mid-process — a payment run that aborts because a house bank entry references a deleted bank key, for example — they can proactively identify which records need remediation before the process runs. The difference between a five-minute fix on a Wednesday afternoon and a two-hour recovery at 11pm on a month-end Friday is, in most cases, whether the problem was visible in advance.