Custom financial analysis software development
The monthly figures are in, the gap against budget is on paper, and then comes the question no system answers: where does that gap come from? Financial analysis software looks back and explains. Which part of the variance is price, which part is volume, which part is a shift in mix, and which customer or product is pulling margin down. Appfront builds that analysis layer to measure, on top of your general ledger and sub-ledgers, with reporting lines that trace every figure back to the entry beneath it.
Looking back and explaining, not forecasting
Financial data answers three different questions. What happened is the close and the reporting. Why it happened is analysis. What will happen is forecasting and modelling. In practice these three get mixed up in one spreadsheet, and the middle question always loses out. A figure comes out, an expectation comes out, but nobody can show which part of the variance comes from price, which from volume and which from a different product mix. This page is about that middle question: the analysis layer that unpicks and explains actuals, by period, by entity and by margin object.
Are you in the right place? This page is about looking back and explaining. If you want to look ahead, with driver-based models, scenarios and a forecast that updates as new data arrives, you want financial predictive analytics and the predictive analytics dashboard. If things stall one layer lower, because bank transactions, payments and open items are still matched by hand, then financial reconciliation software is the first step: analysis on figures that aren't matched is analysis built on sand. Explaining, reconciling and forecasting are three separate disciplines with three separate sets of requirements, even when they ultimately sit on the same data model.
What sets the analysis layer apart from an ordinary report is the obligation to explain. A report shows a figure. An analysis layer shows the figure, the difference from the comparison basis, the build-up of that difference in named steps, and the route back to the entries it comes from. That last part is not a luxury. As long as a controller cannot trace a figure back to the source document, the person with the loudest spreadsheet wins every argument.
In practice this layer serves three kinds of user. The controller wants the build-up and the route back to the entry. The management team wants four or five lines that tell the story of the period. The manager of a product line or region wants only their own part, but using the same definitions as everyone else. That last point is the silent condition underneath everything: one definition per term, captured as data and not as a formula buried in the report of whoever built it. Once net revenue means something different in two reports, the meeting ends up debating the numbers instead of the business.
A total variance is not an answer
That revenue differs from budget is an observation. Separating price, volume and mix turns it into a finding someone can act on.
Margin lives in the sub-ledger
The general ledger knows accounts, periods and cost centres. Product, customer and order line sit in the layers beneath.
Every figure has an address
From report line to allocation rule to source document, with no stop in a spreadsheet that nobody can retrace.
Variance analysis: from total gap to cause
In almost every organisation the report already exists: budget, actuals, variance, and a column for comments. And in almost every organisation that report becomes useless as soon as the question moves on to the why. The cause lies not in the report but in the data underneath, and it is almost always the same: the budget was drawn up at a different level from the one at which the accounts are posted. The budget sits per cost centre and per period, in a structure the board recognises. The actuals sit as journal lines, with a general ledger account, a cost centre, sometimes a project, sometimes an article, and with a posting date that is not the same as the date of performance. As long as those two levels are not explicitly mapped onto each other, you can add and subtract, but you cannot explain.
Explaining starts with breaking the variance down into effects that can be understood separately. For revenue there are at least three. The price effect is the difference between the achieved and the budgeted price, weighted by the actual volume. The volume effect is the difference between actual and budgeted volume, weighted by the budgeted price. The mix effect is what remains because the balance between products, channels or segments turned out differently from the budget, even if the total volume was right. On the cost side, a rate effect and a utilisation or efficiency effect come in: a different hourly rate from budget, and more or fewer hours per unit. If you operate in multiple currencies, the exchange rate effect belongs as a separate layer in the breakdown, otherwise a weaker currency disappears into what looks like pricing pressure. The result is a bridge: from the comparison basis to the actual result in a handful of named steps, each of which has an owner who can do something about it.
This breakdown requires a choice that is often not made: do you restate the budget downwards, or do you roll the actuals upwards? Restating downwards means spreading a cost centre's budget across articles, customers or orders using an allocation key. You can then compare at a fine level, but you are comparing actuals against an assumption. Rolling upwards means aggregating the actuals to the level at which the budget was set. The comparison is then clean, but the analysis stops at a level too coarse to hold anyone to account. In practice a combination works best: roll upwards for the official variance reporting, and analyse more finely using a key that is clearly marked as an assumption, so that nobody confuses the two. What does not work is leaving the choice implicit, because then two versions of the truth exist and nobody knows which one is on the table.
On the cost side, the breakdown needs one further step. A variance on a cost centre is almost never a single story: there is a price component, a volume component that moves with activity, and a part that is genuinely about control. Costs that move with revenue should therefore first be adjusted for the difference in activity, otherwise a department gets a red line simply because business went well. That adjustment is nothing more than restating the budget at the actual level of activity, and it is exactly why the assumption behind an allocation key must be explicit. Whoever skips that step ends up with a list in which the biggest variances sit with the busiest departments, and that is not a finding but an artefact of the calculation.
Some of the variances on a list like this have nothing to do with the business itself. An invoice booked a period late, a reclassification between accounts, a provision taken in one go, or a correcting entry from the auditor: the difference is real, but the explanation is administrative. If those items cannot be flagged separately, the handful of variances that do matter get drowned out. That is why every variance should carry a category and an owner, and why commentary should stay attached to the figure rather than disappear into an email. A threshold helps here: only variances above an agreed limit require an explanation, so attention goes to the items that actually make up the difference. And because the commentary stays with the figure, you can look back at the following period and see what was said last time, which is one of the few reliable ways to recognise a recurring problem as recurring.
What exactly are you comparing against?
The variance against budget is not a single fixed figure once the budget has a history. There is the originally approved budget, there are the interim revisions, there is the most recently approved forecast, and there is the same period last year. Each of these four gives a different variance, and all four are legitimate, as long as the report states which one is being used. An analysis layer should therefore treat the comparison basis as a first-class dimension, with a version, a point of fixing and a status. That way you can reproduce a report as it looked at the time, and also see what it would show under the current structure and current rules. Without that dimension, you inevitably end up in the discussion where two people open the same report and see a different variance.
Comparisons across the year-end boundary also require two adjustments. The first is the composition of the group: an acquisition or a divested unit makes a growth figure meaningless, so a comparison on a like-for-like composition should sit alongside the reported comparison. The second is currency. The same revenue at a different exchange rate is not a performance. Both adjustments are separate steps in the bridge rather than changes to the source figure, because as soon as you alter the source figure it no longer reconciles to the ledger and you lose the traceability this entire layer is meant to provide.
What a financial analysis layer must be able to do
These components depend on one another. A variance bridge without allocation rules that carry an effective date produces figures that differ next period without anyone knowing why. Allocation without a reconciliation report produces a model that adds up neatly but cannot be traced back to the ledger. And any figure that cannot be drilled through to the underlying posting remains an opinion.
Variance bridge with price, volume and mix
From comparison basis to actuals in named steps, each step with an owner, instead of a single variance column without explanation.
Margin waterfall per product, customer and order
From gross invoice value through discounts, rebates and returns to net revenue, and further to contribution margin per margin object.
Allocation rules with version and effective date
Allocation keys held as data rather than formulas buried in a report, with history, so that earlier periods remain reproducible.
Consolidation with intercompany elimination
Local chart of accounts mapped to the group chart, intercompany balances eliminated, and exchange rate differences shown separately.
Reconciliation report to the trial balance
With every data load, a check per account and per period between the analysis model and the ledger, with differences named.
Drill-through to the source document
From a report line to the journal lines beneath it, with the applied rules visible, without exporting to a spreadsheet.
Margin per product, customer and order
Ask any finance department for the margin per customer, and the answer comes from a spreadsheet. That is not unwillingness. The general ledger is built around accounts, periods and cost centres, while the dimensions you need for margin analysis (item, customer, order, order line and sometimes shipment) exist only in the subledgers and in the order or ERP system. Margin per product is therefore by definition a composite of several sources. That is precisely why the whole stands or falls with reconciliation: the total of the margin analysis must equal the revenue and cost of sales in the general ledger, or the difference must be explained.
The build-up starts with gross invoice value and works down through named steps. Deducted from it are line discounts and volume tiers, credit notes and returns, freight contributions you bear yourself, settlement discounts, and bonuses that are only paid out after the period. What remains is net revenue, and that is the only revenue figure on which a margin discussion is meaningful. Below that come the directly attributable costs: purchase cost or materials, direct hours, subcontracted work, and the logistics and service costs linked to that order. The result is a contribution margin. Only then come the allocated indirect costs, and that step should remain visibly separate, because that is where the assumptions lie.
Bonuses deserve separate attention. An arrangement that settles against a revenue tier at the end of the year should be accrued during the year based on the expected outcome, otherwise the early periods look too favourable and the later ones too unfavourable. The same applies to annual surcharges, marketing contributions and long-term warranty obligations. If you only book these items when they are paid, you end up with a customer that appears profitable all year and drops below water in the final period, even though nothing has changed in the trading relationship. For the analysis layer, this means that some costs are by definition a calculation, and that calculation therefore requires version control and an explanation.
Then the cost of sales itself. If you work with standard costs, the order carries the standard, and price and efficiency variances land on separate variance accounts that never flow back to the order. That is a defensible choice, but it means the sum of the order margins does not equal the operating result, and that difference should appear in the report rather than in a footnote. If you work with actual costs, the margin of an order continues to shift after invoicing, because a later purchase invoice or freight note still arrives. That too is defensible, provided everyone understands that a period is only final once it has been closed. What does not work is using one method in the report and the other in the discussion.
If you work on projects or in services, work in progress comes into play. The margin on an engagement then arises over several periods, and the picture per period depends on how you determine progress and what work in progress you attribute to it. An engagement that overruns towards the end should not deliver that loss all at once as a surprise; it should already have become visible in the expected final outcome. For the analysis layer, this means that alongside the realised margin per period there is a second figure, namely the expected margin at completion, and the movement between the two is just as interesting as the difference from budget.
Finally, there is the service itself. Two customers with the same revenue and the same gross margin can be very different once you factor in how many orders they place, how small those orders are, how often they return goods, and how much attention they demand from internal sales and customer service. Those costs do not appear on the invoice and follow their own allocation key. If you want to go deep on this, cost-to-serve analytics is the most direct route. On this page it is one of the layers in the ladder, and above all a reason not to stop the ladder at gross margin.
- Net revenue after discounts, bonuses and returns as the starting point
- Contribution margin separate from allocated indirect costs
- Allocation keys as data, with version and effective date
- Difference between standard cost and actual cost identified and named
- Sum of the margin objects reconciles to the general ledger
- Drill-through from margin per customer to the underlying order lines
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Consolidating across entities and the route back to the source
Once there are several entities, consolidation is first a mapping problem and only then a calculation problem. Every administration has its own chart of accounts, shaped by its own history, and that chart must be mapped onto a group structure. That mapping is never neatly one to one: some accounts map to several group lines depending on the counterparty or the cost centre, and some accounts that are legally required to be separate in one country collapse into a single line in the group view. The mapping table should therefore have an effective date and an owner, and every change should lead to an explainable movement in the comparative figures, not a silent restatement of the past.
In addition, the dimensions themselves must line up. The same customer appears under three numbers in three countries, the same item has a different code in two entities, and a cost centre means something different at each location. Without a reconciling key across those administrations, you are adding apples to pears, however neat the report looks. That is a data problem rather than a reporting problem, and the solution belongs in master data management and in the data warehouse layer beneath the report, not in an extra column in the group controller's spreadsheet.
Intercompany, currency and the composition of the group
Intercompany transactions must be eliminated, and that sounds simpler than it is, because elimination can only happen once both sides agree. In practice they differ: one entity has posted in one period and the other a period later, or there is an amount or exchange rate difference. Consolidation should therefore begin with a difference matrix per pair of entities, with an owner for each line, and only then eliminate. Alongside the revenue and cost pairs and the mutual receivables and payables, there is one category that is often overlooked: margin that still sits in another entity's inventory and is therefore not yet realised at group level.
Currency is the second layer. The usual practice is to translate the profit and loss account at an average rate, the balance sheet at the closing rate, and equity at historical rates, with the resulting difference booked to a translation reserve. For the analysis, what matters most is that the currency effect is a separate step in the bridge, so that management can see which part of the movement comes from operations and which part from exchange rates. The third layer is composition. A participation may be fully consolidated, proportionally included, or accounted for under the equity method, and that interest can change during the year. The share attributable to non-controlling interests should be shown separately, and any comparison across the year-end should state whether it is based on the current or the then-prevailing composition. Corrections that exist only at group level, such as differing valuation bases or consolidation entries, belong in their own layer that does not overwrite the local figures, with a separate record of who changed what and when.
Reconciling to the ledger and staying traceable
Traceability is not a reporting feature but a design requirement, and it starts with a check that runs automatically: per account and per period, the analysis model must equal the trial balance. If it deviates, the report does not go out until the difference has a name. Such differences always exist, and most are legitimate. The analysis model often works on the performance or delivery date, while the ledger uses the posting date. Manual journal entries have no item or customer and therefore fall into a category that cannot be allocated. Revaluations, rounding, intercompany entries and provisions each generate their own difference.
The answer is not to smooth those differences away but to name them: a reconciliation bridge in which the ledger total equals the model total plus a limited number of categories, each with an owner. An unallocated amount that is quietly spread across products is far more dangerous than the same amount shown separately, because the former makes every product figure slightly untrue without anyone noticing. This reconciliation also involves a choice about dates: which date drives the report, and which deviation you thereby structurally accept. That choice should appear on the report, not only in the head of the person who built the model.
A second requirement follows: reproducibility. If you rerun the report for a closed period today, does it produce the same result? Only if the allocation rules, the mapping tables and the comparison basis are versioned with validity periods. Two views are then both legitimate: the figure as it was reported at the time, and the figure as the current rules produce it. What is not legitimate is not knowing which of the two is on screen. And because postings still arrive for closed periods after closing, the model should detect such late entries and report them, rather than silently including them. Whoever builds that in will not have to answer the question of whether the report is correct by hand every period.
Two requirements always arise in practice: access rights and speed. Access rights, because a regional manager should see their own entity and not a neighbour's, whereas the group controller sees everything. This calls for row-level filtering within the model itself rather than in the report, because getting around a report filter is too easy. Speed, because drilling down from a group total to individual order lines involves far more rows than an average dashboard can handle. A fixed star schema with closed periods stored as snapshots helps here, so that the heavy history is not recalculated with every query and only the open period still moves. Together, these two requirements often determine more of the architecture than the reporting wishes on the first page of the project proposal.
When an off-the-shelf package is the better choice
Financial analysis is not an empty corner of the software market. There is a mature category of planning and consolidation packages, there are BI platforms with a financial layer on top, and most accounting and ERP vendors now offer a reporting module that goes well beyond an export. For some readers of this page, such a package is the more sensible route, and we would rather say so now than halfway through a tender process.
What a package brings is precisely the work you do not want to build yourself: consolidation logic, translation to group currency, version control on budgets, an audit trail, row-level permissions and connectors to the common bookkeeping packages. All of this is maintained and evolves with changing reporting rules. If your situation follows the usual pattern, a manageable number of entities, a standard chart of accounts and margin at product and customer level, you buy that ready-made and shift your effort from building to configuring. Configuring is work too, though, and usually more than the demo suggests.
Custom development pays off in fewer situations than vendors suggest, and the clearest case is an allocation or margin logic that is genuinely your own. A calculation model that builds the actual cost of handling, packing, shipping and returns per order line, in a way that is not standard in your sector, is exactly the part you lose as soon as you have to squeeze it into a package's forms. The second case is an analysis object the package's dimension model does not know: per trip, per route, per construction component, per subscription cohort. The third is granularity: analysis down to order line across several years, with drill-through to the posting, often hits volume or licence limits in packages. The fourth is a source system for which no connector exists, such as a proprietary order, production or case management system.
The downside comes with it. With in-house building, keeping pace with changing reporting and disclosure rules rests with your own organisation, and for consolidation and annual-accounts-related reporting that is no small responsibility. Often the middle road is the best answer: a package for consolidation and the official figures, custom development for the analysis layer that carries your own margin and allocation logic, with a single shared data model underneath. How we weigh that trade-off and which questions we ask, you can read at custom ERP system development; if you work in a regulated environment, software for the financial sector is the broader entry point.
One thing custom development does not solve: a chart of accounts where nobody any longer knows what each account is for, or master data coded differently in each entity. That is groundwork, and it is groundwork you need to do for a package too. Whoever skips that step builds a neat analysis layer on top of a dataset that simply cannot answer the question.
If you calculate the return on property investments for an investment committee, see our app for property return calculation.
- Package when your situation follows the usual consolidation pattern
- Package when version control and audit trail are the heaviest requirements
- Custom development for an in-house allocation or margin logic
- Custom development for an analysis object the package does not know
- Custom development for source systems without an existing connector
- Middle road: package for consolidation, custom development for analysis
Frequently asked questions about financial analysis software
Financial analysis software looks back and explains why actuals deviate from the benchmark, how much of the variance comes from price, volume and mix, and where margin sits by product, customer or order. Predictive analytics looks forward and models forecasts, scenarios and drivers. The two should sit on the same data model, because a forecast without reliable history is guesswork, but they serve different purposes with different requirements. If you are looking for the forward-looking side, the page on financial predictive analytics is the right starting point.
Because the general ledger is structured around accounts, periods and cost centres, not around customers, items and order lines. Those dimensions only exist in the subledgers and in the order or ERP system. Margin per customer is therefore always a composite drawn from several sources. That is fine, provided the composite reconciles to revenue and cost of sales in the general ledger, and provided any remaining differences have a category and an owner rather than being quietly spread across products.
All three are legitimate and they give different answers. The approved budget measures whether the agreed target is being met, the latest forecast measures whether the previous view still holds, and last year measures development over time. What matters is that the comparison basis is a proper dimension, with a version and a point of fixing, so the report states which basis was used. Comparisons across the year boundary need two adjustments: an identical group composition, and the currency effect as a separate step.
By building the reconciliation in as a control instead of doing it by hand afterwards. With every load, the model checks balances per account and per period against the trial balance. Differences are normal, for example from performance date versus posting date or from manual entries without an item, but they should appear in a reconciliation bridge with a category and an owner. If it does not reconcile, the report is not released. In addition, every figure should be traceable down to the underlying journal lines.
Often, yes, and for many organisations that is the more sensible route. Mature planning and consolidation packages and BI platforms with a finance layer exist, including version control on budgets, translation to group currency and an audit trail. If your situation follows the usual pattern, buying that off the shelf makes sense. Custom development only becomes worthwhile with proprietary allocation or margin logic, an analysis object the dimensional model does not cover, analysis down to order-line level, or source systems for which no connector exists.
The source code and documentation belong to the client and sit in a repository to which you have direct access. On handover you receive a description of the architecture, the data models, the attribution rules and the integrations, so that another party can take over without first having to reverse-engineer anything. We work with mainstream technology, because that determines how many parties can take on the maintenance.
Related services
Financial predictive analytics
If you want to predict rather than explain, with driver-based models, scenarios and forecasts that update as new data arrives, then financial predictive analytics is the right starting point. For the visual side of that, with scenarios side by side in one view, there is the predictive analytics dashboard.
Financial reconciliation software
If things get stuck when matching bank transactions, payments, open items and counter-accounts, the work starts there and not with the analysis. Financial reconciliation software makes sure the figures add up and the items are matched before you move on to explaining them.
Custom KPI dashboard
If the outcome is mainly about getting finance results to people outside finance, in a view that shows something different for each role and that nobody has to interpret, then a custom KPI dashboard is the logical layer on top of this analysis. The definitions stay in the analysis layer, so there is only one version of each term.
Taking a closer look at your variance report
Tell us how your budget-versus-actuals report is currently produced, at what level the budget is set and what happens when someone asks where a variance comes from. Also tell us whether margin per client comes from a system or a spreadsheet, and whether its total reconciles with the general ledger. Those answers usually show whether an off-the-shelf package, custom software or a combination fits best.