Skip to content
Kuberan AI Help

Rent changes

Rent changes are mid-lease rent movements that weren’t written into the lease at signing. The classic use case: the annual guideline increase notice a landlord serves their tenant. They sit alongside escalations (which are pre-planned, written into the lease) as the second mechanism for moving Lease.baseRent after signing.

Scheduled vs applied

A RentChange has three statuses:

  • Scheduled — the notice has been served (or at least recorded), but the effective date is in the future. The lease’s current baseRent is unchanged.
  • Applied — the effective date has arrived. Lease.baseRent has been bumped, future unissued RentSchedule rows have been repriced.
  • Rescinded — the landlord withdrew the notice before it applied. Preserved for audit; no rent movement.

The daily cron (03:10) picks up every scheduled change whose effectiveDate <= today and applies it.

Past-dated creates auto-apply

Create a rent change with an effectiveDate in the past (e.g. backfilling a notice you forgot to record), and the server applies it immediately — not on the next cron run. This is deliberate: without it, lease.baseRent would be wrong until overnight, and any rent invoice generated in the meantime would use the old amount.

The API returns appliedImmediately: true in that case.

The 12-month cooldown warning

Ontario and BC residential-tenancy rules require 12 months between rent increases. When you create a new RentChange, the server checks the last applied OR scheduled rent change on the lease — including scheduled ones prevents stacking pending increases to evade the warning. If the new effective date is less than 365 days after that one, the response carries a cooldown_12mo warning with the month gap.

This is warn-only — the change is still created. Scenarios where under-12-month increases are legitimate:

  • AGI (above-guideline increase) approved by the LTB.
  • Commercial leases (no cooldown rule).
  • Mutual agreement with a signed addendum.
  • Jurisdictions outside Ontario/BC with different rules.

The UI surfaces the warning as a yellow banner on the create dialog. The user confirms by proceeding; no second click is required beyond the initial save.

Create a rent change

  1. Open the Lease detail.
  2. Click Add rent change in the Rent History tab.
  3. Enter the Effective date (when the new rent kicks in) and the New rent amount.
  4. Optional: add a Notice date and Reason (guideline / AGI / market / mutual).
  5. If a cooldown warning appears, confirm it applies to a legitimate exception.
  6. Click Save. Status is scheduled if the effective date is in the future, applied if past.

Apply a scheduled rent change early

If the tenant agrees to apply the increase before the effective date:

  1. Open the Rent History tab.
  2. Click Apply now on the scheduled row.
  3. Confirm. The change is applied immediately — Lease.baseRent updates and pending RentSchedule rows reprice.

Already-applied or rescinded changes show “Apply now” as disabled.

Rescind a scheduled rent change

When the landlord withdraws a notice before it applies:

  1. Open the Rent History tab.
  2. Click Rescind on the scheduled row.
  3. Enter a Reason (optional, max 2000 chars — becomes part of the audit record).
  4. Confirm.

The row status flips to rescinded. Lease.baseRent is untouched. Rescinded changes are preserved forever — they never apply to rent, but they show in the Rent History tab with their rescind date and reason.

Note: applied rent changes cannot be rescinded. To reverse an applied change, create a new counter-change with the opposite movement.

Past-rent forecasting

The warning-cooldown check counts both applied and scheduled rent changes. This means if a tenant is already on a scheduled increase, stacking a second increase within 12 months of either the prior applied date OR the prior scheduled date triggers the warning.

What rent changes do NOT touch

  • Already-issued invoices. History stays accurate — an invoice issued at the old rent stays at the old rent.
  • Past RentSchedule rows (with invoiceId set). Once invoiced, they’re locked.
  • The escalations array on the lease. Escalations and rent changes are parallel mechanisms; one doesn’t overwrite the other.