Costs & ROI
How to calculate software cost per building managed
Cost per building managed is the metric that reduces the weight of software to a simple number: you take the total cost of the tool over a period and divide it by the number of buildings under management. Once you have this value, assessment becomes immediate, because that unit cost is compared with the fee each building brings to the firm and with alternative plans. For a condominium manager it is the most direct way to understand whether a subscription is sustainable building by building, and to notice early that, as the portfolio grows, the unit cost tends to fall. This guide explains how to calculate it correctly and how to read it without falling into the most common mistakes.
Data needed for the calculation
- Total annual cost of the software, subscription and modules used included
- One-off setup and migration costs, spread over the chosen horizon
- Number of buildings actually under management during the period
- Any distinction between large and small buildings, if the plan scales by unit
- Average annual fee earned per building managed
- Projected portfolio growth in the following months
The base formula and its variants
The starting calculation is simple: total annual software cost divided by the number of buildings managed. The result is how much the tool weighs on each building in a year. To make it realistic, add to the subscription the modules actually used and the annual share of one-off setup costs, spread over the assessment horizon.
There is a useful variant when the plan scales on the number of units or users: in that case it is best to calculate cost per real-estate unit as well as per building, because a building with many units weighs differently from a small one. The choice of variant depends on the software's price structure and must be stated to keep the comparison consistent.
Compare the unit cost with the fee
Cost per building becomes meaningful only when set against the fee each building generates. If the software cost per building is a modest fraction of the annual fee earned, sustainability is evident. The ratio between the two figures tells how much of the margin is absorbed by the working tool.
This comparison is also a basis for reasoning about the fee itself. A manager who knows precisely the unit cost of their tools can set the fee more knowingly, including technology costs as an explicit line rather than a generic expense hidden in the firm's accounts.
Why the unit cost falls with growth
Many software costs are fixed or grow less than proportionally to the number of buildings. As a result, as the portfolio grows, cost per building managed tends to decrease: the same base subscription spreads over more buildings. This effect is worth keeping in mind because it makes the software more convenient precisely as the firm grows.
Beware, however, of plans that scale rigidly by number of buildings or units: in those cases the unit cost can stay almost constant, and the growth advantage shrinks. Knowing in advance how the price evolves with the portfolio avoids surprises and lets you choose the model best suited to the firm's trajectory.
Mistakes to avoid in the calculation
The most common mistake is dividing by the maximum listed number of buildings instead of those actually managed: it inflates the denominator and makes the unit cost look lower than it is. Another mistake is forgetting the additional modules, which can noticeably change the total cost and therefore the unit cost.
Also avoid comparing unit costs calculated on different bases, for example one per building and the other per unit. For an honest comparison between solutions the formula must be identical, with the same items in the numerator and the same denominator, otherwise the numbers are not comparable and the choice rests on an illusion.
Use the figure to choose the plan
Cost per building managed is the right lens to choose between different plans: you calculate the value for each plan on the current and expected size of the portfolio, and pick the one that stays sustainable along the growth path. A plan convenient today but with a sharply rising unit cost tomorrow may not be the best choice.
To apply the method with real data it helps to read on /prezzi how AmministraPro plans are structured relative to the number of buildings and to check on /funzioni which activities are covered at no extra cost, so you can calculate a cost per building that reflects the firm's actual use.
Frequently asked questions
Is it better to calculate cost per building or per unit?
It depends on the software's price structure. If the plan is flat-rate, cost per building is enough. If it scales on the number of units, it is best to calculate cost per real-estate unit too, because a large building weighs differently from a small one and the per-building figure alone could mislead.
Should I include setup costs in the unit cost?
Yes, but spread over the assessment horizon. Adding all one-off costs to the first year would inflate the initial unit cost; spreading them over two or three years, as done in total cost of ownership, gives a more realistic value of the software's weight per building.
How do I use cost per building for my fee?
Knowing the unit cost of your tools lets you include technology as an explicit line in the fee calculation, instead of leaving it as a generic expense. Knowing how much the software weighs on each building helps set a fee that covers costs and keeps an adequate margin.
Does cost per building always fall as you grow?
Not always. It falls when software costs are largely fixed, because they spread over more buildings. With plans that scale rigidly by building or by unit, instead, the unit cost stays almost constant. You need to know in advance how the price evolves with the portfolio.
Try AmministraPro
Accounting, thousandths-based cost splitting, meetings, communications and artificial intelligence in a single Italian software, compliant with UNI 10801 and GDPR.