The first objection in almost every building technology conversation is the same, and it is a good one. "We run on Yardi. We are not moving off Yardi." Nobody says it apologetically. They say it the way you would say the building has a foundation.

They are right. In most cases a Yardi integration for building operations is a better outcome than a migration. The accounting system of record should stay exactly where it is. The question is what happens to the twenty things a building does every day that the accounting system was never built to do.

What the system of record is for

Yardi holds the lease, the rent roll, the receivables, the general ledger, the budget. It is where the auditor looks and where the owner's reporting comes from. It is correct, it is controlled, and changing it is a project with a steering committee.

That control is a feature. It is also why nobody wants a porter raising a work order in it, and why no property manager is going to give a vendor a login to upload a certificate of insurance.

What happens in the gap

Below the ledger there is a layer of daily work with no natural home. A tenant reports a leak. A contractor needs access on Saturday. A COI expires. An inspection is due. A guest arrives for the eleventh floor. A parking space changes hands. An amenity is booked and needs to be billed.

In most buildings this layer runs on email, a phone number, three spreadsheets and one person's memory. That is what happens when the only system available is the wrong shape for the work.

Buildings do not fail because the ledger is wrong. They fail in the layer above it, where the work is real, fast and unrecorded.

Sit on top, do not replace

An operations platform that integrates with Yardi reads what it should read and writes only what it should write.

It reads tenants, suites, lease terms and contacts, so a work order knows which suite it belongs to and a notice knows who to reach. It reads the rent roll so the stacking plan matches the accounting instead of a version someone rebuilt in a spreadsheet.

It writes back sparingly and deliberately: billable amenity charges, parking revenue, chargeable work order costs. The rule that keeps this clean is simple. Money settles in the system of record. Work happens in the operations platform. Neither pretends to be the other.

What to ask a vendor about integration

Which direction does each object flow? A vendor who cannot answer this per object, instead of in general, has not built the integration you need.
What is the refresh, and what happens when it fails? Nightly is fine for most objects. Silent failure is not. Somebody should be told.
Who wins on a conflict? If a suite is renamed in both systems, there needs to be a rule for that before it turns into a support ticket.
What does it need from our Yardi administrator? Credentials, a service account and a defined scope, agreed before implementation instead of discovered in week three.
What breaks if we turn it off? A clear answer is a good sign. A platform that becomes unusable without the integration has made your system of record its dependency, and yours.

The integration nobody scopes and everybody needs

Access control. The lease data in Yardi decides who belongs in which suite. The access system decides who gets through which door. In most buildings those two facts are reconciled by a human being with a spreadsheet, usually late.

A move-out is the clearest case. Accounting knows the term ended. The badge does not, and a credential that should have died on the thirtieth keeps working into the next quarter. Connecting lease data to access control through the operations layer closes that gap without asking either system to change what it is.

What implementation looks like

Set realistic expectations. Reading tenant and lease data is straightforward and usually the first thing to go live. Writing charges back takes longer, because it touches accounting policy and someone in finance has to approve the mapping. Access control depends on which system is installed and how it was configured, which is a site question, not a product question.

The projects that go badly are the ones that try to do all three at once, in a building where nobody has agreed which system owns a suite name. The projects that go well start with reads, prove the data matches, and add writes when finance is comfortable.

The case for keeping the ledger where it is

Every hour spent migrating an accounting system is an hour not spent on the layer where tenants experience the building. Owners rarely lose a renewal because the ledger was in the wrong package. They lose it because a request took nine days, a guest was treated badly, or a suite was not ready when it was promised.

Leave the foundation alone. Fix the floor everyone walks on.

The "one more system" objection

Somebody in the room will point out that the team already logs into too many things, and they are right. Do not promise fewer systems. Be specific about who uses which one.

Accounting stays in Yardi and rarely opens anything else. Engineers and porters live in the operations platform on a phone and never open Yardi at all. Property managers move between both, and that is the seat where the integration has to earn its keep, because they are the ones who currently reconcile the two by hand.

Counted properly, a good integration removes work from the person with the most work. Counted badly, it adds a login for everyone and helps nobody.

Reporting across the two

There is also a cultural question hiding in the reporting one. Accounting measures a building monthly, in arrears, with everything reconciled. Operations measures it hourly, in the present, with everything still moving. Both are right, and the first argument in a joint report is usually about which version of a number is the real one. Decide that before the report exists instead of in the meeting where it is presented.

Owners ask questions that cross the line: what did we spend on this suite, what is the cost of running the amenity floor, how long does this building take to close a request compared with the one across town.

Answering those means agreeing early on which identifiers travel between the systems. A shared property code and suite identifier make later reporting a query. Skipping that agreement makes every cross-system question a manual join, which is the tax nobody quotes in the business case.

It is a half-day conversation at implementation and it saves a quarter of arguing later.

Where BuildingHub fits

BuildingHub integrates with Yardi instead of replacing it, and the four Hubs run the layer above: work orders, preventive maintenance and certificate tracking in Operations Hub, credentials and visitors in Security Hub, critical dates and stacking in Leasing Hub, bookings and parking in Amenity Hub. Access control connects through Genea, LenelS2 and HID, so a lease change can reach a door without a spreadsheet in the middle. The full list is on the integrations page.

Yardi integration for building operations: sit on top, don't replace