Job costing software: where the margin goes
Matteo Migliore

Matteo Migliore is an entrepreneur and software architect with over 27 years of experience developing .NET-based solutions and evolving enterprise-grade application architectures.

He has led enterprise projects, trained hundreds of developers, and helped companies of all sizes simplify complexity by turning software into profit for their business.

The job closed five months ago. The customer paid, the commissioning went well, and everyone in the company remembers it as a good piece of work. Then the accountant closes the year, the margin is half what was forecast, and nobody can say which of the eleven jobs of the year ate it. Suspicion always falls on the same one, the one that ran long, but it is only suspicion: the numbers to prove it do not exist.

If your company works project by project, you know this scene. This article gives you the real cost of not knowing your margin while the work is still open, the four numbers a job costing software must give you and how quickly, the exact point where these projects fail, the real price brackets between a subscription product and a custom system, and the threshold in euros where the arithmetic flips.

I have been writing software for twenty six years and I have spent much of that time inside companies that work to order: steel fabricators, contractors, automation firms, special machine builders, engineering practices. I have seen companies turning over eight million euros costing their jobs on a spreadsheet only one person ever opened, and companies turning over two million buying a thirty thousand euro a year project management platform and using it as a task list.

What I have learned, and what no vendor will tell you during the demo, is this: in job costing the number that matters is not the final cost, it is the margin at completion: what you will make on this job if the rest of it goes the way it is going now. The final cost is a post mortem. It tells you what the patient died of, and it always arrives too late for you to do anything about it. If a system does not give you margin at completion while the job is open, you have bought an archive.

What job costing software is, and why the system you already have will not give it to you

Job costing software holds four things together: the quotation you sold, the costs you are consuming to deliver it, the real progress of the work, and the link to invoicing. It answers a single question, but continuously: on this job, today, am I making money or losing it?

You will find it under several names, and the confusion helps the selling. The international term is job costing. In Italy it goes by industrial accounting, analytical accounting, management control by project, contract management, site management. There is also a nearby category that is something else entirely, project management, which organises tasks and people but knows nothing about money.

The difference between knowing what you invoiced and knowing what you earned

The accounting system you use for invoices, orders and bookkeeping thinks in documents and in periods. It can tell you what you invoiced in June, to whom, and on what terms. It is excellent at that and has no intention of doing anything else.

It cannot answer any of these: what has job 2026-014 cost so far, including the engineering office hours; how many hours you sold on that job and how many you have already burned; how much material was bought for that job rather than another; what margin is left if the installation takes the three weeks still outstanding instead of the two you quoted.

This is not a fault in your accounting system and there is no point asking for a module. It is a difference of subject: general accounting thinks by financial year, job accounting thinks by object, and the object lives across two financial years. A job opened in November and closed in March never appears in full in either year, and that is exactly the case where the margin disappears without anyone noticing.

The three kinds of company that look for it, and look for different things

Companies that manufacture to order. Fabricators, special machine builders, automation firms, machining to customer drawings. Here the main problem is workshop hours and engineering office hours, which are the largest cost line and the least measured. The quote is built on an estimate of hours, the invoice goes out at the agreed price, and in between nobody compares the two until it is too late.

Companies that install on site. Electrical and mechanical contractors, specialist construction, industrial installation. Here the problems are travel, material that leaves the warehouse and never comes back, and above all variations: the customer asks for a change on site, the foreman says fine, and that change enters no document until there is an argument at the end.

Companies that sell projects and hours. Engineering practices, consultancies, agencies, software houses. Here cost is almost entirely people, so margin is a direct function of hours, and the fixed price contract is where the money is lost. The real question is not how many hours we did, it is what we are effectively selling the hour for on that contract against what it costs.

How far a spreadsheet takes you, and where it breaks

The spreadsheet is not the enemy, and anyone telling you to throw it away immediately is selling you something. It works perfectly well up to a point, and that point is recognisable from three precise signals.

