The fee catalogue
Every fee your workspace charges is a row you control, not a number in the code.
Every fee — rent, deposits, surcharges, one-offs — is a definition in your workspace's own catalogue. Nothing about what you charge, or how much, is fixed by OmniPM. Two workspaces running the same software can bill entirely differently, and neither is a special case.
This is why documentation never quotes an amount as fact. Any figure you see in a worked example is illustrative. The authoritative answer to "what is the late fee?" is your own catalogue, and nowhere else.
What a definition holds
| Field | What it decides |
|---|---|
| Code | The stable identity. Survives relabelling — rename the fee and its history still lines up. |
| Label | What residents see, in English and Japanese. |
| Timing | When it bills: at move-in, monthly, at move-out, or per night. |
| Method | How the amount is derived — see below. |
| P&L category | Which revenue line it reports into. |
| Auto-settles | Whether it clears itself against the deposit at settlement. |
| Active | Whether it can be charged at all. Deactivating never rewrites history. |
The five methods
- Fixed — a flat amount.
- Percent of rent — a share of base rent, so it tracks a rent change automatically.
- Tiered by stay — the amount depends on how long the resident stayed, in days or months.
- Per extra guest — applies from a guest count threshold, optionally multiplying per additional guest.
- Per bed — priced by bed size, which is how bedding is billed.
The room-restoration fee is the one built-in exception: it is set on the unit (Properties ▸ a unit's Pricing tab — see Properties), not as a catalogue rule, and it is frozen onto the reservation the moment it is made. Editing a unit's fee only ever affects bookings made afterwards.
Rules: the same fee, different answers
A definition says what the fee is. Rules say what it costs in a given situation, and the more specific rule wins. A rule can be narrowed by:
- Property type — sharehouse or apartment.
- Building — one building overrides the type-wide default.
- Bed size, for per-bed fees.
- Date range — every rule has an effective-from, and optionally an effective-to.
That last one matters more than it looks. Changing a price means adding a rule that starts today, not editing yesterday's. An edited rule rewrites what the past says it charged; a new rule leaves the old one intact and correct for the reservations that were quoted against it. See Pricing snapshots for why that history has to survive.
Built-in and workspace-defined fees
Some codes are built-in: rent, utilities, building maintenance, the security deposit, the reservation fee, short-term and guest surcharges, bedding, restoration, the room-change fee. They are built in only because they occupy named places in invoices, contracts and the ledger — not because their amounts are fixed. Every one is still a row you set.
Anything else your workspace bills gets its own code and rides the generic path. It appears on invoices, in the ledger and in the P&L exactly like a built-in one.
Catalogue mode
A workspace runs the catalogue in one of three modes:
- Legacy — pricing comes from the older per-building fields.
- Shadow — the catalogue is evaluated alongside legacy pricing and the two are compared, but legacy still decides what is billed. This is the safe way to move an existing workspace across.
- Active — the catalogue decides.
Never infer which mode a workspace is in from documentation, including this page. Check the workspace. A change made in the wrong mode either does nothing visible or changes real invoices, and the two look identical while you are making it.
Ordering
Fees appear on invoices and quotes in the catalogue's own sort order, not alphabetically and not in the order they were added. If a fee is showing up in an odd place on a resident's invoice, that is where to fix it.
See also Pricing snapshots, The ledger and Move-out penalties.