I've redesigned the expense model into a structured, scalable system with built-in growth, categorisation, and allocation logic, enabling accurate modelling and creating a clear foundation to layer in the Recoveries system next.
01
Problem
The previous approach didn't let users model expenses to the level of detail they needed, and treated operating expenses as isolated inputs, with limited structure and no clear way to model growth, categorisation, or property-level variation. This made it difficult to reflect how costs behave in reality, especially across longer hold periods or more complex assets.
02
Solution
We introduced a structured, scalable expense model that allows users to define costs with clear categories, timeframes, growth profiles, and allocation logic. By moving to a more flexible table-based system, users can model expenses with precision and consistency, while also laying the foundation to seamlessly extend this logic into Recoveries in future iterations.
03
How it works
Operating expenses are structured into a flexible, table-based system where users can define costs at a granular level, assign categories such as CAM, utilities, or non recoverable, and control how each expense behaves over time through periods, growth profiles, and variability. This approach replaces rigid inputs with a clear, scalable model that reflects real world cost structures, while keeping everything transparent and easy to understand across the investment lifecycle.
RECOVERIES SYSTEM
A recoveries system is a way to track and allocate shared property costs (like maintenance, utilities, or services) back to tenants. It defines which costs are recoverable, how they’re grouped, and the rules used to distribute them (e.g. by area, lease terms, or caps) in order to mirror real-world lease agreements while keeping calculations transparent and scalable.
04
Legacy Tools
Above, you can see the Argus Enterprise recoveries interface, where recovery logic is spread across multiple tables and inputs, requiring users to manually configure methods, link expenses, and define caps with little visibility into how everything connects, making the overall process difficult to follow and error-prone.
Fragmented Setup
Recovery logic is split across multiple sections, forcing users to piece together how everything works rather than seeing a clear flow.
Tenant-Level Only
All recoveries are defined per tenant, with no abstraction layer (like pools or reusable structures), leading to repetition and poor scalability.
Low Transparency
It’s difficult to understand what costs are being recovered and how, as rules, caps, and allocations are buried in different fields and tables.
High Cognitive Load
The interface requires prior knowledge of the system, making it hard to learn and increasing the risk of errors when setting up or modifying recoveries.
05
Our approach
We introduced a structured, layered system that breaks recoveries into three clear parts: operating expenses, where all cost lines are defined and modelled; expense pools, where costs are grouped based on how they should be recovered; and recovery structures, where rules like method, caps, and base year are applied and then assigned to leases. This creates a clear mental model from costs → pools → structures → leases, replacing a black-box setup with something much easier to follow. As a result, users can clearly understand what is being recovered, control how it’s recovered, and apply the same logic consistently across a portfolio.
06
Expense Pools
Expense pools add a layer between costs and leases, allowing users to group expenses based on how they should be recovered instead of assigning them directly one by one. For example, costs like repairs, cleaning, and maintenance can sit under a single “Recoverable Operating Expenses” pool, while utilities, management fees, and taxes are handled separately. This makes the setup much easier to follow, as users are no longer mixing what a cost is with how it’s treated in recoveries. It also scales much better across assets, since the same pools can be reused and applied consistently, rather than redefining the logic for every lease.
07
Recovery Structures
Recovery structures are where users define how costs are recovered, building on top of the expense pools created earlier. From this screen, users can select which pools are included, set the recovery method (net, fixed, pro-rata), and configure rules like base year, caps, and gross-ups. Instead of spreading this logic across different areas, everything sits in one place, making it much easier to understand what’s driving the recoveries and to reuse the same setup across multiple leases.
08
Lease Assignment
Once a structure is defined, it can be applied directly to leases from the same screen. Users can select contracted or synthetic leases from the 'Assign Leases' table and assign them in bulk, while also seeing which leases are already linked at the top. This makes it easy to manage and update recoveries without jumping between different views, and reflects how the logic works in practice: define the rules once, then apply them consistently across the portfolio.
09
Outcomes
This system turned a previously opaque process into a much clearer and more structured workflow, creating a clean separation between costs, recovery logic, and lease application. It reduced the complexity of setting up recoveries for both new and experienced users, while improving confidence in the outputs by making the logic easier to follow. During feedback sessions, the C-suite at Howard Hughes Holdings highlighted that this approach will remove a significant amount of friction from their current workflows and make recoveries far easier to manage at scale.