Every time someone asks an AI chatbot a question, a building somewhere gets a little warmer. Multiply that by billions of questions a day, add the training runs behind the scenes, and you get one of the fastest-growing energy stories on the planet.

The International Energy Agency says electricity used by data centers worldwide will more than double to around 945 terawatt-hours by 2030, with AI as the biggest reason. That is roughly as much electricity as Japan uses today. Water is part of the story too. One industry estimate puts global data center water use at 5.6 billion gallons a day in 2026, and community pushback over water has already delayed or blocked more than $150 billion worth of projects.

So it is fair to ask: is there a way to run AI without draining the grid and the river?

There is, and it is not what most people expect. The biggest new idea is not a better solar panel or a bigger battery. It is swapping copper wires inside the data center for light traveling through glass. That sounds like a small engineering detail. It is not. Moving data around burns a surprising share of a data center's power, and light does it far more cheaply than copper.

This blog walks through why data centers are so hungry, what "optical" really means, how Cisco turned itself into a major player in that world, what a startup called Ayar Labs is doing inside the chips themselves, and what all of this means for the people who own, operate, and report on data center buildings.

Think of a data center as a giant hair dryer that never turns off. Inside are rows of computer chips doing math. Every bit of electricity those chips use turns into heat. That heat has to go somewhere, or the chips cook themselves.

For years the answer was air. Big fans blew cold air across the servers, and the warm air went outside. To make that cold air, data centers often used cooling towers. Those towers work like sweating: water evaporates, and evaporation carries heat away. It works well, but roughly 80% of the water that goes into a cooling tower is lost to the sky. That is why a single large data center can drink as much water as a small town.

AI made all of this worse, fast: a normal server rack used to draw 5 to 10 kilowatts. An AI rack packed with GPUs can draw ten times that or more. Too much heat is packed into too small a space for air to handle, which is why the industry is moving to liquid cooling, where a fluid runs right up to the chip. We will come back to water later, because liquid cooling helps with some problems and can make others worse.

Here is the part most people miss. Only some of a data center's electricity goes into actual computing. A big slice goes into cooling, and a surprisingly large slice goes into moving data between chips. A GPU is useless on its own. It has to talk to other GPUs, memory, storage, and the network thousands of times a second. For decades that talking happened over copper wires, and copper has a problem that gets worse every year.

Copper carries electricity, and electricity fights back. Push a signal down a copper wire, and it weakens every centimeter. The faster you send data, the worse the loss gets. Today's AI chips want to send data at 200 gigabits per second on a single lane. At that speed, Nvidia says a copper link can lose up to 22 decibels of signal, which is a polite way of saying most of it disappears.

To fix that, engineers add chips called retimers and signal processors that clean up and boost the signal. Those chips burn power. A single high-speed network port can draw around 30 watts to keep the signal readable. Multiply that across tens of thousands of ports, and you have megawatts of electricity doing nothing but shouting over the noise in a copper wire. Every one of those watts becomes heat, and every bit of heat needs cooling; cooling needs power, and often water.

There is a second cost. Because copper loses signal so quickly at high speed, it only works over short distances, a meter or two at most. That forces AI designers to cram GPUs as close together as possible, which packs even more heat into even less space. The chips are hot because they are close together, and they are close together because copper cannot reach any further.

Mark Wade, the CEO of Ayar Labs, puts it bluntly: AI is hitting a power wall driven by interconnect inefficiency. The wires, not the chips, are becoming the limit. One analyst who spent several days at the industry's biggest optical conference this year came home with a simple prediction. All AI data center interconnects will be optical within five years.

If you have fiber internet at home, you already use the trick. Instead of pushing electricity through metal, a tiny laser flashes light down a strand of glass. Light does not weaken the way electricity does. It can travel meters or kilometers with almost no loss; it does not heat the cable, and you can send many colors of light down the same strand at once, each carrying its own stream of data.

Data centers have used fiber for years to connect buildings and racks. What is new is how close to the chip the light now gets. There are three steps on that ladder, and each one saves more power.

Pluggable optics. This is the old way. A small module plugs into the front of a network switch, converts electricity to light, and sends it down fiber. It works, but each module has its own signal-cleaning chip inside, and those chips are power-hungry.

Linear pluggable optics (LPO). Same plug-in idea, but the signal-cleaning chip is removed, and the switch does the work instead. Cisco says this cuts the module's power use by about half and can trim total switch power by around 30%.

Co-packaged optics (CPO). This is the big one. Instead of a module at the front of the box, the tiny laser and light converter sit right next to the switch chip, inside the same package. The copper path shrinks from centimeters to millimeters. Nvidia says its CPO switches are 3.5 times more power-efficient than switches with pluggable modules, with ten times fewer failures because there are fewer parts to break. One early report puts the saving at around 3 kilowatts per switch. In a cluster with hundreds of switches, that freed-up power can run more GPUs instead of more fans.

The simplest way to picture it: copper is like passing a note hand to hand across a crowded room, with people re-writing it every few steps so it stays readable. Light is like saying it once, clearly, across the whole room: less effort, less heat, fewer mistakes.

Most people think of Cisco as the company that makes the routers in office closets. That is still true, but over the last two years Cisco has quietly become one of the three or four companies that matter most in AI networking, and optics is a big reason why.

The foundation is a chip family called Silicon One. In February 2026, Cisco announced the Silicon One G300, a switch chip that moves 102.4 terabits of data per second. Cisco says it is built for AI clusters measured in gigawatts and improves how fast AI jobs finish by about 28% because it handles the bursty, all-at-once traffic AI creates without dropping data.

The chip only matters because of what plugs into it. Alongside the G300, Cisco launched 1.6-terabit optical modules and 800-gigabit linear pluggable optics, the LPO design that strips out the power-hungry signal chip. That is the practical, ship-it-this-year version of the optical shift. Cisco's optics leader, Bill Gartner, has been publicly cautious about co-packaged optics, noting that a CPO package may have a thousand or more fiber connections glued to a piece of silicon and that reliability must be proven. Cisco's bet is to win on the step everyone can take now, LPO, while CPO matures.

The second move changed Cisco's position in the market. In 2025, Cisco and Nvidia agreed to combine their networking portfolios, making Cisco the only outside chip supported inside Nvidia's Spectrum-X AI networking platform. The first product of that deal, the Cisco N9100 switch, runs on Nvidia's silicon with Cisco's management software on top. For a company building an AI data center, that means you can buy Nvidia's GPUs and Cisco's network and have them designed to work together, which is exactly what large enterprises, governments, and sovereign cloud builders want.

Why does this matter for an ESG story? Because Cisco is the vendor most big companies already trust, and it is now selling the energy-saving optics as a standard part of its AI data center kit, not as an exotic option. When the default product from the default vendor cuts switch power by 30%, that saving spreads across thousands of buildings without anyone having to make a brave decision.

Cisco and Nvidia are bringing light to the network switch. A smaller group of companies wants to go one step further and bring it right onto the processor itself. The best-known is Ayar Labs, a Silicon Valley startup that has become one of the most heavily funded hardware companies of the AI era.

In March 2026, Ayar Labs raised $500 million at a $3.75 billion valuation, with Nvidia, AMD, and MediaTek among the investors. It added another $150 million in late September, and Wiwynn, a major server builder, joined as a backer. That is close to a billion dollars raised for a company most people outside the industry have never heard of.

The product is two parts. The first is a tiny chip called TeraPHY. It sits inside the same package as a GPU or AI accelerator and turns the chip's electrical signals into light. A single TeraPHY can move up to 8 terabits per second using 16 colors of light at once. The second part, called SuperNova, is a laser that sits outside the hot chip package and feeds light into it, a bit like a power supply, except it supplies light instead of electricity. Keeping the laser away from the heat is a clever move, because lasers hate being hot.

The energy numbers are the point. Ayar Labs says its optical links use as little as 5 picojoules per bit, which is a tiny fraction of what a long copper link needs at the same speed, and it claims four to eight times better power efficiency than today's pluggable optics or copper. Because light does not care about distance the way copper does, GPUs no longer have to be jammed into one rack. They can be spread across a room and still act like one giant computer. Less crowding means less concentrated heat, and less concentrated heat means a cooling system that can be smaller, cheaper, and thirstier for fewer gallons.

Ayar Labs is not alone. Startups such as Lightmatter and Celestial AI are chasing the same prize with different designs, and in March 2026 AMD, Broadcom, Meta, Microsoft, Nvidia and OpenAI formed an Optical Scale-up Consortium to agree on common standards. Nvidia has also put roughly $4 billion into optical component makers to ensure supply. When buyers, chip makers, and standards bodies all move at once, a technology stops being a lab demo and becomes a line item in next year's budget.

This is where a lot of blogs get it wrong, so it is worth slowing down.

Water use in a data center comes from one thing: removing heat. Every watt that goes into a chip, a copper wire, or a fan comes out as heat, and the heat has to leave the building. If it leaves by evaporating water in a cooling tower, you use a lot of water. If it leaves through a closed loop and a dry cooler, like a car radiator, you use almost no water on site, but you use more electricity to run the fans. There is no free lunch, only a choice about which bill you pay.

That is why liquid cooling gets confusing. Running fluid straight to the chip is far more efficient than blowing air, and it can sharply cut cooling energy. But it doesn't decide where the heat goes afterward. One industry survey found direct liquid-cooled AI facilities using 1.8 to 3.2 liters of water per kilowatt-hour when paired with evaporative heat rejection, more than some air-cooled sites. At the same time, closed-loop and immersion designs have been reported to cut direct water use by 70% or more. Same chips, very different water bills, depending on the last step.

So where do optical cables fit? They attacked the problem one step earlier. Light does not make the cooling system better; it makes the building need less cooling in the first place. Fewer retimers and signal chips mean fewer watts turning into heat. Co-packaged switches drawing kilowatts less each means a smaller load on the chillers. Spreading GPUs across a room instead of cramming them into one rack means heat that is easier and cheaper to remove. Every watt you do not create is a watt you do not have to cool, and roughly a liter or two of water you do not have to evaporate.

Put the three together, and you get the realistic picture of a low-water AI data center in 2027 or 2028: optical links so the chips waste less power talking to each other, direct-to-chip liquid cooling to pull heat away efficiently, and closed-loop or free-air heat rejection so the heat leaves without evaporating a river. Hybrid sites in cooler climates already report under 1.2 liters per kilowatt-hour by using outside air most of the year.

One last honest caveat. The water used to generate electricity at the power plant is usually larger than the water used for cooling at the data center. Cutting power with optics helps that number too, but a data center on a coal grid with perfect cooling still has a big water footprint; it never sees where the electricity comes from matters as much as what happens inside the building.

Most of the companies reading about optics are chip and network buyers. But a growing share of AI data centers are owned by real estate investors, REITs, and infrastructure funds who lease the shell and the power to a tenant. For them, the optical shift changes three things.

The numbers you report. Two metrics drive data center ESG reporting. PUE (power usage effectiveness) measures how much electricity goes to overhead like cooling versus actual computing. WUE (water usage effectiveness) measures liters of water per kilowatt-hour of IT power. Optics and better heat rejection move both in the right direction, and they do it inside the tenant's equipment and the building's cooling plant at the same time. That matters because investors, lenders, and regulators are starting to ask for site-level PUE and WUE, not company averages. Community opposition over water has already delayed or blocked more than $150 billion of projects. A credible water story is now part of getting a permit.

The lease. The lease determines who pays for power and water, who gets credit for savings, and who decides on cooling design. A tenant that upgrades to co-packaged optics and liquid cooling may cut its power draw per rack while asking the landlord for a very different cooling plant. Leases written for air-cooled 10-kilowatt racks do not cover that. Owners are starting to add clauses on liquid-cooling readiness, water budgets, and how they share efficiency gains.

The data. None of the reporting works if meter data, cooling plant logs, and the tenant's IT load are stuck in three different systems. Owners running portfolios on platforms like Yardi or MRI are finding that the ESG module is only as good as the utility and building-systems data feeding it. The firms doing this well treat energy and water data like rent data: metered, reconciled monthly, and traceable to a source.

There is a bigger point underneath all this. Over the next five years, the data center boom will be judged on whether it ate the grid and the water table or found a way not to. Optical cables are one of the few pieces of good news in that story, because they cut the problem at the source rather than cleaning up after it. Owners who understand that will be the ones tenants, lenders and towns want to deal with.

You do not need to understand photonics to act on this. Here is what to ask, whether you are building, buying or leasing.

If you are building or expanding

• Ask the network designer which optics they plan to use: standard pluggable, LPO, or co-packaged. Each step down that list cuts switch power

• Design the cooling plant for liquid cooling from day one, even if the first tenant is air-cooled. Retrofits cost far more

• Decide how heat leaves the building. Evaporative towers use water; closed-loop and free-air designs use power. Pick based on the local water situation, not habit

• Get a WUE target into the design brief, not just a PUE target

If you are leasing to an AI tenant

• Add liquid-cooling readiness, rack power density and a water budget to the lease

• Agree up front how efficiency savings are shared when the tenant upgrades its optics or cooling

• Require the tenant's IT load data in a form that feeds your ESG reporting

If you are investing or lending

• Ask for site-level PUE and WUE, not portfolio averages

• Check whether the local community or regulator has pushed back on water use nearby

• Look at the electricity source. A clean grid shrinks the water footprint you cannot see

If you are running the reporting

• Make sure meter data, cooling logs and tenant IT load land in one system, reconciled monthly

• Treat ESG data with the same rigor as rent and expense data, because lenders soon will

None of this is exotic. It is the same discipline good owners already apply to rent rolls and capital budgets, pointed at kilowatts and liters instead of dollars.

MRI Ascend is MRI Software's annual flagship user conference for clients, partners and industry leaders. The North American edition is the largest, with regional editions in APAC (Sydney), EMEA (London) and South Africa running earlier in the year. The 2026 North American conference is in Las Vegas, October 18–21, at the Caesars Forum Convention Center on the Strip. Registration, agenda, and hotel details are at mriusersconference.com.

Who attends. Ascend draws owners, operators, property managers, fund administrators, and occupiers across every MRI vertical: commercial, multifamily, affordable and public housing, investment management, facilities management, and corporate occupiers. Typical delegates include controllers, property accountants, directors of IT, business-systems managers, and operational leaders who sign off on technology budgets.

