Commercial Building Management Software

A managing agent called me some years into my advisory work with a problem that I have now seen enough times to recognise from the first sentence. They had bought "commercial building management software", gone live, and could not work out why it would not produce a service charge reconciliation. The answer was straightforward and expensive: they had bought a CAFM system. Service charge lives in a property accounting platform. Nobody in the selection process had noticed, because everyone in the room had been using the same four words to mean four different things. That ambiguity is not a footnote to this subject. It is the subject.

The message up front: "commercial building management software" is not a product category. It is a search term that maps onto four distinct categories with almost no functional overlap: plant controls (BMS/BAS), space and services management (CAFM/IWMS), maintenance work management (CMMS), and tenant, lease and money management (property management and accounting). Most commercial landlords and managing agents genuinely need two or three of them. The selection decision that actually matters is not which single platform wins, it is which system is the record of truth for the building, the asset, the space and the tenant.

1. Why the term is ambiguous, and why that costs money

Terms in enterprise software usually settle. "CRM" means something reasonably stable. "ERP" has boundaries people broadly agree on. "Commercial building management software" never settled, for a specific structural reason: four different professions all have a legitimate claim to the phrase, and each one uses it for their own tooling.

The building services engineer means the supervisory software sitting above the controllers, the thing that shows plant graphics and lets them change a setpoint. The facilities manager means the system that holds floor plans, moves people between desks, and logs a helpdesk request. The maintenance manager means the system that issues planned and reactive work orders against an asset register. The asset manager or managing agent means the platform holding leases, rent demands, service charge budgets and tenant arrears. All four are managing a commercial building with software. All four are right. None of the four products will do more than a fraction of another one's job.

This matters commercially because software selection is usually run by whoever raised the requirement, using their own vocabulary, and vendors answer in whatever vocabulary gets them into the shortlist. A BMS integrator asked whether their platform "manages the building" will say yes, and they are not lying. A CAFM vendor asked the same question says yes, also truthfully. The buyer hears two yeses and assumes two comparable options. They are not comparable. They barely intersect.

The pattern of failure I see is consistent: the wrong category is selected, the gap surfaces somewhere between requirement gathering and month four of implementation, and the organisation either bolts on a second system under time pressure with no integration design, or forces the wrong platform to do a job it was never built for. Both outcomes are more expensive than getting the category right on day one, which costs nothing but a clear head.

2. The four categories, side by side

This is the centrepiece of the article and the table I would put in front of any selection committee before the first vendor walks in. Read it as a disambiguation aid, not a ranking. None of these four is better than another; they answer different questions.

Look at the "what it will not do" column and the point becomes obvious. These are not four flavours of the same thing with different emphasis. They have four different data models. A BMS is organised around points and controllers. A CAFM is organised around locations and space. A CMMS is organised around assets and work. A property platform is organised around leases and ledgers. You cannot make one absorb another's data model without significant custom work, and the custom work is usually where the budget disappears.

3. BMS and BAS: controls software that runs the plant

A building management system is the layer that actually operates the building's mechanical and electrical plant. Controllers on the equipment, a network tying them together, and supervisory software above that gives an operator visibility and control. When a chiller sequence needs changing, when an AHU schedule shifts for a new tenant fit-out, when a high-temperature alarm needs investigating, that work happens in the BMS. The major names here are Siemens, Johnson Controls, Honeywell, Schneider Electric and Trend, plus the independent Tridium Niagara ecosystem that many integrators build on.

The signals that a BMS is what you actually need: your problem is described in terms of temperature complaints, energy consumption, plant runtime, out-of-hours scheduling, or alarms you cannot see centrally. Your stakeholders are engineers and your existing pain is that the controls are proprietary, unsupported, or only visible from a workstation in the basement. If the words in the requirement are "setpoint", "schedule", "trend", "graphic" or "integration to the chiller", you are in BMS territory.

