Rental management
Rental owner statements: what an owner is owed, and how the number is derived
If you manage let property for owners, the owner statement is the document your relationship rests on. It has to say what was collected, what you charged, what the property cost the owner, what has already been paid out and what is owed now — and it has to be the same number the accounts say. Here is how that is achieved when the statement is derived rather than composed.
Last revised
What an owner statement actually is
An owner statement answers one question for one owner over one period: how much does the management business owe them, or they owe it, and how did that number come about? It is a running account, not a report — an opening balance, the movements in the period, and a closing balance that becomes next period’s opening.
The trouble starts when the statement is assembled rather than derived: rent collected copied from a receipts list, the management fee typed in, an expense added from an invoice, last month’s payout remembered. Each statement is then a small piece of authorship, and the owner’s balance exists only in the most recent one.
What moves the owner’s balance
In BuilderOne’s Rental module the owner account is not a stored balance. It is derived, for any period, from the documents that have already been recorded — so the statement is a reading of the accounts, not a document somebody writes. These are the sources it reads:
| Movement | Effect on the owner | Source document |
|---|---|---|
| Rent collected on the owner’s units | Credit — owed to the owner | A tenant receipt applied to an issued rent invoice |
| Money received from the owner | Credit | An active receive-from-owner record — for example the owner funding a repair |
| Management or owner service charge | Debit — owed by the owner | An owner service charge that has not been cancelled |
| Property expense the owner bears | Debit | An approved property bill on the owner’s unit, classified as an owner recovery |
| Payout already made | Debit | An executed owner payout, at its net amount |
| A reversed receipt from the owner | Debit | The receive-from-owner record’s reversal |
The balance is simply the credits less the debits. Positive, the business owes the owner; negative, the owner owes the business. Because every source is a document that already exists for its own reason, the statement for any past period recomputes to the same figure — there is no rebuild, and nothing to type.
Three rules that keep the statement honest
Deriving the balance is necessary but not sufficient. Three further rules decide whether the number is right.
- Income is recognised when the tenant pays, not when rent is invoiced. An invoice the tenant has not settled is the business’s receivable, not the owner’s money. This is also what makes partial netting need no special mechanism: 8,000 collected against a 10,000 charge is simply a balance of −2,000.
- Each source is counted once, at its own amount. A payout appears at its net figure, and the charges and expenses it deducted appear as their own debits. That is not double counting — the net payout is income less charges less expenses, so the parts and the whole reconcile by construction.
- The owner’s share is the share effective on the transaction’s own date. Ownership changes; a rent receipt in March is attributed at March’s ownership, not at today’s. A date on which no single owner can be resolved contributes nothing rather than being guessed — the system refuses to charge the wrong person.
Security deposits are not the owner’s money
A tenant’s security deposit is a liability to the tenant. It is not rent, it is not income and it does not appear in the owner’s balance. It is held, refunded or applied against what the tenant owes at the end of the tenancy — each a separate, posted event — and the owner statement should show deposits held as information, never as money owed to the owner.
In the general ledger this is exactly how BuilderOne posts it: a security deposit has its own posting adapter and lands as a liability, kept apart from rental income and from the owner payable.
Paying the owner without overpaying them
The moment of risk is the payout. Two mistakes are common: paying out against a balance that another, not-yet-executed payout has already claimed, and paying this month’s rent while last month’s unpaid charge is forgotten. Both leave the owner overpaid and the business chasing its own money.
- The amount available to pay is the owner’s balance less any payout that is drafted, submitted or approved but not yet executed. Two drafts cannot be raised against one pot.
- A payout deducts every open obligation the owner has on that property — not only the current period’s. An unpaid charge from a prior period is settled first, so the payout can never exceed what is genuinely available.
- The payout is an approved document, and the deduction of charges is final at approval — the first point at which it can no longer be undone. It runs through the same approval and segregation-of-duties controls as every other document that moves money.
- The payout is posted at its net amount, so what the business keeps is never recorded as owner income; it is the gap between gross rent revenue and the net owner cost, visible in the ledger as such.
What a good owner statement shows
- Opening balance, movements and closing balance for the period, with the closing balance carried forward.
- Rent collected, by unit and tenant, with the invoice each receipt settled.
- Charges and expenses, each named, each with the document behind it.
- Payouts made in the period, at the amount actually paid.
- Deposits held, shown separately from the balance.
- What is invoiced but not yet collected — informative, and not part of the balance until it is.
Where this lives in BuilderOne
See it on your own numbers
The fastest way to judge whether this is how your software should work is to put a real project through it. Tell us what you run and we will set your company up.
