A building-materials maker runs 64 exception checks on its full SAP data
Reviewing purchases, payments, assets and sales by sample left gaps. We moved the company's SAP data into one database and built a library of 64 checks that run on every record.
From our own project and product work. Client names and identifying details are removed, and some figures are rounded.
The situation
A large building-materials maker reviewed its sales, finance, procurement, expense claims and manufacturing data by sample. Checking by hand is slow, and a sample misses what it does not pick. The company wanted every high-risk transaction flagged, across the full data.
How we built it
- Extract. We identified the SAP tables each check needs and extracted 34 of them in full, covering accounting documents, sales, deliveries, purchasing, vendors, materials, change logs and user access, into a PostgreSQL database.
- Prepare. We standardised formats, joined tables on their business keys and logged the row and column counts at every step, so nothing is lost between SAP and the result.
- Write the rules. Each risk became a test: duplicates, date sequences, amount and quantity comparisons, ageing, approvals and master data.
- Move to code. The checks were first built as KNIME workflows. They are now moving to a Python pipeline that runs end to end without manual steps.
- Review. For each rule, we checked sample records against the intended condition and refined it with the business.
Examples from the library
| Area | Examples |
|---|---|
| Finance and invoicing | Breaks in invoice series, duplicate vendor and tax invoices, backdated or missing invoices, bank payments with no vendor or customer reference, vendors with debit balances |
| Procurement | Invoice vendor not the order vendor, three-way match failures, invoices dated before the order, unplanned delivery costs above 5% of the invoice, split requisitions and orders, orders to blocked vendors, prices well above the monthly or six-month average |
| Vendor master | Dormant vendors still open, vendor details that match an employee's, vendor bank accounts abroad, a party booked as both vendor and customer |
| Fixed assets | Negative book values, assets in use with no depreciation, capitalisation and depreciation dates that do not line up |
| SAP configuration | Changed tolerance limits, direct changes in the system, incorrect document and message settings |
| Inventory, production and sales | Yield loss above standard, consumption booked after the goods receipt, returns at the wrong price, ageing open sales orders, employees who have left with debit balances |
What happened
Reviewers now start from a list of transactions that meet a defined exception condition, not from a sample. The checks run again each review cycle and are refined as feedback comes in, and the database is ready for a front end the business can use directly.
| Measure | Result |
|---|---|
| Exception checks in the library | 64, across six business areas |
| SAP tables extracted in full | 34 |
| Records flagged for review | 28.7% of the records the checks covered |
| Manual verification effort | Down 58% |
What changed
- From sample to population. Every record is tested against every rule that applies to it.
- From a tool on one laptop to a pipeline. The same logic runs in code, with a log at every step.
- From one-off tests to a library. 64 checks that can be reused, extended and run again.
Products and services
CompliBear carries a library of 750+ insights like these. See continuous controls monitoring and data and AI engineering.