This dataset comes from a real multinational company (anonymized for BPI Challenge 2019). The process mining community uses it as a benchmark for purchase-to-pay analysis. Our forensic engine processed the full 1.6M event log and surfaced several structural concerns:

Payment blocks (22.7%) — Nearly 1 in 4 purchase orders hit a payment block requiring human intervention. This signals systematic issues in invoice matching or vendor master data quality. In a healthy P2P process, payment block rates should be under 5%.

Process variability — With the top 2 variants covering only 32% of cases, the remaining 68% follow hundreds of different paths. This "spaghetti process" pattern makes it difficult to automate, audit, or optimize. Industry benchmarks target 80%+ coverage in the top 5 variants.

Resource concentration — user_002 processes 10.4% of all events. If this person is unavailable (vacation, resignation), the bottleneck could cascade across the entire P2P process. This is a classic single-point-of-failure that process mining can identify but traditional audits miss.

SAP IDES is not production data — it's SAP's official demo and training environment. Thousands of consultants learn SAP using this system. Yet our automated conformance checker found 7 compliance violations that exist in the reference data itself.

This demonstrates two things: (1) Automated process mining catches what manual review misses, even in well-known systems. (2) If reference data contains these patterns, production systems — with real users under real deadline pressure — almost certainly contain more.

The conformance checking engine uses token-based replay (van der Aalst algorithm) to compare actual event sequences against expected process models. For P2P, the expected model requires: PR → PO → Goods Receipt → Invoice → Payment. Any deviation is flagged, measured, and classified by severity.

The O2C analysis reveals a different problem: 158 process variants from just 8 activities. This is a "spaghetti process" — technically functional but impossible to audit or optimize at scale. Combined with the 6,578-day max duration (stale orders from the 1990s still open), it paints a picture of a system that works but accumulates technical debt in its process layer.

Conformance Engine: Token-based replay, ProcessModelBuilder, van der Aalst algorithms
Data Adapters: BPI (XES/OCEL), SAP IDES (sap-extractor, MIT), Synthetic (seed=42)
Pattern Engine: Python 3.11, scikit-learn, scipy (TF-IDF + K-Means + effect sizing)
Temporal Analysis: Throughput time, bottleneck detection, delay probability
Tests: 834 passing (602 TypeScript + 232 Python)
Source: github.com/chrbailey/SAP-Transaction-Forensics

Case 1 (license audit): Structured user data hides $103K in waste — login timestamps and role assignments alone told the story. Case 2 (acquisition tickets): When structured data looks normal, 2,525 help desk tickets reveal an organization under stress — workarounds, data trust issues, and IT drowning in access requests. Case 3 (high-growth ERP): 3 million rows of clean-looking transaction data mask credit hold overrides, a 28.6% return rate, SOD violations in a rapidly scaling company, and approval chains so dysfunctional that a "reroute approver" field was built into the system. In every case, the structured data said "operational." The unstructured layer — tickets, audit findings, override fields, memo text — told the real story.