I am deliberately not going to redo the evaluation work here. If BMS supervisory software is the category you have landed on, the detailed evaluation criteria, open-protocol questions and vendor-lock-in traps are covered in how to evaluate BMS software and platforms, and the broader architecture in the complete guide to building management systems. Where analytics sit on top of the controls layer is covered separately in smart buildings: from BMS to building analytics.

The common misdiagnosis at this boundary is worth naming. Organisations frequently buy a BMS expecting it to manage maintenance, because it produces alarms and alarms feel like work requests. They are not. A BMS alarm is a transient condition notification with no lifecycle, no assignee, no parts, no labour record and no closure audit trail. Treating an alarm list as a maintenance backlog is how buildings end up with three thousand unacknowledged alarms and no maintenance history at all.

4. CAFM and IWMS: space, services and the estate

CAFM manages the building as a place that people occupy and services get delivered into. Its organising concept is location: sites, buildings, floors, zones, rooms, and increasingly individual desks. From that spine hang space and occupancy reporting, churn and move management, room and desk booking, a service helpdesk, soft services scheduling such as cleaning and security, contractor management and SLA performance. IWMS is CAFM with a wider footprint, typically adding lease administration, capital project management, sustainability reporting and sometimes real estate portfolio planning. Planon, Archibus, FSI Concept Evolution, MRI Software and Nuvolo sit in this band, with meaningful differences in how far each leans towards workplace, property or maintenance.

The signals that CAFM or IWMS is your category: your requirements mention floor plans, occupancy density, cost per square metre, allocating space to cost centres or tenants, a single helpdesk number for the estate, or managing multiple service lines across multiple buildings. If you are a managing agent running twenty buildings for six different landlords and you need consistent service delivery visibility across all of them, that is a CAFM or IWMS shape, not a CMMS shape and not a controls shape.

For multi-building estates, the architecture decision about how you model the hierarchy is more consequential than the vendor choice, and I have written that up separately in multi-site CAFM architecture. If you are actively comparing products in this band, the CAFM buyer comparison is the more useful page. MRI in particular straddles the CAFM and property-accounting boundary in a way that makes it relevant to this article's overlap discussion, and is covered in introduction to MRI Software.

5. CMMS: maintenance work management

A CMMS is organised around two things: the asset register and the work order. It holds what equipment exists, where it is, what its maintenance regime is, what work has been done to it, what parts went into it, how long the labour took, and whether statutory obligations have been met and evidenced. Planned preventive maintenance schedules generate work automatically. Reactive requests get logged, prioritised, assigned, executed and closed with a history that survives the technician leaving. IBM Maximo, Hexagon EAM, Infor EAM sit at the enterprise end; MaintainX, Limble, Fiix, UpKeep and eMaint at the accessible end.

The signals that CMMS is your category: your pain is described in terms of work not getting done, compliance certificates you cannot find at audit, no asset register, PPM that exists on a spreadsheet, reactive work arriving by WhatsApp, or an inability to show a client that contracted maintenance was actually delivered. If the requirement contains the words "PPM", "asset register", "compliance evidence" or "work order backlog", you are in CMMS territory regardless of what the search term was.

I am not going to redraw the CAFM/CMMS/EAM/IWMS boundary here, because that four-way distinction has its own treatment in CAFM vs CMMS vs EAM vs IWMS, with the selection logic in which of CAFM, CMMS or EAM is right for you. The distinction between asset management software and CMMS, which trips up asset-heavy landlords in particular, is in asset management software vs CMMS. What matters for this article is only that CMMS is a separate category from the other three, with a separate data model, and that a property platform's "maintenance module" is almost never a substitute for it. If your portfolio is the driver rather than a single building, the specific considerations are in CMMS for property and real estate portfolios, and the general FM application in CMMS for facilities management.

6. Property management and accounting platforms