First: only one person updates the file, and when that person is on holiday the numbers stop. Second: the data going into it is retyped from somewhere else, from timesheets, delivery notes and supplier invoices, and that retyping takes more than half a day a week. Third, and most important: when somebody asks how a job is going, the answer arrives the next day.

If you have two of those three signals, the spreadsheet has stopped giving you information and started giving you work. Below twenty jobs open at once and with a two person engineering office, it is often still better to keep it and fix the method rather than the software. Above that, no.

The real cost of not knowing your margin while the job is open

The five margin leaks that appear when job costs are not measured in real time: unallocated hours, unbilled variations, unassigned purchases, quotes built on a false average and loss making jobs discovered only at the end

Before looking at any product, do this calculation. It serves two purposes: it tells you whether the problem justifies the spend, and it gives you an answer when the vendor asks what budget you have in mind. There are five items and your finance team can estimate them in an afternoon.

The five items that never reach the accounts

Hours that never land on the right job. In companies collecting timesheets on paper or at month end, between five and twelve per cent of hours worked end up on the wrong job, on a generic line such as sundry work, or nowhere at all. With twenty people in production at a fully loaded thirty euros an hour, five per cent is roughly fifty thousand euros a year of cost that exists but no job carries. The damage is not the cost, which you pay anyway: it is that every one of your job margins is overstated, so next year's quotes will be built on inflated numbers.

Variations that never become invoices. This is the most painful item because it is pure margin. The customer asks for a change, somebody carries it out, and the request stays in a phone call or a message. In companies without a variation register attached to the job, between three and six per cent of the value of work is delivered and never billed. On two million euros of contracts that is sixty to a hundred and twenty thousand euros, with no cost to deduct because the work is already done.

Purchases that fall into the general pot. Material ordered for job 14 and used on job 17, supplier invoices booked to general accounting with no job, hire and travel charged to a generic cost centre. In a company buying in forty per cent of its revenue, even three per cent of wrongly assigned purchases moves the margin on an average job by two or three points, which is often the whole margin.

Quotes built on an average that does not exist. This one is invisible and costs more than all the others. If you do not know your real margin by type of work, you price everything at the same percentage. The result is that you sell the easy jobs too cheap and win them every time, and you sell the difficult ones too cheap and win those too: your order book fills up on its own with work that does not pay. I have seen companies discover, the first time they measured properly, that a product line they thought of as their engine had been running at a negative margin for three years.

Loss making jobs discovered at the end. A job that is going badly gives signals within the first third of the work, almost always. If the system tells you at that point you can do something: renegotiate, change the installation method, stop work outside the contract, or simply decide to lose less. If you find out at the end you can do nothing. The difference between intervening at thirty per cent and discovering it at a hundred is typically between a third and half of the loss.

How to run the calculation on your own company

Take the three largest jobs of last year, the closed ones. For each put four numbers on a sheet: the price sold, the cost you forecast, the cost your finance team can reconstruct today, and the hours people remember spending. Then ask your production manager, without the sheet in front of him, what he thinks the margin on each was.

The distance between his answer and the reconstructed number is your problem, measured in euros. In the companies where I have run this exercise the gap almost always sits between six and fifteen margin points. In a two to three million euro company working to order, the five items together usually total between forty and a hundred and twenty thousand euros a year. That is the number to hold in your hand when somebody quotes you.

The four numbers job costing software must give you, and when

Product demos last an hour and show thirty features. The ones that decide whether the system will change your life are four, and in a demo they are the least impressive because they are tables of numbers.

1. Margin at completion, refreshed weekly

This is the central number and almost nobody asks for it during selection. Margin at completion is calculated like this: take the total forecast revenue for the job, including approved variations, and subtract costs already incurred plus the costs you estimate from here to the end. It is not a partial actual, which is a photograph of the past: it is a forecast that updates when something changes.

