Software for aparthotels: monthly stays, meters and billing

Aparthotel software is a property management system built for stays measured in weeks or months rather than nights: it prices by stay length, posts recurring charges to a running guest account, records meter readings as billable data, schedules housekeeping by plan, and keeps identity and invoicing duties visible across long stays.

A guest checks in for six weeks, the flat has its own electricity meter, and nobody is leaving on Friday. A nightly-rate screen has nothing to say about any of that: check whether yours does. This article walks through what actually changes when the unit of sale is a month: pricing bands, recurring billing, meter charges, scheduled housekeeping and the identity and invoicing duties that survive a long stay. It ends with five tests you can take to any vendor demo.

How does an apart stay differ from a hotel stay?#

An apart stay is longer, self-catering and often metered, so the unit of sale is a period rather than a night and the bill stays open for weeks. That single difference reshapes most of the software.

The unit of inventory is a flat with a kitchen and a meter, not a room type with a bed count. Availability has to be tracked per flat, because two flats of the same size may differ in what they include: one may have a balcony and its own meter, the other may not.

Arrivals are fewer and departures are rarer, so the daily rhythm of a hotel, the arrival list, the departure list and the night audit, does not describe the working day. The working list is who is in-house and what is due. Housekeeping is planned rather than daily: a weekly clean, a linen change, an on-request service.

Utilities may be included in the rate or billed by consumption, and that choice changes both the contract and the bill. The guest stays across weeks and often across invoicing periods, so the account is a running ledger with recurring postings, not a folio closed at check-out. And the guest is partly a resident: they receive post, they may want a maintenance visit, and they notice when the internet fails at 21:00.

Can one system price by night, week and month at the same time?#

Yes, if the rate model works in stay-length bands and every quote shows which band and which rule produced the final price. A price a receptionist cannot explain to a guest is a price that will be discounted at the desk.

Define the bands explicitly: a nightly rate, a seven-night rate, a 28-night rate, and a rule for what happens on night 29. A band without a boundary rule produces arguments at the desk. Set a minimum stay per band so a one-night booking cannot pick up the monthly price.

Handle the peak-night problem. A monthly rate that quietly swallows a sold-out weekend loses money, so either the band excludes defined dates or the monthly price is calculated on top of protected nights. Decide the pro-rata rule before you need it: a 45-night stay is one month plus 17 nights, and the order in which the two are applied changes the total. Keep extensions and shortenings inside the same logic, so a guest who stays five nights longer is repriced by rule rather than by guess. For a deeper treatment of the pricing side, see long-stay hotel rates: pricing weekly and monthly stays without losing peak nights.

How do recurring bills and part-month stays work?#

The guest account is posted to on a schedule, so rent, service charges and fees land on the right period while the guest is still in the flat, and the account is reviewed rather than closed.

Define the posting calendar: what is charged at arrival (deposit, first period, cleaning), what recurs (rent, service charge, parking), and what is charged at departure (meter difference, damage, final clean). Fix the period boundary: a calendar month, a 30-night cycle or the arrival anniversary. Pick one and apply it to every flat, because mixed boundaries make the monthly report unreadable.

Decide the part-month rule in days, not in fractions of a month, and write it into the contract. A guest who arrives on the 24th should be able to check the arithmetic. Treat the deposit as a liability held against the flat, not as revenue, and release it with a dated record of what was deducted and why.

Handle mid-stay change carefully. An extension posts a new period; a shortening recalculates the band and may change the price of nights already stayed, so the account must show the recalculation rather than a silent edit. Keep corrections as reversals: a wrong charge is voided and re-posted, never deleted, so the account still tells the truth a month later.

Ask your accountant how often a fiscal document should be issued for a stay that spans periods. The invoicing cadence is a tax question, not a software setting.

Who reads the meter, and how does the charge reach the bill?#

Someone reads the meter on a dated visit, the reading is stored as a number attached to that flat and that date, and the difference between two readings becomes a charge line on the guest account.

