One model.
Every finance question.
Our Finance reference model bundles bookings, invoices, plan and forecast into a single, clean structure. Balance sheet, P&L and cash flow are queries within it — not rebuild projects. Explore interactively how your data fits in.
Distilled from 17+ data projects · No personal data in the core · Live in 90 days
Click your way through your future data model.
Every financial transaction — a booking, an invoice line item — lands exactly once at the centre. Eight angles turn it into every analysis Finance needs.
Is the number right — and where does it come from?
The single fact table
One transaction = one row = one measure in base currency. No parallel worlds of helper tables: every metric is a view on the same figures — from the board dashboard right down to the individual document.
- Amount — the single measure (base currency)
- Document reference — drill down to the source
- Links to all eight dimensions
Granularity, load logic & indexes — in the architecture call
Where does this sit in the balance sheet or P&L?
Account
Every entry hangs off an account (e.g. SKR04) — and the account off a three-level hierarchy up to the balance-sheet/P&L structure. Balance sheet, P&L and open-item lists are therefore filters, not separate data models.
- Account number — your chart of accounts, e.g. SKR04
- Account type — asset / liability / income / expense
- Hierarchy: account → group → statement line
Validity, open-item logic & further attributes — in the architecture call
When booked, when delivered, when paid?
Time — three axes
Every transaction carries three date references: booking, delivery and payment. P&L by delivery date, cash flow by payment date, period close by booking date — same model, three perspectives.
- Booking date — year / quarter / month / week
- Delivery date — the period view of the P&L
- Payment date — the cash-flow view
Calendar logic & fiscal-year variants — in the architecture call
Who owns these costs?
Cost centre
Arbitrarily deep cost-centre hierarchy via parent relationships — from the whole organisation down to the team. Responsibility is kept organisationally, not by person: compliance stays clean.
- Hierarchy — arbitrarily deep, roll-up capable
- Responsibility — organisational unit, not a person
Allocation logic & further attributes — in the architecture call
Who exactly are we doing business with?
Customer / Supplier
Customers, suppliers, debtors and creditors in one partner dimension with role and segment. Customer profitability and supplier analysis come from the same model — no double maintenance.
- Role — customer / supplier / debtor / creditor
- Segment — your market or industry view
Duplicate handling & further attributes — in the architecture call
Actual or plan — or which forecast?
Metric / Scenario
Actual, plan and forecast are values of one dimension, not columns. The plan-vs-actual comparison is a filter, a new forecast version is a data state — and there are no empty forecast fields on actuals.
- Scenario — actual / plan / forecast
- Version — e.g. forecast 03+9, budget 2026 v2
Versioning & approval logic — in the architecture call
Does the project pay off?
Project
Projects with sub- and partial projects — and every project knows its customer. Project result and customer profitability link up automatically, without helper tables.
- Project structure — main and sub-projects
- Customer link — project belongs to the partner
Status logic & further attributes — in the architecture call
What do we make money with?
Product / Service
Products, services and cost objects in one dimension, grouped by product groups. Contribution margins per product line are a query — not an Excel craft project.
- Type — product / service / cost object
- Product group — your assortment logic
Further attributes & classifications — in the architecture call
And our special cases?
Universal dimension
An extension dimension structured identically for every client — your individual mapping docks on here. The model stays standard and maintainable, your specifics are fully preserved.
- Universal structure — proven across projects
- Client-specific mapping — your logic
Mapping templates from 17+ projects — in the architecture call
Questions for the model
How is our cash flow developing?
Cash flow is a query
The same transactions, evaluated by payment instead of booking date and filtered over the account hierarchy. Cash flow needs no separate data model — just a different angle.
Plan vs. actual per cost centre?
Plan-vs-actual is a filter
Plan and actual sit side by side as scenarios in the same fact table. The comparison per cost centre is a filter — no second model, no reconciliation spreadsheet.
Which customer is truly profitable?
Profitability across everything
Revenue and costs hang off partner, project and service. Customer profitability across all projects and services is a single query.
Balance sheet and P&L at the push of a button?
Calculation + filter, not structure
Balance sheet and P&L arise from the account hierarchy plus a period filter. There is no separate balance-sheet structure to maintain — and no discrepancy between report and entry.
Does the forecast hold up?
Forecast accuracy is measurable
Forecast versions sit as scenarios in the model. Forecast against actual across versions — directly analysable, without folders full of planning states.
Connect your systems
DATEV
DATEV docks straight in
General ledger and open items fill the fact table, account and partner dimensions almost 1:1 — the SKR chart of accounts is already anticipated in the model.
ERP (SAP, Dynamics …)
Your ERP delivers the core dimensions
General ledger, accounts receivable/payable, cost centres and material master map directly onto the core dimensions — regardless of the ERP vendor.
Excel planning
Your planning simply moves in
The existing Excel planning is read in as scenario "Plan" — and stands next to actuals immediately. The planning logic stays, the retyping ends.
CRM (HubSpot, Salesforce)
CRM enriches
Customers, segments and projects from the CRM enrich the partner and project dimensions — sales view and finance view speak the same language.
Invoicing
Invoices become transactions
Invoice line items land directly as transactions in the fact table with delivery and payment date — revenue per product and customer simply falls out of it.
Six decisions that make the model hold up.
No diagram for the diagram's sake — every structural decision solves a problem we keep seeing in grown finance landscapes.
One truth instead of three figures
Every transaction exists exactly once. Dashboard, monthly report and individual document show the same numbers — because they share the same source.
One amount, one base currency
Foreign currency is converted at the reference date on load. Your reporting works without currency footnotes and parallel columns.
Plan-vs-actual is a filter
Actual, plan and forecast sit side by side in the same model. A new forecast version is a data state — not a rebuild project.
Compliance stays simple
The core model is purely financial. GDPR, access rights and security reviews become clear-cut instead of a permanent topic.
Balance sheet & P&L as a query
Balance sheet, P&L and cash flow are calculation plus a filter on the account hierarchy — no separate structure that someone has to maintain.
Standard model, your specifics
The model is structured identically for every client; your specifics dock on via an individual mapping. Extensions like quantities or hours stay optional — no core ballast.
We show the full model in the architecture call.
All attributes, hierarchies, mappings and load processes — matched against your chart of accounts and your source systems. 45 minutes, no sales pitch, a clear assessment.
Book an architecture call