The question to put to the vendor is precise: how does the estimate of costs to completion get updated, who updates it and how often. If the answer is that the system calculates it automatically in proportion to progress, the number is useless: that assumes the remaining work will cost what the finished work cost, which is almost never true, because the surprises live in installation and commissioning, that is to say at the end.

The good answer is that there is a place where the project manager, once a week, in five minutes, revises the remaining estimates on the few lines that matter, and the system recalculates. Five minutes a week per job is sustainable. An hour a month is not, because nobody finds it.

2. Hours sold against hours consumed, split by phase

The total is useless: by the time it is out of range it is too late. What you need is the split by phase, and the phases must be few, between four and seven. For a special machine they might be design, procurement, mechanical build, wiring, software, works testing, commissioning on the customer site.

With that split, problems appear early and appear for what they are. Design overrunning by forty per cent means either the quote was optimistic or the customer changed his mind, and those are two different trades. Commissioning overrunning means works testing was done badly, and that is the most expensive lesson a project business can learn: every hour saved on works testing costs three to five on site.

3. Physical progress against financial progress

These are two different numbers that almost everybody conflates, and the distance between them is the most reliable alarm signal there is. Financial progress is how much of the budget you have spent. Physical progress is how much work you have actually finished, measured crudely but honestly: how many drawings issued out of how many planned, how many panels wired out of the total, how many metres of line installed.

If you have spent sixty per cent of the budget and finished sixty per cent of the work, you are on track. If you have spent sixty and finished forty, the job is already lost and there are still months to run. Measuring physical progress needs no sophisticated system: it needs somebody to put an honest percentage down once a week, and for that percentage not to be used to judge people, otherwise it is always ninety per cent.

4. Cash on the job

The fourth number is the one owners look at first once they finally have it: what have I collected on this job and what have I already paid out to deliver it. A job can carry an excellent margin and still sink you, if you pay suppliers at thirty days and collect stage payments at ninety.

The system must link the job to its stage applications, to invoices issued and to supplier invoices. You do not need full treasury management: you need to know, across open jobs, how much of your capital is tied up in them. In project businesses this number is often larger than the year's profit, and nobody knows it.

What they will sell you and what you will not use

Gantt charts with dependencies across hundreds of tasks: they get updated for two months and then freeze, because nobody in a thirty person company has time to maintain a plan at that level of detail. Automatic resource scheduling with optimisation algorithms: it works in a factory with repeating cycles, not where every job is different. A customer portal with live access to progress: if your progress figures are not accurate, opening them to the customer creates problems rather than solving them. Predictive margin analytics: you do not yet have three years of clean data, and without that they are random numbers.

All of these can make sense, but later. Putting them in the first release stretches the rollout by months and moves attention away from the only thing that has to work immediately, which is the clean collection of hours and costs. It is the same dynamic I described writing about maintenance management software, where the piece that decides everything is the job sheet completed on site and not the scheduling.

The piece that decides everything: how hours and costs get in

The six conditions that make job time recording genuinely usable, set against the design mistakes that get it abandoned

You can have the finest dashboard on the market: if the data going into it arrives on the fifteenth of the following month and is invented, the dashboard lies very elegantly. In the job costing projects I have watched fail, the breaking point was always here, never in the analysis.

Why timesheets always arrive late and always wrong

Because they are designed for finance and completed by production. Finance wants hours split by job, phase and activity type, with a reason code. The fitter, at five in the afternoon, wants to go home. Between those two needs the second always wins, and the way it wins is completion from memory: on Friday somebody reconstructs the week, and in the reconstruction all the hours go on the biggest job, because that is the one you remember.

The result is not missing data, which would be honest and visible. It is false data that looks true, and on which you then build your quotes. When I measure data capture in a company, the signal I look at is one: how many days pass on average between the work being done and it being recorded. Above three days, the data is reconstructed from memory. Above seven, it is a narrative.

The six conditions for recording to actually happen

