Most property companies measure growth the same way: doors. More doors this quarter than last, a bigger portfolio, more revenue coming in. It feels like progress, and on the top line it is. But there's a number sitting underneath the door count that decides whether all those doors are actually making you money or just making you busier, and most firms never look at it. The number is simple to state and uncomfortable to answer: what does it truly cost you to operate one more door, and what's left after? That's your unit economics. And it, far more than how many doors you manage, is the real measure of whether your growth is working. What Unit Economics Actually Asks Unit economics is a deceptively simple discipline. It asks one question: do you make money each time you serve one more unit? Not in total, not on average across the whole business, but on the next single unit. There's a clear primer on unit economics here. In property management, the unit is a door. Two numbers define its ...

Ask anyone at your firm why you do something a particular way, how a property gets onboarded, how an approval gets routed, how the month gets closed, and the honest answer is usually some version of "that's just how we've always done it." Which is a polite way of saying nobody remembers choosing it. That's worth sitting with, because it's true of almost everything in how a company operates. Your operating model feels like a design, a coherent way of running the business that someone worked out. It's mostly not. It's an accumulation: a pile of decisions made at different moments, for reasons that may be long gone, that hardened into "how we do things." Very little of it was ever chosen as a whole. It accreted, one expedient at a time, and then it stuck. How An Operating Model Actually Forms Trace a few pieces of yours back to where they came from, and the pattern shows up fast. The reporting process exists in its current shape because of a spreadsheet someone built in the first year to ...

Modern enterprises have an authority problem, and many organizations keep trying to solve it with a connectivity budget. Enterprise Architecture exists to solve that authority problem - but too often the investment goes into integration instead. Every fragmented data environment eventually produces the same recommendation: build an API, wire the systems together, let the data flow. It's the most predictable move in enterprise technology - and one of the most consistently mistaken, because an API was never designed to answer the question that's actually broken. An API is a contract for moving data between two systems. It says nothing about what that data means, which system is allowed to change it, or which version wins when two systems disagree. Those three questions - meaning, ownership, and precedence - are the actual substance of Enterprise Architecture. An API doesn't answer them; it assumes they've already been settled elsewhere, and it faithfully carries whatever it's handed, ...

Ask a CFO what Net Operating Income (NOI) is, and you'll get the textbook answer instantly: revenue minus operating expenses, the clean, pre-financing measure of how a property performs. Ask that same CFO to explain why NOI moved 8 percent last quarter, and the answer gets a lot less confident. That gap is the real story. NOI is treated as a financial number because it lives on a financial statement, gets reported to lenders, and drives asset valuation. But almost everything that actually moves it happens outside finance entirely: a maintenance team deciding whether a repair is routine or capital, a leasing office quietly under-collecting a fee, or a vendor contract renewing at a higher rate nobody flagged. NOI is an operational number wearing a financial number's clothes. CFOs who treat it purely as an accounting output are the ones most likely to be blindsided by what it's actually telling them. Why NOI Is Structurally Misleading to Finance The trouble starts with where NOI's inputs ...

Every property finance team pays a tax that appears on no budget line, gets approved by no one, and is never questioned at year-end. It is the cost of making two systems agree with each other, over and over, every month, forever. Nobody decided to pay it. It simply accrues, quietly, in the hours your most capable finance people spend reconciling numbers that should never have disagreed in the first place. Call it the reconciliation tax. It is what you pay when the same information lives in more than one place, a leasing system and an accounting system, an operations platform and a general ledger, and someone has to sit between them confirming the two versions match. The work feels like normal finance work, which is exactly why it hides. No one budgets for it because no one names it, and no one names it because it looks like the job rather than a cost of a particular way the job was set up. This piece is about naming it. Where the reconciliation tax comes from, how to estimate what ...

Quick Reference: Michigan Repair Obligations at a Glance Requirement What It Means Statute Statewide habitability covenant Premises and common areas must be fit for intended use; kept in reasonable repair MCL 554.139(1)(a)-(b) Modification of covenant Only permitted if lease/license term is 1 year or more MCL 554.139(2) Housing Law of Michigan applies to Qualifying cities, villages, and townships meeting the statute’s population requirements MCL 125.401 Core repair duty (Housing Law) Every dwelling, including plumbing, heating, ventilating, and wiring, must be kept in good repair by the owner MCL 125.471 Smoke alarms in Class A multiple dwellings Required, per state construction code standards MCL 125.482a Dangerous conditions Health officer may order vacating or repairs when a dwelling is dangerous to life or health MCL 125.485, 125.486 Certificate of compliance withheld Rent may be suspended and paid into escrow under the statutory process MCL 125.530 Uncorrected violations ...

Something is broken. Owner statements go out late, or wrong, or both. Maintenance requests sit for days before anyone acts on them. Two people are re-entering the same lease data into two different systems and it never quite matches. The instinct, almost every time, is the same: find the tool that fixes this. A new PM software, a new accounting module, a new dashboard, a new hire to own the mess. Sign the contract, roll it out, and wait for the problem to disappear. Then, weeks or months later, it hasn't. The statements are still late. The requests still sit. Now there's also a new tool nobody fully trusts yet, and a training burden on top of the original problem. This is the pattern worth naming plainly: you can't buy your way out of an operating problem, because the thing you bought was never the thing that was broken. Tools Inherit The Process, They Don't Replace It A piece of software does what your operation tells it to do. If the process feeding it is fragmented, the software ...

Most CFOs can tell you exactly how many entities sit on their org chart. Far fewer can tell you, honestly, whether their financial architecture was actually built to carry that number. That gap tends to stay invisible for a long time. A structure that works cleanly at three entities doesn't announce the moment it stops working at eight. It just gets slower, quieter, more dependent on one or two people who happen to remember which spreadsheet is the real one. By the time the strain becomes visible, usually right after a new acquisition, a capital raise, or a controller giving notice, it's already expensive to fix. This is a test for finding that strain earlier. Five questions, each pointing at a different structural dependency, that together tell you whether your entity structure is something your architecture handles, or something your people are quietly absorbing. Why Entity Count Is Not the Real Variable It's tempting to think of multi-entity complexity as a simple function of how ...

Every finance leader knows how long their month-end close takes, and most quietly treat it as a fixed cost of doing business, a grind that lands every month and simply has to be endured. That framing misses what the close actually is. The close is not just a task. It is the most honest diagnostic a CFO has, a monthly stress test that runs the entire operation through a single pipe and reports back, in days, on how healthy the machine underneath really is. Read that way, the length of your close stops being a nuisance and becomes information. A business that closes in five days and a business that closes in fifteen are not just running their finance teams differently. They are almost always running everything differently, and the close is simply where that difference becomes visible and countable. The benchmark makes the gap concrete: APQC's cross-industry data shows top performers close in about five business days or fewer, the median sits around six, and the bottom quartile takes ten ...

Someone points at a number in your report and asks a simple question: why is this figure what it is, and who approved it? Maybe it's an owner during a review. Maybe it's an auditor, a lender doing due diligence, or a regulator. The question is ordinary. The scramble that follows, in a lot of property operations, is not. Answering means going and digging. Which spreadsheet was this pulled from? Who changed it last? Where's the approval, sitting in someone's inbox, or was it just a verbal yes in a hallway? You assemble a story from fragments and call it an answer. That process has a name: reconstruction. And the fact that you have to reconstruct at all is the tell. You can't audit what you can't reconstruct, and you shouldn't have to reconstruct what a well-run operation would simply have recorded as it happened. What an Audit Trail Actually Is In accounting, there's a precise term for the thing that makes a number answerable: the audit trail. It's the documented path of a transaction, ...