Bentley Systems, Incorporated ($BSY)

Okay. Great. Hi, everyone, and welcome to JPMorgan Boston TMC Conference. My name is Alexei Gogolev, Head of Vertical SaaS team. And today, I'm delighted to be hosting one of the key founders and majority holder of Bentley Systems, Company Chairman, Greg Bentley. Greg, welcome.

I guess first, Greg, I wanted to start by discussing the fact that the stock has traded as if the market is somewhat skeptical about ventless ability to fully capture upside from AI? And in many of your conversations, you've noted that the market has sort of discontinued and discounted your value in the near term. So what's your best case for why Bentley is positioned to be an AI leader and perhaps a long-term winner in this space.

Well, Alexei, the very long term is how we set our compass Bentley Systems, and it perhaps is not surprising given our family majority ownership. And that's the case with our generational succession in management. I was CEO for 30-plus years. Our new management team, new to their positions but not new to the company necessarily are in their 40s. And there their refrain is infrastructure AI as their opportunity. And I had thought of that as rather audacious in the scheme of things, such a major opportunity is that -- but as things developed, I've come to be astonished at the pace at which AI is bringing the future forward for us and what we have always wished to and aspire to bring about better and more resilient infrastructure in the world, and that includes the operations and maintenance of infrastructure and opportunity, which is relatively newer for us. And of course, by -- in bringing the future forward it's the case that AI accelerates the pace of our own development on our road map to the future by multiplying the productivity of our software development. But I'm mainly talking about the inception of changes in the market structure for infrastructure that are truly auspicious for us. And I've been talking this quarter about engineering firms, top design firms in the world because they are together our largest constituency. And I was delighted this week to see the CEO of our largest account in its own comparable transcript say that, well, on the one hand, AI and technology is important to them because their backlogs are at record levels as with everyone, among our accounts, they can't hire more people collectively in the industry because the number of infrastructure engineers only increases 1% per year and that can't change foreseeably, given the demographics of those retiring in comparison to the number in school and that, therefore, to do more work, they need to be more efficient and AI can help with that. But in response to an obvious question about whether AI will reduce their firms work and revenues because their business model throughout infrastructure engineering is charging per hour for their work with the efficiencies of AI will they have lower revenue and he said, I don't believe a bit of that. Our design work has not been optimized yet. And this is the opportunity we have been identifying with AI for engineering firms that in addition to the attended consumption where an engineer sits in front of our modeling and simulation applications. They will now with agentic AI be able to spin up agents that run hundreds and thousands of iterations of their potential designs to optimize in various dimensions and generate better and more valuable products for owner-operators. And he was talking about that value, the risk mitigation and so forth in our own portfolio at Bentley Systems, these levels of optimization include across multiple disciplines. It includes optimizing the constructability of a project with our Synchro applications. It includes mitigating the risk of subsurface conditions, which is the principal risk that occurs in an infrastructure project, optimizing to reuse prior design modules to derisk and improve the quality and then ultimately, optimize the performance of the design by being informed by the performance of other designs for the same owner and how well they have performed in the field using our Bentley Infrastructure cloud data about operations and maintenance. So all of these opportunities are coming together, thanks to AI and when the design portion of an infrastructure project has broadly averaged about 5% of the total installed cost. And the portion of design billings spent on software has been about 1% of the design billings that's 5 basis points of the infrastructure project cost, the infrastructure projects, which collectively across the world consume trillions of dollars -- new dollars every year, 5 basis points of that is currently spent on software to make the design more intelligent and optimized and so forth. The CEO's point was when we're being paid by the hour, we only have time to do 1 version if agents can help us we'll be able to do a much better design. We'll be able to be paid for that. The owner will not be interested in optimizing and reducing the 5 basis points spent on software in the project when it can be a derisked project and perform much better. So now over on the owner-operator side, the opportunity for optimization and operations and maintenance is even larger. The -- what we call the digital twin opportunity is that the engineering logic that the owner pays for during design is at present, never used thereafter, during the remaining operating life cycle of the asset where 80% of the cost occurs in that maintenance. So to be able to optimize maintenance would be able to to do only the needed maintenance and our asset analytics opportunity uses drone capture of existing conditions typically, among other capture modalities to have an as operated calibrated model to which you then apply the engineering logic created during project design to make decisions about whether maintenance is needed and to be sure that the infrastructure remains safe. So those opportunities accelerated by AI asset analytics is only made possible by AI have come together to create an economic opportunity for better and more resilient infrastructure in the world and get past the inhibitions and inertia that the existing institutional business model of charging by the hour have caused in the past. So at the same time, as we have the technical capabilities from AI, we are getting past the commercial model obstacles to smarter and more resilient infrastructure. So much more will be spent on software and computing and infrastructure engineering. And I can't make the claim that, that will all be to the benefit of Bentley Systems. But our position is kind of ideal for this. In our 42 years, we are the trusted quarter master digital quarter master for the engineering organizations and the owner operators, each are half of our business, our modeling and simulation applications, the ones you need to invoke agentically in order to optimize our the established standards in the world and trusted by the engineers. And last of all, the data needed to do this optimization is in our project-wise environment it is the intellectual property of the engineering firm or the owner operator or both, but it positions us very well to help them themselves take advantage of that proprietary data and their proprietary differentiation to improve make infrastructure better and more resilient.