It happens where the work happens, not where the computer is. In the workshop a badge terminal or a wall mounted tablet, on site the phone the technician already has in his pocket. If recording means walking to the office, it will be done from memory.

It happens the same day, and the system makes that visible. A simple indicator showing who has not yet recorded yesterday is worth more than any amount of chasing, provided the workshop supervisor looks at it and not the finance department.

You pick from a short list. The technician should see the three or four jobs he is working on this period, not every open job. If the list is long, people pick the first entry.

Phases are few and carry names used in the building. Not accounting cost centres: the words people actually say. If the workshop says wiring, the entry is called wiring, not indirect electromechanical activity.

It works with no connection. On site and in many workshops there is no signal. The application must behave identically and sync afterwards, without the user having to think about it.

Closing the day takes under a minute. Timed, not estimated. If it takes three minutes per person, across twenty people that is twenty hours a year of pure friction, and friction always produces the same result: reconstruction from memory on Friday.

The test that beats ten demos

Take the person in production who complains the most, hand them the system with no explanation and time three real days. Not a demo: three real days, with their interruptions and their surprises. Then look at what was recorded and compare it against what was actually done.

If in three days they recorded without help and the data matches, the system will work. If they had to call somebody, or if everything landed on a single job, you have just saved forty thousand euros. This test costs half a day and no vendor proposes it spontaneously: propose it yourself, and the way they react to the proposal is already half the answer.

Quote, budget, variations: the chain always breaks at the same point

There is a chain that should be continuous and that in most companies is three separate pieces speaking different languages. The quote is built by sales with the engineering office, often on a spreadsheet of their own. The job budget, where it exists, is rebuilt by somebody else with different lines. The final cost is reconstructed by finance using accounting lines. Three different ways of dividing the same money, and therefore three numbers that cannot be compared.

The quote that never becomes a budget

The rule is simple and rarely respected: the lines you quote with must be the lines you cost with. If the quote says three hundred hours of design and the actuals come back by cost centre, you will never know whether you estimated badly or worked badly, and those are two problems with opposite remedies.

When I take a company through this, the first thing we do is not choose software: it is to put the quote for the last important job and its final cost on the same table and try to line them up. Nine times out of ten it cannot be done. That day, without having bought anything, the company has already understood what its problem is.

The variation nobody records

Variations are where margin dies quietly. The mechanism is always the same: the customer asks for a change verbally, on site or by phone; the person receiving it is a technician, not a salesperson; the technician has no way to record it in thirty seconds; the change is carried out because work has to go on; at the end somebody tries to bill it and the customer says it was never quantified.

The fix is not organisational, it is about friction. Telling technicians to fill in a form does not work, because they never will on site. What works is giving them a way to raise a variation request in thirty seconds, with a photograph and two lines, from whoever receives it; then somebody in the office quantifies it and sends it to the customer. All the value is in the first part, the thirty seconds. Companies that introduce only this, and nothing else, typically recover half of their unbilled variations within six months.

How the loop closes

The loop closes when actuals feed back into quotes. That is, when whoever quotes the next similar machine starts from the real hours of the last one, rather than from what was estimated last time. This is the real return on a job costing system, and it arrives in year two, not year one: the first year collects clean data, the second quotes better.

It is worth saying plainly because it changes the expectations to write into the plan: in year one job costing software saves you money on recovery, that is variations billed and jobs stopped in time. From year two it makes you money on quoting, and that second effect is larger than the first.

Subscription product or custom system: where the threshold sits

Cumulative five year cost of subscription job costing software compared with a custom system, showing the break-even point around year three

Let me start with the conclusion, counterintuitive coming from somebody who builds custom software: for most project businesses the subscription product is the right choice. If the way you run jobs looks like the way everybody else in your sector runs them, paying somebody to rebuild it from scratch is waste.

What the product actually gives you

