At some point every property finance team tries to compare itself to the industry. The benchmark data exists, it is published by the trade bodies, and the exercise looks like an afternoon of work. Then it turns out that your repairs and maintenance line is not their repairs and maintenance line, two of your own properties code landscaping differently, and the comparison quietly gets abandoned. The usual conclusion is that the data was not clean enough. The actual reason is that the chart of accounts was never designed to answer that question. This article covers the standard that already exists, why most portfolios drifted away from it, and what it costs downstream.

The Standard Already Exists

This is the part most operators do not know. BOMA publishes a Functional Accounting Guide and Chart of Accounts that has served as the industry standard for office buildings for roughly a century.

Its design principle is worth stating precisely, because it is the thing that gets lost. Income is segregated by type of occupancy and by special activity, so office rent, retail rent, parking rent and vendor income are distinguishable. Expenses are disaggregated by the functional cause of the expense: cleaning, repairs and maintenance, utilities. The guide provides up to four levels of detail, where the first level reflects functional categories of building operations and the second addresses the means and methods by which those functions are achieved, with further subsets available underneath.

Four levels, cash or accrual, built explicitly so that income and expense line items can be compared on a like-for-like basis across buildings.

The second thing most operators do not know is that the benchmark data is built on the same foundation. Income/Expense IQ is a joint product of BOMA, IREM and NAA, combining property data from all three bodies into benchmarks filterable by asset type and metro area, covering gross potential rent, loss to lease, net effective rent and other revenue on the income side, and administrative, management fees, leasing, repairs and maintenance, utilities, taxes and insurance on the expense side. Participating means uploading twelve-month income statements with properties set up correctly.

So the categories are not a matter of preference. They are the price of admission to the only cross-industry dataset that exists.

Why Your Chart Looks Nothing Like It

Almost no portfolio sets out to diverge. The divergence is a byproduct of how charts of accounts actually grow.

An account gets added because an owner asked for a number broken out. Another gets added when a new property arrives carrying the seller's structure and nobody has time to remap it. A third appears because a controller wanted to track a specific vendor separately during a dispute, and it was never retired. An entity set up in a hurry for a single acquisition gets a chart copied from whichever property was closest to hand. Multiply that across ten years and several dozen entities.

Nothing in that sequence is a mistake in isolation. Each addition solved a real problem for the person who requested it. The result is a chart that answers hundreds of historical questions and no general one.

There is also a deeper structural difference, and it explains why mapping later turns out to be so hard.

Most charts of accounts that grow organically end up organised around who spent the money or where it went. Vendor categories, department codes, the name of the service provider. The standard is organised around what function the expense served. Those are not the same axis, and one does not convert cleanly into the other.

Take landscaping. At one property it is coded to Repairs and Maintenance because the site team requested it. At a second it sits under Contract Services because it is a recurring vendor agreement. At a third it lands in Grounds because someone created that account in 2019. The building is doing the identical thing in all three cases. The function is identical. The account is not.

None of these is wrong. But only the third produces figures that can be compared to another building, and it is the one that organic growth almost never arrives at.

What the Drift Costs

Four consequences, in rough order of how quickly they are felt.

Benchmarking becomes a project rather than a query. Comparing to published industry data requires a mapping exercise from your categories to theirs, done by someone who understands both. That exercise gets postponed, then done once by an analyst who leaves, then postponed again. Many operators never complete it, which means they are running against national and metro data they have already paid to access.

Internal comparison stops working first. This is the one that hurts before anyone notices. If two properties in your own portfolio code the same expense differently, your property-versus-property analysis is measuring account structure rather than performance. A regional manager looking worse on maintenance cost may simply be coding contract services into a different bucket than the peer they are being compared against.

Consolidation requires manual intervention every period. Where entities were set up separately, the mapping to a group-level reporting structure lives in a spreadsheet, gets maintained by hand, and has to be checked every time an account is added. That work recurs monthly and grows with the portfolio.