This is the category most commonly missed by people searching the building-management term, and the one whose absence causes the most acute pain, because its outputs are financial and audited. A commercial property platform manages the lease as the primary object: demised area, term, rent, review dates, break options, indexation, service charge apportionment, insurance recharge, and the accounting entries that flow from all of it. Rent demands go out from here. Service charge budgets are set, expenditure is coded against them, and the year-end reconciliation that tenants are entitled to is produced here. Arrears tracking, tenant statements and investor reporting sit here too. Yardi, MRI, Qube and Re-Leased are the names that recur in commercial property, with Horizon and TRAMPS still in service in parts of the UK market.

The signals that this is your category: anything involving rent, service charge, apportionment, arrears, VAT, a general ledger, RICS service charge compliance, or reporting to a fund or investor. If a stakeholder in the room is a property accountant, this category is in scope whatever else you buy. For an authoritative grounding on what the service charge process actually has to produce, the RICS professional statement on service charges in commercial property is the reference document, and it is worth reading before you let a vendor tell you their module is compliant.

7. The overlap zone: when you genuinely need two or three

Very few commercial landlords or managing agents need only one of these. The realistic patterns I encounter:

• Single owner-occupied office, in-house engineering team. BMS plus CMMS. No lease complexity worth a platform, and space management is often satisfied by a CAD file and a spreadsheet until headcount churn gets serious.
• Multi-tenant commercial landlord, outsourced FM. Property platform plus BMS, with the FM provider's own CMMS doing the maintenance work and reporting into you contractually. You do not need to own a CMMS; you need to specify what evidence the provider must supply.
• Managing agent across multiple landlords. Property platform plus CAFM. The property platform per client for money and leases, the CAFM as your own consistent service delivery layer across all instructions. This is the combination most often mis-scoped as a single purchase.
• Large corporate occupier across many buildings. IWMS plus CMMS plus BMS. The IWMS holds space and the real estate portfolio, the CMMS holds assets and work, the BMS runs plant per building. Leases may sit in the IWMS or in corporate finance depending on lease accounting arrangements.
• Institutional portfolio with heavy plant. All four, plus an analytics layer. This is the only case where the full stack is genuinely justified, and it is a programme, not a purchase.

Notice that in three of those five patterns the answer includes not buying something. That is a legitimate output of a good disambiguation exercise, and it is the one vendors will never suggest.

8. Deciding the system of record for each entity

Once you accept that you will run two or three of these, the decision that determines whether the estate is manageable or a permanent reconciliation exercise is ownership of data. Every entity needs exactly one system that is authoritative for it. Everything else consumes a copy. Where organisations get this wrong, you end up with three different answers to "how many air handling units do we have" and nobody able to say which is right.

The one row that generates the most argument in practice is the asset register. Property platforms want it because assets sit in buildings they own. CAFM wants it because assets sit in locations it models. CMMS should win, every time, because only the CMMS needs the depth of asset data that maintenance requires, and a register maintained anywhere else degrades within a year. Let the others hold a reference to the asset identifier, not their own competing list.

9. The integration pattern that works

Assume two or three systems and design the joins deliberately. The pattern I would recommend for a commercial estate, in order of build:

• Agree one location hierarchy and one coding standard first. Before any integration, every system must use the same site, building, floor and room identifiers. This single decision does more for integration success than any middleware choice. Do it in a spreadsheet, get it signed off, then load it everywhere.
• Location master flows from CAFM outward. One-directional, CAFM or property platform to CMMS and BMS naming. Never let two systems create locations independently.
• Asset identifier flows from CMMS outward. The CMMS mints and owns the asset ID. CAFM and the property platform reference it. No parallel registers.
• BMS to CMMS is alarm-to-work-request, filtered. Do not pipe raw alarms into the CMMS. Define the specific, engineer-agreed alarm conditions that should become a work request, and pass only those. Everything else stays in the BMS. This is the single most abused integration in the market and the reason so many CMMS backlogs are noise.
• BMS to CMMS also carries runtime hours. Genuinely valuable and much less commonly built: plant runtime from the BMS driving meter-based PPM in the CMMS, so maintenance follows actual duty rather than the calendar.
• CMMS to property accounting carries cost, not work. The property platform needs the cost lines for service charge coding, not the work order detail. Summarised, periodic, coded to the service charge schedule.
• Tenant and demised area flows from property platform to CAFM. So the helpdesk knows who is calling, what they occupy, and whether the request is landlord or tenant responsibility. This one repays itself quickly.

