Software · Management information systems
Finance Data Architecture
Project, optionally with operation · 8 to 20 weeks
- The situation
- Each entity’s books are clean on their own, but the group view is built in a workbook maintained by one person. As soon as a chart of accounts deviates or a new company is added, the mechanics break.
- What we deliver
- We build the layer underneath: loading the accounting data, harmonizing the charts of accounts, mapping to a shared reporting model, historization. On Azure SQL, with Power BI on top.
- How you measure success
- Time to the group view after the monthly close, number of manual mappings, effort required to add another company.
Why a layer in between
Many mid-size companies sit on valuable financial data and cannot use it. The systems don’t talk to each other, and every analysis starts with an export.
Connecting Power BI directly to accounting works for one entity and one report. It stops working as soon as multiple companies, differing charts of accounts, or backdated postings come into play. The logic then lives in each report separately, and two reports show two versions of the truth.
The layer in between keeps the logic in one place: which accounts belong where, which company is part of the group, which figures were valid as of which reporting date.
What it includes
- Loading of the accounting data, automated and traceable
- Harmonization of differing charts of accounts into a shared reporting model
- Historization, so backdated changes don’t silently rewrite old reports
- A reporting layer in Power BI that draws on this model instead of on exports
Custom layer or ready-made product
If the financial data lives entirely in DATEV, Datenbrücke already covers much of this. If ERP, upstream systems or different group structures are involved, we build the layer individually. Which route fits is something we clarify openly at the start — depending on which systems are involved and who will maintain the model later.