Management control software: the margin you declare in September is not the one that closes the year

The dashboard said the installation line, half the company's revenue, closed the year with a nineteen per cent margin, and that service was something you kept for customers but that barely paid for itself. On those numbers four people had been hired into installation and a service technician who retired had not been replaced. In February, redoing the calculation with costs allocated by technician hours instead of revenue, installation was at seven per cent and service at twenty four. The owner, sixty people in northern Italy, had spent a year pushing the wrong line while looking at a precise number every month. This is the problem management control software is supposed to solve, and it is also the most sophisticated way there is to get it wrong.

If you recognise the scene, this article gives you the real cost of deciding on numbers that arrive in March, the single number that tells you whether your management control system helps you choose or only reassures you, how to allocate indirect costs without kidding yourself, how far a spreadsheet takes you, the three different things vendors all sell under the same name, the real price bands between a product, the module of the ERP you already own and a custom system, and the threshold in euro beyond which the arithmetic changes.

I have been writing software since 1999 and I have seen company numbers from the inside in very different situations: subcontract machine shops working to order, plant engineering companies selling design, installation and maintenance together, distributors with thousands of order lines and two point margins, professional firms where cost is almost entirely people's hours. I also built and sold a software product used by many companies, and when I sold it I had to answer questions about its margins that no spreadsheet could have supported. Turning what happens inside a company into a number you can trust is a problem I had to solve, not just describe.

What I learnt, and what no vendor says during the demo, is this: the number that decides is not how many dashboards you have, it is how far the margin your management control system declares sits from the one your statutory accounts confirm at year end. If that gap is large, everything you build on top, budgets by line, monthly variances, the dashboard on your phone, does not fix the problem: it makes a false number precise and credible, and the prettier it is the more damage it does, because an ugly number at least gets questioned.

What management control software is, and what it is not

Management control software is the system that knows three things your accounting alone does not: how much you really earn on each business line, each customer and each job; how far you are running from what you planned, while the year is still open; and what happens to the result if you change a price, lose a customer or hire two people. It answers one question, but every month: are we earning where we thought, and if not, do we find out in time to change something.

The market sells it under different names, and the confusion suits the sellers. Management control, cost accounting, business intelligence, corporate performance management, planning and budgeting, executive dashboards, margin analysis. These overlap only partly, cost figures an order of magnitude apart and solve different problems. Working out which one you need is already half the negotiation, because the product that solves your problem may be the least impressive of the three you are looking at.

The difference between keeping the books and making a decision

The accounting you already have almost certainly keeps the books perfectly. The accountant closes the year, the tax return is in order, the balances tie to the cent. It is serious work, and it is why a great many companies get this far and stop. The point is that this work answers a different question from yours. Statutory accounting answers how much the company earned in the period, which is what the tax authorities and the bank care about. Your question is another one: where it earned, where it lost, and what you should do on Monday.

The practical difference is the thing almost nobody explains. Statutory accounts are organised by nature of cost: wages, materials, depreciation, services, rent. Decisions are made by destination: what the installation line cost, what customer Rossi cost, what the hospital job cost. One euro of wages is a single line in the accounts; in your head it is an hour of a technician who spent that day at one customer's site and not another. Management control is exactly the work of turning the first view into the second, and everything else follows from that.

Then there is time. The statutory result is true and arrives late: the 2026 accounts you really study in spring 2027, when there is nothing left to do about those facts. Management control is worth something if it arrives within a few days of month end, and much less at forty days, because a decision taken in May on March data has let two months of instinct-driven choices go by. This is not a defect of accounting: recording facts and steering a company simply run on different clocks.

The three families of companies that look for it, and look for different things

Companies with several business lines under one roof. Manufacturing and service, sales and installation, product and consulting. The problem here is working out which line is carrying the other, because people and buildings are shared and nobody knows how to split the cost. The value is in indirect cost allocation and in margin by line. Vendors show them dashboards full of indicators, and miss the target: the target is a ten row table done properly.

