When reporting is late every month, the cause is rarely the reporting itself. The real problem sits one layer below — in the data. Numbers live in DATEV, in the bank account, in spreadsheets and in operational systems; each source speaks its own language, and none talks to the others on its own. Building a monthly report from this means copying, sorting and reconciling — by hand, month after month. A nicer dashboard does not fix that. What fixes it is the invisible layer beneath: how data flows from the source systems into one consistent basis.
Why manual reporting eventually breaks
At first the copy-and-paste approach works. One company, one account, a handful of reports — one person holds that together in a single workbook. But with every additional company, account and new report, the effort grows disproportionately. Three symptoms then return reliably:
- Lateness. The report is only ready once the month is long over — and decisions have already been made.
- Inconsistency. Two reports show different figures because they were assembled from different versions.
- Dependency. Only one person knows how the file fits together. If they are out, reporting stops.
These symptoms are not a question of diligence. They are the natural consequence of merging data by hand instead of through a system.
The data sources that have to come together
Robust reporting starts with connecting the relevant sources cleanly. In mid-sized companies these are usually three:
- Financial accounting. DATEV or a comparable system provides income, expenses, accounts and balances — the bookkeeping truth.
- Bank and liquidity. Statements show the actual cash flows and available balance — often offset in time from the accounting.
- Operational systems. CRM, ERP, project or time tracking hold the volumes: orders, utilisation, project progress. Only they explain why the financial figures look the way they do.
Each source has its own format, logic and rhythm. At its core, reporting means translating these three into one shared language.
A single source of truth
Before automating, you have to agree. What exactly does „revenue“ mean — booked, invoiced or paid? What is an „active customer“? How is „margin“ calculated? As long as these definitions are not set and documented, every report contradicts the next, and discussions revolve around figures instead of decisions. The goal is one consolidated layer with consistent definitions that all reports rely on — a single source of truth instead of many competing versions.
The data model is the real work
What is visible in the end is the dashboard. The value, however, lies in the model beneath it. A sound data model separates cleanly into layers:
- Raw data from the source systems, unchanged and traceable.
- Cleaned data — unified formats, stable keys, consistent periods.
- Defined metrics — the agreed figures, calculated once, identical everywhere.
- Reports — the view that management and the bank actually read.
Mixing these layers — for instance calculating metrics directly inside a chart — produces a model no one can check and no one can maintain. The separation is unspectacular, but it decides whether the system still holds a year later.
Automation: from manual to scheduled
Automation does not replace people; it replaces the repetitive: scheduled imports, the same transformations, regular refreshes. People review, interpret and decide; the machine assembles. That lowers three things at once: lateness, the error rate and dependency on a single person. The order matters — first a clean model, then automation. Automating an unclear process only delivers wrong numbers faster.
Quality assurance has to be built in
A system that delivers quickly but wrongly is more dangerous than a slow one. Controls therefore belong firmly in the process:
- Reconciliation. Does the report match DATEV? Does the reported balance match the bank account?
- Plausibility. Automatic rules that flag unusual jumps or empty fields before they reach the report.
- Traceability. Every figure must be traceable back to its source. A metric whose origin no one can explain is worthless.
Build it yourself or buy a tool?
The answer is usually pragmatic. You start with what is already there — structured exports and tools such as Power Query — and introduce a dedicated BI tool only when complexity justifies it. Over-engineering is as much a risk as endless spreadsheets: a system only a specialist can operate is no solution in mid-sized companies. The benchmark is not the most modern stack but reliability and maintainability.
What counts in the end
The goal is reporting that largely updates itself, is internally consistent and traceable back to the source — and that frees management from assembling data so there is time for the actual task: deciding. The data layer beneath goes unnoticed as long as it works. That is precisely its purpose.