The short answer

Property data is difficult because a unit is not one thing. It can simultaneously be represented as a physical space, a legal premises, a revenue stream, a maintenance asset and a marketing listing, and those representations have different lifecycles, different boundaries and different owners inside your organisation.

Most systems model the unit once, usually as whichever representation mattered to whoever bought the software. Everything then works until the physical space and the legal premises stop agreeing, which happens the moment a unit is combined, subdivided, renumbered, taken offline or converted.

Some reporting problems are not data quality problems at all. They are modelling problems, and they were created years before anyone noticed.

Why does the same unit have different answers in different systems?

Because each system may be describing a different representation, and each can be correct.

Consider a single apartment. Facilities knows it as a physical space with a footprint, an HVAC unit and a maintenance history. Leasing knows it as a legal premises with a demised boundary defined in a lease. Finance knows it as a revenue stream with a rent schedule and a recovery share. Asset management knows it as a component with a useful life and a replacement schedule. Marketing knows it as a listing with photographs, a floorplan and an advertised size.

Five records. One apartment. None of them wrong.

The trouble starts because these representations do not move together. Combine two units into one and the physical space changes immediately, the legal premises changes when the new lease is signed, the revenue stream changes at the rent commencement date, and the maintenance history belongs to two records that no longer exist. Four different effective dates for one renovation.

This is why "clean your data" is such unhelpful advice. The underlying records may be accurate. They are describing something with more than one true description, and cleansing does not resolve a structural ambiguity. Even perfectly accurate data can produce conflicting answers when the model does not represent the underlying entity correctly.

Five ways the same unit is represented

Which representation a system treats as primary tells you what that system was built for. A leasing platform may make the legal premises primary. A facilities system may make the physical space primary. An accounting system may make the revenue stream primary. Each is a reasonable choice, and each creates a blind spot where the other representations diverge.

That is the structural reason behind a point we made in what is property management ERP software: when two systems maintain separate databases that must be kept in sync, the gap between them is managed rather than eliminated. The synchronisation problem is not purely technical. It is that the two systems may be modelling different things and calling them by the same name.

Why is a unit's size not one number?

Because the industry's own measurement standards produce several legitimate figures for the same physical space, by design.

BOMA International has set measurement standards for more than a century, publishing its first office standard in 1915, and today serves as the American National Standards Institute secretariat for a suite of area measurement standards. Its current suite includes separate standards for office, industrial, multi-family and hospitality, retail, mixed-use and gross areas.

The clearest illustration is the 2024 Gross Areas Standard, ANSI/BOMA Z65.3-2024, which includes five named methods of measurement: Gross Area 1 (Leasing Method), Gross Area 2 (International Method), Gross Area 3 (Volumetric Method), Gross Area 4 (Construction Method) and Gross Area 5 (ENERGY STAR Method). Five methods, one building, all published by the same accredited body, because each answers a different question.

The same pattern appears at unit level. The 2023 Multi-Family and Hospitality Standard provides a Gross Area Method and a Net Area Method, with the Net Area Method offering two distinct levels known as the Inside Net Method and the Centerline Net Method.

Layer onto that the distinction between usable area, the space a tenant exclusively occupies, and rentable area, which can include a proportional share of common elements. Then add the advertised size in a listing, the size on original architectural drawings, and the size held by a local assessor.

A single unit can therefore have several defensible square footage figures, and which one is appropriate depends on what you are calculating: rent, recovery share, energy benchmarking, valuation, marketing or maintenance scope.

This matters more than it sounds, because area is the denominator in a large amount of property arithmetic. Recovery allocations, price per square foot, expense ratios and the pro-rata share in a CAM reconciliation all divide by it. We covered why the choice of denominator changes the answer in allocating maintenance costs in mixed-use properties, and this is the layer beneath it.

What breaks, and when

The failures are predictable once you know where to look, and they cluster at the moments when representations diverge.

• Combination and subdivision.

  Two units become one, or one becomes three. The physical space now has no clean predecessor, so year-on-year comparison can silently misstate. Maintenance history attaches to records that no longer exist. Your occupancy denominator changes mid-period.

• Renumbering.

  A building renumbers its floors or units, often after a refurbishment. If the identifier is the key, historical records can be orphaned or attached to the wrong unit. This can be one of the most disruptive events in property data, and it can be done for operational convenience without anyone recognising the historical consequences.

• Conversion.

  Residential becomes commercial, or a unit becomes an amenity space. The revenue stream changes character, the lease structure changes and the recovery treatment changes. A system that handles this by creating a new record without preserving the predecessor relationship can sever the history.

• Taking a unit offline.

  A unit under renovation is physically present, legally undemised, generating no revenue and not marketable. Whether it belongs in your occupancy denominator is a definitional choice, and different systems can make different choices silently.

• Change of ownership within the portfolio.

  A unit moves between entities in a restructure. The physical space is unchanged, the legal premises is unchanged, and everything financial changes.