Companies working to order. Plant engineers, contractors, software houses, agencies, technical practices. The problem here is the margin of the individual job and the fact that you find out when it is finished, when nothing can be fixed. The value is in progressive cost capture and percentage of completion, that is, knowing halfway through whether you are running over. It is a distinct enough case to have its own market, and I covered it in detail in job costing software.

Companies with many customers and thin margins. Distribution, wholesale, recurring services. The problem here is that the average margin does not exist: there are customers above and customers below, and the average hides both. The value is in analysis by customer and product, and above all in the cost to serve, meaning freight, returns, rush orders and credit, which is the item that decides and that almost nobody allocates.

The three families buy products with the same name and use different parts of them. Before you watch any demo, decide which one you are in, because it is the only thing that makes two quotes comparable. If you are in two at once, which happens often, decide which one is losing you more money today.

The real cost of deciding on numbers that arrive in March

This is the calculation almost nobody does, because none of these items has a line in the accounts: they are margin that never formed and decisions taken blind. My reference is a company with twelve million in revenue, sixty people and three business lines: manufacturing in the workshop, installation at the customer site, service and maintenance. It is a very common size and shape among the people who write to me.

Prices and mix decided on badly allocated margins

This is the largest item and the least visible. Suppose forty per cent of revenue, nearly five million, runs through a line that management control shows as more profitable than it is, because indirect costs were split by revenue instead of by a sensible driver. If the allocation error is worth five margin points, and you build prices, the sales plan and hiring on that line, you are working badly on two hundred and fifty thousand euro a year. You do not lose all of it, because the market corrects some of it by itself, but that is the order of magnitude of the mistake.

The damage does not stop there. If one line is shown better than reality, another is shown worse, and that is where you cut: you do not replace the person who retires, you do not invest, you raise prices to recover a margin you already had. It is the most efficient way I know of shrinking the healthy part of a company with a clear conscience, and the signal is always the same: revenue grows, profit does not, and nobody can explain why.

Loss-making customers and jobs nobody ever isolated

In almost every company I have seen, a brutal rule holds: a minority of customers produces most of the margin, a middle group breaks even, and a tail erodes. The tail is made of customers who buy little and ask for a lot, long-standing customers on prices frozen for years, and the big customer who takes up half the company and is protected by their revenue. Nobody isolates them because isolating them means allocating the cost to serve: freight, returns, technician time, rush orders and days of credit.

On twelve million, with normal industrial margins, the eroding tail is worth between twenty and ninety thousand euro a year. The figure matters less than the fact that it is invisible: a loss-making customer does not complain and does not leave, so they stay. And the real cost is not what you lose on them: it is the capacity they take away, the technician hours you could not sell to a customer who paid.

Decisions taken two months late

If cost accounting closes at fifty days, you see March in late May, and by late May the second quarter is already written. The cost of the delay never shows up as a line item, it shows up as a series of decisions taken on instinct: the price quoted to a new customer, the job accepted because it looked good, the hire postponed, the discount granted to close the quarter. In a company of that size, decisions taken blind over a year are worth between twenty and seventy thousand euro, and that rises quickly when markets move.

The rule I use is simple: a number that arrives within five working days of month end changes a behaviour, a number that arrives at forty days produces a discussion. Better a margin by line accurate to five per cent delivered on the fourth of the month than an exact one delivered on the twentieth, because the first makes you change something and the second makes you comment on something.

Inventory and work in progress valued by eye

In companies with stock or open jobs, the monthly result depends on the value of what you have not sold yet. If you estimate that value, the margin of the first three quarters is an estimate, and in December comes the adjustment nobody saw coming. I have watched companies discover at year end that stock was worth two hundred thousand euro less than expected and have to explain to the bank why the result was half of what had been declared in September.

The cost here is twofold: capital tied up in stock you do not need, which costs between fifteen and twenty five per cent of its value a year in finance, space and obsolescence, and the credibility of your numbers in front of the people who fund you. Between ten and forty five thousand euro a year, and the worst part cannot be quantified. Stock is one half of the problem that many overlook, and I covered it in warehouse management software.

Rebuilding the numbers by hand

