Maybe I’m overthinking this, but how do you merge different PMs data without chaos?

Question

Hey BP, curious what people are actually doing when the portfolio is split across multiple PMs (for example: one in Cincinnati, one in Alabama, and one for Atlanta SFRs).

How are you consolidating portfolio reporting without a monthly spreadsheet fire drill? I’m talking about combined views across occupancy, collections, maintenance, P&L, leasing funnel, and renewals.

At the 100-300 unit level, what actually works for you in practice?

- Propexo (or similar) + custom dashboard / BI setup?

- Standardized PM templates + manual monthly roll-up?

- Something else?

Trying to avoid creating a giant copy-paste workflow that breaks every reporting cycle.

Curious what’s working for you.

Chris Seveney · Answer

We ran into this exact problem as our portfolio scaled across multiple markets with different PMs, and the spreadsheet fire drill gets old fast.

What actually worked for us was building around our existing Microsoft stack rather than bolting on another SaaS platform. We use Power Apps as the front end, Dataverse as the data layer, and Power BI for consolidated reporting. Each PM feeds data into standardized templates on a set cadence, and the platform normalizes it into a single portfolio view across occupancy, collections, and financials. It connects directly to our accounting system so we're not duplicating data entry or reconciling two sets of numbers.

The key mindset shift for us was recognizing that we are asset managers, not property managers. We don't need every work order detail or leasing conversation log that a PM-facing system tracks. We need the performance metrics that tell us whether the asset is performing to underwriting, where capital needs to go, and where a PM relationship needs attention. That's a much narrower data set, and it's easier to build for.

The Propexo-style aggregation layer is interesting if your PMs are all on different PM software, but you're still paying for middleware and depending on API stability. If your PMs can commit to a standardized reporting template, even a simple one, you can ingest that into Power Automate and skip the aggregator entirely. Also propexo looks very expensive.

The honest answer is that the technology is typically the easiest part. Getting three different PMs to report consistently and on time is the actual problem. Build the system, but build the PM accountability structure around it first.

Stephen Quesinberry · Answer

Hey Denis,

I have properties across a few different managers in two different states. While it's not easy, I set it up so that I get automated reporting delivered to my inbox weekly for KPIs and then monthly for financials. I then have a VA that helps me organize the data into consistent metrics that I want to track/review quickly each week/month. We just use a google sheet for weekly KPIs and a custom excel dashboard for monthly financials.

Nick DiCarlo · Answer

@Denis Frolov its fascinating that you have this problem that feels so real and seems like it would be common and you wouldn't have gotten any responses to this. I also wonder about this. My portfolio is much smaller than 100 to 300, and we only have one PM, but we are already starting to see cracks in our ability to stay on top of all of the issues.
Would love to hear about what you have figured out!

Denis Frolov · Answer

@Christopher Woodward Thank you for taking the time to write this out. This is genuinely helpful, and I appreciate the practical example.

Your data engineering angle makes a lot of sense to me, because that’s where my mind immediately goes too. Once everything is in a clean unit-level table, with unit ID, PM, market, rent, occupancy, costs, etc., the reporting becomes much easier.

The part I’m trying to think through as we grow is how to systematically handle the messy step required to get there: getting different PMs to actually send clean, consistent data every month, or having some process on the owner side to clean up whatever they send.

From your experience, when this works well, who usually owns that cleanup and enforcement step? Is it the owner pushing PMs to follow the template, someone manually cleaning the files each month, or having repeatable scripts around the same standard format?

Also curious how granular you keep it in practice. With my past reporting experience, I know you can build a very detailed data model, but as an owner, I’m wondering what other people actually use month to month.

To be honest, I’d almost assume most owners don’t even need a full dashboard as much as a short list of what changed, what looks off, and what needs follow-up with the PMs.

Christopher Woodward · Answer

You are correct about dashboards. Dashboards are mostly a toy. They have lost of colors, and you can interact with them. You can also just read what happened and gain the information. A graph showing you a trend is just as valuable as a graph showing you a trend with a slider attached to it.

You likely won't get property managers to send you clean data on their own. You could definitely use a form to enforce structured data. Honestly, a Google Form is just fine for this, but you can use whatever you like. You make every field a required field, and they submit the form.

The cleanup part you mentioned is inevitable, and generally happens on the back end if you have massive amounts of data; for example, if you have 10,000 rows of data coming in every hour, you want to automate the clean up and do it on the back end. For a monthly ingestion where rent payments are due, you can run a script to ingest and clean it all up.

You will need two layers of data storage. The first layer is to take in raw unprocessed data from your property managers. We will use the forms example and build the scenario.

You have the first layer where these forms come in and they go unchecked. They come in and go straight into this first layer. This first layer can be a folder or a "bucket" if you are using the cloud. This layer allows you to take in everything that comes in without rejection. If someone sends theirs in late, you will still have it. If someone put "9999999999" for a phone number, you will still have it. ( Avoid personal identifiers in your database if at all possible. It triggers regulation that makes this a lot more complex. ) This layer has all your intake over time. You will have a growing time-series of raw unclean data.

The second layer is where good clean signal data is going to be stored. This is what graphs with if you would like. If you're into dashboards, they're not a crime; you can build one from this layer. This layer has all your clean historical data. As the data is cleaned up nice and pretty, it gets added here, and your time-series grows.

