Software choice
How to import thousandths tables into the software
Thousandths (millesimi) tables are the criterion by which the software splits expenses: if they go in wrong, every split will be wrong. Importing them into new software is not just copying columns of numbers, but rebuilding the correct structure: the general ownership table and the special tables for stairs, lift, heating and other uses. Each table must balance to one thousand and every unit must carry its value in each table that concerns it. This guide explains how to prepare the thousandths data, how to handle special tables that do not concern all units, and how to verify the import by comparing a test split with the last one produced by the old system, before using the tables on real balances.
Checks on tables before using them
- Every imported table sums exactly to one thousand thousandths
- The general ownership table covers all units of the condominium
- Special tables include only the units actually affected by the use
- Every unit carries the correct value in each table that concerns it
- Central heating tables distinguish the fixed quota from the consumption quota where applicable
- A test split matches the last split produced by the old system
Why tables must be imported methodically
Expense allocation follows Article 1123 of the Italian Civil Code: general expenses are divided in proportion to each owner's property value, while expenses for common parts serving owners to a different extent are split in proportion to use. To this are added special criteria, such as Article 1124 for stairs and lifts, which combines half by value and half by floor height, and Article 1126 for terraces in exclusive use.
This means a condominium usually has several tables, not just one, and the software keeps them separate because each expense is split on the relevant table. Importing only the general table and forgetting the special ones leads to charging everyone for costs owed by only some: the lift to the ground floor owners, for example.
Preparing the thousandths values
The most reliable method is to build a sheet with one row per unit and one column per table: general ownership, staircase A, staircase B, lift, heating, and so on as set by the condominium regulation. Each column must close to one thousand. Units not affected by a special table carry a value of zero in that column, and this should be left explicit, not ambiguously blank.
Values must be taken from the official source, meaning the tables attached to the regulation or those approved by the owners' meeting, not copied from a convenient old listing that might contain rounding. If the condominium has revised the tables over time, the version in force should be imported, while keeping a record of the previous one for financial years already closed.
Handling special tables
Special tables are the trickiest part of the import because they do not cover all units and because their criterion is not simple ownership. For stairs and lifts, Article 1124 provides a mixed split, and many condominiums already have a precalculated table accounting for both value and floor. It should be imported as approved, checking only that it closes to one thousand among the units served.
Central heating deserves separate attention: where heat metering applies, the expense is divided between a fixed quota tied to power thousandths and a consumption quota measured by individual meters, following the criterion set out in technical standard UNI 10200. The software must be able to keep the two components separate, so during import the heating thousandths table should be indicated without confusing it with the general one.
Verifying with a test split
Importing tables is validated by putting them to work. You take a known expense from the last financial year, for example stair cleaning or lift consumption, record it on a test year and generate the split. If the quotas per unit match, give or take a cent for rounding, the ones from the last split produced by the old system, the tables are correct.
This comparison should be run on at least one expense per table, not just the general one, because it is precisely on special tables that import errors hide. If a split does not match, the cause is almost always a column that does not close to one thousand or a unit with a wrong value, both immediately identifiable with the balancing check.
Keeping a record of versions
Tables can change: a revision approved by the meeting, the splitting of a unit or the merging of two rooms alter the thousandths. The software must keep the history, so that already closed financial years remain split with the tables in force at the time and new ones use the updated version. During import it is therefore best to load the current version and note the effective date.
Closing this stage in an orderly way avoids disputes: an owner rereading an old balance must find the quotas calculated with the tables of that time. Software like AmministraPro manages general and special tables with automatic balancing and version history; the /funzioni page describes the allocation tools and /prezzi lists the plans that include them.
Frequently asked questions
Should I import a single table or all the condominium's tables?
All those set by the regulation and approved by the meeting. A condominium usually has the general ownership table plus several special tables for stairs, lift, heating and other uses. The software splits each expense on the relevant table, so importing only the general one would charge everyone for costs owed by only some. Each table must be loaded and verified separately, checking that it closes to one thousand among the units it concerns.
How do I treat units that do not use a common part, such as the lift?
In the special table for that common part those units carry a value of zero, and the value should be left explicit. The lift table, for example, must close to one thousand among only the units served, typically excluding the ground floor as set by the regulation. Leaving a cell ambiguously blank may lead the software to interpret the data differently: it is better to enter zero where the unit does not participate.
Is central heating imported like a normal thousandths table?
Not entirely. Where heat metering applies, the expense is divided into a fixed quota on power thousandths and a consumption quota measured by meters, following technical standard UNI 10200. The software must keep the two components separate: during import you load the heating thousandths table distinct from the general one, while individual consumption is entered year by year, since it is not a fixed thousandths value.
How do I verify tables were imported correctly?
With a test split. You record a known expense on a dummy year and generate the split, then compare the quotas per unit with the last split produced by the old system. If they match, apart from minimal rounding, the tables are correct. The comparison should cover at least one expense per table, general and special, because it is on the special ones that import errors concentrate.
What happens to tables if a unit is split after the import?
Splitting a unit alters the thousandths and requires a new version of the tables, normally approved by the meeting. The software must keep the history: already closed years remain split with the tables then in force, while new ones use the updated version with its effective date. That is why it is best to import the current version noting the date, so the revision can later be added without rewriting the past.
Try AmministraPro
Accounting, thousandths-based cost splitting, meetings, communications and artificial intelligence in a single Italian software, compliant with UNI 10801 and GDPR.