There is a person in the finance office who every month exports three files from the ERP, one from the time system and one from accounting, pastes them into a spreadsheet, fixes the codes that do not match by hand, applies the allocation percentages and sends the file to the owner. It takes two or three days. If a controller exists, it takes twice as long because they also check. That is between four hundred and eight hundred hours a year, fifteen to thirty five thousand euro, done by the most valuable people you have in the most demoralising way there is: rebuilding instead of analysing.

The total, for a twelve million euro company, sits between one hundred and twenty and four hundred and ninety thousand euro a year, and no company hits the top of all five items. The range is wide because the real variable is not size: it is how different your lines are from one another. A company doing one thing for similar customers sits at the bottom, one putting activities with different cost structures under the same roof sits at the top. Before you read on, do the sum with your own numbers, roughly, on a single sheet. If your total is under twenty five thousand euro a year, software is not your most urgent problem, and further down I tell you what is.

The reconciliation gap: the number that decides whether the project makes sense

If I could keep one number from this whole article, it would be this: how far the sum of the twelve monthly margins declared by your management control system sits from the operating result your statutory accounts later confirmed. I call it the reconciliation gap. It decides everything, because every function of management control software, from budgeting to variances to pricing, starts from that number and multiplies it by something else.

The reason this number matters more than any other is that it is the only external check you have. An internal dashboard is consistent with itself by construction: if you get the allocation wrong, the dashboard still ties and no total notices anything. The statutory accounts, instead, are a judgement from outside, checked by a professional and filed. If the two never speak to each other, you have two truths and you are using the convenient one.

How to measure it, in half a day

Take the last closed year. Retrieve the twelve monthly operating margins management control declared month by month, the ones the owner looked at and the meetings discussed. Add them up. On the other side take the operating result for that year from the statutory accounts, that is the result before finance costs and tax, and add back or take out the items management control deliberately excluded, such as exceptional items or provisions decided at closing. The difference between the two totals, divided by the statutory result and taken in absolute value, is your gap.

Then do a second pass, and that is the one that tells the truth: repeat the same calculation for each business line. A total gap can be small and hide two large errors that cancel out, one too high on one line and one too low on another. That is the most dangerous situation of all, because the company as a whole ties and you are deciding on individual lines.

If the data already sits in a database, the measurement is a query. This is the shape I use on SQL Server. The table names in your system will differ, the substance will not:

-- Gap between the margin declared month by month and the result confirmed by the accounts
WITH Analitica AS (
    SELECT LineaBusiness,
           SUM(Ricavi) - SUM(CostiDiretti) - SUM(CostiIndirettiRibaltati) AS MargineDichiarato
    FROM MovimentiAnalitici
    WHERE Anno = 2025
    GROUP BY LineaBusiness
),
Bilancio AS (
    SELECT LineaBusiness,
           SUM(CASE WHEN Segno = 'A' THEN Importo ELSE -Importo END) AS RisultatoConfermato
    FROM SaldiContabili
    WHERE Anno = 2025
      AND ClasseConto IN ('RICAVI', 'COSTI_OPERATIVI')
    GROUP BY LineaBusiness
)
SELECT a.LineaBusiness,
       a.MargineDichiarato,
       b.RisultatoConfermato,
       a.MargineDichiarato - b.RisultatoConfermato AS Scarto,
       ABS(a.MargineDichiarato - b.RisultatoConfermato) * 100.0
         / NULLIF(ABS(b.RisultatoConfermato), 0) AS ScartoPercento
FROM Analitica AS a
FULL JOIN Bilancio AS b ON b.LineaBusiness = a.LineaBusiness
ORDER BY ScartoPercento DESC;

The line that matters is the FULL JOIN. Lines appearing on one side only are the most valuable finding: they are costs the statutory accounts recorded and cost accounting never saw, or centres that exist only in management control and were never tied to an account. In my experience that empty row explains half the gap on its own.

Three warnings, because the measurement is easy to distort without meaning to. Do not fix past months with what you learnt later: you need the numbers as they were when decisions were being made, otherwise you are measuring your own memory. Do not exclude the bad months because they look like exceptions: if three months out of twelve are off, the exception is the rule. And do not pick which lines to compare, take them all, small ones included, because that is where the percentage gap explodes.