Take an opening reading at check-in and a closing reading at check-out, both with a date, a value and a photo. Without the opening reading there is no defensible difference. Decide who reads: your staff on a route, the guest sending a photo, or a remote meter that reports on its own. Each choice changes how often you can bill and who owns a mistake.

Store the unit price alongside the reading, so a price change mid-stay does not rewrite past charges. Separate what is metered per flat from what is shared (common corridors, hot water, internet); a shared cost is a fixed fee, not a meter charge, and mixing the two invites disputes. Set a fair-use cap or an allowance in the contract, for example a monthly kilowatt allowance included in the rent, and let the software apply the allowance before it charges the excess.

Make the evidence visible to the guest: a reading they can see, with a date and a photo, ends most arguments before they start. Never keep readings in a free-text note; a note cannot be summed, audited or shown to a guest who asks in month two.

How does housekeeping work when nobody checks out?#

Housekeeping is scheduled against the stay plan, not against a departure list, so the task appears on the right day even though the flat stays occupied.

Define service tiers in the contract: a weekly clean with linen change, a mid-week refresh, and an on-request service with a stated notice period. Model flat status differently from a hotel room: occupied and serviced, occupied and due, vacant and clean, vacant and dirty. A two-state clean/dirty model loses the information the supervisor needs.

Trigger tasks from the arrival date plus the service interval, so a 40-night stay generates its cleans automatically and a 3-night stay generates none. Record access: a guest who works from the flat needs a time window, and a refused service should be logged rather than silently skipped. Plan maintenance the same way, because a long stay is when the air-conditioning filter and the boiler actually get looked at. Keep the inspection separate from the clean, so quality is checked by a second person on long stays where there is no departure to hide behind. How much technology a property of your size needs is covered in hotel technology by size.

What changes for identity notifications and tax on a long stay?#

The duties do not disappear because the stay is long; what changes is timing, refresh and invoicing cadence, and those answers belong to your accountant and your own case.

In Türkiye, every stay involves a payment, a fiscal document (an invoice or e-document), a guest identity notification (KBS, the misafir kimlik bildirimi) and personal data (KVKK, the kişisel verilerin korunması kanunu). A six-week stay contains all four, not fewer. Ask your accountant and, where relevant, the law enforcement portal, whether a long stay needs a refreshed notification, and record the answer in your procedure so reception applies it the same way every time.

A stay that crosses tax periods raises the invoicing question: how often a document is issued, and what it covers. The answer depends on your taxpayer scope, so confirm it rather than copying another property. Personal data collected at check-in is kept under a retention rule; a long stay accumulates more data (contract, meter photos, correspondence), so decide where it lives and when it is destroyed.

Do not rely on fine amounts or deadlines quoted in a blog or a forum; they are re-valued and amended, and the current figure comes from your adviser. Write the answers down as a one-page procedure: what reception does at check-in, what the accountant does each period, and who checks that both happened.

What should you test in an aparthotel software demo?#

Test the five cases that a nightly-rate system fails, and ask the vendor to run them live rather than showing a prepared screen. A prepared screen proves nothing about the five situations that will actually cost you money.

• Sell a 45-night stay that contains a sold-out weekend, then read the quote: it must show the band, the protected nights and the final figure without anyone explaining it verbally.
• Post a monthly rent charge in the middle of a stay and check that it lands on the correct period and the correct flat account, and that the guest bill shows it as a period charge rather than a random line.
• Enter two meter readings with dates and a photo, and confirm the system calculates the difference, applies the allowance and produces a charge you can show to the guest.
• Set housekeeping to weekly, then confirm the task appears on the right day for an occupied flat with no departure in sight.
• Shorten a stay by five nights and check that the price recalculates by rule, that the account shows the recalculation, and that nothing already posted is silently edited.

What to do next#

Write your own three rules down before you look at any software: the stay-length bands and what happens at their boundaries, what is metered and how it is read, and the housekeeping interval per stay length. Then take the five demo tests to a vendor and ask your accountant the invoicing and identity questions in parallel, because the software can only apply rules that you and your adviser have already decided.