No Such Thing as a Unit: Modelling Property in Generic Software
No general business system has a "unit" or a "building". So before you enter a single tenant, you have to choose which generic container will stand in for them — and that choice decides which questions you can answer for the next five years.
Every property business that adopts general business software runs into the same wall in the first week. The system has customers, vendors, invoices, expenses, projects, departments, warehouses and locations. It does not have a building, a unit, a lease or a landlord. So you improvise — a building becomes a project, or a department, or a customer prefix in a naming convention — and the improvisation works, right up to the month somebody asks a question the improvisation cannot answer. By then you have two years of data shaped the wrong way.
This post is the one nobody writes because it is unglamorous: how to choose the stand-in. It is worth twenty minutes of your attention because the decision is close to irreversible. Re-coding eighteen months of expenses onto a different dimension is a data-migration project, and the usual outcome is that nobody does it and the reporting stays broken.
The four containers, and what each one actually reaches
The critical insight is that these containers are not interchangeable, because they do not appear on the same documents. A dimension is only useful for reporting if it exists on the records that carry money. So the right way to choose is not by which one feels like a building — it is by tracing which documents each container can actually appear on.
| Container | Reaches money in | Reaches money out | Reaches stock | Natural fit |
|---|---|---|---|---|
| Project | Yes — on a customer invoice | Yes — on an expense, a stock adjustment and a payout run | Yes | A building, or a development |
| Department | No | No — not on an expense or an adjustment | No | An internal team, not a property |
| Warehouse | On the invoice header only | No | Yes | A building, for stock purposes only |
| Location | On the invoice header only | No | Yes | A unit or a store within a building |
That table is the whole answer, and it is more lopsided than most people expect. Project is the only container that appears on both the money-in and the money-out documents. A department reaches budgets, purchase orders and staff but does not exist on an expense or a stock adjustment — so a department-based model can budget for a building and never report what the building actually spent. Warehouses and locations are stock containers: excellent for where a water pump is stored, useless for what a flat earned.
Owner
No landlord or owner entity, and no reverse-direction statement. Track owners in a maintained list outside the system and accept that per-owner balances are assembled by hand.
Building
Model as a project. It is the only dimension that reaches invoices, expenses, adjustments and payouts, so it is the only one that can produce a building P&L.
Unit / flat
No container reaches money at unit level. A disciplined naming convention on the customer and the invoice is the practical answer, and it means unit reporting is a spreadsheet exercise.
Tenant
A customer, properly — with contacts, addresses, a balance, a credit limit, invoices, receipts, statements and ageing. This layer needs no improvisation at all.
Lease
No lease or tenancy entity: no start, end, rent amount, escalation or notice period as fields. Renewal dates live in a calendar or a spreadsheet you maintain.
Common areas and plant
The lift, generator, pump and tank are assets — with custody, condition, location and movement history. This maps cleanly and is often overlooked.
Building as a project: what you get and what it costs
Once a building is a project, a surprising amount falls into place. Rent invoices carry the project, so revenue per building is real. Repairs coded to the project give you cost per building. A payout run against the project pays the owner and the contractors with an approval step. The project itself carries a budget amount, so you have a crude budget-versus-actual per building. That is most of a property P&L, assembled entirely from generic parts.
The costs are specific and worth naming. A project holds a single budget figure rather than a line-level budget, so "KES 400,000 for the year" is expressible and "KES 120,000 of that for lift servicing" is not. Projects were designed for work with a beginning and an end, so a building that has existed since 2009 sits slightly awkwardly in screens that expect a completion date. And the project list becomes your building list, which means anyone who creates a project for an actual project — a refurbishment, say — pollutes your portfolio reporting unless you agree a naming rule on day one.
Building as a project
- Reaches invoices, expenses, stock adjustments and payout runs — the only container that does.
- Gives a genuine revenue and cost figure per building without any manual assembly.
- Carries one budget amount, so a crude budget-versus-actual per building works.
- Awkward in screens that assume a start and an end date.
- Mixes with real projects in the same list unless you enforce a naming convention.
Building as a warehouse, units as locations
- The right model for anything physical — spares, consumables, plant and where they live.
- A location carries a code, a zone and a capacity, which map neatly onto floor, wing and unit size.
- Reaches no expense and no payout, so it produces no financial view of the building at all.
- A warehouse has a manager and an address, which is a genuinely good fit for a caretaker and a building.
- Best used alongside the project model, not instead of it.
Use both, deliberately
The mistake is treating this as a single choice. Model the building as a project for money and as a warehouse for things, and keep the codes identical between them — WESTLANDS-01 as both a project code and a warehouse code. It costs nothing, and it means the day someone asks "what did Westlands cost us, and what spares do we hold there", both halves answer without a translation table. Agree the code format before you enter the second building, because retrofitting it is the part nobody does.
What a property manager says What it has to become
The Westlands block A project, and a warehouse with the same code
Project for financial attribution, warehouse for stock. Same code in both so they line up without a lookup.
Flat 3B A naming convention
No container reaches money at unit level. Put the unit in the customer name and the invoice reference and be consistent to the character.
The tenant in 3B A customer
This one is a genuine fit — balance, credit limit, invoices, receipts, statement and ageing all work as intended.
The lease expires in March A diary entry you maintain
No lease entity and no renewal date field. A recurring task with a due date is the closest the system gets to reminding you.
The landlord A payee on a payout run
A vendor or a named payee on an approved payout. Not a party with a running balance, because that does not exist.
The generator An asset
A clean fit — custody, condition, location, movement history and warranty expiry all real.
You manage buildings for third-party owners
Project per building, and start the naming rule today
Financial attribution per building is your product, so use the only dimension that reaches both revenue and cost. Prefix property projects distinctly — PROP- — so they never mix with refurbishment projects in a report.
You own and occupy your own premises
Warehouse and location, and skip the project entirely
If nobody needs a P&L per building, the financial dimension is overhead. Model buildings as warehouses and rooms as locations for asset custody and consumables, and let costs sit in ordinary expense categories.
You run a single mixed-use building
Project per revenue stream, not per building
With one building, the useful split is commercial versus residential versus parking, because those have genuinely different margins and tax treatments. A project per stream tells you something; a project for the one building you own tells you nothing.
You are about to build a portfolio quickly
Fix the code format first, then enter data
A four-character site code used identically as a project code, a warehouse code and an invoice reference prefix is twenty minutes of agreement that saves a migration. Do it before the second building, not after the twentieth.
What you will not be able to answer, whatever you choose
Being honest about the ceiling is more useful than optimism about the workaround. Per-unit profitability is not reachable — no dimension that carries money goes below the building. Occupancy is not a computed figure, because there is no unit to be occupied and no lease to occupy it. Rent escalation is not applied by anything. And rent itself is invoiced by hand every month for every tenant, because nothing generates a set of invoices on a schedule. That last one is the single largest recurring cost of running a property business on generic software, and it is worth pricing in hours before you commit.
What AWRA OpsHub does today
- Projects as a dimension on money in and money out. A project appears on a customer invoice, an expense, a stock adjustment and a payout run — the only container that reaches all four, which is why it is the recommended stand-in for a building.
- A project budget amount, giving a crude budget-versus-actual per building, plus a project profitability view of budget against actual spend and payout position.
- Warehouses with a manager and an address, and locations beneath them carrying a code, a storage role, a zone, an aisle, a bay, a shelf, a bin, a pick sequence and a capacity. A genuinely usable building-and-unit structure for anything physical.
- Tenants as customers, with contacts, addresses, a balance, a credit limit with live exposure, invoices, receipts, ageing and an emailable statement of account.
- Plant and common-area equipment as assets — the lift, generator, pump and tank — with named custodians, condition, location, movement history and warranty expiry.
- Custom fields on the main records, so a building code, a plot number or an LR number can live on the project or the customer rather than in a naming convention.
- Recurring tasks that genuinely spawn, so tank cleaning, generator servicing and a lease-renewal reminder can be scheduled and will appear on their own — a daily job creates the next occurrence.
What it does not do
- No property, building, unit, lease or tenancy entity. Every one of them is a convention you impose on a generic container, and that is the premise of this entire post rather than a footnote to it.
- No dimension reaches below a building. Neither an expense nor an invoice can be coded to a unit, so per-unit profitability is arithmetic performed outside the system, always.
- No department on an expense or a stock adjustment. Departments exist and reach budgets, purchase orders, assets, staff and tickets — but not the two documents that record spending. So a department-based property model can budget and never report actual spend, which is the trap worth avoiding.
- A project holds one budget figure, not budget lines. "KES 400,000 for the year" works; apportioning that across lift servicing, cleaning and security does not.
- No occupancy, vacancy or rent-roll figure, because there is no unit to be occupied and no lease to occupy it. Occupancy is a number you maintain.
- No rent escalation. Nothing applies an annual uplift; a new rent is a new invoice amount that someone types.
- No recurring invoice generation. Every tenant's rent invoice is raised by hand every month. For a fifty-unit portfolio this is the dominant administrative cost of the whole approach.
- No owner entity, so there is no per-owner balance and no statement in the direction an agency needs — covered in owner statements and payouts.
The honest summary is that this maps better than you would guess at building level and not at all at unit level. A project per building plus a warehouse with the same code gives you revenue, cost, stock, plant and a crude budget per building using nothing but generic parts, and tenants as customers is a genuinely clean fit. Below the building the model runs out, and the monthly rent invoicing is manual. Decide whether building-level truth is enough for your business before you commit, because that is the real question and no amount of configuration changes the answer.
The short version
Building as a project, building as a warehouse with the identical code, unit as a naming convention, tenant as a customer. Agree the code format before the second building — that twenty minutes is the whole difference between a portfolio you can report on and one you cannot.
With the structure settled, the operational disciplines that sit on it are rent and service charge collection, utilities and recharges, maintenance and lease renewals and vacancy — and the overview that ties them together is property management operations.
Model it once, properly
Projects as a dimension on invoices, expenses, adjustments and payouts; warehouses and locations for buildings and stores; tenants as customers with statements and ageing; plant as assets with custody. Property, unit and lease entities are not built — the note above is exact about the ceiling.
See the property setup in AWRAFrequently asked questions
Should a building be a project, a department or a warehouse?
A project, if you need financial reporting per building — it is the only dimension that appears on customer invoices, expenses, stock adjustments and payout runs. A department will not work for this: it reaches budgets and purchase orders but not expenses, so you could budget for a building and never report what it spent. Use a warehouse in addition, for stock and plant, with the same code.
Can we report profitability per unit?
No. No dimension that carries money reaches below building level, so a repair cannot be coded to Flat 3B and neither can a rent invoice in a reportable way. The practical answer is a rigid naming convention on the customer and the invoice reference, and per-unit analysis in a spreadsheet. If per-unit margin is central to your business, test this specifically before buying anything.
Why not use departments for buildings?
Because there is no department on an expense or on a stock adjustment. Departments exist and reach budgets, purchase orders, assets, staff and tickets, so a department model looks correct while you are setting up budgets and fails the moment you want actual spend. It is the most common wrong turn in this decision and the most expensive to reverse.
How should tenants be modelled?
As customers, and this part needs no improvisation. You get contacts, addresses, a running balance, a credit limit with live exposure, invoices, receipts, ageing buckets and a statement of account you can email as a PDF. Of the six layers in a property model, the tenant is the one that maps cleanly onto generic software.
What happens with leases and renewal dates?
They live outside the system. There is no lease entity, so no start date, end date, rent amount, escalation clause or notice period as fields. The closest available mechanism is a recurring task with a due date as a renewal reminder — recurrence does genuinely spawn occurrences on a daily schedule, so the reminder will appear. The lease terms themselves stay in your document store.
How much manual work is rent invoicing?
This is the number to price before committing. Nothing generates invoices on a schedule, so every tenant's rent invoice is raised by hand every month. At ten units it is an afternoon; at fifty it is a recurring job that dominates the administrative cost of the whole approach. Estimate it in hours per month at your actual unit count and decide with that figure in front of you.
Is it worth using the same code for the project and the warehouse?
Yes, and it costs nothing if you do it early. Identical codes mean the financial view and the stock view of a building line up without a lookup table, so "what did Westlands cost and what spares do we hold there" is two straightforward queries. Agree the format before the second building — retrofitting codes across existing data is the task that never gets done.