In many of these cases the physical space persists while one or more of the other representations change. A data model that cannot express that will lose history at exactly the moments when history matters most.

Why standards have not solved this

Because the standards that exist solve a different problem, and solve it well.

The Real Estate Standards Organization has done genuinely successful work. Its Data Dictionary provides a common language for real estate data, standardising fields and pick lists so property information can move consistently between MLSs, brokers, websites and other systems.

But that addresses a different problem. RESO's centre of gravity is interoperability around listing and transaction data. BOMA's standards address measurement. Neither is designed to model the internal lifecycle of an operating asset across multiple representations over decades.

That gap is not a criticism of either body. It is an observation about scope, and it explains why an operator cannot solve this simply by adopting a standard. The problem sits inside your own systems and has to be solved there.

What to do about it

Five modelling decisions are worth making before the data is already embedded in downstream systems.

This is also where master data management becomes more than a governance exercise: before every system can reference the same unit, the organisation has to decide what that unit actually represents. Our guide to master data in real estate covers the entity side of that question.

• Separate the identifier from the label.

  The unit's name is what people call it. The identifier is what the system uses. If they are the same field, renumbering can destroy historical continuity. This is the highest-value change in this article and it costs nothing at implementation.

• Model succession explicitly.

  When a unit is combined, subdivided or converted, record the predecessor and successor relationship rather than creating an orphan. It is the only way year-on-year comparison survives a renovation programme.

• Give area a purpose field.

  Not one square footage but several, each labelled with what it is for: rentable, usable, advertised, as-built, benchmarking. Systems that hold one number force everyone downstream to guess which one it is.

• Date the attributes, not just the transactions.

  Unit type, area, status and entity all change over time. If they are stored as current values only, historical reports are calculated using today's attributes rather than the ones that applied then, which quietly rewrites the past.

• Decide the denominators once, in writing.

  Whether an offline unit counts in occupancy, whether a master-leased block counts as one tenancy or forty, whether a converted unit is new or continuing. These decisions belong with the data model rather than being left to individual reports.

The practical test for whether your model holds is simple. Ask what happens to three years of history when you combine two units. If the answer involves a manual adjustment or a note in a spreadsheet, you have found the limit of your model, and you have found it in a calm moment rather than during a diligence process.

Symptoms of a modelling problem

Frequently asked questions

Q1. Why is property data so difficult to manage?
Because a unit can be represented several ways at once: physical space, legal premises, revenue stream, maintenance asset and marketing listing. Each has a different lifecycle, and most systems model only one of them as primary.

Q2. Why do two systems report different unit counts?
Usually because they are counting different representations or applying different rules to edge cases such as offline units, master-leased blocks, amenity spaces and units mid-conversion.

Q3. Why does a unit have more than one square footage?
Because different measurement methodologies answer different questions. BOMA's 2024 Gross Areas Standard alone includes five named methods, and its 2023 Multi-Family and Hospitality Standard provides Gross Area and Net Area methods. Usable, rentable, advertised and as-built figures also serve different operational purposes.

Q4. What property data changes are most likely to disrupt historical reporting?
Renumbering, subdivision, combination and conversion, when the model does not preserve predecessor and successor relationships. Renumbering is particularly risky where the unit identifier and display label are the same field, because changing the label also changes the key historical records rely on.

Q5. How do you keep history when units are combined or split?
Model succession explicitly by recording predecessor and successor relationships rather than creating new records and abandoning old ones. Without it, year-on-year comparison breaks at every renovation.

Q6. Why do historical reports change when rerun?
Usually because attributes such as unit type, area, status or entity are stored as current values rather than effective-dated. The report recalculates the past using today's attributes.

Q7. Is this a data quality problem or a data model problem?
It can be either, and the distinction matters. A data quality problem means the record is inaccurate or incomplete. A data model problem occurs when accurate records cannot represent the underlying business reality cleanly, for example when one unit needs several representations or historical states the model cannot preserve.

The real reason this matters

Property data problems are usually discovered in the reporting layer, which is the last place they can be fixed. By the time two departments disagree about occupancy, the disagreement is years old and lives in a structure nobody remembers choosing.

The underlying difficulty is not carelessness. Property genuinely is ambiguous. A unit really can be represented several ways, its area really does have several correct values, and its history really is discontinuous when the building changes. The industry's own standards bodies acknowledge this by publishing multiple methods rather than one.

What separates portfolios that report reliably is not cleaner data. It is a model that expects the ambiguity: identifiers that survive renaming, succession that survives renovation, effective-dated attributes that preserve what was true at the time, and denominators someone actually decided.

Get those right and many reporting problems stop being problems. Get them wrong and no dashboard will help, because the dashboard is downstream of the thing that broke.

RIOO is built on NetSuite and uses a unified data model across operational and financial workflows. See how the platform is structured.