It gives you time. A well configured product is live in six to ten weeks, against four to six months for a custom project, and during those weeks you are already collecting the clean data that is the real prize. It also gives you the fact that somebody else has already made the mistakes: the time entry screens of mature products have been rewritten four times in ten years on the back of complaints from thousands of workers, and that is an asset your custom supplier does not have.

What the product does not give you is the part that makes you different. If your company has a particular way of breaking down jobs, or a close link to machinery and systems you already own, that is where the product will ask you to change how you work, or will sell you custom development by the day which, added up over the years, exceeds the cost of building your own without giving you ownership of anything.

The threshold calculation, line by line

The calculation is on total annual spend, not on the subscription. Four lines: the subscriptions, and here the decisive question is who counts as a user, because if the workers clocking in count too the number doubles; the onboarding spread over the expected life; the custom development you need every year, the line everybody forgets; and the hours you still spend by hand because the system does not cover a piece.

The practical threshold sits around thirty thousand euros a year of total spend: below it the subscription product almost always wins; above it custom starts to pay for itself within three or four years. It comes from simple arithmetic: thirty thousand a year for five years is a hundred and fifty thousand euros, more than it costs to build a well scoped job costing system, including its evolution and its maintenance.

The general reasoning behind this choice, valid for any business system, is in custom software development. In job costing there is one important difference: the part that gets personalised most is the structure of phases and cost lines, and that is precisely what standard products make hardest to change, because it is their core.

The three cases where custom pays even below the threshold

When the way you run jobs is why customers choose you. If you win tenders because you can commit to times and prices others cannot, that mechanism is your competitive advantage and does not belong inside a tool everybody has.

When you must connect to something of your own. Machines producing data, a product configurator built in house, a plant supervision system. Closed products reach a standard interface and stop, and from there you pay sole supplier prices for custom work. I wrote about this pattern in connecting software to the machines themselves.

When many people use the system lightly. Per user pricing is designed for companies with few intensive users. If you have forty workers recording two minutes a day, paying for them as full users takes you over the threshold quickly, and negotiating this single point matters more than anything else in the deal.

What job costing software costs: the real brackets

These are orders of magnitude for the Italian market, for companies between fifteen and a hundred people. They tell you whether a proposal is in range, they are not a budget.

The subscription product

Job costing systems sold on subscription typically run forty to a hundred and twenty euros per user per month, with a sharp difference between a full user and a user who only records hours, where the second costs a fraction. Onboarding runs five to twenty five thousand euros one off, covering configuration, loading master data, migrating history if you want it, and training.

The question to ask at the first meeting, before any other, is who counts as a user and how the number changes if you hire ten more people in production next year. The second is whether there is a contractual cap on annual subscription increases. Without those two answers in writing, what you are holding is not a quotation.

Custom, entry bracket: twenty to forty five thousand euros

Time recording from workshop and site, job register with phases and budgets, purchase allocation, margin at completion, four or five management reports, export to accounting. Three to five months. This is the scope that solves eighty per cent of the problem in most companies, and my recommendation is almost always to stop here in the first release.

Mid bracket: forty five to ninety thousand euros

Add the estimating tool linked to the budget, the variation register with customer approval, coarse resource planning, job stores, stage applications and two way integration with the accounting system. Six to ten months. You get there best in successive steps, putting the entry bracket into production and growing on top of what already works.

Upper bracket: above ninety thousand euros

Multiple sites or legal entities, a product configurator linked to quoting, data collected directly from machines, a customer portal, margin forecasting from history. At this point you are beyond job costing and building the company's operating system, and it only makes sense once clean data has existed for a couple of years.

What moves the price inside each bracket

The number of integrations. Every connection to an existing system is worth three to fifteen days: a modern system with documented interfaces sits at the bottom, a twenty year old system whose tables you read directly sits at the top. It is the line that most often blows quotations, and I wrote about it in detail in what really breaks when two systems have to talk.

How much history you want to carry over. Migrating three years of closed jobs from a spreadsheet with inconsistent lines costs more than anyone quotes, because it is reconciliation work rather than technical work. In most cases it is better to start from zero on open jobs and leave the history where it is, readable.