Greg, you released the STAT MCP server and said you're exploring token-based pricing for API consumption so can you give us some early data, how many accounts are actively using the step MCP server today what does a typical session look like in terms of compute intensity and when should investors expect the first commercially priced API consumption contract outside of asset analytics.

Well, it's only a couple of weeks now since this first of our MCP servers was released. And over the coming year, we'll completely outfit and instrument our application portfolio, both modeling and simulation applications. So there's not a record yet there are more than a couple of hundred downloads, and we don't think we can count those that are done through Claude itself. But what we can answer is the monetization question, which is that we'll have no monetization this year from API consumption or MCP consumption because our determination is to benefit the long term by having our accounts do as much exploration and experimentation with the APIs and services as they can do with no intention to monetize it during this year. We reckon that this year, we'll learn for instance, about the cost, as to which you asked. And the reason there's not a big risk to us in this year is that initially, the APIs and MCP services execute on the engineers on desktop. And that's a machine they have available to them anyway. It's a terrific -- they find that they can do hundreds of iterations at machine speed. At the same time, they could have done 1 at human speed. And we'll hopefully get experience as well and what the benefits are of these optimization approaches as we enable them to become richer and richer with more and more APIs across our modeling and simulation applications during the remainder of this year, Alexei.

Okay. Thank you, Greg. So at the most recent earnings call, you've laid out really well the math on representative, let's say, $1 million design project and how software today is about $10,000 in that contract, and you suggested that hypothetically doubling it to $20,000 with API consumption could really save almost like 20% of engineering labor. So that looks like a very compelling ROI. But what's the realistic adoption curve, like are any of your hundreds of accounts spending over $1 million already and already running some agenting workflows in their production? Or is this still entirely in pilot?

Well, we have 220 accounts that spend over $1 million with us, 820 accounts that spend $250,000 or more. And these are big enough enterprises to have been already investing in AI R&D. What they don't need to do with our Agentic API road map is start at the bottom replicating functionality that they couldn't replicate and wouldn't be able to validate any way for modeling and simulation, but they can put that together into levels of optimization all the way up to the project level with the context they know about -- that's a wonderful thing for them to be doing. Many of them are already doing that, exercising our APIs that exist in our products today without our help, we don't have a way of tracking that. We don't have a way of monetizing it, but we want to encourage it anyway for the reasons that I just mentioned.

Okay. So in terms of certain bear case scenarios, it sounds like it could be that horizontal AI platforms with agents having access to open source structural analysis tools could eventually replicate some of that stat and what it does without paying Bentley for API access. So would validate simulation engine and the regulatory requirement for proven tools or maybe something else prevent such a displacement?

Well, you're asking about our first MCP service is for TAD. STAT is our structural application that is, I think, the leader in the world in structural analysis, and there are open source structural analysis programs now that our accounts could be using. The stat users are not, in general, they prefer the commercial products, which cost them only about 3% of an engineers cost each day on average under our E365 program across our application set. So there's not a great incentive to not need the best product set STAAD. STAAD understands the design codes, which the open source ones don't in their jurisdictions, it does some optimizing at the element level. So its functionality is is better. But generally, the engineering firms have much more to gain by spending their are their AI discretionary R&D investment on leveraging the existing tools that are proven, that are mandated by their owner clients and which the engineers already know how to understand and use and have chosen in these levels of optimization. And what I mean by levels of optimization, you could optimize material or cost for a structural solution, but a structural solution is only one of the disciplines that need to be solved and a design if you could orchestrate across those to have an objective function across the design, that would be good. But for a project, you might want to also optimize the availability of the materials, the type of labor and maybe conformity with designs and assets the owner already uses, for instance, these are all aspects of adding value that we can't do in the granular applications? And is the opportunity preferably for both us and the account for them to add in optimizing at a higher level of value.

How about the fact that you've highlighted that you explicitly need consent from your customers to train your own AI and those models. Obviously, some of your competitors may consider using their customers' data without consent to train their models could your principle stance become a competitive handicap rather than an advantage longer term?

