Linking units to thousandths tables in the software

Why a building has several tables

Condominium expenses are not all split the same way. Article 1123 of the Italian Civil Code provides that expenses be allocated in proportion to the value of each person's property, but it also establishes that, when a thing is intended to serve to a different extent, the expense is allocated in proportion to use, and that if a building has several staircases, courtyards or systems intended to serve only some of the members, the related expenses fall only on those who benefit.

This is where multiple tables come from. The general table measures the value of the property and serves for expenses common to all; the specific tables, such as stairs, lift or heating, measure use or service and serve for items concerning only some. Some tables follow specific criteria, such as Article 1124 for stairs and lifts, which splits the expense half based on value and half based on floor height.

• General table: property value, expenses common to all
• Stairs and lift table: value and floor height (Art. 1124)
• Heating table: consumption and technical elements
• Service tables: only for those who benefit (Art. 1123)

How the unit-table association works

In the software each table is a list of units with their respective thousandths value, and the sum of a table's thousandths must give the expected total, normally one thousand. Linking a unit to a table means giving it its weight in that group of expenses. A unit can appear in several tables with different thousandths: for example weighing one way on the general table and another on the lift.

The association governs automatic allocation: when the manager records an expense and assigns it to a table, the software distributes the amount among only the units linked to that table, in proportion to their thousandths. If a unit is not linked, it does not receive its share, and the expense does not balance. This is why the correctness of the associations is the condition for every reliable allocation.

Excluding units that do not use a service

One of the most important uses of tables is exclusion. A shop with an independent entrance from the street may not use the internal stairs; a ground-floor unit may be excluded from the lift under the regulations or actual use. Linking units to tables selectively lets each expense fall only on those who benefit, as provided by Article 1123.

In the software this means not associating that unit with the table of the service that does not concern it, or giving it a weight consistent with reduced use. It is an initial setup task that, if done well, avoids recurring disputes: those who do not use a service do not want to be charged for it, and the law agrees with them.

Checks before considering the setup complete

After linking units to tables it pays to make some checks. The first is the sum of each table's thousandths: it must match the expected total, otherwise the allocation will be unbalanced. The second is coverage: every unit that must take part in a table is actually linked to it, and no unit that must be excluded appears by mistake.

A third useful check is the allocation test: you record an expense of known amount on a table and verify that the sum of the shares splits the amount exactly, with no gaps beyond natural rounding. This spot test, repeated on one expense per table, gives certainty that the associations are correct before going live.

• The sum of each table's thousandths gives the expected total
• Every unit is linked to the tables that concern it
• No excluded unit appears by mistake
• The allocation test on a known expense balances correctly

When tables change: revision and rectification

Thousandths tables are not immutable. Article 69 of the implementing provisions sets out the cases in which the values may be rectified or modified, for example when they result from an error or when changed conditions of part of the building have significantly altered the original ratio between the values. When this happens, the associations in the software must be updated accordingly.

Software that manages table versions lets you update the thousandths while keeping a memory of the previous values, so the allocations of past years stay consistent with the tables then in force. It is an important aspect of transparency: history is not rewritten, the correct table is applied to each period.

Correct associations, reliable allocations

Linking units to tables well is the hinge between the register and the accounts: all allocations pass through it. Investing time in the initial setup and the checks pays off in correct shares, fewer disputes and greater member trust in the management.

AmministraPro lets you manage several thousandths tables, link each unit with its own weight, exclude units from services that do not concern them and verify allocations. The features are described on the /funzioni page and the plans for your practice on the /prezzi page.

Frequently asked questions