How many people have to change habits. This is the real multiplier and it never appears in quotations. A system touching three people in the office goes live in weeks. A system touching forty people in production needs an adoption plan, and that plan is worth fifteen to twenty five per cent of the project.

If you are weighing the build against hiring the people to do it in house, the real arithmetic is in what a development team actually costs. And it is worth knowing what you end up owning: a process running on software you own is an asset on the balance sheet, while a subscription stays a cost.

Integration with accounting: where the boundary runs

The boundary between job costing software and the accounting system, showing the three points where the two must exchange data and the direction of each exchange

This is the question I get most often and it is usually asked the wrong way round. It is not whether to integrate, but where the boundary runs and in which direction the data flows. Getting the boundary wrong is the most efficient way to spend twice as much.

The three contact points, and who is in charge of each

Master data. Customers, suppliers and items must have a single home, and that home is the accounting system, because that is where they are born for tax reasons. The job costing system reads them and does not write them. Every time I have seen two customer lists maintained in parallel, a year later they were different and nobody knew which was right.

Purchases. The purchase order and supplier invoice live in the accounting system, but the job they belong to must be chosen when ordering, not when the invoice is booked. It sounds trivial and it changes everything: if finance assigns the job two months later by reading a description, the data is a guess. The job field belongs on the purchase order, and whoever orders fills it in because they know why they are ordering.

Revenue. Stage applications and sales invoices are born in the job and end up in the accounting system, not the other way round. The job costing system proposes what has been earned, a person checks it, and the accounting system issues. This direction is almost always the opposite of what accounting vendors propose, since they want to remain the centre of everything.

The one way bridge, and why it is nearly always enough

You do not need a complete two way real time integration, which is the most expensive and most fragile option available. You need a bridge that once a day carries master data one way and transactions the other, with a rejection log somebody looks at every morning. It costs a fraction, takes a few days and covers almost all the value.

This way of approaching integration, in pieces that stand on their own rather than as one large connection, is the same one I use in modernising the software a company already has. It has a useful side effect too: if your accounting vendor changes version, or if you decide to change accounting system, a one way bridge is rewritten in days, a two way integration in months.

The question nobody asks

Ask the vendor: if in three years I decide to change this system, what do I take with me and in what format. The good answer describes a complete export including hours line by line, allocated costs, attachments and variation photographs. The bad answer is of course, the data is yours, and nothing more. Photographs and attachments are the clause that fails most often: the tables come out and the documents stay in, which is the elegant way of keeping you.

How to choose in two weeks without calling five vendors

Calling five vendors is the surest way to lose two months and end up with five proposals you cannot compare. The useful work happens first, and it happens in house.

Week one: look at how you actually work

Run the five item calculation described above on the three largest jobs of last year. You need a number, not a feeling.

Spend a full day in the workshop or on site, without an obvious notebook open, watching how people record what they do today. Anyone who has never done this discovers more in half a day than meetings produce in a year.

Ask whoever reconstructs the actuals which information is always missing. That list is your specification, written for free, and it is worth more than any requirements document.

Write a single page, not thirty, on what must happen from the moment you win a job to the moment you invoice it. If you cannot get it onto one page, the problem is not the software: it is that the process is not clear even to you, and no system will clarify it on your behalf.

Decide the phases. Four to seven, with the names used in the building. This is the most important decision in the whole project and you can take it now, free, with a blank sheet.

Week two: test, do not watch demos

Two candidates, not five. One subscription and, if the calculation puts you above the threshold, one custom, so you are comparing two routes rather than two near identical products.

Run the three real days test with the most sceptical person in production, stopwatch in hand. That is the test that decides.

Ask them to load one of your real jobs, with its quotation and its actual costs, and show you margin at completion. Not a sample job: yours, with its mess. The difference between the two is the whole truth about the product.

