Software choice
How to test the data after software migration
Importing the data is not enough: the migration has succeeded only when the data has been tested. Testing is the phase in which you put to the proof what has entered the new software, before declaring it operational, to bring out the silent errors that are not visible at a glance. The essential checks are four: the balancing of tables and balances, a test split compared with the old system's, the reconciliation of the dedicated bank account, and a completeness check of the document archive. This guide describes each check with the criterion for passing it, so you have an objective verification list rather than the feeling that everything looks fine.
The testing checks to pass
- Every thousandths (millesimi) table sums exactly to one thousand
- Every unit has a linked owner with the correct start date
- The sum of owners' opening balances is consistent with cash and receivables
- A test split matches the last one produced by the old system
- The accounting balance of the dedicated account matches the bank statement
- The document archive is complete per condominium and per year
Balancing tables and records
The first check is structural and done on screen. Every thousandths table must sum exactly to one thousand: a listing per table immediately reveals those that do not close, a symptom of a badly imported value or a missing unit. Then you verify that every unit has a linked owner, with the correct start date, distinguishing owner, usufructuary and tenant where needed.
Orphan units, with no owner, and tables that do not balance are the most common import errors and the easiest to spot in this phase. Fixing them now, before generating any document, prevents them from propagating to splits and communications. It is a quick but decisive check: the records structure is the foundation on which everything else rests.
The compared test split
The most meaningful test is putting the software to work on a known case. You take an expense from the last year, record it on a test year and generate the split, then compare the quotas per unit with those of the last split produced by the old system. If they match, apart from minimal rounding, tables and records have been transferred correctly.
The comparison should be run on at least one expense per table, general and special, because it is on the special ones that errors concentrate. A lift expense checks the lift table, a heating one the heating table. If a split does not match, the cause is almost always upstream, a table that does not close or a wrong value, and must be fixed before proceeding.
Reconciling the dedicated bank account
The financial part is tested with reconciliation. The condominium operates through a dedicated bank account, required by Article 1129 of the Italian Civil Code, whose balance is the reality benchmark. You compare the accounting balance reconstructed in the new software with that of the bank statement at the same date: if the two figures match, the migration of the financial part is reliable.
A difference signals a problem to investigate: a receipt counted twice, a wrong opening balance or a forgotten movement. This reconciliation is the most objective test because the bank account does not lie: it is the external proof that the internal figures are correct. It should be done condominium by condominium, not at an aggregate level, to isolate any discrepancies.
Document completeness check
The fourth test concerns the archive. For every condominium and every year, you verify the presence of the documents that must be there: meeting minutes, approved statements, contracts in progress, plant certificates and the period's invoices. A verification list ticked item by item is more reliable than a quick scan, because gaps in an archive go unnoticed until precisely the missing document is needed.
You should also check that electronic invoices have been kept in the original format and not as mere printouts, and that documents are accessible to those entitled, since owners can request to inspect and extract copies. Completeness and accessibility together certify that the archive has been migrated and not just copied haphazardly.
Closing the test and documenting it
Once the four checks are passed, it is worth documenting the outcome: noting which condominiums were tested, with which checks and with what result. This record is useful if a doubt later arises, letting you know what had already been verified, and it gives the office the confidence to start operations without surprises. Testing turns migration from an act of faith into a verified operation.
Only after testing does the new system become the daily tool and the old one go read-only. Software like AmministraPro supports this phase with automatic balancing checks, a test split and account reconciliation tools; the /funzioni page describes the accounting and verification features and /prezzi lists the plans, useful for planning a migration with structured testing.
Frequently asked questions
What are the minimum checks to consider a migration tested?
Four: the balancing of the thousandths tables, which must sum to one thousand, and of the records, with every unit having an owner; a test split compared with the old system's last one; the reconciliation of the dedicated bank account with the bank statement; the completeness check of the document archive per condominium and year. Once all four are passed, the migration is verified. Skipping even one leaves a category of errors uncovered that then surfaces once the system is in use.
Why should the test split be compared with the old system?
Because the comparison makes the verification objective. By recording a known expense on a test year and generating the split, the quotas per unit must match those of the last split produced by the old software, apart from minimal rounding. If they match, tables and records were transferred well. The comparison should cover at least one expense per table, general and special, because it is on the special tables for stairs, lift and heating that import errors hide.
How do I reconcile the account after migration?
You compare the accounting balance reconstructed in the new software with the statement balance of the dedicated bank account, required by Article 1129 of the Italian Civil Code, at the same date. If the two figures match, the financial part is reliable. A difference indicates a problem to investigate, typically a receipt counted twice or a wrong opening balance. The reconciliation should be done condominium by condominium, not aggregated, so as to isolate any discrepancies immediately.
How do I verify the document archive is complete?
With a verification list ticked item by item, for every condominium and every year: minutes, approved statements, contracts in progress, plant certificates and the period's invoices. You should also check that electronic invoices are kept in the original format and not as mere printouts, and that documents are accessible to those entitled, since owners can inspect and extract copies. Gaps in an archive are noticed only when the missing document is needed.
Is it worth documenting the testing outcome?
It is very useful. Noting which condominiums were tested, with which checks and with what result, creates a valuable record: if a doubt later arises, you know what had already been verified, and the office can start operations with confidence. Documenting the test turns migration from an act of trust into a verified operation. Only after passing and recording the checks does the new system become the daily tool and the old one go read-only.
Try AmministraPro
Accounting, thousandths-based cost splitting, meetings, communications and artificial intelligence in a single Italian software, compliant with UNI 10801 and GDPR.