In SMEs that have never done it, the result almost always sits between fifteen and forty per cent. The gap is not random: it nearly always runs the same way, because the declared margin is higher than the real one. The reason is almost always the same. Indirect costs enter management control at a share somebody decided years ago, and since then the organisation has grown without that share being updated. Anything that is not a direct purchase invoice tends to be understated: internal people's time, structural costs, hours lost travelling, the credit you pay the bank for because customers settle at ninety days.

The four thresholds, and what you can do at each

Under five per cent: your numbers decide. You are in the minority, and your problem is not fidelity but depth. Here it pays to go a level down: from margin by line to margin by customer, product and job, and to bring the closing time under five days. An analysis tool repays what it costs straight away, because it works on reliable data. You can skip much of what follows and go straight to choosing.

Five to fifteen per cent: right in total, wrong on the individual line. The company as a whole ties, and the line that carries a fifth of revenue can be out by a factor of two. This is the most common situation in companies with a management control system that was well built and is now old. The work here is not buying: it is rebuilding the allocation criteria with today's drivers, and rechecking that every account has a destination. Six weeks of work, almost all analysis rather than IT.

Over fifteen per cent: you are deciding about a different company. The monthly numbers do not help you choose, they reassure you, and every new dashboard amplifies them. There is only one possible sequence: reconcile first, fix the criteria second, automate third. Anyone proposing you start with dashboards is selling you the part with the lowest return, which also happens to be the part that demonstrates best.

Never reconciled: you do not know. This is the most common case of all, and it is not a failing: cost accounting and statutory accounting often live in two different systems, looked after by different people, and nobody was ever asked to make them talk. The first job is not buying software, it is doing this comparison once, on the last closed year. Half a day of someone who knows both worlds is enough, and the result changes the conversation with any vendor.

There is only one practical rule: before buying a system that tells you where you are going, get a way to check that it knows where you have been, because a budget built on a consuntivo that is twenty per cent wrong is precise and false. If your gap is large, you do not have a tooling problem. You have a criteria problem, it is cheap to fix, and without fixing it nothing else works.

Allocating indirect costs: where dashboards lie with correct arithmetic

This is the heart of the craft, and the part no demo touches, because it is not a software feature: it is a decision of yours that the software executes. Direct costs are easy, the invoice allocates them: material bought for that job belongs to that job. Indirect costs are everything else, and in service or plant engineering companies they are the majority: the building, the offices, administration, sales, the technical office, machinery, management. They have to be split between lines, and the way you split them decides which line looks profitable.

This is the sentence I want to stay with you: changing the allocation criterion changes the margin of every line without a single euro moving in the company. Nobody spent more, nobody sold less, and the ranking of the lines flips. If you have never run that test, run it: it is the most instructive half hour you will spend on your own numbers this year.

Contribution margin, and why it comes before full margin

There is an intermediate step that solves half the problem and that almost everyone skips in order to jump straight to the final margin. Before allocating anything, calculate contribution margin: revenue minus only the costs that exist because that sale exists. Material, subcontracting, freight, commission, technician hours if those hours are genuinely variable. No structure, no depreciation, no office salaries.

That number has a property the full margin does not: it depends on no debatable choice, so nobody can contest it in a meeting. And it is what you actually need for short term decisions: accept or refuse a job, grant or refuse a discount, choose between two orders when capacity will not cover both. A job with a positive contribution margin pays for a piece of your structure, even if at full margin it shows a loss. Refusing it because the dashboard shows it red is an expensive mistake, and I have seen it made often.

Full margin is for long term decisions: keep or close a line, raise prices structurally, decide where to invest. The two questions are different and want two different numbers. Good management control shows both, side by side, and makes clear which to use for which decision. A dashboard showing only full margin systematically pushes you to refuse work that was worth taking.

Drivers that hold up and drivers that lie

The driver is the quantity in proportion to which you split an indirect cost. The choice has to be made item by item, and the right question is always the same: what makes this cost grow? The most common criterion in Italy, splitting everything in proportion to revenue, is the most convenient and the worst: it says a line consumes structure in proportion to what it sells, which is almost never true. The service line invoices little and takes up the phone, the vans and half the spare parts store; manufacturing invoices a lot and mainly consumes machines, which are its own.