Well, our principal stance is that our users intellectual property is their intellectual property, and we're not entitled to appropriate it to co-mingle it to share it, especially not to have it help their competitors. And that may seem different than other software companies viewpoints on the matter, but our position is a bit different. For one thing, before we get to the principal of it, consider the sensitivity of this data. This is -- these are the designs of the world's critical infrastructure and consider whether anyone would want uploaded to cloud or downloaded from chat GPT, whatever, the vulnerabilities potentially for terrorists or adversary, et cetera, of the airports and the wastewater and grid and so forth can't be anonymized by the way, because it's intrinsically geo-located, each such design. So we have a responsibility to secure it and steward it. But that doesn't disadvantage our account whose data this is because it's sufficient data for a given owner of operator of infrastructure, they're all large. There's lots of data that they have. In the case of engineering firms, the same is the case our opportunity is to help them make the use of -- make the most use of that data. An example would be, for instance, in automating drawing production, which is where 20% gets saved of the engineer's time that allows them to work on an incremental project at a fixed pricing and improve the margins very substantially. But automating drawing production can use the standards of a particular engineering firm or perhaps a Department of Transportation would want all of its drawings to a particular dialect that works for them so that they're the contractors to whom they're sending those drawings for construction bidding and can expect a certain consistency. That training can be done sufficiently with data, which is the intellectual property of our account or which has agreed to share it. So we do not even solicit permission from our accounts to have standing permission to access and use their data for AI training. When we have particular projects and to train models, we can ask and be authorized to access certain data that is not differentiated or confidential in the accounts judgment. And then we have a data agreement registry to keep track of that. But it will serve us very well because of the scale of these accounts and the amount of data they have to help them in a proprietary way, improve their differentiated offerings by using their own data where we help them do that. That's the right compass setting for us, we think.

That makes all the sense, Greg. Talking about the -- one of the attractive businesses within your portfolio, asset analytics, it recently crossed $50 million revenue run rate. You've been clear that not all of it qualifies as ARR because inspections aren't always annual. But can you maybe help us size this more precisely longer term? Like what needs to happen to make most of this revenue annual is it some regulatory change that you're expecting or maybe some pricing packaging or some technology change?

Well, to back up a bit, we have forever been promoting the potential of digital twins, which reuse the engineering intelligence developed for the project delivery in the first place after delivery during operations and maintenance. And in parts of the world like Asia, that's taken up right from the outset. Our new metro system will have a digital twin approach right from the start and use and if it's done in Singapore, that will be the case, for instance. But for owner operators, for instance, in the U.S., that's too complicated. They don't have many new projects starting and what asset analytics enables is using new continuous surveying, data capture technologies, drones in the main. I always do this wagging my finger to show a drone, circling a drone produces video. Video is overlapping images. Our software resolves overlapping images into a 3D reality mesh that captures the digital twin of the operating asset today. and then you make it intelligent with AI, recognizing everything and relating it to the engineering models. So that's the AI enables asset analytics to create an instant on digital twin which you can use in operations and maintenance to know what operations and maintenance is required and to ultimately optimize that. So it's a very powerful opportunity. We started with cell towers and then roadway miles from Dash Cam data and Google Street View and now distribution poles, for instance, that together add up to this proven -- now it is recurring revenue, but the -- and it's a subscription, an annual subscription in each case, but it may be a subscription for a year when construction is occurring for a particular pole or a tower or asset or mile. And it may not necessarily be renewed for subsequent years. In the case of distribution poles, an inspection is required every 5 years in the United States. But so our hesitation in classifying it as ARR, it is recurring revenue, it may not be annually recurring if you don't renew it every year. it may be somebody different that you need to sell to after the construction or after the inspection. And we're working on that. The best way to work on that to make sure that the surveying by drone or otherwise is, in fact, continuous and occurs regularly is to make it simpler, have more AI extract more value from it and make it more worth doing more often, which in turn, by the way, if you knew you were going to inspect something regularly, you wouldn't need to replace it quite so often because you would know you're going to be able to catch a problem before it becomes significant, which the engineering model would tell you. At any rate, you can imagine also in terms of the ARR challenge for an account having floors and ceilings because they may be doing different assets each year and so forth. So we're doing all of those things to make it an ARR business substantively and contractually. But the most important thing is to capture as many assets get out there in front of this big opportunity that we can do.

Greg, since acquiring a business called Seequent, you've grown subsurface ARR quite materially in civil infrastructure. I think you were saying by a factor I don't know what dollar amount that equates to, but what's the addressable opportunity for that division? How many of your top 470 design firms accounts are already using sequence for ground investigation.

Well, Seequent was what we call a platform acquisition almost 5 years ago now. And it is a global company that started with 3D modeling below the ground from mining, in particular, we saw the opportunity to apply that technology which is different technology below the ground. You can't see and measure and take pictures. You need to do boreholes and samples and drills and then infirmathematically what the strata are below the ground and where the water is seeping and environmentally modeling of that, we saw the applicability of that to civil infrastructure projects where ground conditions are the biggest source of risk that cause project overruns and the Mining and Resources business has also turned out to be good. The Seequent business has multiplied while we've owned it. But the civil portion of it has grown to be a very significant double-digit proportion, but there's lots of headroom there as well. It happens that not quite half of our top design firm accounts that you're referencing use sequence at this point for subsurface modeling for ground informed design for derisking projects and they all should for all their projects, and we'll work -- continue to work on that opportunity.

