The Challenge: Three Company Codes, One Messy Vendor Master
The client was a mid-market discrete manufacturer with approximately $180M in annual revenue. Following two bolt-on acquisitions over 18 months, the business was operating with three separate SAP company codes, each with its own vendor master that had been set up independently by different AP teams using different naming conventions and onboarding workflows.
The AP controller had flagged payment exception rates that were running higher than peer benchmarks but could not pinpoint the source. Standard ERP duplicate checks were blocked by differing vendor IDs across company codes. No one had a clean cross-entity view of who they were actually paying.
The core problems:
- Parallel vendor identities: the same legal entities appeared under different names, IDs, and bank account registrations across the three company codes.
- No cross-entity deduplication logic: SAP's built-in duplicate checks operated within a single company code, not across the merged estate.
- Invoice reference inconsistencies: acquired entities used different invoice numbering conventions, making pattern-based duplicate detection in the ERP unreliable.
- Audit trail gaps: the controller could not trace payment exceptions back to root-cause vendor records without significant manual effort per transaction.
The Approach: Four Steps, No ERP Changes
DataQubi ran the entire engagement as a data overlay, pulling read-only exports from SAP, running all detection and analysis in a governed Microsoft Fabric environment, and delivering findings through a Power BI controller dashboard. The SAP environment was not touched.
Results
Beyond the direct recovery, the controller team gained a reusable detection model that now runs as a scheduled refresh against new AP transactions, turning what was a one-time recovery project into an ongoing payment integrity control.
What Made It Possible Without Touching the ERP
The engagement worked because the detection logic was separated from the ERP entirely. Three factors were decisive:
- ERP-agnostic data extraction: SAP exports (vendor master and AP line items) were sufficient. No API access, no ERP admin involvement beyond a one-time data pull request.
- Fabric as the detection layer: Microsoft Fabric's Lakehouse enabled clean medallion staging of the multi-entity data, with full lineage from source records to flagged payment cases.
- Confidence-scored outputs: rather than flagging everything for review, each duplicate pair and each payment match was scored. Controllers received a prioritized queue, not a spreadsheet dump.
Key insight: Post-acquisition vendor master debt is almost always resolvable without ERP consolidation. The detection can run on exports. The value is in the scoring model and the controller workflow, not in touching the source system.
Key Takeaway for Finance and AP Leaders
If your business has gone through an acquisition in the past three years and your AP teams maintained separate vendor masters, the probability of material duplicate payments is high. Industry benchmarks consistently put duplicate vendor rates at 8–15% in merged estates. The question is not whether duplicates exist; it is whether you have a systematic method to surface them.
The 12-day recovery timeline in this case was achievable because the engagement had a clear scope: top-spend vendors by company code, 24-month payment history, six detection patterns. Broad-scope ERP cleanups take months. Targeted detection on high-value vendor populations takes days.
If your organization has not run a cross-entity AP duplicate scan since your last acquisition, the expected recovery value typically exceeds the cost of the engagement by a meaningful multiple within the first 90 days.