Data validation before reporting: the step most managers skip

Every quarter, fund manager teams run the same painful correction cycle. Data arrives from property managers. Someone loads it into the model. The report runs. Then someone checks the output, finds a number that doesn't look right, traces it back through the workbook, and discovers that a vacancy figure from one régie was entered in a different currency, or that a rent roll total doesn't reconcile with the prior period because one manager changed their account coding convention.

The correction takes hours. Sometimes it takes days. And it happens every single quarter, because the error detection mechanism is a human reading a number and thinking it looks wrong — not a systematic check applied at the point of ingestion.

Where the errors actually come from

The standard explanation for reporting errors in Swiss real estate fund management is "data quality from property managers." This is partly true but mostly misleading. The more precise explanation is that errors arise at the boundary between two systems that don't share a common schema.

A property manager operating Quorum, Garaio REM or a similar platform delivers data according to the conventions of that system and that régie's internal accounting practice. A fund manager receiving data from five régie partners is effectively receiving five different datasets that have been given the same column headers to make them look compatible. They're not.

The discrepancies are predictable: vacancy defined by unit count rather than revenue, capex categorised as maintenance, lease income including service charges that should be excluded, square metre figures mixing net and gross. These aren't errors in the conventional sense — they're classification differences that the fund manager's team must resolve every time data arrives.

The problem with detecting errors in the report

When errors are detected at the reporting stage — by a human reading the output — several things have already happened. The data has been loaded into the model. The model has run. The report may already have been partially reviewed. At that point, correcting the error means retracing the entire data pipeline to find where the discrepancy entered, correcting it, and re-running the report.

This correction cycle is expensive not just in hours but in attention. The deadline pressure that accumulates in the last week before board reporting is precisely the environment in which corrections are made hastily, secondary errors are introduced, and the final report goes out with less confidence than the team wants.

The more fundamental problem is that errors detected at report time teach the team nothing useful about the data source. The same discrepancy will arrive again next quarter from the same régie, in the same format, and the same correction will have to be made again.

What validation at the point of ingestion does differently

The alternative is to apply validation rules at the moment data enters the system — before it reaches the reporting layer. This is structurally different from checking the report output, because it identifies discrepancies against a defined schema rather than against human expectation.

Validation rules at ingestion can check: whether vacancy figures are expressed as percentages or absolutes and flag inconsistencies with the expected format; whether income totals reconcile with the prior period within defined tolerance thresholds; whether any line items are missing that were present in the previous submission; whether capex figures fall within the expected classification categories; and whether currency conversions are applied consistently.

When a validation check fails, the issue is flagged before the data enters the reporting model. The fund manager team sees a specific, described discrepancy — "régie X has reported vacancy by unit count; expected by revenue" — rather than a number in a report that seems slightly wrong. The correction can be made at source, or a mapping rule can be applied to translate the régie's format into the fund's schema.

The compounding benefit: institutional memory

The less obvious benefit of systematic validation is that the rules become institutional memory. Each validation rule represents a known discrepancy between a régie's data conventions and the fund's schema. Over time, these rules accumulate into a comprehensive mapping of how each property manager delivers data and what transformations are required.

This matters when team members change. The analyst who has been correcting the same classification error every quarter for three years carries that knowledge in their head. When they leave, the error reappears — and the new team member has to discover it through the correction cycle. Documented validation rules transfer that knowledge to the system.

What this means for the reporting timeline

The practical consequence of systematic data validation is a shorter, more predictable reporting cycle. When data validation happens automatically at ingestion, the fund manager team starts the reporting period from a position where the data has already been checked — not from a position where the checking is part of the reporting work.

The quarterly review cycle becomes a review of outputs, not a search for errors in inputs. This shift is the difference between a two-day reporting sprint and a half-day review process — and it compounds across every reporting period.

For teams preparing for FINMA examinations or investor due diligence, systematic validation also provides documentation that data quality controls exist and are applied consistently. An examiner reviewing a fund's data governance can see which validation rules were applied, which issues were flagged, and how they were resolved — rather than relying on a team member's description of what they check manually.