Perfect. Switching to E365. I understand it's now 46% of ARR and growing pretty rapidly. Can you walk us through the unit economics of E365 renewals? And what's the typical floor uplift you're achieving at those renewals? And how does that compare to maybe a few years back?

Well, E365 is a pure consumption program were paid for and our revenue and our ARR are strictly based on for our open applications, the number of days used for our project-wise environment, which is 20% or 30% of it, it's per quarter in that case. But what we're -- the great aspect of this is there's no multiyear contracting and commitment or accounting. It's strictly ratable revenue recognition back to the good old days before 606. And what occurs at renewal is an annual price escalation becomes effective. So there tends to be some increase in ARR. But we were asked by accounts, although this is not an aspect of the program contractually, if we would grant them a ceiling on what their consumption could become in the ensuing year. And we said, yes, if you'll grant us a floor. So a collar became conventional for the contract to be negotiated a contract renewal. And then a few years ago, accounts who saw this sort of thing elsewhere said, can we negotiate that for multiple years in the future so that we'll have a cap on what we could potentially spend based on how our consumption goes over time. And we said, yes, if we could symmetrically negotiate a floor as well. And that has become the norm for each of these renewal negotiations. What happens at renewal mechanically is our ARR would be increased by the price escalation, which tends to be in mid-single digits each year. The remainder of the consumption increase is there. And the main there upsell to use more specialized applications of ours, a better for us, mix of product usage. Not much of it anymore comes from increased volume because there is a limited number of infrastructure engineers as we said earlier. But there's information in the result of this negotiation and I always ask each quarter, where did we wind up with the average of the negotiated collar increased escalation out into the future and the answer for as long as we've been doing it is 10% or so on average across the world and across all account sizes and so forth, which is the mentality. I think we can gauge from that that infrastructure engineering organizations, the substantial ones. These are the ones the 2/3 of that or pay us $250,000 a year and more are confident in their need for an expectation for and what they'll actually pay us is what they actually consume. It's a very fair -- the most fair contract format you can imagine, but they're confident enough about their next several years, notwithstanding AI concerns and threats and so forth to be able to commit to floors and we grant sealings at that 10% level. So that provides a lot of consistency in our ARR, it must be said, I take the view as an owner of the business that -- it's so much consistency allows us to take on some risk on the margin like the asset analytics business, which is less predictable going after big contracts and so forth. We're going to have a happy medium while we work on building building that one up ultimately to be comparable, I think. But in the meantime, AI is on everyone's mind, and it's not a deterrent to continuing to commit to the level of attended consumption because that's what we're charging for now for our existing applications.

Perfect. Greg. And final question. So you've talked a lot about having capacity for up to $400 million worth of annual programmatic acquisitions without increasing leverage. Last year was a little bit light, so you spent less than $100 million on acquisitions. What do you feel is holding you back from deploying more capital aggressively? Is it lack of targets, maybe some valuation discipline or integration bandwidth and how that -- now that you've expanded beyond asset analytics, what other domains are you looking at?

Well, for a period of time after our platform acquisitions, that's the billion-dollar scale acquisitions of Sequent, which was, at the time, about 10% of our size and then power line systems the next year, we issued convertible bonds that if you consider them, that brought our leverage ratio up to 5x or so and over several years, we've worked that down now to be under 2x on which we regard to be tolerably optimal. So we have no wish to delever further. And that gives us the number given our cash flow is above $500 million this year -- last year and this coming year to be able to do $400 million or so of acquisitions. That is our priority. We would like to especially acquire AI for additional asset types and asset analytics beyond the ones I mentioned, just to get the time advantage of not needing to take the time to do the training ourselves but they're scarce to find those good assets. And it took us until the end of last year to do the couple of acquisitions we did do all that was our priority. But now while we're -- we've reached an optimal leverage. We will continue also to repurchase our shares. But the greater priority will be such acquisitions, including now since we can expand beyond the asset analytics opportunity, where we are disciplined, and it's not the case that we're allergic to dilution in margins compared to our very good margins but we are disciplined in valuation compared to private equity firms perhaps still. And we are now returning to prioritize as well acquisitions of established simulation engines, especially that have the value in this agent immediate future that I'm describing of allowing us to optimize on even more dimensions of engineering performance. So you'll see, hopefully, both of those, we really do hope so in this year.

Perfect. Greg, thank you very much for joining us today. I appreciate your time.

Thank you.