Rentara Manual, as shipped in the download
Rentara — User Manual
Properties, tenancies, rent and maintenance, on your own server. Version 3.1.4 [src: app/controllers/api.php:17].
About this manual
Every statement here was written by reading Rentara's own source, and each one carries the file it came from in a bracketed src marker. Paths are relative to the folder this docs directory sits in. If a sentence disagrees with the application, the application is right and this manual has a bug — the markers exist so you can check rather than take our word for it.
Nothing is described that the code does not do. Where something is deliberately limited, that is said plainly rather than left out.
What Rentara is
Properties and units, tenants and leases, the rent they owe and the maintenance they report. The operations logic sits in one pure module that the screens and the test suite both call directly, with no database and no network involved [src: app/src/Rent.php:3].
Money is integer cents; dates are YYYY-MM-DD and months YYYY-MM [src: app/src/Rent.php:15]. Because ISO dates sort lexicographically the same way they sort chronologically, plain string comparison is used for every date boundary [src: app/src/Rent.php:16].
Rent charges
Charge generation is idempotent. A lease that already has a charge in a month is skipped, so re-running never double-creates [src: app/src/Rent.php:100]. Only active leases produce charges [src: app/src/Rent.php:120].
There is a second guard in the same function against duplicate leases appearing in the input [src: app/src/Rent.php:129], so a bad query upstream cannot produce two charges either.
Arrears means an unpaid charge past its due date — the boundary being strictly before today [src: app/src/Rent.php:57].
Late fees
Off by default: with both the flat amount and the percentage at zero, the automation is disabled entirely [src: app/src/Rent.php:334].
A fee is a flat amount plus a proportion of the overdue rent expressed in basis points, clamped to the integer range [src: app/src/Rent.php:310].
Four rules govern when one is charged, and they are worth knowing because they are what stops a late-fee system running away.
One fee per overdue period, ever [src: app/src/Rent.php:352].
Fees never compound. Only rent charges are considered; a late fee cannot itself attract a late fee [src: app/src/Rent.php:344].
Grace is inclusive of its last day. The source gives the worked example: a charge due 1 July with five grace days incurs no fee through 6 July, and a fee from 7 July [src: app/src/Rent.php:320].
The fee's own due date is deterministic — the original due date plus the grace period plus one day — so re-running the catch-up on any later day produces the identical row [src: app/src/Rent.php:321].
That last one matters more than it sounds. It means you can run the process late, or twice, or after restoring a backup, and the books do not change.
Leases and units
Assigning an active lease to a unit occupies it; ending the lease frees it [src: app/src/Rent.php:186].
Leases expiring within a window are listed soonest first, with the window inclusive at both ends and already-expired leases excluded [src: app/src/Rent.php:138].
Lease-ending emails
Off until you tick "a lease is 60 days, and again 14 days, from ending" under Settings → Email. The check lists every active lease that has newly reached 60 days, or 14 days, from its end date, in one message to your notification address, through your own SMTP server [src: app/controllers/app.php:95]; each lease is mentioned once at each stage, and a renewed lease (a new end date) starts over. Slots are claimed before the mail server is contacted and released if the send fails [src: app/controllers/app.php:122]. It runs when cron/lease-ends.php runs (once a day; --dry-run sends nothing) or when you press Check leases now [src: app/controllers/app.php:172]. Nothing is written to a tenant.
Maintenance tickets
The transition table is small and explicit [src: app/src/Rent.php:161]:
| From | May move to |
|---|---|
open | in progress, resolved |
in_progress | open, resolved |
resolved | open |
A resolved ticket can be reopened, and the agent instructions give the reason plainly: reopening a job that was not actually fixed is a real thing that happens [src: app/controllers/v3.php:31].
Resolving stamps the time and preserves an existing stamp; moving to any other state — including reopening — clears it [src: app/src/Rent.php:174].
The tenant portal
A lease can be issued a self-service link, and revoked again [src: app/index.php:112].
The portal is public and token-gated [src: app/index.php:145], reachable at a token URL where a tenant can view their tenancy and submit a request [src: app/index.php:146]. The source describes it as carrying no personal information beyond the lease itself [src: app/index.php:145].
Issuing and revoking those links is a portal.manage permission, held by agents and administrators.
Users and roles
Three roles. The source names the asset as money movement and the tenancy record, and the reasoning is the sharpest justification for a role split in the catalogue [src: app/src/Perms.php:5]:
Marking rent paid is not data entry — it is an assertion that money arrived, and it is what a tenant will point at months later when a deposit is withheld. Ending a lease, deleting a tenant or wiping a property destroys the record a deposit dispute rests on. Changing the late-fee rule silently changes what every future arrears figure means [src: app/src/Perms.php:7].
The split it draws: the letting desk runs the day, the owner's office holds the record [src: app/src/Perms.php:12].
This table was produced by executing the product's own permission function against every permission the routes ask for.
| Permission | viewer | member | admin |
|---|---|---|---|
dashboard.view | yes | yes | yes |
properties.view | yes | yes | yes |
tenants.view | yes | yes | yes |
leases.view | yes | yes | yes |
rent.view | yes | yes | yes |
tickets.view | yes | yes | yes |
statements.view | yes | yes | yes |
exports.run | yes | yes | yes |
rent.record | — | yes | yes |
properties.edit / tenants.edit / leases.edit | — | yes | yes |
tickets.edit | — | yes | yes |
portal.manage | — | yes | yes |
properties.delete / tenants.delete / leases.delete | — | — | yes |
settings.view / settings.manage | — | — | yes |
team.view / team.manage | — | — | yes |
audit.view | — | — | yes |
Recording rent is a member permission; deleting anything is not. That is the split in practice — an agent can assert that money arrived, but only the owner's office can remove the record of it.
The late-fee rule sits behind the settings permission, so it is an administrator's decision. Changing it changes what every future arrears figure means [src: app/src/Perms.php:9].
A viewer reads the rent roll, arrears, leases, tickets and statements, sees no tenant contact details it does not need, and can change nothing [src: app/src/Perms.php:14].
Backups follow the model here
Rentara's database backups are permission-gated, requiring the settings permission rather than a bare sign-in [src: app/controllers/api.php:322], and so are the restore page and the scheduled-backup token. A viewer or member cannot download the database.
The API and agent access
Seven tools are exposed to an agent, of which two write [src: app/controllers/v3.php:34]: properties, leases, lease detail, the rent roll and the arrears report on the read side; creating and advancing a maintenance ticket on the write side.
The MCP tool set contains no payment tool — an agent working through it cannot assert that money arrived.
The REST interface is a different matter, and the distinction is worth stating precisely rather than glossed. POST /api/leases/{id}/payments does record a payment against a charge [src: app/controllers/api.php:213], and it is gated by exactly the permission a person needs: rent.record, checked against the key's own role [src: app/controllers/api.php:82].
So a key issued to a viewer cannot record a payment, and a key issued to an agent or administrator can. That is the same rule the office works under, applied to the key — not a bypass of it.
Payment methods are recorded, not processed: cash, cheque, transfer, card or other [src: app/src/Billing.php:104]. "Card" means a card payment happened somewhere else and is being written down.
The instructions tell an agent that a ticket moves only along the product's own transition table [src: app/controllers/v3.php:30], and that arrears and rent-roll figures come from the same engine the screens render [src: app/controllers/v3.php:33] — so an agent's numbers and the office's numbers cannot diverge.
What Rentara does not do
It does not take payments. Recording that rent arrived is an assertion by a person [src: app/src/Perms.php:7]; the money moves somewhere else.
It does not process a payment. A key with the rent.record permission can write down that one arrived [src: app/controllers/api.php:82], and the method recorded is just a label [src: app/src/Billing.php:104] — no money moves through Rentara.
It does not compound late fees [src: app/src/Rent.php:344], and it charges at most one per overdue period [src: app/src/Rent.php:352].
It does not double-charge if you run it twice [src: app/src/Rent.php:100], and a late-fee catch-up run on any later day produces the same rows it would have produced on time [src: app/src/Rent.php:320].
It is not a deposit scheme, a credit reference or a tenancy-law adviser. It holds the record that a dispute would be argued from; it does not decide the dispute.