What the format looks like. Expect four pillars across the week:

1. General sessions and keynotes from MRI leadership covering strategy, roadmap, and the state of the industry.

2. Product sessions and training by module, many eligible for CPE credit. MRI is a registered NASBA CPE sponsor, with one credit per eligible 50-minute hour, which is a meaningful draw for accounting teams.

3. Client case studieswhere operators walk through how they solved a specific problem on MRI.

4. The partner expo, where MRI's solution and consulting partners demonstrate integrations, add-ons, and services. This is where you will find Assetsoft.

Why does Las Vegas 2026 matter more than usual? MRI has spent 2026 repositioning MRI Agora from an integration platform into the foundation for its AI strategy. The June launch of Agora Intelligence and Agora Orchestrator, the PMX 10.7 release, and the roll-out of Agora to APAC at Ascend Sydney in August all point to Las Vegas being the event where North American clients see the full picture for the first time. If you are planning a PMX upgrade, a migration from a legacy system, or an AI pilot in 2027, the decisions you make in the next twelve months will be shaped by what is announced here.

The official agenda is published closer to the event, but MRI's own framing for 2026 is clear: new integrations, expanded product features, unified user experiences, and AI-powered automation. Based on what MRI has shipped and announced this year, here is what we expect to dominate the general sessions and the hallway conversations.

1. MRI Agora moves from platform to operating layer. For the last two years, Agora was described as MRI's open, connected platform. In 2026, the language changed. Agora is now positioned as the architecture under every MRI application, with four layers: Agora Workflow (connecting and coordinating processes), Agora Intelligence (detecting issues and recommending actions), Agora Orchestrator (executing multi-step workflows with agentic AI), and the MRI applications themselves as systems of record. Expect Las Vegas to be the first full North American showcase of all four working together.

2. Agora Intelligence and Orchestrator get real demos. Launched in June 2026, these two products answer the question every operator is asking: can the software act on the data, not just store it? Intelligence surfaces recommendations, such as a lease expiry with no renewal activity or an AP batch with a duplicate-invoice pattern. Orchestrators take the recommended action through a governed workflow. The sessions worth attending are the ones where MRI shows the approval controls, the audit trail, and how an agent is stopped when it is wrong, because that is what your auditors will ask about.

3. PMX 10.7 and Application Studio. PMX 10.7 and Application Studio were highlighted at Ascend Sydney as the combination that lets clients extend PMX without custom code. For North American PMX clients still on older Web X versions, this is the version to plan an upgrade around, and the one on which most new Agora capabilities will land first.

4. From automation to intelligent action. MRI's product strategy team framed the 2026 shift as moving from efficiency (automate the repetitive task) to outcomes (make the better decision). Expect keynotes to lean on that language, and expect the best client case studies to be the ones that show measurable results: days cut from the close, hours removed from reconciliation, leasing conversions lifted.

5. The partner ecosystem matters more, not less. Agora is explicitly an open platform. The more MRI pushes AI into the core, the more the quality of the data feeding matters, and the more the integrations around the edges (banks, expense systems, construction platforms, document repositories) determine whether the AI is trustworthy. That is why the expo floor is worth two hours of your schedule, not twenty minutes.

What we recommend you do before you arrive. Write down the three processes that cost your finance team the most hours every month. For most PMX clients, that list includes bank reconciliation, AP invoice processing, and CAM reconciliation. Then use the sessions and the booths to answer one question for each: who fixes this, natively or through a partner, and by when?