On protocols: at the controls layer insist on open standards rather than proprietary integration, which in practice means BACnet for building automation and, where it applies, verified interoperability rather than a claim on a datasheet. At the enterprise layer, REST APIs with documented schemas, and a scheduled reconciliation report that flags records diverging between systems. That reconciliation report is unglamorous and it is the thing that keeps a multi-system estate honest.

For PPM content itself, rather than building schedules from scratch, an industry standard such as SFG20 is a far better starting point than a vendor's generic library, and it also gives you a neutral basis for comparing what each candidate platform can actually import.

10. A decision guide you can run in a morning

Work through this in order. It is deliberately blunt, and it is designed to be done before any vendor conversation.

Step 6 is the one most often skipped, and skipping it is how a BMS integrator and a CAFM vendor end up on the same scoring matrix, where the scoring is meaningless because they are answering different questions.

11. The misdiagnoses I see most often

• Buying CAFM expecting service charge. The opening story of this article. CAFM can hold cost data; it cannot produce a RICS-compliant reconciliation.
• Buying a property platform expecting real maintenance management. Works while maintenance is fully outsourced and low-risk. Breaks the moment statutory compliance evidence or in-house labour enters scope.
• Treating BMS alarms as a maintenance backlog. Produces thousands of unactioned alarms and zero maintenance history.
• Expecting a BMS upgrade to deliver FM improvement. Better plant visibility does not create work management. Different category, different problem.
• Letting two systems own the asset register. Guaranteed divergence, and the divergence is discovered during an audit.
• Buying the broadest suite to avoid integration. A rational instinct, but it trades integration risk for module-depth risk. Test the weakest module before committing.
• Running one shortlist across categories. The scoring matrix produces a number, the number is meaningless, and the decision gets made on the demo that felt best.

None of these are stupid mistakes. Every one of them is the natural consequence of four professions sharing one vague phrase, and every one is avoided by spending a morning on disambiguation before spending a year on implementation. On measuring whether any of it worked afterwards, the FM KPI framework is the companion piece.

The idea to walk away with

There is no such product as commercial building management software. There are four products, and the phrase is a symptom of the fact that four professions manage the same building through different lenses without a shared vocabulary. The value in recognising this is not academic. It is the difference between a selection process that produces the right two or three systems with clear data ownership, and one that produces a single expensive platform that satisfies the loudest stakeholder and disappoints everyone else.

So resist the pull to name a winner. Name the entities instead: the setpoint, the square metre, the work order, the lease. Decide which system is authoritative for each. The product decisions follow almost mechanically from there, and they follow correctly.

Final thoughts

The buyers I have seen get this right were not the ones with the biggest budgets or the most rigorous scoring matrices. They were the ones who noticed early that the people in the room were using the same words to mean different things, and who stopped to fix that before writing a specification. It is an hour of uncomfortable conversation that saves a year of expensive rework.

If you are at the start of this and the search term is all you have, the most useful thing you can do costs nothing: take the three problems that prompted the search, tag each one with the entity it concerns, and see how many categories you land in. If it is one, your selection is simpler than you feared. If it is three, you have just saved yourself the worst version of this project.

Related reading: Building management systems: a complete guide, How to evaluate BMS software and platforms, CAFM vs CMMS vs EAM vs IWMS, CMMS for property and real estate portfolios, Best CAFM software: buyer comparison, Multi-site CAFM architecture.