The rules I use, and that hold in most SMEs: machinery depreciation on machine hours; the building on square metres actually occupied, measured once with a floor plan and a pencil; the technical office on recorded design hours; service on interventions or technician hours; sales on the number of quotes issued, not on what was sold, because the cost is generated by the quote and not by the order; administration on the number of documents handled, which is the real engine of that work. Management, and only management, can be left on revenue or kept out of everything and read below line margin.

Two warnings worth more than the rules. First: every driver has to be a number the company already produces, or can produce with no extra work. A beautiful criterion that requires somebody to fill in a sheet every week lasts three months. Second: the fewer different criteria, the better. Five drivers applied consistently for three years are worth more than twenty perfect ones nobody can explain any more, because the value of management control lies in comparison across periods, and if you change the criteria every year you are no longer comparing anything.

What the calculation looks like in code

Allocation is simple arithmetic, and it is worth seeing written down because it makes obvious where the decision enters. This is an example in C# that compiles and runs: it computes contribution margin and then full margin, allocating each indirect cost on its driver.

using System;
using System.Collections.Generic;
using System.Linq;

public sealed record Linea(string Nome, decimal Ricavi, decimal CostiVariabili);

public sealed record CostoIndiretto(string Voce, decimal Importo, string Driver);

public static class ControlloDiGestione
{
    // Driver quantities per line: machine hours, square metres, quotes issued...
    public static IReadOnlyList<(string Linea, decimal Contribuzione, decimal MarginePieno)> Calcola(
        IReadOnlyList<Linea> linee,
        IReadOnlyList<CostoIndiretto> indiretti,
        IReadOnlyDictionary<string, IReadOnlyDictionary<string, decimal>> driver)
    {
        var risultato = new List<(string, decimal, decimal)>();

        foreach (var linea in linee)
        {
            var contribuzione = linea.Ricavi - linea.CostiVariabili;
            var quotaIndiretti = 0m;

            foreach (var costo in indiretti)
            {
                var quantita = driver[costo.Driver];
                var totaleDriver = quantita.Values.Sum();
                if (totaleDriver == 0m)
                {
                    continue;
                }

                quotaIndiretti += costo.Importo * quantita[linea.Nome] / totaleDriver;
            }

            risultato.Add((linea.Nome, contribuzione, contribuzione - quotaIndiretti));
        }

        return risultato;
    }
}

The interesting part is not the code, which is trivial: it is the driver dictionary. That dictionary is the only thing deciding the result, and it is a governance choice, not a technical parameter. When a vendor tells you their product calculates margins by line, there is one question to ask: who fills in that dictionary, with which numbers, and how often it is updated. Half the time the answer is that it is set up at go-live and then sits there for five years, which is exactly why your reconciliation gap grows every year without anyone touching anything.

One last check costs ten minutes and I always recommend it: the sum of the allocated shares must equal, to the cent, the total of indirect costs. It sounds obvious and it is not: in spreadsheets built in layers with fixed percentages, part of the cost almost always gets lost along the way, and the overall margin comes out higher than the truth. If your management control file does not have that check written at the bottom, add it today.

How far a spreadsheet takes you, and where that point is

Almost every Italian management control system is built in Excel, and that is not a failing: it is an excellent modelling tool, everyone knows it and it costs nothing extra. I have seen spreadsheets built better than forty thousand euro products. The question is not whether Excel is adequate but when it stops being so, because it stops silently: it does not break, it starts lying a little, and nobody notices.

The five conditions that break it

The number of manual transfers. While data comes from a single source with one export, the spreadsheet holds. From the third transfer on, meaning ERP plus time plus accounting, every close is a half day of craft work only one person can do. The cost is not the time: it is that this person becomes a single point of failure and cannot take holiday in peace.

The number of rows. A sheet with ten thousand transaction rows is manageable. At a hundred thousand it gets slow, at half a million it opens in a minute and nobody wants to touch it. That is the point where people start working on extracts, and extracts are out of date the next day.

