Your accounts show what the company spent in total. What a single order, product or site earned usually remains an estimate.
Accounting and consolidation provide the financial view, and they do it well. To answer what a single reference object earns, it has to be connected to the quantities from operations and to your own allocation rules. That connection is what we build — traceable down to the individual entry. We shape the structures behind it; the consolidation itself is run by your finance department.
In an air operation the costs sat in the consolidation system and the performance data in the flight operations system. Both sides were complete. They were simply not connected, and so nobody could say which aircraft paid for itself.
Starting data. On one side the entries from the consolidation system, across several financial years, broken down by account level, accounting entity and cost centre. On the other side flights, flight hours and outgoing invoices from the operational system.
Allocation. Each aircraft had a cost centre in the accounts and a registration in operations. The two were linked through a maintained mapping table — the real piece of work, because it requires a decision for every case that is not unambiguous. Where one invoice covered several aircraft, an agreed distribution rule applied. Anything that could not be allocated stayed visible as an exception instead of disappearing into an overhead.
Result. Cost, revenue and margin per aircraft — monthly, across several years, and against the actual consumption recorded in operations. Traceable down to the individual entry.
The reference object here was an aircraft; it can just as well be an order, a product, a project or a site. The underlying approach carries across — which allocations, distributions and time references are needed follows from your business model. The full case is described on the page about the Aviation Control Stack.
Consolidation systems answer the questions of the finance department. Systems such as LucaNet come with their own reports, analyses and dashboards, and they keep their own data warehouse holding the account structure, periods, adjustment levels and postings. What remains open is the question about a single reference object, because that requires operational quantities and allocation rules specific to your company. Which data can be used for it is established at the start, from the available interfaces, the permissions and the configuration of your systems. What we build from it are the structures your reports rest on: account levels, accounting entities, adjustment levels and cost objects.
Adjusted values, raw data and entries from a purchase price allocation sit side by side in the same system. Which level answers a question is decided and recorded per metric — not set once for everything.
A chart of accounts has several levels. Reaching in at the right one returns a metric rather than a sum of individual accounts.
The real value appears when a cost item from the accounts sits next to the quantity from the operational system.
The entry point is a quick check of the accounting processes, and it is deliberately bounded. Order-to-cash, purchase-to-pay and record-to-report are not surveyed in full but recorded along the one question you want answered. For that we need the chart of accounts and the group structure, a list of the systems involved, the reports in use today and read access. Around the table sit finance, controlling and IT.
Afterwards you know where you stand and what to do first. On that basis management decides which metric is built first.
What comes out of it once you commission the second step — each item verifiable on its own.
The data model and its presentation are two different things. The substance sits in the model; whether the views are built in Grafana or in Power BI is a separate decision. We align that choice with your existing environment, your user groups and the running cost — which is how a specialised analysis tool and broad distribution to a larger readership can be combined deliberately. If you already run a Power BI landscape, we are no reason to commit to a second tool.
We connect to what you already use. The reporting logic is joined to our dashboard and data pipeline work, so the figures are carried forward automatically instead of being assembled by hand each month. The report states when the data was last loaded and what is still outstanding — an automatic refresh and a complete set of postings are two different things.
For in-depth business analysis, restructuring and interim CFO mandates we extend our services through our cooperation with Triple A Consult RGL GmbH of Munich.
The cooperation is explicitly an extension: the data and reporting structures remain our task, and who covers which part is settled before the work starts.
Your finance department is accountable for the postings and for the professional decisions: which metric applies, which adjustment level is the right one, which distribution rule is agreed. We are accountable for the processing as agreed — that the derivation of every figure stays traceable, that the agreed checks on completeness and plausibility run, and that anomalies are named rather than quietly absorbed into an overhead. Resolving them is a joint effort.
On consolidation itself. We shape the structure it rests on — account levels, accounting entities, adjustment levels and cost objects — and we report on it. Performing the consolidation and carrying the responsibility for it under commercial law stays with your finance department and its advisers.
Also outside this service: tax advice and assessment under commercial law, annual accounts, audit and bookkeeping, as well as licences and the introduction of consolidation software by us alone.
One decision determines the outcome, and it belongs at the start: who in the organisation can demand the input? If nobody is named, even the best model stays empty.
Tell us briefly what it is about – we will get back to you.