Controllership Copilot

Context

In companies running a large SAP ERP, controllership lives with a paradox: the whole ERP is already replicated in the data lake, and every closing question still becomes a ticket. The people who know the accounting don’t write SQL; the people who write SQL don’t know the accounting. In between sits a data model with over a thousand tables, four-letter German column names and rules written down nowhere: the sign of an amount lives in another column, a reversal is flagged by a counter-intuitive field, and each document can exist in several versions in the lake.

Challenge

• A data model nobody reads end to end: technical tables and business rules living in a few heads.
• Cost per question: the accounting line-item table holds terabytes and is partitioned by lake arrival, not posting date. One badly written question scans hundreds of gigabytes.
• Errors nobody notices: a wrong closing number doesn’t crash anything, it circulates.
• AI in a critical process: hallucination, a query that writes to the database, prompt injection and, most expensive of all, a plausible answer with no grounding in the accounting rule.
• Audit: who asked, which model answered, with which parameters, why that SQL, and whether the delivered file is the one the system produced.

Solution

A copilot that turns the question into SQL but treats that SQL as a proposal that has to clear controls before it runs. The model receives a context assembled by RAG over the data dictionary, the chart of accounts and the business rules written in plain language. The query goes through a read-only guardrail, a cost estimate before execution and a human review showing the tables, columns and accounts involved. If the estimate rejects it, the agent corrects itself by reading the error, but only before approval: an error after the “go ahead” comes back as a new proposal, never as an automatic re-run. Approved queries become recurring routines exportable to an orchestrator.

Architecture

• 01Ingestion: ERP replicated into the lake through SAP Datasphere, as change data capture, over a private connection with an extraction-only technical user
• 02Layered lake: a raw zone faithful to the ERP, a refined zone by domain and a semantic zone with the dictionary, chart of accounts and rules
• 03Agent: dictionary RAG, deterministic generation with declared reasoning, read-only guardrail, cost estimate and bounded self-correction
• 04Execution with a byte ceiling, timeout, row limit and cost labels per area and user
• 05Delivery: result export, cash panel reconciled against the bank statement and recurring routines in n8n, inactive by default and with no credentials in the file
• 06Observability: logs, metrics and traces correlated by the interaction ID

Governance & security

• Read-only by construction: any write statement is refused before it reaches the database, including in recurring routines
• Cost is a control: mandatory estimate, explicit acceptance above the ceiling and a hard ceiling that acceptance cannot unlock
• The decision stays human: the agent proposes; the approver sees the tables, columns and accounts the query touches
• Hash-chained audit trail: every model call, every SQL with its reasoning, every execution with its cost and every file with its hash
• Identity, not passwords: corporate sign-on, a read-only service account and secrets in a managed vault
• Guardrail regression suite and adversarial tests against prompt injection on every prompt or model change

Current state

• In evaluation
• ERP GRC rules (segregation of duties, roles, approvals) stay in the ERP itself; the copilot only reads
• The demo below uses fictional data and lake names; the SAP tables and fields are the real ones