How many people have to use it. A sheet with one author and one reader works. With five people editing, versions appear, and with versions trust ends: the moment two people in a meeting read two different numbers from the same indicator is the moment management control stopped being useful.

How far back you need to look. Comparing a customer's margin over three years means having three years of data on the same criteria and the same master records. In spreadsheets the criteria change and so do the master records, and historical comparison becomes impossible exactly when you need it, which is when you have to decide whether a trend is real.

Whether anyone outside finance has to see it. The moment line managers or sales people need to look at their own numbers, you need permissions, traceability and one shared version of the truth. That condition alone justifies moving to a system, even when the other four still hold.

My practical rule: if two of these five conditions are true, you are at the limit and have time to organise. If three or more are true, Excel is already costing you more than a system, except that you pay in people's hours and wrong decisions rather than in invoices. And I will add something no vendor will tell you: if none or one of them is true, stay where you are, fix the allocation criteria and postpone the spend by two years.

What you carry over and what you throw away

When you move to a system, do not throw the spreadsheet away: it is the best specification you have. It contains the real allocation criteria, the exceptions nobody ever wrote down and the shape of the reports the owner is used to. The first serious task of a management control project is reading that file with whoever maintains it and writing down the rules it contains, including the hand-typed cells that are worth more than whole formulas.

What you throw away are the manual corrections nobody remembers the reason for, almost always sitting at the bottom with names like adjustment or alignment. Every manual correction hides data arriving wrong from somewhere, and the project exists to fix that source, not to reproduce the patch. If the new system reimplements the patch, you have bought a more expensive spreadsheet.

Cost accounting, budgeting, dashboards: three different things with one name

The three functions have three prices and three returns, and the order in which you buy them decides whether they work. Here they are with what each actually covers, because quotes arrive with them mixed together and comparing two offers becomes impossible.

Cost accounting answers where the money went. It is the structure: cost centres, jobs, allocation criteria, margin by line and by customer. It is the least spectacular part, the one demos skip, and the only one that decides whether the rest tells the truth. It costs little in licences and a lot in analysis, because the real work is deciding the criteria, not configuring them.

Budgeting and forecasting answer where you are going. Budget by line and by centre, monthly variances between plan and actual, reforecast during the year when things change. It only makes sense on top of reliable actuals: without them it is an exercise in optimism repeated every quarter, and everyone in the company can tell, which is why budgeting has such a poor reputation in many companies.

Dashboards answer how you look at it. Indicators, trends, cuts by customer and product, access from your phone. It is the part you see in the demo and the part that costs least, because visualisation tools are mature and good ones cost a few tens of euro per user per month. It is also the part bought first almost every time, for an understandable reason: it is the only one you can see.

The sequence that works, and the one you see around

The sequence that works is: cost accounting, then budgeting, then dashboards. The sequence you see around is the opposite, and it produces a result I recognise from a distance: a very good looking dashboard, refreshed nightly, showing margins nobody really believes, which after six months only the person who bought it opens. The vendor delivered what was promised, the company spent thirty thousand euro, and the original question, which line earns, is still unanswered.

There is one honest exception to this rule, and it is when the dashboard exists to show people a number that already exists and is reliable but that nobody looks at because it sits in a file. In that case buying visualisation first makes sense, costs little and changes behaviour immediately. The whole difference is in the word reliable, and that is why measuring the gap comes before any purchase.

What management control software costs: product, ERP module or custom

The figures below are the ones I see in quotes to Italian SMEs between five and thirty million in revenue. They are not price lists: they are the order of magnitude to compare what arrives on your desk with, and they mainly help you recognise the quote that is low because it is incomplete.

The module of the ERP you already own

Almost every Italian ERP has a cost accounting module, and in many companies it has already been paid for and never switched on. Turning it on costs between six and thirty five thousand euro, almost all configuration and consulting days rather than licence. It is the route I suggest evaluating first, for three reasons: the data is already inside, there is no transfer to build, and you already know the vendor.

The limit is rigidity. ERP cost accounting modules are often built on a classic cost centre model and struggle with mixed structures, for example business lines sharing people and jobs crossing several centres. If your way of working fits, it is by far the best option for value. If it does not fit, forcing it costs more than changing route, and you find out after a year.

