Choosing software
What to really test during a condominium software trial
During a condominium software trial most managers try the easy cases, the ones any software handles, and skip the hard cases, which are the only ones that reveal the real limits. A mid-year change of ownership, an expense to split on a special table, centralised heating to divide under the UNI 10200 standard, a defaulting owner, a multi-block condominium: these scenarios show whether the program handles the reality of a practice or forces you into workarounds. This guide lists the operational scenarios to reproduce during the trial, explaining what to watch in each and which results tell a good candidate from an unsuitable one.
Scenarios to reproduce during the trial
- Mid-year change of ownership, splitting charges between seller and buyer
- Splitting an expense across different tables: general, stairs, lift, heating
- Centralised heating split between consumption and fixed share under UNI 10200
- Applying Article 1124 for stairs and Article 1126 for flat roofs
- Handling a defaulting owner, with reminders and credit status
- Full report with the three documents required by Article 1130-bis
- Notice of call with terms, quorum and proxies under Articles 66 and 1136
- Multi-block condominium or units with different uses, if you actually manage them
The mid-year change of ownership
The change of ownership is the acid test of condominium accounting. When a unit changes owner mid-year, charges must be split between seller and buyer according to the period they belong to, and future instalments must follow the new owner while arrears stay with the old one. During the trial it is worth entering a real change of ownership and checking that the software handles the split without forcing manual recalculations.
Many programs tie instalments to the unit statically and fail to move the burden correctly when ownership changes: the result is that the buyer receives requests that belong to the seller, or the reverse. If the software gets this wrong, it will get it wrong on an event that recurs constantly in a practice, which is reason enough to rule it out.
Special apportionments and different tables
The heart of accounting work is apportionment across different tables. A stair expense follows Article 1124, which splits half by thousandths (millesimi) and half by floor height; an expense on a flat roof in exclusive use follows Article 1126; general expenses follow ownership thousandths under Article 1123. During the trial reproduce at least three different apportionments on the same condominium, to see whether the software handles multiple tables or forces everything onto general thousandths.
Also watch the rounding behaviour: the sum of the shares must match the apportioned amount to the cent, without discrepancies that then carry into the report. A candidate that does not close the accounts to the cent generates disputes in the meeting, and it is a flaw you only find by testing on real amounts.
Centralised heating under UNI 10200
If you manage condominiums with centralised heating, the split between the voluntary consumption share and the fixed share under the UNI 10200 standard is a scenario to test without shortcuts. It is one of the areas where software diverges most, because it requires handling meter data, energy-demand thousandths and the separation of the two components of the expense.
During the trial it is worth entering the consumption of a real season and checking that the report separates the two shares correctly. If the software is unaware of the standard and distributes everything on general thousandths, the result will not be compliant and will be a source of dispute with owners who watch their consumption closely.
Defaulters, reminders and credit status
Handling defaults is a daily test. Enter an owner who does not pay and check how the software tracks the credit: whether it updates status on a partial payment, whether it generates reminders linked to the position, whether it keeps track of amounts due for a possible injunction. The manager is accountable for collection, and a system that loses the thread of credits turns an obligation into a risk.
Also test the match between payments and instalments: record a receipt and see that the owner's position updates, the cash balance changes and the transaction stays traced. This is a step repeated hundreds of times a month, so any friction here weighs disproportionately on working time.
The meeting cycle and the edge cases
The meeting cycle should be tested in full: a notice of call with a detailed agenda, the calculation of the notice terms under Article 66 of the implementing provisions, the constitutive and deliberative quorums of Article 1136, proxy handling with the limits based on the number of participants. This is where you see whether the software knows the rules or leaves the calculation to the manager.
Finally, if you manage particular arrangements, such as a multi-block condominium or units with different uses, reproduce those too. AmministraPro lets you reproduce these scenarios on real data, from special apportionments to heating and the meeting cycle, before you decide; the features and pricing pages help you connect each scenario to a concrete feature and understand what is included in each plan.
Frequently asked questions
Why test the hard cases and not the easy ones?
Because any software handles the easy cases, so they do not tell candidates apart. It is the hard cases, a change of ownership, a special apportionment, centralised heating, that reveal the real limits. Testing only simple accounting gives false confidence: the program looks adequate until the first complex event, which in a practice arrives almost immediately.
Which scenarios are the most revealing overall?
The mid-year change of ownership and apportionment across different tables are the two most revealing, because they touch the heart of accounting and recur constantly. Next come centralised heating under UNI 10200 and closing a report compliant with Article 1130-bis. If a software passes these four scenarios, it is likely to handle the practice's real work.
Do I really need to enter heating consumption during the trial?
If you manage condominiums with a centralised plant, yes, because the split under UNI 10200 is one of the areas where software diverges most. Just use the data of a single real season to see whether the program correctly separates the consumption share and the fixed share. If you do not manage centralised plants, you can skip it and focus on the scenarios that concern you.
How do I know if the trial report is compliant?
Article 1130-bis of the Italian Civil Code requires the report to contain an accounting register, a financial summary and an explanatory note. During the trial, check that the software generates the three documents and that structure and amounts match the ones you produce today. If making them add up requires manual adjustments, compliance is only apparent and the flaw is structural.
What do I do if a scenario is not reproducible in the trial plan?
Ask the vendor whether the feature is missing entirely or available in a higher plan not active in the trial. This distinction is decisive: a feature present but paid is a cost question, a missing feature is a structural limit. Clarifying it during the trial, not after purchase, avoids discovering the gap once you have already signed.
Try AmministraPro
Accounting, thousandths-based cost splitting, meetings, communications and artificial intelligence in a single Italian software, compliant with UNI 10801 and GDPR.