In between these two layers is a script. It can be Python script or some other language of your choice, Python is really good here. This script will pull in the files from Layer 1, build this tabular format you and I are discussing, and you can program it to put "N/A" in places where you have absolute nonsense values like "a;sdlkfj" for a middle name or something so you don't have random values that all mean the same thing: nothing. You will have one single value for nothing. You also want to program this script so things like "1st Street" and "First Street" are not different. You want to make everything line up perfectly.

So you have:

- Layer 1 (everything is just dumped in)

- Script (Takes data from layer 1 and cleans it all up)

- Layer 2 (Your script saves the clean data here. You can make graphs and analyze and all that fun stuff.)

If you can trust your property managers to fill out a form and use your standardized format, this is really easy. That python script is not a lot of code. If you're doing it in the cloud, it's a little more complex, but if everyone can follow the process, you can really make this simple.

You can make your model very complex. Ultimately, it's yours. You can put the color of the unit if you want, and test for statistical significance in the future. You can also make it really really simple. The main thing I would say must be there is every single unit must have a unique id. Other than that, it's your database.

Christopher Woodward · Answer

It sounds like you have a data infrastructure problem brewing. The monthly spreadsheet fire drill comment gives me a good idea of what you could be dealing with.

I do this kind of work a lot. The "spreadsheet" approach gets harder and harder over time as the data becomes more complex. You need schema. I could be wrong without seeing a sample of your data, but here's one way you could do it.

If there are 500 units, you have 500 rows.Here's an example:

2026-07-03 | 001 | 123 First St | Somewhere City | New York | 12345 | 1500 | 600

2026-07-03 | 002 | 321 Second St | Somewhere else City | California | 23456 | 2200 | 900

When you have 500 rows like that, you can do total revenue and total cost. If you only want to see what happened in x zip code, you can do that. If the unit is not rented, "Rent" would be $0, or you can put a simple binary flag (1 or 0) in a column named Occupied. The average of that column is your occupancy across all units, or you can do that same thing across zip codes or city names. You can also add a column for Property Manager and put their names in the rows. This would allow you to partition or group the data by the property managers to see who is performing well or not.

From here you can start to do things like set up a dashboard if you wish.

The copy and paste thing will only go away once you create a standard for the data like this and enforce it.

I personally write my own code and do this kind of thing every single day, but not in your situation. There is very likely not some premium software that you can dump your spreadsheets into, and it come out clean; but if you do something like the structure I demonstrated, that makes it almost easy to do at that point.

I hope this helps. I know this issue all too well.

Denis Frolov · Answer

@Chris Seveney, thank you for taking the time to share all this! This is extremely helpful.

The “asset manager, not property manager” point is probably the clearest way I’ve heard this framed. I think that’s one of the most important mindset shifts when scaling, but not an easy one.

One thing I personally keep coming back to is where you draw the line between staying high-level and catching smaller PM misses that may quietly cost money. I’m talking about things like maintenance charges that don’t look right, missed rent increases, wrong amounts collected, fees not applied, etc.

I would imagine that gets a bit challenging with this setup. Do you try to catch those too, or are they mostly immaterial and you mainly ask for PM explanations once they start showing up in the higher-level numbers?

And I agree, getting PMs to report consistently and on time is definitely a tough battle. We had a situation where one PM was on Yardi and another was on their own proprietary software, and even getting clean basic data, like a historical lease table from both, was way harder than expected.

Denis Frolov · Answer

Hi @Drew Sygit,

I get the skepticism, and you're right, I’m new here.

We're not operating at this scale yet, but we would love to think the future is bright.

For context, my personal background is in real estate reporting, mostly around larger portfolios where there were teams, tools, and processes for the kind of stuff we discuss here.

That’s actually why I asked. I’m trying to understand how other owners of growing portfolios handle it when they don’t have that machine behind them. At the moment, I’m not sure I understand how people do this efficiently once there are multiple sets of PM reports, portals, statements, and different definitions flying around, without becoming part-time data wranglers themselves.

I do think this is worth discussing here. The perfect setup probably doesn’t exist anyway, but I’d imagine some people have figured out their own way through it already. It would be helpful to hear what actually works for them, and I’m sure there are others here wondering the same thing.

Drew Sygit · Answer

"Real estate reporting", so guessing you're NOT referring to being a news reporter.

So, that then leaves us with, you compile real estate data and create corresponding reports.

I'm going to estimate that 99% of BP members are under your 100-300 unit threshold.

According to several publications, one of them below, small investors with less than 5 properties own 85% of the SFR rentals.

https://econofact.org/factbrief/do-private-equity-firms-own-...

Appears you may be looking in the wrong place for your 100-300 door owners:(

Denis Frolov · Answer

@Nick DiCarlo, thank you for your response! To be honest, that surprised me too. At some point I even stopped checking responses in this thread.

Anyway, yeah, I started asking for advice around a multi-PM problem, but I’m hearing more and more that even with one PM, things can start slipping through the cracks once there are enough moving pieces.

I don’t have a perfect answer yet. So far it seems like people either read through each PM portal/report package separately, or they have some kind of manual process to clean things up and pull everything into one spreadsheet.

When you say you’re already starting to see cracks, what does that look like for you, if you don’t mind sharing? Is it maintenance follow-up, collections, leasing, expenses, or just too many little things to keep in your head that take too much time?

Maybe I’m overthinking this, but how do you merge different PMs data without chaos?

Maybe I’m overthinking this, but how do you merge different PMs data without chaos?

Most Popular Reply

14 Replies