Assetsoft will be exhibiting on the partner expo floor at Caesars Forum for all three conference days. Look for the Assetsoft booth [Booth #TBC] in the partner pavilion. Our team of senior MRI consultants, solution architects, and the product team behind ABR will be on hand throughout.

Who we are, in one line. Assetsoft is a multi-platform Protech consultancy founded in 2012 and headquartered in Markham, Ontario, with delivery teams in Canada, the United States, India (Pune and Chennai), and Sri Lanka. We are an MRI Software Gold Service Partner, a Yardi Independent Consultant Network member, a Procore partner, a SAP Concur partner, and a UiPath certified partner. Our practice is led by a founder with more than 25 years in real estate technology, and our consultants average 15+ years of hands-on platform experience.

What we do for MRI clients. Assetsoft delivers the full MRI lifecycle:

• MRI PMX implementation and configuration for commercial, multifamily, and investment portfolios

• Data migration and conversion into MRI from Yardi, Sage, JD Edwards, spreadsheets, and legacy systems

• Web X upgrades, including the move to PMX 10.7

• MRI Analytix BI reporting and dashboards

• Integration between MRI and the systems around it: banks, SAP Concur, Procore, Zoho, document AI and RPA

• Ongoing managed services and help desk support across North American and Australian time zones

What we are showing at the booth.Three things:

1. Automatic Bank Reconciliation (ABR) for MRI PMX, demonstrated live on a PMX environment. Bring your own reconciliation pain points, and we will show how the matching rules handle them.

2. Integration and automation around MRI, delivered through our KriyaGo platform, including bank feeds, expense integration, and document capture into MRI AP.

3. MRI implementation, migration and upgrade advisory, with a free 30-minute planning session for operators scoping a 2027 project.

Where we work: Assetsoft supports MRI clients across the United States, Canada, Australia and New Zealand, with 24/7 coverage from our global delivery centers. Active ANZ clients include Goodman Group and Colliers International, and our North American MRI practice spans REITs, fee managers and private owner-operators.

Book a time before you arrive. Booth traffic peaks after the general sessions. If you want a dedicated 20-minute walkthrough, reserve a slot, and we will hold it for you.

ABR is a native bank reconciliation engine for MRI Property Management X. It takes bank activity in, matches it against the cash transactions already in MRI, and posts the reconciled results back to MRI. The result is a reconciliation done daily by the system rather than monthly by a person, with exceptions surfaced for review instead of the whole statement.

The problem it solves. Bank reconciliation in property management is a volume problem disguised as an accounting problem. A fee manager with 300 bank accounts across trust, operating, and reserve structures reconciles thousands of lines a month. The matching logic is mostly deterministic, yet it still happens in spreadsheets, with CSV downloads from the bank, VLOOKUPs against an MRI cash export, and manual journal entries for the leftovers. The consequences are familiar: close slips, exceptions that pile up, auditors asking for evidence that doesn't exist in one place, and the most expensive people on the finance team spending their month ticking lines.

How ABR works. Three steps, visible on screen:

1. Ingest. ABR accepts bank activity by direct bank feed or by file upload. BAI2 statement files work out of the box. Non-standard bank formats are mapped once and reused, and the matching engine stays bank-agnostic from there.

2. Match.Configurable rules match bank lines against MRI receipts, disbursements, transfers, and fees. Rules handle cases that break spreadsheets: one bank deposit covering many tenant receipts, one MRI batch split across multiple bank lines, bank fees with no MRI counterpart, timing differences, and reversals. Matches are scored, and anything below the confidence threshold is routed to an exceptions queue with the suggested match pre-filled.

3. Post. Matched items are marked reconciled in MRI. Exceptions are cleared in a single review screen, and approved adjustments are posted back to MRI through supported channels, with a full audit trail of who matched what, when, and under which rule.

Why native to MRI matters. ABR reads and writes MRI data directly rather than keeping a parallel ledger in another tool. That means the reconciliation status in ABR is the reconciliation status in MRI, the GL stays the system of record, and there is no second reconciliation of the reconciliation tool. It also means ABR fits the direction MRI itself is taking with Agora: clean, continuously reconciled cash data is exactly what Agora Intelligence needs to produce recommendations finance teams will trust.

What it delivers. Operators who have piloted ABR report the same three outcomes:

• Time. Reconciliation moves from a multi-day month-end task to a daily exception review measured in minutes per account.

• Close. Cash is reconciled before the close starts, not during it, which removes one of the longest poles in the month-end tent.

• Control. Every match has a rule, a timestamp, and an approver. Audit requests are answered by filtering a screen, not rebuilding a spreadsheet.

Where it is already in use, ABRwas launched to the MRI community at Ascend APAC in Sydney in August 2026, where MRI announced it to its Australian client base as the preferred automatic bank reconciliation solution for PMX. Las Vegas is the North American launch. It is built and supported by Assetsoft, delivered on our KriyaGo integration and automation platform, and hosted in a dedicated environment per client.

Who is it for? Any MRI PMX client with more than a handful of bank accounts: third-party fee managers, REITs with trust-accounting obligations, investment managers reconciling fund and property-level accounts, and owner-operators who want the close to be boring again. If your team touches a bank statement in a spreadsheet, ABR is worth 20 minutes at the booth.

See it live or see it now. We will run ABR demos continuously at the Assetsoft booth throughout MRI Ascend. If you cannot make it to Las Vegas, or you would rather see it on your own data before you arrive, request a virtual ABR demo, and we will schedule a 30-minute session on a PMX environment this month.

The most useful conversations start with a specific problem. These are the five we hear most often from MRI clients, and each one has a concrete answer we can show rather than describe.

1."We reconcile 200+ bank accounts in Excel. What does day one on ABR look like?"We will walk through onboarding: bank format mapping, rule configuration against your receipt and disbursement patterns, and the first parallel run. Most clients live on their first group of accounts within weeks, not quarters.

2."We are still on Web X.5. Should we upgrade to PMX 10.7 before or after the new Agora capabilities land?" We will show the upgrade path, the modules affected, and how to sequence an upgrade so you are not rebuilding integrations twice.

3."Our AP invoices come in by email and get keyed into MRI by hand. What are the options?" We will demonstrate document capture into MRI AP, comparing MRI-native tooling, UiPath document understanding, and our own Document AI, so you can choose based on volume and budget.

4."We use SAP Concur for expenses and MRI for the GL. They do not talk." We will show the Concur-to-MRI integration pattern we use for expense import and AP automation.

5."We are migrating from Yardi, Sage or JD Edwards to MRI. What goes wrong?" Ask our conversion team. We have run hundreds of migrations in both directions and keep a list of what breaks: open AR, security deposits, CAM pools, historical attachments, and job-cost commitments.

If your question is not on this list, bring it anyway consultants, not salespeople, staff the booth.

Depth in MRI, breadth across the stack.We are an MRI Software Gold Service Partner with full PMX implementation, migration, Analytics BI, and support practice. We are also certified on Yardi, Procore, SAP Concur, and UiPath, which matters because no MRI client runs MRI alone. Construction data lives in Procore, expenses in Concur, documents in SharePoint, and the bank is the bank. Assetsoft connects those systems to MRI as part of the engagement rather than handing you a list of other vendors.

We build as well as consult. ABR exists because our consultants reconciled bank statements for clients for years and decided to solve the problem in software. The same R&D group, Assetsoft Labs, builds our integration platform, Document AI and smart notifications. Clients get a partner who understands the accounting and owns the code.

Global delivery, local accountability. Projects are led onshore from Canada and the United States, with delivery centers in Pune, Chennai, and Sri Lanka that give clients 24/7 support coverage and cost-effective capacity for migrations, testing, and reporting work. Our ANZ practice supports MRI clients across Australia and New Zealand from Sydney.

Measured, not marketed.Since 2012, Assetsoft has delivered more than 500 implementations across four continents with a 98% project success rate and a 4.9 average client rating. We are happy to put you in touch with reference clients on MRI in the United States, Canada, and Australia.

Industry knowledge first. Our consultants have worked inside property management, investment management and construction companies. We understand CAM recovery, trust accounting, fund waterfalls, draw management and affordable-housing compliance as business processes, not just as MRI screens.

Somewhere this morning, a $3,800 landscaping invoice for a suburban retail center was approved, coded to the right GL account, matched to a purchase order, and queued for payment. Nobody in accounts payable looked at it. Nobody in property management looked at it. An agent did, with a second agent checking its work, and both cleared a confidence threshold someone set in a configuration screen six months ago.

That is not a hypothetical. Yardi's Smart Approval agent, part of Virtuoso, evaluates eligible invoices against learned rules and approves those that qualify; one agent decides, and a second confirms or challenges it. MRI's Agora Orchestrator, launched in June 2026, moves workflows from recommendation to automated execution across commercial, multifamily, and residential portfolios. Both are good products. Both answer a question most property finance teams have not asked yet: when an agent acts, who authorized that?

The wider enterprise is asking it loudly. This week the US Federal Trade Commission opened a broad investigation into frontier-model risk, after a run of incidents in which agents reached systems they were never meant to touch. Fortune reported that the CIOs of Cisco, Intuit, Workday and ServiceNow are building oversight layers around agents, with Cisco's operations chief refusing to authorize any third-party vendor agent at all to avoid "agent sprawl."

The number that should stop a CFO mid-sentence comes from a 2026 survey of 235 large-enterprise security leaders, cited by the Cloud Security Alliance: 71% say AI systems already have access to core ERP, CRM, and financial platforms, and only 16% govern that access effectively. In property management, where the ERP is Yardi or MRI and the "financial platform" is the rent roll, the gap is the same, and the controls are thinner.

This is a playbook for closing it before you switch on native platform agents, not after.

The word "agent" covers a lot of ground, and governance only works if you know which kind you are dealing with. Inside the two dominant property platforms, agents now sit at three levels of autonomy.

Level 1: It answers. Yardi Chat IQ handles prospect and resident conversations across chat, email, text, and voice, grounded in live Voyager data. MRI Agora Intelligence watches the portfolio and recommends actions. These agents read a great deal of data but post nothing to the ledger. The governance risk is disclosure and accuracy, not transactions.

Level 2: It acts within rules. Yardi Smart Approval, paired with Smart AP, captures, codes, and approves invoices that meet amount, vendor, property, and GL criteria you define, using 12 months of your approval history to generate vendor-specific rules. MRI Agora Orchestrator lets teams deploy agents from a pre-built catalog, configure them, and, in MRI's words, let them run. These agents post transactions. They are, functionally, approvers with system access.

Level 3: It builds other agents. Yardi Virtuoso Composer and MRI's agent configuration tools let operators create custom agents without code. A property accountant can now build an agent that reconciles a bank feed, chases tenants, or prepares a month-end journal. Nobody in IT needs to be involved, which is the point- and the problem.

The shift that matters is from Level 1 to Level 2. Once an agent can approve, post, or pay, it has stepped into the control environment that external auditors, lenders, and investors rely on; in most property firms, that environment was designed in the era of named users, wet signatures, and dollar-threshold approval matrices. Agents do not fit it, and the platforms do not retrofit it for you. MRI's own announcement frames Orchestrator as keeping every decision with the person responsible for it; Yardi lets you set amount and confidence thresholds. Both leave the design of that responsibility to you.

Cisco's answer to agent sprawl was to centralize every authorized model, agent and dataset on one internal platform and refuse third-party agents entirely. Few property companies can do that, and most should not. But the reasons Cisco worries apply with more force to a real estate operator than to a software company.

Agents arrive inside the platform, not through IT. A Yardi or MRI release note enables them. A regional controller switches one on for a trial. A marketplace agent gets added to a module during an upgrade. There is no procurement event, no security review, no change ticket. Intuit's CIO describes the resulting risk as agents that get orphaned and become an attack vector when their creator leaves. In property management, where turnover in site and regional accounting roles is high, orphaned agents will be common within a year.

The control environment is shared with third parties. Owners, managers, lenders, joint-venture partners, and outsourced accounting teams all touch the same Yardi or MRI database. An agent enabled by a third-party manager can approve invoices on an owner's property. Whose approval matrix applies? Whose auditor signs off? Management agreements written in 2022 do not say.

Month-end is a chain of dependent steps. Bank reconciliation, accruals, CAM reconciliation, intercompany, investor reporting. An agent that executes one step well can push an error into every step after it, and the error surfaces three weeks later in a distribution calculation. Agents fail fast; property accounting discovers slowly.

The volume case is strongest where the controls are weakest. Yardi reports that 80% of client invoices are under $5,000 and take at least six days to approve. Those are exactly the invoices nobody scrutinizes today, which is why automating them is attractive, and why the fraud and duplicate-payment risk concentrates there.

None of this argues against agents. It argues for treating the day you enable a Level 2 agent as a control-environment change, with the same rigor you would apply to giving a new employee approval authority.

External auditors have not yet published an agent-specific standard for real estate, but the questions are predictable because they are the questions already asked of any automated control. Expect these five in your next audit planning meeting and expect them from lenders and institutional LPs soon after.

The single most useful mental shift is to stop thinking of an agent as a feature and start thinking of it as a new hire. New hires get a role, a manager, a set of system permissions tied to that role, an approval limit, and a review date. Agents should get the same.

A role, not a toggle. In Yardi, create a dedicated security role for each agent rather than letting it inherit the permissions of whoever enabled it. In MRI, do the same with the agent's service identity. The role should allow only the tables, properties, and transaction types the agent needs. The CSA's guidance is that agents should not hold standing access to production systems and should get time-bound, task-scoped credentials where the platform supports it. Few property platforms do yet; where they do not, a narrow dedicated role is the compensating control.

A manager. Every agent needs a named human owner who is accountable for its thresholds, reviews its exception log, and is the first call when it misbehaves. This is normally the controller or AP manager for finance agents and the regional property manager for operational ones. Record the owner in the agent register. When that person leaves, reassign or disable the agent the same day as their user account.

Thresholds that mirror the delegation matrix. Most owners already have a delegation-of-authority matrix: a site manager approves up to $2,500, a regional manager up to $10,000, a VP up to $50,000. An agent's approval limit should be a line in that matrix, approved by the same governance body, not a number typed into a configuration screen. Consider three dimensions, not one:

• Amount per transaction (Yardi's beta clients ran Smart Approval at up to $2,500, a sensible starting point)

• Cumulative amount per vendor per period, which catches split invoices

• Confidence threshold, set conservatively at launch and loosened only on evidence

A review date. Agents learn from history, and their rules drift. Schedule a quarterly review of each Level 2 agent's thresholds, exception rate, and false-approval rate, and minute the results. Treat a change to an agent's limits as a change to the delegation matrix, requiring the same sign-off.

This is unglamorous work. It is also exactly what distinguishes a firm that can show an auditor a control from one that can show them a screenshot.

Segregation of duties is the oldest control in accounting: the person who creates a vendor should not approve its invoices, and the person who approves invoices should not release payments. Agents break this in two easy-to-miss ways.

The agent collapses the chain. Smart AP captures and codes the invoice; Smart Approval approves it; a payment run releases it. If all three are agents configured by the same AP manager, that manager has, in effect, end-to-end control of cash disbursement through a tool that never pushes back. Yardi's two-agent design, where a second agent must confirm the first, is genuine control, but it is a control within the vendor's logic, not within your SoD matrix. Your matrix needs to say which human reviews the agent's exceptions and which human can change its rules, and those should be different people.

The agent inherits a person's conflicts. An agent built in Virtuoso Composer by a property accountant typically runs with that accountant's permission. If the accountant can both post journals and approve them in a small-team configuration, so can the agent, at scale and without the accountant noticing. Agents built on over-privileged human roles are the most common finding in the governance reviews we have seen this year.

The practical fix is a three-column exercise. List every agent. For each, record the duties it performs using the same categories as your human SoD matrix: initiate, approve, record, reconcile, custody. Then overlay the human owners and configurations. Where one person, directly or through agents, touches two conflicting duties for the same transaction stream, you have a finding. Resolve it by splitting the agent's role, moving ownership, or adding a documented compensating review.

Two further SoD points for property firms specifically. First, in a third-party management arrangement, make the owner's finance team, not the manager's, the approver of agent thresholds on owner-funded bank accounts. Second, treat agent rules as privileged access: log them, review them monthly, and keep the ability to change rules away from the people whose work the agent approves.

A log is not evidence until someone can show it answers a question. Property platforms log agent actions, and MRI explicitly positions Orchestrator around the governance and audit trail enterprise operators require. But auditors want more than a list of what happened. They want assurance that the agent does what you say it does, every time, and that its behavior hasn't drifted. Two disciplines borrowed from enterprise automation answer that.

Test automation proves the agent behaves as configured. Treat an agent's rules the way you would treat a Yardi or MRI configuration change: write test cases and run them before go-live and after every platform upgrade. A regression suite built in a tool such as UiPath Test Suite can push a controlled set of invoices through the AP workflow (a duplicate, a split invoice, an over-budget line, a new vendor, an invoice at the threshold, one just above it) and confirm that the agent approves, holds, or escalates each one correctly. The output is a dated, repeatable test report that says: on this date, with these rules, the agent made these decisions. That is control evidence. Re-run it quarterly and after every Yardi or MRI release, and you have a continuous-assurance record instead of a one-time sign-off.

Process mining proves what actually happened in production. Test cases cover what you thought to test. Process mining reads event logs from Yardi, MRI, and surrounding systems and reconstructs how invoices, work orders, or journals actually flowed, including paths nobody designed. It answers the questions auditors and CFOs ask after the fact: What share of invoices did the agent approve versus route to a human? How often did a human override it? Did any approval bypass the purchase-order match? Did the agent's approval rate for a particular vendor jump in a particular month? Those patterns are invisible in a transaction log and obvious in a process map.

Together, the two give you something most firms lack: a before-and-after baseline. Mine the AP process for six months before enabling Smart Approval or an Orchestrator workflow. Record cycle time, touch count, exception rate, and error rate. Enable the agent. Mine again. Now the ROI claim in the board paper is measured, the control claim in the audit file is evidenced, and drift is detectable because you know what normal looked like.

One caution. Both techniques depend on clean, consistent event data from the platform. Firms whose Yardi or MRI instance carries years of inconsistent coding, custom tables, and workarounds often find that the first governance project is data clean-up, not a control design.

Run this before enabling any agent that can approve, post, pay, or change master data. It takes a competent controller and a platform administrator for two to four weeks for a first agent and a few days for each one after.

Before enablement

• Add the agent to the agent register: platform, purpose, owner, enablement date, autonomy level

• Create a dedicated security role with least privilege of access; do not inherit a human user's permissions

• Set amount, cumulative-vendor and confidence thresholds, and add them as a line in the delegation-of-authority matrix with the same sign-off

• Map the agent's duties against the SoD matrix and resolve or document any conflict

• Capture a process-mining baseline of the workflow it will touch

• Build and run a regression test set covering normal, boundary, and adversarial cases

• Confirm where the agent's reasoning and actions are logged, how long logs are retained, and who can read them

• Write the kill-switch procedure: who turns it off, how, and what the manual fallback is for month-end

• Where third-party managers or owners are involved, confirm in writing whose approval matrix governs

First 90 days

• Owner reviews the exception log weekly

• Re-run the regression suite after any platform release

• Compare post-enablement process-mining data to baseline at day 90; report cycle time, override rate and error rate

Ongoing

• Quarterly threshold review, minutes

• Agent reassigned or disabled on the day its owner leaves

• Register and evidence pack presented to the audit committee annually

None of this slows down a well-run deployment. It mostly moves work that would otherwise happen in a panic, three weeks after a distribution went out wrong, to a planned fortnight before go-live.

Agent governance is not a standalone project, and firms that try to run it as one tend to produce a policy document that nobody reads. It works when it is attached to four things most property operators are already doing or planning.

A platform health check. You cannot govern agents on a Yardi or MRI instance you do not fully understand. Most operators running a platform for five or more years carry undocumented customizations, dormant user accounts, over-broad security roles, and workflow exceptions that were "temporary" in 2021. A structured health check of security roles, workflows, configuration, and data quality is the prerequisite: it tells you which human roles are safe to model agent roles on, and which are not.

A Yardi or MRI AI strategy.The platforms are shipping agents faster than any operator can evaluate them. A written AI strategy decides which workflows are candidates for Level 2 automation, in what order, under what thresholds, and what the business case has to show. It is also where the firm decides its posture on third-party and custom agents, the question Cisco answered with an outright ban and most property firms will answer with a tiered approval process.

Test automation. The regression suite described above is the same asset that de-risks every platform upgrade. Firms that have invested in UiPath Test Suite or equivalent for Yardi and MRI releases already have the harness; adding agent test cases is incremental. Firms that have not usually find that the agent project is the business case for building it.

Process mining.The baseline-and-compare method is also how you find the next workflow worth automating, measure the one you just automated, and give the audit committee numbers instead of adjectives. It tends to pay for itself in the AP process alone.

Firms such as Assetsoft, which has implemented, integrated, and supported Yardi and MRI for owners and managers in Canada, the United States, and Australia since 2012 and runs UiPath test-automation and process-mining engagements on those platforms, see the same pattern across clients: governance done before enablement is a two-week task; governance done after the first incident is a two-quarter one. The difference is rarely the technology. It is whether anyone owned the agent register.

On Tuesday, September 29, 2026, the White House gathered the heads of OpenAI, Anthropic, Google, Meta, Nvidia and xAI to sign a voluntary frontier AI safety accord built on internal controls, outside audits and board oversight. The same week, the US Federal Trade Commission opened a broad probe into frontier-model risk, and Bank of England governor Andrew Bailey argued that financial regulators need a formal "right to intervene" when autonomous systems threaten cyber or financial stability.

That is the macro story. The micro story is sitting in your property management system. Since June 2026, Yardi's Virtuoso Connector has been part of Virtuoso Enterprise, letting live Yardi data flow into Anthropic's Claude through an MCP connector, with other models promised to follow. MRI Software's Agora platform and a growing ecosystem of "bring your own AI assistant" tools are heading the same way.

So the tenant ledger, the rent roll, the bank reconciliation file, and the lease abstract that your team spent a decade protecting behind role-based security are now one authenticated connector away from a large language model. Most of those models are hosted outside your country, run by vendors who can change them with a release note, and sit inside a regulatory perimeter that moved twice this week.

This is what "model sovereignty" means for real estate finance: knowing, and being able to prove, which AI models touch your tenant PII, bank data, and lease terms, under whose laws, and what happens when a vendor swaps a model or a regulator steps in. The rest of this guide gives a CFO a practical frame for answering that in Canada, Australia, and the United States.

Data sovereignty is a familiar term: your data is subject to the laws of the country where it is stored. Model sovereignty is the next layer. It asks who controls the model that reads, reasons over, and acts on that data, where the inference happens, and whether you can change or exit that arrangement on your own terms.

For a property owner or manager, three classes of data make this concrete:

•Tenant and resident PII. Names, contact details, screening results, payment history, and in residential portfolios, information about dependants and guarantors. This is the data privacy regulators care about most.

•Bank and treasury data. Bank account numbers on vendor and tenant records, lockbox files, automatic bank reconciliation feeds, and payment instructions. A model that can read your Yardi or MRI bank reconciliation workflow can see every counterparty you pay.

•Lease and commercial terms. Rent steps, percentage-rent clauses, co-tenancy rights, renewal options and CAM caps. Not personal data in the legal sense, but commercially sensitive, and frequently covered by confidentiality clauses with the tenant.

An LLM connector does not copy your database. It retrieves records on demand, under the connecting user's permissions, and passes them to the model as context. That is a sensible design, and Yardi's connector authenticates through Yardi, so access follows existing user permissions. But every record retrieved still leaves your system boundary, crosses into the model provider's infrastructure, and is processed under that provider's terms, region, and retention policy.

The practical question for finance is therefore not "does the vendor encrypt the data?" It almost certainly does. The question is: for every AI feature we switch on, can we name the model, the hosting region, the retention period, the subprocessor chain and the exit path?

Boards do not need a tutorial on transformer architecture. They need four answers, in writing, from every vendor whose product connects property data to an AI model.

1. Which models touch our data, and where do they run? A vendor that says "we use leading AI" has not answered. You want the model family, the version, the provider, and the inference region. Yardi's connector today runs on Claude; its own press material says additional LLMs will follow. That is normal product evolution, but each addition is a new data flow to assess.

2. Under whose jurisdiction? A Canadian REIT whose tenant data is retrieved by a connector and processed by a model hosted in the United States has made a cross-border transfer, whether or not anyone called it that. The same applies to an Australian fund manager using a US-hosted model, or a US owner whose offshore accounting team queries the connector from Pune or Manila. Jurisdiction attaches to where processing happens and who can compel access, not to where the head office is.

3. What happens if the vendor swaps models? The AI market is moving fast enough that model swaps will be routine. A vendor may switch providers for cost, performance, or commercial reasons. Your contract should define that as a material change requiring notice, an updated data-flow description and, where the new model sits in a different jurisdiction, your consent.

4. What happens if a regulator intervenes? This week showed two different regulatory postures. Washington chose a voluntary accord with no penalties. The Bank of England asked for the power to step in. If a supervisor orders a model provider to suspend a capability, or an Australian or Canadian privacy regulator restricts a transfer, which of your month-end processes stop working? Business continuity planning now has to include "the model is unavailable" alongside "the data center is down."

Canada does not prohibit sending personal information to a model hosted abroad, but it makes you accountable for what happens to it there.

Under PIPEDA, the accountability principle follows the data. If a US-hosted model processes a Toronto or Vancouver property manager's tenant records, the organization remains responsible for providing a comparable level of protection through contractual and other means. The Office of the Privacy Commissioner's long-standing position is that transfers for processing require transparency with individuals that their information may be processed in another country. It may be accessible to that country's authorities. In practice, that means your privacy notice to tenants and residents needs updating as soon as an AI connector goes live.

Quebec's Law 25 goes further and is the stricter benchmark for any national portfolio. Three obligations matter here:

• Privacy impact assessment before transfer. Any communication of personal information outside Quebec requires a documented assessment of the destination's legal framework, the data's sensitivity, and the protective measures in place. A connector to a US-hosted model is squarely in scope.

• Automated decision notice. When a decision is based exclusively on automated processing, the individual must be informed and given a route to make representations to a human. Tenant screening, late-fee waivers, and renewal pricing are the first places AI touches decisions in property operations.

• Privacy by default and a named privacy officer. Someone in the organization must own the AI data-flow register, not just the privacy policy.

There is also the federal context. Canada's proposed Artificial Intelligence and Data Act did not survive the last Parliament, and no replacement has passed, so for now Law 25 and PIPEDA are the binding rules, with Ontario's public-sector AI rules affecting municipal and Crown landlords.

For a Canadian CFO, the pragmatic position is this: treat every AI connector as a cross-border transfer, run the Law 25 assessment nationally rather than only for Quebec properties, and make model region and retention explicit in the vendor's data-processing schedule.

Australia is midway through the most significant privacy overhaul since the Act was written, and two dates sit directly on the property calendar.

10 December 2026. From that date, new Australian Privacy Principle 1.7 requires an APP entity that uses personal information in automated decision-making that could significantly affect someone's rights or interests to disclose that practice in its privacy policy. The obligation covers decisions made solely by automation and decisions substantially assisted by it. A tenancy application declined on an automated score, or a rent review generated by an AI agent and rubber-stamped by a property manager, is in scope. Using a vendor's engine does not move the obligation: you are still the one deciding on the tenant.

Tranche 2. On 31 August 2026, the Government released the exposure draft of the Privacy Amendment (Personal Data Protection) Bill 2026, packaging roughly 40 proposals. Consultation closed on 17 September. Expect a stronger fair-and-reasonable test for data handling, tighter rules on direct marketing and a renewed push toward EU-style standards. The small-business exemption is also under review, which matters for the many strata and boutique agencies that currently sit outside the Act.

Already live is the statutory tort for serious invasions of privacy, in force since June 2025, and the enlarged penalty regime from the 2022 and 2024 amendments. A model that leaks a resident's details through a misconfigured connector is no longer only an OAIC matter; it is a civil claim.

On cross-border transfers, APP 8 applies: before disclosing personal information to an overseas recipient, including a model provider, you must take reasonable steps to ensure it complies with the APPs, and you remain liable for its breaches unless an exception applies. Most US-hosted frontier models fall under this. Your vendor's assurance that it is "SOC 2 compliant" is useful evidence but not a substitute for the APP 8 analysis.

For an Australian CFO using Yardi or MRI, the near-term task is to register every AI-assisted decision touching tenants, cross-referenced to the model and region used, and finish it before December.

The United States has no federal privacy statute and, as of this week, no binding federal AI rule. The White House accord asks frontier labs for internal monitoring, external audits, and board committees, and leaves the door open to legislation later. That gives a US property owner less certainty, not more.

Three forces fill the gap:

• State privacy laws. California (CCPA/CPRA), Colorado, Virginia, Texas, Connecticut, and more than a dozen others now give residents rights over personal data and, in several states, specific rules on automated decision-making and profiling. Colorado's AI Act, aimed at high-risk automated decisions including housing, is the one to watch for tenant screening and pricing.

• The FTC. The Commission opened a broad investigation into frontier-model risk this week. The FTC has a long record of treating poor data security and misleading privacy claims as unfair or deceptive practices. A property manager that tells residents their data is "never shared with AI" while running an LLM connector has a Section 5 problem.

• Fair housing. HUD and the courts have already signaled that algorithmic tenant screening and pricing can produce disparate impact. An AI model that participates in those decisions pulls the whole model-governance conversation into fair-housing compliance.

The quieter risk is bank data. Property management systems hold vendor and tenant bank account details, lockbox files, and reconciliation feeds. Many owners also act as agents for lenders and investors. Once a model can read the bank reconciliation workflow, your exposure under state financial-data laws, your lender covenants and your cyber-insurance warranties all need rereading. The same logic drove the Bank of England's intervention call: finance regulators are not waiting for a general AI law to worry about autonomous systems touching payment data.

For a US CFO, the practical frame is: assume your strictest state applies portfolio-wide, document AI's role in every tenant-facing decision, and ring-fence bank and payment data from general-purpose AI access until the vendor can show a specific, audited control.

None of this is an argument against connecting Yardi or MRI to an LLM. The productivity case is real: asking "which properties are likely to exceed budget next quarter" in plain language and getting an answer grounded in live data is exactly what Yardi describes Virtuoso Connectors doing. The argument is for switching it on with your eyes open.

Here is the question set a finance team should put to Yardi, MRI Software, and any third-party AI vendor before, not after, enabling a connector.

Two observations from running this exercise with clients. First, the answers are often better than people fear. Enterprise model providers typically offer no-training, limited-retention terms, and Yardi's permission-inheritance design is the right one. Second, nobody can answer the scope-control question until someone in your organization has actually mapped which fields in the Yardi or MRI schema hold PII and bank data. That mapping is a data-strategy task, and it is usually missing.

Most property technology contracts were drafted for software, not for models. They cover uptime, support tiers, and data ownership. They rarely say anything about which AI processes your data or what happens when that changes. Six clauses close the gap.

1. Model and region schedule. A schedule to the data-processing agreement naming the model provider, model family, inference region, and retention terms, updated by the vendor upon any change.

2. Material-change notice. A model swap, a new subprocessor, or a change of hosting region is a material change requiring 60 to 90 days' written notice and, where jurisdiction changes, your written consent.

3. Training and retention prohibition. Your prompts, retrieved records, and outputs are not used to train or fine-tune any model, and are not retained beyond the session except for security logging with a stated limit.

4. Scope and field exclusions. The connector will not retrieve named categories of fields, such as bank account numbers, government identifiers, and screening results, without a separate written enablement.

5. Regulatory suspension. Either party may suspend the AI feature without penalty if a regulator restricts the model or the transfer, and the vendor must provide a non-AI path for the affected workflow.

6. Portability and deletion on exit. On termination or feature disablement, all stored context, embeddings, and indexes derived from your data are deleted and certified, and any configuration you built is exportable.

Lock-in in the AI era is subtle. It is not only that your data lives in the vendor's database; it is that your prompts, agents, custom skills, and the institutional knowledge embedded in them live inside one model ecosystem. Yardi's Virtuoso Composer and MRI's Agora Orchestrator both let you build agents. Ask early how those agents would move if the underlying model, or the vendor, changed. A portfolio that has built 40 agents on one platform has made a strategic commitment, whether or not the board approved it.

You don't need a two-year program. Ninety days of disciplined work puts most owners and managers in a defensible position before the Australian December deadline and ahead of whatever Washington or Ottawa does next.

Days 1 to 30: know what you have

• Inventory every AI feature already enabled across Yardi, MRI, Procore, banking portals and productivity tools, including the ones individual teams turned on themselves

• Map the fields in your property management schema that hold tenant PII, bank data and confidential lease terms

• Identify every AI-assisted decision that affects a tenant, resident, vendor or investor

Days 31 to 60: ask and assess

• Send the due-diligence question set to each vendor and record the answers in a model register

• Run the cross-border transfer assessment (Law 25 PIA, APP 8 analysis, strictest-state review) for each model and region

• Update tenant and resident privacy notices to disclose AI processing and automated decision-making

Days 61 to 90: control and contract

• Apply field-level exclusions so bank and identity data stay out of general-purpose connectors

• Negotiate the six clauses above into renewals and new AI feature enablements

• Add "model unavailable" to the business continuity plan for month-end close, rent collection and bank reconciliation

• Brief the board or audit committee on the model register and residual risks

The register is the single most valuable output. When a regulator, auditor, lender or tenant asks, "is our property data safe in AI?" the answer is a document, not a reassurance.

Model sovereignty is not a legal project with a technology appendix. It is three disciplines that real estate firms often run separately, now forced into one room.

Yardi and MRI data strategy answers the first question: what do we actually hold, where, and how sensitive is it? Firms that have invested in a governed data layer, with a clear chart of accounts, consistent property and lease coding, and a field-level data dictionary, can map PII and bank data to an AI connector in days. Firms that have not are discovering that their "single source of truth" has nine custom tables nobody documented. An AI-ready data strategy is also what makes the model's answers trustworthy in the first place; a connector that reads inconsistent data produces confident, inconsistent analysis.

Technology strategy answers the second and third questions: which platforms, in which regions, under which model providers, and with what exit paths. A sensible 2026 technology strategy for a property owner treats the AI model as an architectural component with its own lifecycle, not as a feature inside the ERP. It defines where general-purpose assistants are allowed, where domain agents belong, and which workflows stay deterministic. For many portfolios, it also means a middleware layer between the system of record and any model, so that field exclusions and audit logging are enforced once rather than per vendor.

Software selection advisory is where the clauses get written. Whether you are choosing between Yardi Voyager and MRI, evaluating Procore for construction, or deciding whether to adopt a vendor's native AI platform or bring your own assistant, the model-sovereignty questions belong in the RFP scoring, not in a post-signature security review. Selection processes that weight data residency, model transparency and portability alongside functional fit are producing noticeably better contracts this year.

Firms like Assetsoft, which has implemented and integrated Yardi, MRI, and Procore for owners across Canada, the US, and Australia since 2012, are increasingly asked to run this three-part exercise: map the data, design the architecture, and carry the requirements into selection and contract. The common thread in the engagements that go well is that the CFO, not the IT manager, owns the model register.

YASC stands for the Yardi Advanced Solutions Conference. It is the annual user conference Yardi Systems runs for its clients, and it has grown from two US events in the mid-2000s into six in-person conferences on four continents plus a free virtual edition each spring. The North American event is the largest, and San Diego has been its home for several years running.

YASC is a client event, not a trade show. Registration is open to Yardi clients, and the content is built for people who already run Yardi software and want to run it better. That changes the tone. Yardi product staff and industry principals teach sessions; classrooms are organized by product and vertical; and a large share of the audience includes controllers, property accountants, systems administrators, IT leads, and operations managers rather than buyers kicking tires.

For the class catalog, hotel blocks, registration status, and the Yardi Events app, use Yardi's pages: the YASC hub and the event summary. Yardi's own preview, YASC San Diego 2026: Bringing AI to the forefront, is the best single read on what the company intends to showcase.

If you work in Canada, note that YASC Canada already ran earlier in 2026; we covered Peter Altobelli's announcements in Yardi Canada's biggest leap since Y2K. San Diego is where the full North American roadmap gets its widest airing, and many Canadian clients attend both.

Yardi is no longer a single product with add-ons. It is a connected platform, and the easiest way to make sense of 250 classes is to map them against the layers below. Each heading links to Yardi's own product page; we are describing what matters for an operator, not restating the brochure.

Voyager Suite is the core: property management and accounting for commercial, residential, affordable housing, PHA, and senior housing. Voyager 8 is the current generation, and upgrade planning, custom-report migration, and the retirement of legacy plug-ins are the questions we hear most from clients still on 7S. Expect Voyager 8 classes to be full.

Yardi Virtuoso is the AI layer that runs across the whole suite. Virtuoso Enterprise lets organizations create, deploy, and govern AI agents against live operational data, with no-code agent tooling and the Virtuoso Connectors that reached general release this summer (our breakdown: Yardi Virtuoso Connectors now in general release). If YASC 2026 has one headline, it is Virtuoso.

RentCafe covers marketing, leasing, resident portals, and payments for multifamily, with affordable, PHA, and senior living variants. CommercialCafe does the same for commercial tenants.

Procure to Pay Suite (PayScan, Bill Pay, VendorCafe, VendorShield, Marketplace) is where AP automation lives. Combined with Virtuoso document intelligence, this is the most immediate ROI story on the floor.

Elevate Suite covers asset performance: Asset IQ, Forecast IQ, and Revenue IQ on the residential side; Deal Manager, Construction Manager, Facility Manager, Forecast Manager, and Floorplan Manager on the commercial side. Smart Lease, Yardi's AI lease abstraction, sits here too.

Investment Suite handles the fund side: Investment Manager, Investment Accounting, Debt Manager, Performance Manager and Acquisition Manager. If you run funds or JV structures, the investment track at YASC is consistently one of the strongest.

Energy Suite, Yardi Breeze for small to mid-size portfolios, Yardi Kube for flexible workspace, the Care Suite for senior living, and the data products (Data Connect, Replicate) round out the catalog. The data products deserve more attention than they usually get: they are the foundation every AI use case depends on, as we argued in Yardi data architecture for AI.

The practical point: almost nobody uses all of this well. YASC is the one week a year where the people who built each piece are in the same building as the people who have to make it work.

Three days, roughly eight o'clock to five, with evening events on two of the nights. Here is how the week is structured and what each piece is actually for.

The bulk of the agenda. Classes are grouped by product and by market, so a commercial controller, an affordable compliance lead, and a multifamily marketing manager will each have a distinct track. Yardi staff teach classes, peer-led roundtables include a Yardi facilitator, and client panels bring operators on stage to explain what they did and what went wrong. Expect three types of sessions:

• Product deep dives: what a module does, including features released since last YASC and features on the near-term roadmap.

• Workflow sessions: how to run a process end-to-end (month-end close, CAM reconciliation, lease-up, draw management) using several modules together.

• Strategy sessions: AI governance, data readiness, change management, and executive panels on where the platform is heading.

The full class list is published in the Yardi Events app and on the event page in the weeks before the conference. Classes with hands-on labs fill fastest.

Yardi leadership and the product roadmap

Yardi executive leadership takes the stage with an exclusive look at the product roadmap and the trends it is building toward. In 2026, that means Virtuoso Enterprise, agents, Voyager 8, and the connected platform. This is the session to attend if you have to go back and brief a board or an executive team.

Knowledge Central

Yardi's one-stop support zone, open throughout the conference. You can book one-on-one time with product specialists, get a tailored overview of a module you are considering, or bring a specific configuration problem and work through it live. For many attendees, this is the week's highest-value hour. Bring screenshots.

Networking reception and the Yardi Party

The networking reception is a sunset event on the waterfront, and the Yardi Party is the headline evening with live music. Both are badge-access only. They sound like the fun part, and they are, but they are also where you meet the controller from another REIT who solved the exact intercompany problem you are stuck on.

Partners and consultants

Yardi's ecosystem of interface partners, Independent Consultant Network members, and service providers is on site. This is the right place to ask the questions Yardi itself cannot answer neutrally: which third-party tools work, which integrations are brittle, and who has done your kind of project before.

For registration, hotel blocks, and the current agenda, go to Yardi's YASC pages. Registration is restricted to Yardi clients, and guest-pass rules are set out there.

The difference between a good YASC and a wasted one is preparation. Here is what we tell our own clients.

1. Write down your three problems. Not "learn more about AI" but "our CAM reconciliations take six weeks" or "we cannot get Procore job cost into Voyager without rekeying." Measure every session, booth visit, and Knowledge Central slot against those three.

2. Split the team across tracks. If three people attend, cover finance, operations, and technology rather than sitting together. Agree on a nightly fifteen-minute debrief.

3. Book Knowledge Central early. Slots with the most popular specialists (Voyager 8 upgrade, Virtuoso, Investment Accounting) go within the first morning.

4. Read the release notes for your current version. Half the "new" features people get excited about at YASC are already in their environment, unconfigured.

5. Line up partner meetings in advance. Consultants and interface partners have calendars that fill before the conference opens. Ours included.

Sessions worth prioritizing in 2026

• Virtuoso Enterprise and agents: how to build, govern and measure an agent. Ask who owns the agent after go-live and how you audit what it did.

• Voyager 8 upgrade paths: especially if you have custom reports, custom plug-ins, or SQL-based integrations.

• Procure to Pay with document AI: the fastest payback in the suite, and the easiest to pilot.

• Data Connect and Replicate: if your BI, Fabric, or Power BI strategy depends on Yardi data, these are not optional.

• Your vertical's roundtable: commercial, affordable, senior, investment, or PHA. Peer roundtables are where the real configuration advice gets traded.

Questions to ask Yardi staff

• What is the recommended path from where we are to Virtuoso Enterprise, and what is the licensing model?

• Which of these features require Voyager 8, and which run on 7S?

• What does the SIPP (Standard Interface Partner Program) mean for the integrations we rely on today?

• How does Yardi recommend handling historical data and attachments during a conversion?

After you get home

Turn the notes into a one-page list: what to switch on now, what needs a project, what needs budget. Assign an owner to each line. Then decide which of the projects you will run with your internal team and which need outside help. If the answer is "we need help, but we are not sure who," that is the conversation to have with us while you are still in San Diego.

Assetsoft is a multi-platform PropTech consultancy founded in 2012, headquartered in Markham, Ontario, with delivery teams across Canada, the United States, India, and Sri Lanka. We are a Yardi Independent Consultant Network (ICN) member and Yardi Virtuoso Qualified, and we are also an MRI Software Gold Service Partner, Procore Partner, and SAP Concur Integration Partner. That mix matters at a Yardi conference, because a growing number of the projects we start on another platform and end on Yardi.

Our team will be at YASC all three days. Here is what to bring us.

If you are still on 7S, or you upgraded and nothing feels faster, we can walk through your custom reports, plug-ins, interfaces, and reporting stack and tell you what the upgrade will touch. Our platform health check is designed to be scoped in a single conversation.

MRI, Sage, JD Edwards, or spreadsheet-to-Yardi conversions

Data conversion is where Yardi projects go wrong, and it is where we have spent the most time. We have converted commercial, multifamily, affordable, and investment portfolios from MRI, Sage 300 CRE, and legacy systems, and we are building a middleware conversion utility that reduces manual mapping effort. Read our Yardi and MRI data migration playbook before you come, then bring your cutover questions.

Virtuoso AI readiness and AI strategy

We are Virtuoso Qualified, and we spend a lot of our time telling clients what to fix before they switch anything on: chart of accounts hygiene, attachment strategy, Data Connect and Replicate foundations, and governance. Our Yardi AI strategy and Yardi data strategy pages describe the approach.

Complex modules

Investment Management and fund accounting, Job Cost and Construction Manager, CAM recovery and reconciliation (see CAM reconciliation and recovery: how to stop leaving money on the table), Energy Suite, and affordable housing and Canadian social housing compliance.

Managed help desk and test automation

A shared Yardi support desk with ticketing standards, SLAs, and a named manager, for clients who do not want to hire a full-time Yardi administrator. Plus automated regression testing of Yardi workflows, so an upgrade or Virtuoso rollout doesn't break month-end.

We work with clients in the United States, Canada, and Australia, and our delivery centers give us overnight coverage for all three. Whether you are a REIT in Dallas, a social housing provider in Ontario, or an industrial fund in Sydney, the conversation starts the same way: what is the problem, and what would fixed look like?

A property company that owns buildings in more than one country is really running several businesses in several currencies at once. Rent may be billed in euros, a construction contractor may invoice in US dollars, the mortgage may be in pounds, and the investors may expect a single set of financial statements in Canadian or US dollars. Every one of those amounts moves a little every day as exchange rates change.

Multi-currency accounting is the discipline that keeps those moving parts honest. Done well, it gives local teams accurate books in their own currency and gives head office a consolidated picture that auditors, lenders, and investors can rely on. Done poorly, it produces unexplained variances, manual spreadsheet adjustments, and a month-end close that never quite ties out.

This guide explains the key terms, the accounting rules behind them (IFRS and US GAAP), how global property owners structure the process in practice, and how Yardi Voyager supports each step.

In short:

• Multi-currency accounting records, remeasures, and reports transactions that occur in more than one currency.

• Every legal entity has a functional currency, the currency of its primary economic environment, which drives how it is accounted for.

• Revaluation updates open foreign-currency balances to today's rate and produces unrealized gains or losses in profit or loss.

• Translation converts a whole set of books into a reporting currency for consolidation; the difference goes to the cumulative translation adjustment (CTA) in equity, not profit or loss.

• The governing standards are IAS 21 under IFRS and ASC 830 under US GAAP.

• In Yardi Voyager, each legal entity has a base currency; transactions can be entered in other currencies, and revaluation and translation run as rule-driven, schedulable processes.

Multi-currency accounting is the process of recording transactions in the currency in which they occur, converting them into the currency in which each entity keeps its books, and then presenting the group as a whole in a single reporting currency. It answers three separate questions, and most problems start when they get blurred together.

1. What currency did this transaction happen in? A tenant in Frankfurt paying rent in euros is a euro transaction, regardless of where the landlord is headquartered.

2. What currency does this entity measure itself in? A German property company normally lives in euros, so the rent lands in the ledger as euros. A Canadian entity paying a US contractor records a US-dollar invoice converted into Canadian dollars.

3. What currency does the group report in? A North American fund may present everything in US dollars, so the euro and Canadian-dollar books must be converted again for consolidation.

Each conversion uses a different exchange rate and produces a different kind of gain or loss, understanding which is which underpins everything that follows.

The vocabulary is where most confusion begins, because accounting standards and software vendors sometimes use different words for the same idea. Finance teams need to share these terms before configuring any system.

Foreign currency accounting is governed by IAS 21, The Effects of Changes in Foreign Exchange Rates under IFRS, and by ASC 830, Foreign Currency Matters under US GAAP. The two standards reach broadly similar answers and follow the same three-step logic.

Everything starts here. Both standards ask which currency mainly influences the entity's prices and costs, and which currency generates its financing and operating cash flows. For a property-owning entity, the main indicators are usually:

• the currency in which leases are priced, and rent is collected;

• the currency of the local market whose conditions set rental rates and property values;

• the currency of operating costs, staff, property taxes and construction contracts;

• the currency in which debt is raised, and cash is retained.

The answer is a judgment; document it, and change it only when the underlying economics change. Choosing the wrong functional currency affects every downstream number, so the controller and auditors should decide this before anyone configures a system.

Step 2: Record foreign-currency transactions and remeasure monetary items

A transaction in a foreign currency is recorded at the spot rate on the transaction date (an average rate is acceptable when rates are stable). At each reporting date:

• monetary items (cash, receivables, payables, loans) are restated at the closing rate, with the difference recognized in profit or loss;

• non-monetary items carried at historical cost (such as buildings under the cost model) stay at the historical rate;

• non-monetary items carried at fair value (such as investment property under the IAS 40 fair value model) use the rate on the date fair value was measured.

US GAAP uses the word remeasurement for a related situation: when an entity keeps its books in a currency that is not its functional currency. In that case, the ledger must be remeasured into the functional currency using historical rates for non-monetary items and current rates for monetary items, and the result goes through net income, with no CTA. This is common for Canadian or European entities that report into a US parent and are judged to have a USD functional currency while keeping local-currency books for tax.

Step 3: Translate into the reporting currency

To consolidate a foreign operation, its functional-currency statements are translated into the group's reporting currency:

• assets and liabilities at the closing rate;

• income and expenses at the transaction-date rates, or an average rate as a proxy;

• equity items at historical rates.

Because the balance sheet and income statement use different rates, the books will not balance after conversion. The difference is the cumulative translation adjustment, recorded in other comprehensive income and accumulated in equity. It is reclassified to profit or loss only when the foreign operation is disposed of.

Two further points matter for property groups. Long-term intercompany loans that are not expected to be repaid can form part of the parent's net investment in a foreign operation, so their FX differences go to equity on consolidation rather than profit or loss. And entities operating in hyperinflationary economies (IAS 29 under IFRS, or the highly inflationary rules in ASC 830) need special treatment altogether.

Global owners, REITs, funds and developers tend to converge on the same operating model: keep each entity's books in its own currency, push foreign-currency activity through controlled processes, and convert to the reporting currency as late and as mechanically as possible.

A typical month-end sequence

1.Load exchange rates for every currency pair and rate type (daily spot, month-end, monthly average) from an approved source, ideally automatically.

2.Post foreign-currency activity in each entity: tenant charges and receipts, vendor invoices and payments, debt draws and interest, each converted at the transaction-date rate.

3.Settle and book realized gains and losses on anything paid or collected during the month.

4.Revalue open monetary balances in each entity at the month-end rate, booking unrealized gains and losses.

5.Reconcile intercompany balances in both currencies so each side agrees before translation.

6.Translate each functional-currency ledger into the reporting currency using translation rules, generating the CTA.

7.Consolidate and eliminate intercompany balances and investments in subsidiaries, then roll up to group statements.

8.Review and lock the period, with documented rate sources and variance explanations for auditors.

A worked example

A Canadian-dollar property books a US$100,000 invoice from a contractor when USD/CAD is 1.36, so the payable is recorded at C$136,000. At month-end, the invoice is still unpaid, and the rate is 1.38. Revaluation restates the payable to C$138,000 and books a C$2,000 unrealized FX loss. Next month, the invoice is paid at 1.37, so the final cost is C$137,000, and the loss settles at a realized C$1,000.

Now the US parent consolidates. The Canadian entity's balance sheet is translated to USD at the month-end rate and its income statement at the monthly average. The building, the payable, and the rent all convert at different rates, and the leftover difference lands in CTA. The same US$100,000 invoice has now touched three different exchange rates and two different kinds of FX results, which is why clear rules and a reliable system matter.

Property businesses face currency issues that a typical trading company does not, because their assets are large, long-lived, and financed over many years.

• Leases priced in a foreign currency. Some commercial and hospitality leases are denominated in USD or EUR even where the local currency differs. Each billing creates a foreign currency receivable to revalue, and some arrangements raise embedded-derivative questions under IFRS 9 or ASC 815.

• Development and capital projects. Equipment, steel, and specialist contractors are often priced in another currency. Capitalized costs use the rate at the date each cost is incurred, so the project ledger needs transaction-level rate history, not just month-end balances.

• Debt in a different currency. Mortgages and construction loans are monetary items, so a large foreign-currency loan can swing reported profit every month. Many groups hedge this exposure, which brings hedge accounting into scope.

• Investment property at fair value. Under the IAS 40 fair value model, valuations are non-monetary and use the valuation-date rate, which must be kept separate from operating FX movements.

• Funds and multi-layer ownership. Investors may commit capital in one currency, invest through holding entities in another, and own assets in a third. Each layer needs its own functional-currency analysis.

• Tax and statutory reporting. Local regulators usually want books in local currency, while group reporting wants another. Keeping both reliable without double entry is a core system requirement.

• Indirect taxes. Sales taxes such as GST, QST, or VAT on foreign-currency invoices must still be reported in local currency at the rates the tax authority prescribes, which can differ from the accounting rate.

Yardi Voyager handles multi-currency through its international currency functionality, which maps closely to the accounting steps above. The building blocks are configured once and then run as part of the normal close.

• Base currency by legal entity. Each legal entity is assigned a base currency, and every property linked to it inherits that setting. Different entities in the same database can use different base currencies.

• Rate providers and rate types. Teams define where rates come from and which types they need, typically a spot rate for balance sheet use and an average rate for the income statement.

• Exchange rate tables. Rates are stored per currency pair, provider, type, and date. They can be keyed manually or loaded automatically through ETL and Task Runner, which is the better practice for audit trail and consistency.

• Additional GL books. Translation results are written to a separate translated book, so the local-currency books stay untouched.

Non-base currency transactions

Voyager lets users create lease charges, ad hoc charges, receipts, payables, payments, and journal entries in a currency other than the entity's base currency. The system looks up the rate, shows both the transaction-currency and base-currency amounts, and records the base-currency value in the ledger. When a foreign currency item is settled at a different rate, Voyager books the realized currency gain or loss.

Currency revaluation

Revaluation calculates unrealized gains and losses on open non-base currency items and posts them as journal entries, normally at month-end, though it can run daily. Revaluation rules can be set to reverse the next month automatically or to calculate the change from the prior period without reversing. Getting the account scope right is essential, since every monetary account exposed to foreign currency should be covered.

Currency translation

Translation converts a base-currency book into a reporting-currency book using translation rules. Each rule covers a range of GL accounts and assigns a rate type so that balance sheet accounts can use a closing rate, income statement accounts an average rate, and selected accounts a historical rate. The Historical Weighted Average (HWA) option translates selected balance sheet accounts transaction by transaction at the rate in effect on each transaction date, which is useful for equity and certain long-lived assets. You can rerun translation within a month, with each run backing out the prior result.

Automation, consolidation and reporting

Task Runner can schedule rate loads, revaluation, and translation so they run each period consistently. Translated books then feed Voyager's consolidation and intercompany tools, where account trees, consolidation rules, and elimination rules roll entities into group-level statements.

In practice, the software is only as good as its design. The same Voyager functions can produce clean, auditable results or a stream of manual adjustments, depending on how functional currency, segments, intercompany accounts, rule ranges and close sequencing are set up.

Across multi-currency property portfolios, the same lessons come up repeatedly. Most issues are not software defects but gaps between accounting policy and system configuration.

• Decide functional currency before configuring anything. If an entity's ledger currency differs from its functional currency, the setup must remeasure correctly (historical rates for non-monetary items, results in net income), not simply translate. Treating a remeasurement case as a translation case is one of the most expensive mistakes to unwind.

• Revalue every monetary account, not just bank and receivables. Payables, accruals, deposits, intercompany balances, and loans in foreign currency all carry exposure. A revaluation scope narrower than the accounting definition leaves FX misstated.

• Govern exchange rates like master data. Use one approved source, load rates automatically, restrict manual overrides, and keep a record of which rate was used for each run.

• Design intercompany for two currencies from day one. Each side should agree in its own currency and in the reporting currency, with clear rules for which balances form part of a net investment.

• Fix the close sequence and stick to it. Revalue before translating, translate after the period's activity is complete, and define when reruns are allowed. Running steps out of order is a common source of unexplained variances.

• Plan reporting detail early. Translated books may summarize activity rather than reproduce every transaction line, so decide up front what drill-down analysts and auditors need in the reporting currency.

• Test with real scenarios. Reconcile translated trial balances, CTA and FX gain/loss accounts to an independent calculation for a few entities before go-live, and again after any configuration change.

• Document for auditors and SOX. Functional currency memos, rate sources, rule definitions, and reconciliation evidence turn a working process into a controlled one.

Property accounting is structurally more complex than most industries. Instead of one set of books, a real estate organization manages many properties, legal entities, ownership structures, JV partners, bank accounts, tenants, vendors, and operating agreements, often across several currencies and jurisdictions.

A typical property-accounting close includes:

• Bank reconciliation across dozens or hundreds of operating, trust, and security-deposit accounts

• Accounts payable review, invoice coding and approval

• Accounts receivable, tenant ledger and cash application review

• Accruals, prepaids and recurring journal entries

• Intercompany and inter-entity settlements

• CAM, tax and insurance recovery calculations

• Job-cost and draw reconciliation on development projects

• General ledger review and variance analysis

• Property-level, fund-level and investor reporting

• Exception resolution and audit-trail documentation

Every new property adds transactions, bank accounts, invoices, and exceptions. When those depend on spreadsheets and manual comparison, the finance team becomes the bottleneck and the close stretches from days into weeks.

Manual close processes are more than an efficiency problem; they are an operational-risk problem. Consider the reconciliation workflow most accountants still follow:

Multiply that across 200 bank accounts, and most of the department's capacity goes to moving and comparing data rather than analyzing it. Manual processes also drive delayed reporting, human error, inconsistent procedures, poor visibility into open exceptions, and key-person risk. BlackLine and FloQast data indicate that automating bank reconciliation, journal templates, and real-time matching typically cuts close-cycle time by 30–50%.

Property accounting automation uses software, system integrations, workflow tools, and increasingly AI to reduce repetitive, rules-based activity in real estate financial processes such as bank reconciliation, invoice processing, cash application, approvals, journal posting, and reporting. Rather than an accountant completing every step, the system executes the predictable work and directs people toward the transactions that genuinely require judgment.

The shift is from processing every transaction to managing the transactions that need attention. Across a large portfolio, that difference is measured in days of close time and thousands of hours per year.

The terms are often used interchangeably. They are not, and conflating them leads to poor buying decisions.

Rules-based automation works when a process follows deterministic logic: *if invoice amount, vendor, and purchase order match, continue the workflow.* It is fast, auditable, and cheap to run.

AI earns its place when a process requires interpretation, classification, pattern recognition, or tolerance for variability extracting data from unstructured invoices, proposing a match between a bundled bank deposit and several tenant receipts, spotting a duplicate payment, or explaining a budget variance in plain language.

The strongest property-accounting workflows combine both, in a clear hierarchy: automation handles rules, AI supports interpretation, people provide judgment and control.

Bank reconciliation is the clearest automation opportunity in property accounting. The matches themselves are easy; the problem is volume and exceptions. Unless the system matches first, accountants touch tens of thousands of lines a month.

An automated workflow looks like this:

Yardi Voyager includes an Automatic Bank Reconciliation capability that imports BAI2 files and auto-clears matching transactions. Implementation partners report that a well-configured setup clears 60–80% of items automatically and is included in the core Voyager license, with most banks supplying the file at no charge. Yardi's AI layer, Yardi Virtuoso (launched at YASC 2025), extends this with agents across financial workflows, and early adopters report reconciliation and reporting effort per property falling from more than 20 hours to under five.

MRI Software has moved decisively toward automated reconciliation, with 2026 partner webinars focused on fragmented bank data, bundled matches (one bank withdrawal representing several MRI payments, or several receipts making up one MRI batch) and disciplined exception handling. In Australia and New Zealand, MRI has named Assetsoft's sister platform, KriyaGo, as its preferred automatic bank reconciliation provider for the Platform X client base; its KriyaBalance/Treasury 360 engine reconciles bank feeds against MRI and supports BAI2, CAMT.053, and ISO 20022.

The guiding principle for any of these tools: don't make accountants review what the system already understands. Point their expertise at what it does not.

The traditional AP chain receives, keys, validates vendor, code, routes, posts, and pays, adding time at every handoff. Document AI now extracts vendor, invoice number, date, property, amount, PO, tax, and line items on arrival; workflow automation validates, applies coding rules, and routes to the right approver by property, entity, or threshold.

Yardi: PayScan, part of the Yardi Procure to Pay suite, now embeds Virtuoso AI. Smart AP extracts invoice details the moment a PDF is uploaded or emailed; Smart Review flags discrepancies against invoice history; and Smart Approval, a premium Virtuoso agent, auto-approves routine invoices that meet defined criteria, logging every decision. Yardi's own materials estimate Smart AP can save the average PayScan client roughly $40,000 per year.

MRI: Platform X supports AP automation through native workflows, third-party AP platforms with MRI connectors, and the MRI Agora platform: Ask Agora (natural-language queries), Agora Actions (agentic automation) and, since June 2026, Agora Intelligence and Orchestrator. Independent reviewers note that MRI has not yet published customer outcome metrics for these releases, so buyers should measure results in their own environment.

For owners and developers, much of the close-time pain sits in construction accounting: commitments, change orders, subcontractor invoices, retainage, lender draws, and job-cost reconciliation between project and accounting teams. Procore is the project system of record for that activity, and it offers direct accounting connectors for both Yardi Voyager and MRI Platform X among its nine native ERP connectors.

With the Procore + Yardi Voyager connector, vendors, jobs, and budgets sync from Yardi to Procore; commitments and purchase orders push to Yardi; approved subcontractor invoices export on approval; and Yardi payments flow back to Procore commitments. Job-cost transactions from Yardi or MRI import so project managers see direct costs on budget lines without waiting for month-end. Procore's documentation is candid about limits: the Yardi connector is for new projects only, does not evaluate tax, and excludes credit-card vendors and stored-materials retainage. Those caveats are why integration design not just switching the connector on determines whether a development close gets faster.

The most important change automation enables is timing. In a traditional model, problems are discovered after the month ends:

For most real estate organizations, Yardi Voyager or MRI Platform X is the system of record for GL, AP, AR, entities, leases, vendors, bank accounts, budgets, and reporting. Automation must never be a set of disconnected tools orbiting the ERP. Before automating at scale, answer six questions:

1. Where does the transaction originate?

2. Which system owns the financial record?

3. How does information enter Yardi or MRI via API, interface file, RPA, or manual import?

4. What approvals are required, and at what thresholds?

5. What happens when an exception occurs, and who owns it?

6. How is every automated action recorded and audited?

A modern real estate finance stack connects Banks ↔ Yardi/MRI ↔ AP and payment platforms ↔ Procore ↔ Procurement and expense (e.g., SAP Concur) ↔ Reporting and data platforms. Without reliable integrations, staff still download, reformat, and re-upload files, and automation's value collapses. Yardi Interfaces plug-ins, MRI's MIX APIs, Procore's ERP Connector platform, and middleware layers each play a role. A deliberately designed integration architecture with ownership, error handling, and monitoring is the foundation of automated property accounting.

The highest-value use of AI in property accounting is often not processing ordinary transactions but finding the extraordinary ones: unexpected amounts, duplicates, unusual timing, missing data, and improbable account combinations. AI surfaces the items that need attention, changing the accountant's role fromfinding the problem to understanding and resolving it.

The same applies after posting. Variance analysis why opex rose, which property is below budget, which accounts drove the change traditionally means paging through reports. AI-assisted analytics such as Ask Agora in MRI or Virtuoso-powered reporting in Yardi identify significant movements, summarize likely drivers, and point analysts to the right property and account. The professional still owns the interpretation; the technology shortens the search.

Automation does not remove financial controls; done properly, it makes them clearer. Auto-matching two predictable transactions is appropriate; auto-posting a material adjustment without review is not. Thresholds, segregation of duties, and approval rules belong in the workflow itself:

Both major vendors have adopted this posture: Yardi logs every Smart Approval decision, and MRI's Agora features sit under a published responsible AI framework. Efficiency and accountability are not in tension when the workflow is designed correctly.

Step 1: Map the current close. Document every activity, owner, system, and manual step.

Step 2: Measure manual effort. Quantify hours by task; bank rec and AP are usually first.

Step 3: Standardize the process. Automation amplifies whatever it is given; remove variation first.

Step 4: Fix data quality. Clean vendor, property, entity, GL, and bank master data in Yardi or MRI.

Step 5: Strengthen integrations. Replace file transfers with APIs, plug-ins, or middleware; add monitoring.

Step 6: Automate the predictable. Turn on ABR/BAI2 matching, PayScan or MRI AP workflows, Procore ERP sync, and scheduled journal templates.

Step 7: Introduce AI where interpretation adds value. Document extraction, bundled matching, anomaly detection, variance narratives.

Step 8: Measure results. Close duration, auto-match rate, exceptions per 1,000 transactions, invoice cycle time, hours saved.

Not fully autonomous, and it should not be. Accountants spend far less time downloading, copying, matching, reformatting, and searching, and far more time reviewing, investigating, analyzing, advising, and controlling. The department scales with the portfolio rather than the transaction count, and month-end becomes a review checkpoint instead of a ten-day sprint.

Automating property accounting takes more than buying a tool. It requires understanding the ERP configuration, integrations, controls, data, and processes and the people who run them.

Assetsoft is a multi-platform PropTech consultancy founded in 2012 and headquartered in Markham, Ontario, with roughly 50 specialists across Canada, the United States, India (Pune and Chennai) and Sri Lanka, serving clients in North America, the United Kingdom, Australia and New Zealand. Assetsoft holds consulting and services agreements with both Yardi and MRI Software, and its integration platform KriyaGo has marketplace status with Procore and SAP Concur. Assetsoft supports real estate organizations with:

• Yardi Voyager consulting, optimization, upgrades, and Virtuoso/Procure to Pay enablement

• MRI Platform X consulting, Web X migrations and Agora adoption

• Property accounting workflow and close-process assessments

• Bank reconciliation automation for Yardi and MRI environments

• Accounts payable automation and PayScan/AP workflow design

• Procore Yardi and Procore MRI integration design and implementation

• System, bank and API integration (Yardi Interfaces, MRI MIX, Procore ERP Connector, middleware)

• Data migration, data conversion (MRI, Sage, SAP to Yardi) and master-data quality

• Reporting, analytics and Power BI/lakehouse architecture

• AI-readiness assessments and responsible-AI governance for finance

If your team is still spending ten days a month reconciling, coding, and chasing exceptions in Yardi, MRI, or Procore, Assetsoft can map where the time goes and what to automate first. Visit www.assetsoft.biz or contact our team to schedule a property accounting workflow assessment.

Real estate organizations generate enormous amounts of information across properties, tenants, leases, vendors, accounting, maintenance, banking, construction, and portfolio operations.

Historically, organizations could sometimes work around data inconsistencies through spreadsheets, manual reviews, institutional knowledge, or reporting adjustments.

AI changes the equation.

When organizations begin asking intelligent systems to interpret data, identify anomalies, recommend actions, or participate in operational workflows, data quality becomes significantly more important.

An AI system can process millions of records but processing poor-quality data faster does not necessarily create better decisions.

Before organizations invest heavily in AI, they should therefore ask:

Can we trust our data?

Many real estate companies have expanded their technology environments over years or even decades.

A typical enterprise environment may include:

Yardi or MRI + CRM + banking platforms + construction software + document management + Power BI + procurement tools + spreadsheets + custom applications.

Each system may contain a different part of the organization's information.

Over time, this can create challenges such as:

• Duplicate records
• Inconsistent naming conventions
• Missing information
• Different property identifiers across systems
• Outdated vendor records
• Multiple versions of reports
• Manual spreadsheet transformations
• Unclear systems of record
• Legacy integrations
• Data isolated within individual departments

These issues already affect reporting and operational efficiency. In an AI-driven environment, their impact can become even greater.

The traditional technology principle of “garbage in, garbage out” becomes especially relevant with artificial intelligence.

Imagine an AI system analyzing lease information across a large portfolio.

If renewal dates are missing, tenant names are inconsistent, lease amendments are stored separately, and critical information exists only in unstructured documents, the system may be working with an incomplete picture.

Or consider an AI-enabled financial workflow designed to identify unusual transactions.

If account mappings are inconsistent between properties or historical transactions contain classification errors, AI may generate unnecessary exceptions or unreliable recommendations.

The sophistication of the AI model cannot compensate for every weakness in the underlying information.

AI-ready data does not mean every database has to be perfect. Instead, organizations should focus on several fundamental characteristics.

1. Accuracy

Information should correctly represent the property, tenant, lease, vendor, financial transaction, or operational event it describes.

2. Consistency

The same information should follow consistent structures and definitions across systems.

For example, property identifiers should not change depending on whether the information comes from the property management system, reporting environment, CRM, or another application.

3. Completeness

Critical information required for reporting, automation, and decision-making should not routinely be missing.

4. Accessibility

Data must be available to authorized applications and users when required.

Information trapped inside isolated spreadsheets or legacy systems can be difficult to use effectively for enterprise AI.

5. Governance

Organizations should clearly understand:

Who owns the data?
Who can modify it?
Which system is authoritative?
How long should information be retained?
Who should have access?

These questions become increasingly important as AI systems interact with enterprise information.

For many property owners, operators, managers, and investment organizations, platforms such as Yardi Voyager and MRI Software serve as critical systems of record.

They may contain information supporting accounting, leasing, property management, maintenance, budgeting, and other essential processes.

That makes the configuration and quality of these environments particularly important.

Before connecting AI or advanced automation to a property management system, organizations should understand:

• How properties and entities are structured
• How charts of accounts are configured
• How tenant and lease information is maintained
• How vendors are managed
• How historical information has been migrated
• How custom fields are being used
• Which integrations create or update records
• Which processes still depend on spreadsheets

Configuration decisions made years ago can eventually become data problems affecting reporting, integration, automation, and AI initiatives today.

Data migration is another area where AI readiness can be won or lost.

When organizations migrate from legacy systems or consolidate portfolios, the objective should not simply be to move every available record into the new platform.

A successful migration should consider:

What data should move?
What should be cleaned?
What should be standardized?
What should be archived?
What information is duplicated?
How should historical records be mapped?

Migrating poor-quality information into a modern platform simply relocates the problem.

Instead, migration can become an opportunity to improve the organization's overall data foundation.

Integrations are essential in modern PropTech environments. However, poorly designed integrations can also introduce inconsistencies.

Consider an environment where information moves between:

Property Management System → CRM → Banking → Reporting → Construction Platform → Data Warehouse

If every integration applies different transformation rules or uses different identifiers, inconsistencies can multiply.

This is why organizations should establish clear systems of record.

For each major category of information, there should be clarity around which platform owns the authoritative record.

For example:

Property data → Property management system
Customer interactions → CRM
Financial transactions → ERP/property accounting system
Analytics → Data platform/BI environment

The exact architecture will vary by organization, but the principle remains the same:

Every critical data element needs an authoritative source.

Excel remains an important business tool, and it is unlikely to disappear from real estate operations.

The problem occurs when spreadsheets become unofficial databases.

Organizations may have critical processes where teams:

Export → Clean → Reformat → Combine → Calculate → Email → Re-upload

Every manual step introduces another opportunity for inconsistency.

It also makes automation and AI harder because the information exists outside governed enterprise workflows.

Organizations preparing for AI should identify spreadsheet-heavy processes and determine whether some activities can be replaced by:

• System integrations
• Automated workflows
• APIs
• Centralized reporting
• Data platforms
• Business intelligence tools

The objective is not to eliminate Excel. It is to reduce unnecessary dependency on manual data movement.

Organizations sometimes respond to reporting challenges by creating additional reports.

But when different teams produce different numbers for the same metric, the underlying problem may not be the reporting tool.

It may be the data architecture.

For example:

Finance reports one occupancy number.
Operations reports another.
Asset management has a third spreadsheet.

Before introducing AI-generated insights, organizations need confidence that fundamental metrics are being calculated from trusted information.

A strong reporting environment should therefore establish:

Common definitions + Governed data + Reliable integrations + Consistent calculations.

Once this foundation exists, AI can add another layer of intelligence rather than another layer of confusion.

Many real estate organizations have already invested in platforms such as Power BI and other analytics tools.

These environments provide an important bridge toward AI.

Traditional business intelligence primarily answers:

“What happened?”

Advanced analytics can help answer:

“Why did it happen?”

Predictive models may address:

“What might happen next?”

And emerging AI systems increasingly aim to help answer:

“What should we do about it?”

The further organizations move along this progression, the more important reliable data becomes.

AI should therefore be viewed as part of a broader data and analytics strategy, not as a standalone technology project.

Real estate organizations do not need to rebuild their entire technology environment before experimenting with AI.

A structured approach can help prioritize the areas that matter most.

Step 1: Identify Critical Data

Determine which information supports the organization's most important financial, operational, leasing, and reporting processes.

Step 2: Map the Data Landscape

Understand where information originates, where it moves, and where it is ultimately consumed.

Step 3: Identify Data Quality Issues

Look for duplication, missing records, inconsistent identifiers, outdated information, and manual transformations.

Step 4: Establish Systems of Record

Clearly define which application owns each major category of information.

Step 5: Modernize Integrations

Reduce unnecessary manual exports and fragile point-to-point connections where practical.

Step 6: Improve Governance

Define ownership, access, security, retention, and data-quality responsibilities.

Step 7: Connect AI to Trusted Data

Once the foundation is reliable, organizations can introduce AI into carefully selected workflows where it can create measurable value.

Once the data foundation improves, organizations can explore more advanced capabilities with greater confidence.

Intelligent Lease Analysis

AI can help extract, classify, summarize, and analyze lease information, allowing teams to work with large volumes of documents more efficiently.

Financial Exception Detection

AI and analytics can help identify unusual transactions or patterns and surface them for human review.

Automated Bank Reconciliation

Automation and intelligent matching can reduce repetitive reconciliation work while directing attention toward exceptions that require review.

Predictive Maintenance

Historical maintenance and equipment information can support more proactive identification of potential issues.

Portfolio Intelligence

AI can help users explore large datasets through natural-language queries and automated analysis.

Intelligent Reporting

Executives and property teams can potentially move from static dashboards toward more conversational and proactive insights.

The common requirement behind all of these capabilities is trustworthy information.

As AI tools become more widely available, simply having access to artificial intelligence will become less of a differentiator.

The advantage will increasingly come from an organization's ability to connect AI to its own trusted operational data and workflows.

Two real estate companies may use similar AI technologies.

But the organization with cleaner data, better integrations, stronger governance, and more standardized processes may be positioned to generate significantly more value from those tools.

That makes data modernization more than an IT initiative.

It becomes a business capability.

Preparing real estate data for AI requires an understanding of both technology and the business processes behind the information.

Assetsoft works with real estate organizations across Yardi, MRI Software, data migration, system integration, reporting, automation, and technology optimization.

Assetsoft can support organizations with:

• Yardi consulting and optimization
• MRI Software consulting
• Data migration
• Data quality assessment
• System integration
• API strategy
• Reporting and analytics
• Workflow automation
• Process optimization
• AI-readiness assessment

Rather than starting with the question,“Which AI tool should we buy?”, organizations can begin with a more fundamental question:

“Is our data ready for AI?”

AI can transform real estate operations, but its value depends on the quality of the data behind it. By improving data quality, integrations, governance, and Yardi or MRI environments today, real estate organizations can build a stronger foundation for intelligent automation and AI-driven operations tomorrow.

The first stage of enterprise AI adoption focused largely on experimentation.

Organizations tested AI for activities such as:

• Lease and document abstraction
• Tenant and resident communications
• Invoice processing
• Reporting and analytics
• Data extraction
• Knowledge search
• Maintenance support
• Workflow automation

The next stage is considerably more complex.

Instead of simply generating an answer or summarizing information, emerging AI systems can potentially participate in multi-step business processes, collecting information, identifying exceptions, recommending actions, triggering workflows, and interacting with enterprise applications.

This evolution is often described as agentic AI.

For property management and real estate organizations, that could eventually mean AI supporting workflows across accounting, leasing, maintenance, procurement, reporting, and portfolio operations.

But there is an important catch:

AI can only operate effectively when the systems underneath it are ready.

It can be tempting to treat AI as another application that can simply be added to the technology environment.

In practice, enterprise AI depends heavily on the quality of the infrastructure surrounding it.

Consider a property management organization operating:

Yardi or MRI + CRM + banking platforms + document management + Power BI + construction systems + spreadsheets + custom applications.

If those systems contain inconsistent data, disconnected processes, outdated integrations, and large amounts of manual work, adding AI does not automatically solve the problem.

It may simply add another layer of complexity.

Before organizations scale AI, they should therefore evaluate several foundational areas.

AI systems depend on data.

For real estate organizations, that data may include:

• Properties
• Units
• Tenants and residents
• Leases
• Vendors
• General ledger information
• Work orders
• Invoices
• Bank transactions
• Budgets
• Contracts
• Portfolio performance

If information is duplicated, inconsistent, incomplete, or stored across disconnected systems, AI-generated insights and automated actions can become less reliable.

Organizations preparing for AI should review their data quality, ownership, structure, governance, and accessibility.

This may involve cleaning historical data, standardizing records, improving data migration processes, and establishing clear governance around how information moves between platforms.

For Yardi and MRI environments in particular, the quality of the underlying configuration and data structure can have a major impact on downstream automation and analytics.

Modern real estate technology environments rarely consist of one platform.

Property management systems often need to communicate with banking platforms, CRMs, construction systems, business intelligence tools, procurement applications, document repositories, and specialized PropTech solutions.

AI adds another participant to this ecosystem.

That makes integration architecture increasingly important.

Organizations should understand:

- Where does the data originate?
- Which system is the system of record?
- How does information move between applications?
- Which integrations depend on manual exports?
- Which processes rely on spreadsheets?
- Where are APIs available?

A fragmented integration environment can make AI implementation significantly harder.

A well-designed integration strategy, on the other hand, creates a reliable foundation through which applications, automation platforms, and AI services can securely exchange information.

APIs have already become fundamental to modern PropTech environments.

Their importance increases further as AI becomes embedded into operational workflows.

For example, imagine an AI-enabled process that identifies an accounting exception.

Recognizing the exception is only one part of the workflow.

The system may also need to:

Retrieve data → Analyze transaction → Compare records → Recommend action → Obtain approval → Update enterprise system → Record result

That requires reliable connections between multiple systems.

Real estate organizations should therefore evaluate whether their existing applications and custom integrations can support this level of connectivity.

This is where an API-led integration strategy can help reduce dependency on manual exports and fragile point-to-point connections.

Not every business problem requires artificial intelligence.

In many organizations, significant efficiency gains can still come from traditional workflow automation.

For example:

Invoice received → Validate → Match → Approve → Post

If that workflow is largely manual today, introducing AI without first understanding the underlying process may simply automate an inefficient workflow.

A better approach is to identify:

• Repetitive activities
• Manual handoffs
• Approval bottlenecks
• Duplicate data entry
• Spreadsheet dependencies
• Exception-heavy processes

Organizations can then determine which steps require conventional automation and which genuinely benefit from AI.

This creates a more practical path toward intelligent operations.

As AI becomes capable of supporting more complex workflows, organizations also need to determine where human approval remains necessary.

This is particularly important in financial and operational environments.

Consider bank reconciliation.

An intelligent system might be able to:

Import transactions → Identify potential matches → Detect exceptions → Recommend resolutions

But organizations may still require a finance professional to approve specific exceptions before anything is posted.

The objective should therefore not always be 100% autonomous automation.

In many situations, a more appropriate model is:

AI identifies → AI recommends → Human reviews → System executes

This approach allows organizations to gain efficiency while maintaining appropriate controls.

Real estate platforms contain sensitive financial, tenant, vendor, lease, and operational information.

Organizations therefore need clear rules governing how AI can access and use that information.

Important questions include:

• Which data can AI access?
• Which applications can AI interact with?
• What actions can AI perform?
• Which actions require human approval?
• How are AI activities logged?
• How are permissions managed?
• How are exceptions reviewed?

AI governance should be designed alongside the technology architecture rather than introduced after deployment.

For organizations running platforms such as Yardi Voyager or MRI Software, AI readiness should begin with the existing enterprise environment.

That means reviewing areas such as:

System Configuration → Data Quality → Integrations → Reporting → Automation → Security → Governance

Organizations do not necessarily need to replace their core property management systems to become AI-ready.

In many cases, the bigger opportunity is to modernize the architecture around those platforms.

This may include improving integrations, eliminating unnecessary manual processes, cleaning data, strengthening reporting environments, and creating more reliable connections between the property management system and the broader technology ecosystem.

Once the underlying technology environment is prepared, organizations can begin identifying areas where AI can create practical value.

Property Accounting

AI and automation can support transaction matching, financial exception detection, invoice processing, reconciliation, and variance analysis.

Lease Administration

Document intelligence can help extract, classify, summarize, and analyze information from leases and related documents.

Property Operations

AI-assisted workflows can help teams organize maintenance requests, identify recurring issues, classify work orders, and prioritize operational information.

Reporting and Analytics

AI can complement traditional business intelligence by helping users explore portfolio information, summarize trends, and identify areas requiring further investigation.

Data Management

Intelligent tools can help identify duplicates, classify information, detect anomalies, and improve the way organizations work with large volumes of property data.

The goal should not be to introduce AI everywhere.

Organizations should prioritize use cases where AI can solve a measurable business problem.

Instead of starting with an AI product, organizations can begin with a structured readiness assessment.

Step 1: Map the Current Technology Environment

Document the systems supporting property management, accounting, leasing, construction, CRM, reporting, banking, and other critical operations.

Step 2: Identify High-Value Workflows

Look for processes involving high manual effort, repetitive tasks, large data volumes, or frequent exceptions.

Step 3: Assess Data Readiness

Evaluate data quality, accessibility, ownership, duplication, and governance.

Step 4: Review Integrations

Identify manual exports, outdated interfaces, custom scripts, disconnected applications, and opportunities for API-led integration.

Step 5: Automate Predictable Processes

Use workflow automation for repetitive and rules-based activities before introducing unnecessary AI complexity.

Step 6: Introduce AI Where Intelligence Adds Value

Apply AI where interpretation, prediction, classification, anomaly detection, document understanding, or decision support can meaningfully improve the process.

Step 7: Establish Governance and Human Controls

Define permissions, approvals, audit requirements, security controls, and accountability before scaling AI across the organization.

Step 8: Measure Business Outcomes

AI initiatives should be measured against business results rather than the number of AI tools deployed.

Depending on the use case, organizations can monitor metrics such as:

• Processing time
• Manual effort
• Exception volumes
• Error rates
• Reporting turnaround
• Workflow completion time
• User adoption

This can help organizations determine where AI and automation are producing meaningful operational improvements.

The next phase of real estate AI will not be defined simply by who adopts the most AI tools.

It will be defined by which organizations successfully connect data, enterprise systems, integrations, automation, governance, and AI into reliable operational workflows.

For companies operating complex Yardi, MRI, and multi-platform environments, that transition requires both technical expertise and a strong understanding of real estate business processes.

That is where an experienced PropTech consulting partner can make a difference.

Assetsoft helps real estate organizations modernize and optimize technology environments across Yardi, MRI Software, integrations, automation, analytics, and enterprise workflows.

Rather than treating AI as an isolated technology initiative, Assetsoft can help organizations examine the systems and processes that AI ultimately depends on.

Areas of support can include:

• Yardi consulting and optimization
• MRI Software consulting
• System configuration and optimization
• Data migration and data-quality initiatives
• API and system integration
• Workflow automation
• Reporting and analytics
• Process assessment
• AI-readiness planning

The objective is not simply to introduce another technology.

It is to create an enterprise environment where people, processes, data, automation, and AI can work together effectively.

Moving from AI pilots to production requires more than adopting the latest AI technology. Real estate organizations need clean data, optimized Yardi or MRI environments, reliable integrations, scalable automation, strong governance, and clearly defined human controls. By strengthening these foundations now, organizations can enter 2027 better prepared to turn AI experimentation into practical, secure, and measurable business value.

Ready to move beyond AI experimentation? Assetsoft can help assess your current technology environment and develop a practical roadmap toward connected, automated, and AI-ready real estate operations.

Walk onto the executive floor of any REIT, and you’ll find people arguing about cap rates, HVAC optimisation, agentic AI, and the CAM reconciliation that’s three weeks late. You will not find anyone arguing about urinals.

That is a mistake, and the numbers say so. With around 56 million urinals in non-residential settings in the United States alone, on the order of one million litres of urine is splashed onto the floor daily, not because of user error, but because of geometry. The urinal in Marcel Duchamp’s 1917 art piece “La Fontaine” would not look out of place in a modern restroom. A century of building science has upgraded everything around it sensor faucets, low-flow valves, touchless dispensers and left the one surface that actually receives the liquid untouched.

The consequences are measurable. Urinal surfaces carry significantly higher bacteria concentrations than traditional toilets, with the surrounding floor highest of all, and ammonia levels on the floor around a urinal run roughly 100 times higher than any area near a toilet. Every stray litre becomes a mop pass, a chemical purchase, a corroded grout line, an odour complaint, and, eventually, a five-figure restroom renovation. It is one of the largest drivers of your janitorial contract and one of the most common grievances in your tenant surveys, and almost nobody has ever put it on a dashboard.

The Nautilus, nicknamed the “Nauti-loo”, is a urinal design developed at the University of Waterloo’s Department of Mechanical and Mechatronics Engineering. Long and sleek, it nearly eliminates splatter on floors, pants, and shoes by ensuring the angle at which a stream hits the wall doesn’t exceed about 30 degrees, a threshold determined through theoretical modelling and validated by physical experiments. At that shallow angle, the liquid stops rebounding and instead forms a smooth wall film that drains away.

Start with what happens to any liquid jet. Given enough distance, a stream breaks up into droplets through the Rayleigh–Plateau instability; in the team’s tests, the median droplet diameters ranged from 4.4 mm to 7.2 mm. By the time it reaches a urinal wall, you are no longer dealing with a stream but with a train of fast-moving drops carrying real kinetic energy.

What happens next depends on the angle of impact. Hit a hard surface close to perpendicular, and each droplet shatters on contact, throwing off satellite droplets that ricochet onto the floor, the partition, the user’s shoes and as aerosol into the air. Hit the same surface at a glancing angle and surface tension and viscosity win: the droplet spreads instead of shattering, and the liquid glides along the wall as a thin film. The team’s model predicts that at a 30-degree impinging angle, splash is reduced by about 95% from maximum, and that this inflection point is almost invariant across the range of conditions found in human urination.

The engineering problem, then, was spatial. A flat plate tilted at 30 degrees would work, but only for one user height and one trajectory. Real restrooms serve children, adults, and wheelchair users, standing at different distances and aiming at different points. Thurairajah’s team reframed the question as an isogonal curve problem: find a curve that intersects a family of stream trajectories at a constant angle, and solving the resulting differential equations in the top-view plane produced logarithmic spirals, the same curve found in a nautilus shell.

The team built and tested two prototypes. Both the Cornucopia and the Nautilus keep impinging angles at or below 30 degrees across their entire surface, and experiments showed they can reduce splashback to only 1.4% of the splash of a common contemporary commercial urinal. Under the high-splash conditions where conventional fixtures perform worst, the Nautilus achieved 85% and 95% reductions; by contrast, a contemporary commercial urinal throws droplets roughly half a meter to either side.

The Nautilus won on the criteria that matter to a facility manager. Its low lip, between 430 mm and 140 mm off the floor, makes it accessible to users of all heights, including wheelchair users, exceeding accessibility standards that require a lip no more than 430 mm high; its larger open area makes cleaning significantly easier; and because it tolerates poor aim, it may prove useful on aircraft and boats. Physics got the team to a splash-free surface; industrial design got them to a product a building could specify.

One more detail matters for procurement: the improvement comes solely from geometry, requires no expensive or complicated coatings, and is compatible with conventional materials.

Facility teams have fought splashback for decades with screens, mats, and behavioural tricks. Screens and mats catch splash rather than prevent it, with no published data on their effectiveness; and the famous fly sticker at Amsterdam’s Schiphol Airport produced a reported 50–80% reduction in splashback and an 8% cut in cleaning costs a reduction, not an elimination. The fly is a nudge; the Nautilus is a law of physics. Nudges depend on the user. Geometry doesn’t.

The Ig Nobel Prizes, organized by the magazine Annals of Improbable Research, honour research that first makes people laugh and then makes them think. This year’s ceremony marked a historic shift: after 35 years in the United States, the awards moved to a convention centre in Zurich, Switzerland, amid concerns about attendees getting visas, and the 2027 ceremony is already booked for Antwerp. Real Nobel laureates Esther Duflo, Abhijit Banerjee, Michel Mayor and Tim Hunt handed out the prizes on September 3, 2026.

The Waterloo team won the Physics Prize for their “theoretical and experimental attempts to design a splash-free urinal.” They wore yellow raincoats as couture at the ceremony and collected the traditional foot-mushroom statue and a ten-trillion-dollar bill from Zimbabwe, worth 15 to 30 Canadian dollars. Back in Waterloo, the professor and student had celebrated the news by sipping blueberry wine from espresso cups in Pan’s office.

The comedy is the point; so is what sits underneath it. Thurairajah described the prize as a symbol of learning things for their own sake: even if it seems silly, “it’s beautiful to know about how the world works.” Pan, for his part, has argued that without physics and math you cannot design even a humble urinal and that a pinch of art and humour makes ordinary life a little better.

For anyone who manages buildings, the beauty is in the budget.

Take the joke out and what’s left is a cost model. Splashback drives expense through four channels at once:

1. Custodial labor. High-traffic men’s restrooms are serviced on accelerated cycles, and a disproportionate share of each visit is spent on the floor and walls around the urinals rather than the fixtures themselves.

2. Consumables and chemicals. Uric acid crystallizes as puddles evaporate, and the odor drives recurring purchases of caustic cleaners, enzymatic sprays, deodorizing blocks, and disposable mats.

3. Accelerated capital expenditure. Urine is corrosive. Repeated wetting and drying cycles push salts into grout lines and past waterproofing membranes, delaminating tile and degrading subfloor. Restrooms that should last a decade end up in the renovation queue early, and a full gut renovation of a commercial restroom runs well into five figures before you count the disruption of closed facilities.

4. Work orders and complaints. Odor and wet-floor tickets are a perennial top category in office and retail CMMS logs, and every ticket carries dispatch overhead.

The researchers put a Canadian number on it. Using Toronto subway data, they note the TTC was projected to spend an annual average of $122,418 CAD per bathroom on cleaning alone from 2020 through 2024, and estimate that up to around $10,000 CAD per bathroom could be saved annually. That’s transit-grade traffic. Here is what the same logic looks like for a typical commercial asset:

A worked example. Take a Class-A office building or suburban mall with 40 urinals. Assume custodial staff spends four minutes per fixture per day on splash-related cleanup. That is 160 minutes, about 2.7 hours every day. At a fully loaded contractor rate of $28 an hour, the routine costs roughly $27,000 a year, and it exists only because liquid escaped a basin it was never supposed to leave.

Eliminate 75% of that work, and you free up about $20,400 a year in operating expense. Because commercial assets are valued as Net Operating Income divided by the cap rate, $20,400 of recurring NOI at a 6.0% cap rate translates into roughly $340,000 of asset value before counting chemical savings, deferred CapEx, or reduced ticket volume. Multiply that across a 50- or 100-property portfolio, and the ceramic fixture becomes a seven-figure decision.

In a post-pandemic market, physical space has to justify its existence. Office landlords compete against the kitchen table; shopping centres compete against a phone. Both win or lose on the quality of the in-person experience, and few things undercut a premium environment faster than a restroom that smells, feels sticky underfoot, or shows visible splatter around the fixtures.

In retail, restroom cleanliness is one of the most reliable predictors of dwell time and brand perception; a bad washroom in a luxury centre reads, subconsciously, as bad management everywhere else. In the office sector, tenant satisfaction surveys consistently rank restroom condition alongside temperature as a top workplace grievance, and unlike temperature, it is a grievance the landlord fully controls.

Thurairajah framed it in human terms: if the team can make bathrooms and public spaces more inviting, “that’s, like, a good thing for society.” For a landlord, the same sentence reads: more inviting facilities, higher retention, stronger asking rents.

Sustainability frameworks LEED, BREEAM, and WELL now shape tenant leasing decisions and institutional financing terms, and restrooms carry an awkward contradiction. Low-flow and waterless urinals cut potable water use, but with less flow to carry residue away, they often worsen odour and crystallization. Facility teams compensate with hot-water mopping, disposable mats and harsher chemicals, quietly undoing the gain the fixture was installed to deliver.

Containing splash at the source resolves the paradox. The researchers estimate that if the Nautilus replaced the 56 million non-residential urinals in the U.S., and cleaning consumes ten times the volume of splashed urine, it could save up to 10 million litres of fresh water a day. Add the disposable mats that never need to be bought, the quaternary ammonium compounds and bleach that never reach the sewer, and the aerosolized droplets that never degrade indoor air quality, an audited parameter under the WELL Building Standard.

A low-flow valve is an ESG line on a spec sheet. A fixture that stops the mess before it starts is an ESG outcome.

Here is the uncomfortable truth about physical innovation in real estate: a better fixture alone does not move NOI. Savings that are never measured never make it to the valuation model. The second half of the Nautilus story is digital.

At Assetsoft, we spend our days inside real estate's operational systems implementing and integrating Yardi Voyager and MRI Software; building automations with UiPath and Power Automate; and wiring Power BI to the data that actually runs a portfolio. When a client installs splash-free fixtures, the questions we help answer are the ones that turn a nice idea into a documented return:

• Is the labour saving real? Tag janitorial time and consumables in the CMMS by restroom and fixture class in Yardi Facility Manager or MRI X, so the before-and-after is a report, not an anecdote.

• Are cleaning schedules responding to reality? Occupancy sensors feeding the work-order system let cleaning cadence follow foot traffic instead of a fixed clock.

• Does finance see it? Vendor invoices, work orders, and property-level cost codes need to move between systems without manual keying. Working with integration partners such as KriyaGo, we connect the CMMS, the ERP, and the bank so the savings reconcile automatically and show up in the numbers finance actually reports.

In our world, the equivalent of fluid splashback is data splashback: the manual keying error, the unreconciled work order, the misallocated CAM charge, the broken handshake between two systems that should have talked to each other. It splatters drag across finance, leasing, and operations, and people spend hours every week mopping it up.

What the Waterloo team did with porcelain is what a good systems team does with an ERP, and the principles are identical:

1.Reject the default. A fixture, workflow, or report having worked “that way” for a century is not evidence that it is optimized.

2.Consult the mathematics. Solutions built on measured data and modeled behavior beat cosmetic tweaks and nudges every time.

3.Design for reality. Real users vary in height and trajectory, or in how they key an invoice. The system has to absorb that variance, not assume it away.

4.Capture compounding margins. Four minutes per fixture or thirty seconds per invoice is trivial once and transformative at scale.

The coverage has been global, which tells you the pain point is too. CBC Radio’s As It Happens interviewed Thurairajah on the research and the Zurich ceremony, and CBC’s The National featured him in a video segment.The Guardian covered the laureates in the UK; PBS NewsHour, Scientific American and the Daily US Times covered it in the United States; and the fluid-dynamics community’s own outlet, FYFD, walked through the physics. The University of Waterloo profiled the team in Waterloo News and on the MME department site, and the underlying study is open-access in PNAS Nexus.

The Ig Nobels promise to make you laugh first and think second. The Nautilus delivers on both: it is funny that a seashell fixes the men’s room, and it is serious that a hundred-year-old ceramic default has been quietly draining operating budgets the entire time.

Optimization happens at the margins. The owners who outperform on NOI over the next decade will be the ones willing to question every layer of their operating model: the fixtures, the data pipelines, the maintenance logs, the manual processes everyone else takes for granted. That is exactly where the untapped value is sitting.

Ready to find the splashback in your operations? From tuning your Yardi or MRI environment to automating reporting, integration, and reconciliation, Assetsoft engineers the digital layer that turns physical improvements into measurable returns. Talk to our real estate technology consultants.