Ask for the name of a customer in your sector and of your size, and telephone them. Five questions: how long the rollout really took, how many people stopped using it, what they had to change in the way they work, what they pay now against year one, what they would do differently.

Ask what happens if you change the phase structure in a year, because you will. If the answer is that it needs chargeable work by the vendor, add it to the threshold calculation.

Three things to fix before buying anything

There are three pieces of work that cost nothing in licences and that, if you skip them, make any software useless. In order of importance.

Decide the phases and use them everywhere. The same four to seven phases must appear in the quotation, in the budget, in time recording and in the actuals. As long as sales quotes as a lump sum, production records by department and finance costs by cost centre, no system will be able to compare those numbers, because they are not comparable even in principle.

Establish the true hourly cost, and only one. Not the contractual wage: the fully loaded company cost, including social charges, holidays, training, equipment and a share of overhead. In companies measuring for the first time the real hourly cost is usually forty to seventy per cent higher than the owner had in mind. A margin calculated on the wrong cost is a wrong margin, however handsome the dashboard showing it.

Establish who the project manager is and what they may decide. A job costing system produces numbers for somebody. If that somebody does not exist, or exists but cannot stop work or call the customer about a variation, the numbers will be read only by the owner, once a month, to get annoyed. The value of these systems is realised when a person with a name and a mandate can change something within the week.

These three take two or three weeks of internal work and are done well with a sheet of paper. They are also the best way to find out whether you really need software: some companies, having fixed them, discover the spreadsheet kept properly will do for another year. That is an excellent outcome, and no vendor will tell you about it.

Where to start

A job costing system is not an IT project, it is a measurement project, and measurement projects succeed when they start small and honest. The first release that nearly always works is this: jobs with their phases, hours recorded the same day by the people doing them, purchases allocated at the point of ordering, and one report, margin at completion, that the project manager updates for five minutes a week. Nothing else.

With that scope you are in production in a few weeks with a product, in three or four months building custom, and from that moment you are collecting real data. Everything else, the linked estimating tool, variations with customer approval, planning, stage applications, gets built on top of data that exists, and costs less because by then you know what you actually need.

If you are running this calculation now and want to know which side of the threshold you are on before spending anything, send me two pages: how a job is born and closed in your company today, and the number that came out of the five item calculation. In half an hour I will tell you whether yours is a product problem, a custom problem or a method problem, and where it is a method problem I will say so, because a customer who buys the wrong thing comes back angry.

Frequently asked questions

There are two routes with two different economics. Subscription products in Italy typically run forty to a hundred and twenty euros per user per month, with a sharp difference between a full user and somebody who only records hours, who costs a fraction, plus a one off onboarding of five to twenty five thousand euros for configuration, loading master data and training. The decisive question at the first meeting is who counts as a user and how the number changes if you hire ten more people in production. Custom software has three brackets: twenty to forty five thousand euros for time recording from workshop and site, a job register with phases and budgets, purchase allocation, margin at completion and export to accounting, in three to five months; forty five to ninety thousand with an estimating tool linked to the budget, a variation register, job stores and two way integration; above ninety thousand for multiple sites, a product configurator, data collected from machines and a customer portal. Annual maintenance on a custom project runs fifteen to twenty per cent of the initial cost and carries no per user fee.

For most project businesses the subscription product is the right choice, and that comes from somebody who builds custom software: if the way you run jobs looks like the way everybody else in your sector runs them, paying to rebuild it from scratch is waste. The practical threshold sits around thirty thousand euros a year of total spend, counting subscriptions, amortised onboarding, custom development and the hours still done by hand: below it the product almost always wins, above it custom pays for itself in three or four years. Three cases justify custom even below the threshold: when the way you run jobs is why customers choose you, when you must connect to something of your own such as machines producing data or an in house configurator, and when many people use the system lightly and per user pricing becomes disproportionate.