The specialised product

These are the vertical management control and planning products sold by subscription. The bands I see run from one hundred and fifty to nine hundred euro a month, depending on modules and users, plus a setup fee between ten and fifty thousand euro covering analysis, connections to your systems and training. Setup is the item quotes compress to look competitive, and the item that later grows, because connections to the ERP are always more laborious than expected.

They are excellent products when your cost structure resembles the one they were designed for, and almost all of them were designed for a company with cost centres, an annual budget and quarterly reforecasts. The two questions to ask are always the same: what it costs to connect to the ERP I have, by name and version, and what happens to my data if I stop after two years.

Custom

A system built around your way of measuring starts at thirty thousand euro for the core, meaning importing data from your sources, an allocation engine with your drivers, margins by line, customer and job, and the reports you actually use. It reaches one hundred and fifty thousand with budgeting, reforecasting, group consolidation and simulations. Add fifteen to twenty per cent a year of maintenance, which is not extortion: it is what keeps the system alive when you change ERP, open a new line or your accountant changes a criterion.

It makes sense in three cases, and outside those three it is nearly always waste. When your way of measuring is your competitive advantage, meaning you can calculate something competitors cannot. When sources are many and varied, typically an ERP plus a time recording system plus a configurator plus departmental spreadsheets, and no product joins them without customisation costing as much as building. And when the ERP you have works and should be kept, building around it rather than replacing it, which is the most frequent and most underestimated situation. The full reasoning between the two routes, in numbers, is in business management software, off the shelf or custom.

The threshold, and the variable that is not economic

The practical rule I use is this: below twenty five thousand euro a year of total expected spend, subscriptions and customisation included, the product or the ERP module almost always wins. Above that, redo the calculation, because at that level the subscription over five years reaches the cost of building and the difference is all maintenance, which you pay either way. In the chart the break-even falls around year four.

At that point one variable matters that is not economic: how much your company will change in five years. If you expect to open a new line, buy a company or enter a market with different cost rules, the flexibility of your own system is worth the premium, because every structural change in a product is a customisation request with its own lead time. If your structure has been stable for ten years, the product is the rational choice and custom is a luxury. For the general reasoning on building rather than buying, the starting point is custom software development.

The questions to ask before signing, and the test that dismantles demos

Demos of these products are all convincing, because they show clean data on an invented company that resembles yours just enough. The way to come out with real information is to bring your own hard cases and watch how the person in front of you reacts. It takes three weeks, and it is worth more than any comparison of feature sheets.

Week one: prepare your five cases

Write on one page the five cases your management control has to handle, taken from your real life. Here are the ones that in my experience dismantle the most quotes. The technician who in one day works on three jobs across two lines: how does their cost enter. The job lasting eight months across two financial years: how is margin recognised in the months in between. The customer return arriving three months after the sale: which month does it hit. The agent's commission paid on cash collected rather than invoiced: how is it aligned to margin. And the leased machine used by two lines: where does the lease payment land.

These five cases have a useful property: they are not solved by a feature, they are solved by a choice of criterion. Someone who knows the craft asks you questions and then offers two alternatives, explaining what changes. Someone who only knows the product shows you a screen.

Week two: the same questions for everyone

Ask all vendors in the same order, so the answers compare. What does year three cost in total, with the people and modules you will have in three years. What does it cost to connect the ERP I have, by name and version, and who does it. How many analysis days are included and what happens if more are needed. Who decides the allocation criteria, and when they change can I change them or does it take a support request. How many days does a company like mine take to close the month, measured on a real customer. What happens if I stop after two years, in what format does my data come out and what does the extraction cost. And can I speak to two companies like mine, without the sales person present.

The most informative moment is when you ask for something off script and watch the reaction. Someone who knows the product tells you immediately that it cannot be done and how to work around it. Someone who does not know it promises, and then files a development request after you sign.

Week three: the test on a closed month