Budgets inherit the problem. Building next year's budget against categories that do not correspond to any external reference means the only benchmark available is last year's version of the same figures. The budget is internally consistent and externally unanchored.

Fixing It Without Rebuilding

The instinctive response is a full chart of accounts migration, and for most operators that is the wrong first move. It is expensive, it breaks historical comparability at the moment you convert, and it requires a level of organisational agreement that is difficult to assemble.

The cheaper sequence:

• Map before you migrate. Build the crosswalk from your existing accounts to the standard functional categories. This alone makes benchmarking possible and will surface every inconsistency between entities without changing a single posting.

• Standardise new entities from the day they are created. Divergence compounds, so stopping the growth is worth more than fixing the history. Any entity added after the decision should be born on the standard structure.

• Fix the categories that carry benchmark value first. Repairs and maintenance, utilities, administrative, management fees, insurance and taxes are the lines the published data actually covers. Precision in accounts that nothing external reports on is effort without return.

• Retire accounts that answer expired questions. The vendor account created for a 2019 dispute is still collecting postings. Most charts can lose a meaningful share of their accounts without losing any information anyone currently uses.

• Decide where subledger detail belongs. Much of the sprawl exists because the general ledger is being asked to store analytical detail. Vendor-level and unit-level analysis belongs in a subledger or an operational system, which lets the GL stay at the functional level where the standard operates. Systems that carry property and unit detail alongside the ledger, RIOO among them, make that separation practical.

The mapping exercise is also the diagnostic. Whatever will not map cleanly is precisely where your reporting has been quietly unreliable.

Conclusion

The chart of accounts is usually invisible until somebody tries to compare properties. Until that moment it works: transactions post, statements produce, owners get paid. The design flaw only surfaces when a question arrives from outside the portfolio, and by then the structure has a decade of history in it.

The industry solved this a long time ago. A functional standard exists, it has existed for about a hundred years, and the benchmarking data that most operators want is published in its categories. The gap is not that the standard is missing. It is that individual charts of accounts drifted away from it one reasonable addition at a time, and nobody was assigned to notice.

Mapping to the standard is a smaller job than it appears, and it is the prerequisite for every comparison that follows. A chart of accounts that only your own team can interpret is not a reporting structure. It is a private language with a general ledger attached.

FAQs

1. What is a chart of accounts in property management?
A chart of accounts is the structured list of general ledger accounts used to record every transaction for a property or entity. In property management it typically covers rental and other income, operating expenses, capital items, assets and liabilities. Its structure determines what questions the financial statements can answer, which is why the design matters more than the number of accounts.

2. Is there a standard chart of accounts for property?
Yes. BOMA publishes a Functional Accounting Guide and Chart of Accounts that has been the office industry standard for roughly a century. It segregates income by occupancy type and special activity, disaggregates expenses by functional cause such as cleaning, repairs and maintenance and utilities, and offers up to four levels of detail while supporting both cash and accrual accounting.

3. Why can I not compare my properties to industry benchmarks?
Usually because your expense categories do not correspond to the categories the benchmark is published in. Industry data through Income/Expense IQ, a joint BOMA, IREM and NAA product, is organised by functional expense category. If your accounts are organised by vendor, department or historical accident, every comparison requires a manual mapping step first.

4. What is functional accounting?
Functional accounting groups expenses by the building function that caused them rather than by who was paid or which team requested the work. Landscaping is grounds care regardless of whether it was billed by a contractor or performed in house. This is what allows two different buildings, run by two different operators, to be compared on the same line.

5. Do I need to rebuild my chart of accounts to fix this?
Rarely as a first step. Building a mapping from existing accounts to standard functional categories delivers most of the benchmarking benefit without disrupting historical data or postings. Full restructuring is worth considering at a system migration or when entity count has grown to the point that manual consolidation mapping has become a recurring monthly cost.