Homestay PMS vs Excel: What Breaks at 10, 30 and 50 Units (and What It Costs to Fix)

A spreadsheet can run a homestay business with one owner, one channel and under 10 units. It breaks in a predictable order as you grow: the calendar first (around 10 units on two or more channels), the owner statements next (around 30 units with several owners), and the people last (around 50, when the sheet becomes one person's memory). Here is what breaks at each stage and what a PMS costs to replace it.

Every "software vs spreadsheet" article on Google is written for long-term landlords in America: one tenant a year, one rent a month, three units is "a lot". A homestay in Johor Bahru or Desaru is a different animal. One unit turns over 8 to 12 times a month, sells on three or four channels at once, collects deposits, needs a cleaner between every stay, and usually belongs to someone else who wants a statement at month end. The spreadsheet does not fail at 3 units. It fails at specific jobs, and the job that fails depends on how many units, channels and owners you have.

We run 100+ units in Johor Bahru and Desaru on AntlerHub, the PMS we built for ourselves. This article is not "spreadsheets bad, software good". It is the list of what actually breaks, in the order we have seen it break for operators who come to us, so you can decide whether you are there yet.

What does a homestay spreadsheet actually have to do?

More than a landlord's sheet, and the difference is the whole argument.

A sheet that tracks all of this for one unit has five tabs. For 10 units on three channels it has 30 live calendars that must agree with each other and with the channels, and nothing in Excel makes them agree. That is the first thing that breaks.

What breaks at 10 units?

The calendar, the moment you are on more than one channel.

With one channel (say Airbnb only) and 10 units, a spreadsheet plus the Airbnb app is survivable. Airbnb holds the real calendar; the sheet is just your record. The trouble starts when you add Agoda or Booking.com for the weekday gaps that Airbnb leaves empty. Now there are two sources of truth and the sheet is the thing in the middle, updated by a human after the fact.

The failure is not usually a dramatic double booking on the first week. It is slower:

• A booking lands on Agoda at 11pm. You block it on Airbnb the next morning. Between those two moments the night was open on both.
• You raise the weekend price in the sheet and on Airbnb, and forget Agoda. Agoda sells the Saturday at the old price. Your sheet says one number; the payout says another.
• A guest extends by a night through Booking.com. You copy the original dates into the sheet last week; the extension never makes it in. The cleaner turns up to an occupied room.

At 10 units and three channels that is 30 calendar pairs to keep in step by hand, every day. We wrote a separate piece on the 7 ways a channel sync goes wrong even when it is automated. By hand, all seven happen, just more slowly.

The honest exception: 10 units, one owner (you), one channel, and you are the only person touching the sheet. That works. We would not tell that person to buy anything yet.

What breaks at 30 units?

The owner statements, and the trust that depends on them.

By 30 units you almost certainly have several owners, and each one wants to know at month end what their unit earned, what it cost, and what they are getting. In a spreadsheet this is a monthly ritual: export the Airbnb payout CSV, export the Agoda statement, paste, match each line to a unit, split the cleaning fee, allocate the shared expenses, write the statement, send it.

Three things go wrong at this size, and they are all money:

Payouts do not match bookings. An OTA pays you in batches, weeks later, net of commission, sometimes 40 stays in one transfer, sometimes a line in SGD inside a MYR transfer, sometimes with no booking reference at all, just a guest name and a check-in date. Matching that to 30 units by eye is where the leaks are. A line that cannot be placed gets "parked" and the owner it belongs to is short that month. Nobody notices until an owner asks.

Shared expenses get allocated by feel. Wi-Fi for a building, a bulk linen order, a handyman call that covered three units: in a sheet someone divides it however seems fair that month. Two owners in the same building compare statements over coffee and find different numbers for the same expense. That is the conversation that ends management contracts.

The statement is only as right as the person who built it, that month. A real one from our own operation: an owner with 10 units grossed RM 67,081 in December 2025 and received RM 50,311 after commission and expenses. That statement has a month of bookings across several channels behind it, plus deposits held and released, plus the shared expense split. In AntlerHub it is generated on the day; the owner logs in and sees it. In a spreadsheet it is a weekend of work for one person and it is wrong if that person is tired.

The rule a PMS enforces here is dull and essential: every ringgit in has a booking or a flagged exception, every expense has an owner or a share rule set once, and the statement is produced from those, not typed. We have written separately about what real owner statements look like, including the quiet months.

What breaks at 50 units?

The people. The spreadsheet has become one person's memory, and that person cannot take a holiday.

At 50 units you have cleaners, a handyman, someone on WhatsApp with guests, probably a second admin. The sheet is now shared, and shared spreadsheets fail in a way single-user ones never do:

• Two people edit the same tab; one overwrites the other's bookings. Nobody knows which version was right.
• The cleaner has a different sheet (or a WhatsApp group) for turnover. The admin's sheet says "ready"; the cleaner's says "still dirty". The guest gets the door code anyway.
• The person who built the sheet is the only one who knows which cell not to touch. When they are sick, bookings go unblocked for two days.
• Deposits are held in someone's head: which guest paid RM 300 by transfer, which one is due a refund, which one forfeited. At 50 units with 8 to 12 stays each, that is hundreds of deposits a month.

What a PMS does at this size is not "automation" in the brochure sense. It is that the calendar, the turnover state per unit, the deposit ledger and the owner numbers live in one place that several people can touch at once without overwriting each other, with a record of who changed what. In AntlerHub the turnover state (occupied, dirty, ready) is per unit and visible to the cleaning team; deposits are held, released or forfeited with the accounting entry written at the same time; and every channel call is logged. None of that is clever. It is just not possible in Excel with four people.

What does a PMS cost at 10, 30 and 50 units in Malaysia?

AntlerHub's published price is one flat rate: RM 1.50 per credit, 10 credits per active unit per month, so RM 15 per unit per month before SST, with the channel manager, direct booking site, self check-in, AI WhatsApp replies, deposits, owner portal and payout runs all included. New accounts get 50 credits free, there is no setup fee and no contract.

For the spreadsheet column we have deliberately not invented an hourly rate. Use your own. If you want a floor, Malaysia's statutory minimum wage is RM 1,700 a month; at 10 units, one hour a day of calendar work at even that rate costs more than RM 150. At 30 and 50 the comparison is not really about hours any more; it is about whether the owner statements are right.

Is there a case for staying on the spreadsheet?

Yes, and we would rather say it than have you find out after paying.

• Under 10 units, one channel, one owner: stay. Airbnb's own calendar is your system; the sheet is for tax.
• You only want the calendar synced and nothing else: a cheaper channel-manager-only tool may be enough. AntlerHub bundles the owner portal and finance whether you use them or not, and at 10 units with no outside owners that is paying for things you do not need yet.
• You are not ready to let one system own the calendar: a PMS only works if you stop editing the channels by hand. If your team will keep "just quickly" changing a price on the Agoda extranet, the PMS will fight them and lose. Fix the habit first.
• Your real problem is occupancy, not admin: software does not fill rooms. If 30% of your nights are empty, the money is in pricing and photos, not in a better sheet.

How do you move off the spreadsheet without a double booking?

The switch is the most dangerous week in a homestay operation, because for a few days two systems both think they own the calendar.

1. Import first. Every existing booking from every channel goes into the PMS before anything is switched on. The sheet stays live.
2. One listing, one channel, read-only. Connect a single unit and let the PMS read bookings for a few days. Compare against the sheet. Fix the mapping until they agree.
3. Pick a cut-over date. On that date the PMS takes ownership of pushing rates and availability for that unit; you stop editing that channel by hand. In AntlerHub, push ownership is recorded per listing per channel, so the system refuses to push to a channel it does not own.
4. Roll out by building, not all at once. Owners get their logins when their units are live, not before.
5. Keep the sheet for one more month, read-only, to check the first statements against it. Then retire it.

The whole thing is usually two to four weeks for 30 units. The step people skip is step 2, and that is where double bookings come from.

The short version

AntlerHub is the system we built to run our own 100+ units, and every rule above exists because we hit the problem first. If you are at 10 units on three channels and want to see what your calendar looks like when one system owns it, the AntlerHub page has a demo request: 30 minutes on your own listings, not a slideshow.