The short answer: a homestay owner statement is gross revenue for the month, minus the expenses that belong to that unit, split by whatever the contract says (a share of revenue or a share of net profit), minus anything the owner owes, equals the amount paid. Our PMS, AntlerHub, computes that for 100+ units every month in three stages: draft, generated, paid. Here is exactly how.
Most guides to owner statements are written for the United States and stop at a list of line items. They do not show you the formula, they do not say who pays the electricity bill, and they do not explain why the owner's money does not arrive on the 1st. This article does, using the rules our own system runs on. Where a number is an example rather than a real figure, it says so.
What is actually on a homestay owner statement?
Ours has six lines that must reconcile with each other before anything else matters. The names are the ones the system uses.
| Line | What it is | Where it comes from |
|---|---|---|
| Gross revenue | Everything guests paid for stays that fall in the month, OTA and direct | Reservations, one row per stay |
| Shared expenses | Costs that both owner and operator carry, in the agreed ratio | Expense bills tagged to the unit |
| Owner portion | The owner's share before their own expenses | The split formula |
| Management fee | What the operator keeps | Gross − expenses − owner portion |
| Owner expenses | Costs that are 100% the owner's | Expense bills tagged "owner" |
| Paid amount | Owner portion − owner expenses − anything the owner owes | The number that goes to the bank |
One check runs on every statement: owner portion plus management fee must equal gross revenue minus all expenses. If it does not, the statement is wrong and we do not send it. A spreadsheet can carry a broken total for months; a statement engine refuses to.
For what a real month looks like once those six lines are filled in, see the December statement we published: 10 units, RM67,081 gross, RM50,311 to the owner.
Where does the gross figure come from, and which month does a booking belong to?
Gross is the sum of what the guest paid for each stay, taken from the reservation itself, not re-typed. Every stay night in our system keeps a snapshot of the rate it was sold at, so the statement for March still shows March's price even if the rate card changed in April.
The month boundary is Malaysia time, first day 00:00 to last day 23:59. That sounds obvious until you run a system hosted in UTC: a booking that checks in at 7 am on 1 March is still 29 February in UTC. We convert on purpose so no owner ever sees a stay land in the wrong month.
Three things do not change the gross line, because they are not revenue:
- Referral commission. When a guest came through a friend's referral code, the 5% commission is an expense row on the statement, not a cut taken out of the room price. The room stays at what the guest paid.
- Owner's own stays. If an owner stays in their own unit, that is not a booking that earned money, so it is not revenue (more on it below).
- Deposits. Security deposits are held and refunded; they never pass through the owner statement.
Which expenses are deducted, and who pays each one?
This is the part most owner statement templates skip, and it is the part owners argue about. Our statement has twelve expense buckets, and every bucket carries a tag: owner, operator or shared.
| Expense bucket | Typical tag in our contracts | How "shared" is split |
|---|---|---|
| Water, electricity, internet | Shared or owner, depends on the plan | In the owner's revenue ratio |
| Cleaning | Shared, one line per checkout | Same |
| Laundry, toiletry set | Shared | Same |
| Check-in fee, check-out fee | Operator or shared | Same |
| Service / admin fee | Set as a percentage of gross if the plan has one | Same |
| Promo code discounts | Shared | Same |
| Referral commission (5%) | Shared by default | Same |
| Other | Whatever the bill says | Same |
"Shared" means the owner carries the expense in the same percentage as their revenue share: on an 80% plan, the owner carries 80% of a shared bill and the operator 20%. "Owner" means 100% comes off the owner's side. "Operator" means the owner never sees it deducted.
Cleaning deserves one honest note. The correct source for the cleaning line is an actual bill per turnover. When there is no bill entered yet for a checkout, the system fills the gap with that unit's standard cleaning cost from its settings, so the statement is complete on the day it is generated. That filler is a standard rate, not a receipt. If the real bill later comes in different, we re-post, and the owner sees the correction. We would rather tell you this than pretend every line was an invoice.
How is the owner payout calculated? Revenue share vs net profit share
A PMS is only useful here if it can run the formula your contract actually uses. Ours supports five. The first two cover almost every contract we run.
| Contract type | Formula for the owner | Who carries expenses |
|---|---|---|
| Revenue share (our 90% plan) | Gross × 90%, then owner's own expenses come off | Owner pays cleaning, utilities, consumables |
| Net profit share (our 80% / 70% plans) | (Gross − all expenses) × 80% or 70% | Deducted from revenue before the split |
| Fixed rent (sublet) | A fixed amount per month | Operator carries everything |
| Guaranteed return | A fixed floor, plus a % of any surplus above it | Deducted before the surplus is worked out |
| Threshold two-tier | One % up to a revenue line, a second % above it | Deducted from revenue |
A worked example (these are illustrative numbers, not a quote): one unit, RM10,000 gross in the month, RM3,000 of expenses. On the 90% plan those expenses are the owner's; on the 80% and 70% plans they come off before the split.
| 90% revenue share | 80% net profit | 70% net profit | |
|---|---|---|---|
| Owner share before expenses | RM9,000 | — | — |
| Net after expenses | — | RM7,000 | RM7,000 |
| Owner receives | RM9,000 − RM3,000 = RM6,000 | RM7,000 × 80% = RM5,600 | RM7,000 × 70% = RM4,900 |
| Operator keeps | RM1,000 | RM1,400 | RM2,100 |
Notice that at 30% expenses the 90% plan pays the owner more; push expenses past 50% of gross and the 80% plan overtakes it. Which plan wins is a question about the unit's expense ratio, not about the headline percentage. We wrote that comparison out in full here. The point for this article is simpler: the statement engine must know which formula each unit is on, because two owners with identical gross can correctly receive different amounts.
What happens when the owner stays in their own unit?
Every management contract allows the owner some nights a year. Our system lets the operator set the rule once per company: how many nights, whether the allowance is per unit or across all the owner's units, when the year resets, and what a stay costs (free, the unit's cleaning fee, or a fixed amount). Nights beyond the allowance are still bookable, at the normal price.
Whatever an owner stay costs is taken off the paid amount after the split, as its own line. It is deliberately not treated as revenue (it is not a sale) and not as an expense of the unit (it is not a cost of running it). It is money the owner owes, so no revenue share and no expense split touches it. A blocked date where nobody stays costs nothing and uses no nights.
Why does the statement not arrive on the 1st, and what are the three stages?
The answer is that a statement is not one event. Ours goes through three states, and each one exists for a reason.
1. Draft. Every day, a scheduler creates a draft for the previous month for any active unit that does not have one yet. Drafts recompute from live data every time they are opened, so if a cleaning bill is entered on the 4th, the draft on the 5th already reflects it. If a unit was switched on mid-month or the server restarted, the next morning's tick simply fills the missing draft. Nothing is sent to the owner at this stage.
2. Generated. When the operator is satisfied the month's bills are in, they press Generate. The numbers freeze, the owner can see the statement in their portal, and the management fee invoice is written to the accounting ledger (a sales invoice per unit, so the company's revenue for the month is booked at the same moment the owner sees their figure). Generating is reversible: voiding a generated statement voids that invoice and returns the row to draft.
3. Paid. The payout run happens, and each statement is marked paid with the accounting entries behind it. There are two ways to pay 100+ owners. One line per owner on the bank statement, which is clean for the auditor but slow to key. Or one bulk transfer with a payout list, which is how we do it: the ledger records one money-out line for the batch and a bill per unit underneath it, so the bank statement shows a single transfer and the books still know who got what.
The gap between the end of the month and "Paid" is mostly waiting for bills and for the platforms. Agoda, Booking.com and the others pay on their own schedule; our settlement screen matches each payout statement to the reservations it covers and flags any stay that is still awaiting money. A statement can be generated before every platform has paid, but we prefer the owner's money and the owner's paper to agree.
What does the owner actually see?
Each owner has their own login. They see their bookings, their occupancy, the expense rows with the bill behind each one, and the monthly statement once it is generated, downloadable as PDF or CSV. The operator decides what is visible. If an owner wants to check the cleaning line against the number of checkouts, the checkouts are on the same screen.
This transparency cuts both ways, and we think that is correct. An owner who can see every bill will ask about the ones that look wrong, and sometimes they are right. We would rather fix a RM40 line in the portal than defend it in a WhatsApp group.
Can a spreadsheet do this instead?
At 3 units, yes, and we said so in our PMS vs Excel article. At 10 units with two contract types, a shared-expense ratio and an owner who stayed four nights in March, the spreadsheet is where the mistakes live. The formula is not hard; keeping it applied correctly to a hundred units, every month, with the bills arriving late, is what a statement engine is for. The same engine also has to agree with the calendar, which is a separate problem we covered under channel sync.
For operators who want to run this themselves, AntlerHub's published price is RM 1.50 per credit and 10 credits per active unit per month, so RM 15 per unit per month before SST, with owner statements, the owner portal, payout runs and the accounting posting included; new accounts start with 50 free credits and there is no contract. If you are closing month-end for other people's units, the full flow is on the AntlerHub page.
This article describes how our software records and presents figures. It is not accounting or tax advice; how your company books management fees, SST and owner payouts should be confirmed with your own accountant.