It is a difference of subject, not of features. The accounting system thinks in documents and in periods: it tells you what you invoiced in June, to whom and on what terms. Job costing software thinks by object: what job 2026-014 has cost so far including engineering office hours, how many hours you sold and how many you consumed, what material was bought for that job rather than another, what margin is left if installation takes the three weeks outstanding instead of the two you quoted. This is not a fault in your accounting system and there is no point asking for a module: general accounting thinks by financial year, job accounting thinks by object, and the object lives across two financial years. A job opened in November and closed in March never appears in full in either year, and that is exactly where margin disappears unnoticed.

Margin at completion is total forecast revenue for the job, including approved variations, less costs already incurred plus estimated costs from here to the end. It is not a photograph of the past like a partial actual: it is a forecast that updates when something changes. It matters more because the final cost is a post mortem, it tells you what the patient died of and arrives when you can no longer do anything. A job going badly gives signals within the first third of the work almost always, and the difference between intervening at thirty per cent and discovering it at a hundred is typically between a third and half of the loss. The question to put to the vendor is how the estimate of costs to completion gets updated, who updates it and how often: if the system calculates it automatically in proportion to progress the number is useless, because it assumes the remaining work will cost what the finished work cost, and the surprises live in installation and commissioning, that is to say at the end.

Far more than zero, spread so that it appears on no line of the accounts. There are five items. Hours that never land on the right job, five to twelve per cent of the total in companies collecting timesheets at month end: across twenty people at thirty euros an hour that is roughly fifty thousand euros a year of cost no job carries, and the real damage is that every margin is overstated and quotes get built on false numbers. Variations delivered and never invoiced, three to six per cent of the value of work, which on two million euros of contracts is sixty to a hundred and twenty thousand euros of pure margin. Purchases charged to the general pot. Quotes built on an average that does not exist, so the order book fills up on its own with work that does not pay. And loss making jobs discovered at the end. In a two to three million euro project business the total is usually between forty and a hundred and twenty thousand euros a year.

Because timesheets are designed for finance and completed by production. Finance wants hours split by job, phase and activity type with a reason code, while the person on the floor at five in the afternoon wants to go home, and the second need always wins: on Friday the week is reconstructed from memory and all the hours land on the biggest job. The result is not missing data, which would be honest and visible, but false data that looks true and on which you then build your quotes. There is one signal to measure: how many days pass between the work being done and it being recorded. Above three days the data is reconstructed from memory, above seven it is a narrative. Six conditions make recording workable: it happens where the work happens rather than where the computer is, it happens the same day and the system makes that visible to whoever runs the workshop, you pick from a short list of three or four jobs, phases are few and carry the names used in the building, it works with no connection, and closing the day takes under a minute when you actually time it.

In two weeks and without calling five vendors. Week one you look at how you work: run the five item calculation on the three largest jobs of last year, spend a full day in the workshop or on site watching how recording happens today, ask whoever reconstructs the actuals which information is always missing because that list is your specification written free of charge, write a single page on what must happen from winning the job to invoicing it, and decide the phases, four to seven, with the names used in the building. Week two you test: two candidates rather than five, the three real days test done by the most sceptical person in production with a stopwatch, loading one of your real jobs with its quotation to see margin at completion, a phone call to one of the vendor's customers in your sector and of your size, and the question of what happens if you change the phase structure in a year, because you will.

Leave your details in the form below

Matteo Migliore

Matteo Migliore is an entrepreneur and software architect with over 27 years of experience developing .NET-based solutions and evolving enterprise-grade application architectures.

Throughout his career, he has worked with organizations such as Cotonella, Il Sole 24 Ore, FIAT and NATO, leading teams in developing scalable platforms and modernizing complex legacy ecosystems.

He has trained hundreds of developers and supported companies of all sizes in turning software into a competitive advantage, reducing technical debt and achieving measurable business results.

Stai leggendo perché vuoi smettere di rattoppare software fragile.Scopri il metodo per progettare sistemi che reggono nel tempo.