This is the test I always recommend and almost nobody runs. Take a month already closed and reconciled, give the vendor the raw data for that month and ask them to produce margin by line. Then compare with what you know to be true. It is not a functionality test, it is a method test: you watch how many questions they ask before answering, which missing data they discover, and how long it takes. If the number ties, you have found your vendor. If it does not tie, you have found where the problem is before paying for it, and the problem is almost never the product: it is data nobody in the company records.

The three things to fix before buying anything

There are three jobs that cost little, take a few weeks and without which any management control software delivers half of what it could: closing the chart of accounts onto destinations, deciding how people's hours are recorded, and choosing the five numbers you will discuss. They have to be done first, not after, because afterwards the project has started and the criteria get decided by whoever configures it, meaning a consultant who does not know your company.

A chart of accounts that talks to destinations. Every cost account in the statutory accounts needs a destination: direct to a job, attributable to a line through a driver, or pure structure. Three categories, no more, and the exercise consists of going through the accounts with movements in the last year and assigning them. It takes two or three days, is done with your accountant or whoever keeps the books, and delivers half the result on its own, because that is where you discover which costs had never entered cost accounting at all.

People's hours. In service, plant engineering and software companies, cost is almost entirely people's hours, so the quality of management control depends on how they are recorded. You do not need a complicated system: you need each person to attribute their day to jobs or activities, in a form that takes less than a minute, and for the total of attributed hours to match the hours paid. That reconciliation check is everything, because without it the missing hours end up in a pot that inflates structure and flatters jobs.

The five numbers you will discuss. Choose five indicators and stop there for a year. In most SMEs these work: contribution margin by line, full margin by line, the top twenty customers by margin rather than by revenue, the order book with expected margin, and average days to collect. Five numbers looked at every month change a company; twenty indicators looked at once change nothing, and the second time nobody looks.

One more way to start, which is not a job but a choice: begin with one line, the most different from the others, and run it for three months before extending. Companies starting on everything at once reach month three with half the data to fix and go back to the spreadsheet. The second attempt is much harder, because by then everyone in the company knows that thing did not work.

If your total across the five cost items was under twenty five thousand euro a year, here is your most urgent problem: it is these three jobs, not software. Do them, remeasure the gap after six months, and only then look at products.

Where to start

You start with a small first release, because a management control system is not an IT project: it is a project about agreeing how things are measured, and agreement projects succeed when they put few things on the table at a time. The first release that almost always works is this. Revenue and direct costs by line and by job, taken from the ERP without adjustments. Indirect costs allocated on five drivers, not twenty. Contribution margin and full margin, side by side. One report, delivered by the fifth day of the month, showing the lines, the top twenty customers by margin and the comparison with the same month last year. Nothing else.

With that scope you are live in a few weeks with a product or the ERP module, in two or three months if you build custom. From then on you can remeasure the reconciliation gap every quarter, comparing declared actuals with the updated accounting position. If it falls, the project is working. If it does not, the problem is in the criteria or in a data source, and no extra feature will fix it. Everything else, budget by centre, reforecasting, dashboards for managers, consolidation, gets built on top of a number you can trust. It also costs less, because by then you know what you actually need.

The owner with the two lines, in the end, bought nothing for the first three months. He redid the allocation using technician hours instead of revenue, discovered service earned three times what he thought, raised installation prices by four per cent and hired two technicians instead of four installers. The software came later, and cost less than what he had been about to buy, because by then he knew exactly what it had to do.

If you are doing this calculation now and want to know which side of the threshold you are on before spending anything, send me two pages: how your business lines are organised and which systems the numbers come out of today, plus the two numbers from the test, the reconciliation gap on the last closed year and the total of the five cost items. In half an hour I will tell you whether yours is a criteria problem, an ERP module problem or a custom problem. Where it is an organisational problem I will tell you that too, because a customer who buys the wrong thing comes back angry. You can get in touch to do that calculation together, or read the general reasoning on building rather than buying in custom software development.

If you are still framing the problem, three readings that sit around this one. Cost control when you work to order, the same problem seen from the projects office, is in job costing software. The real times and costs coming off the shop floor, that is, the source of the production data, are in production management software. And if your most urgent problem is the value of what sits in stock, the starting point is warehouse management software.