Understanding recurring contracts
Back to index The two objects, and why there are two A recurring expense in URBI is built out of two things. They stay separate on purpose. The template is the WHAT. The vendor, the amount, the tax,...
Last updated
The two objects, and why there are two
A recurring expense in URBI is built out of two things. They stay separate on purpose.
The template is the WHAT. The vendor, the amount, the tax, the GL account, the line items. It answers: "what does this expense look like?"
The contract (the schedule) is the WHEN and the HOW MUCH TOTAL. The frequency, the interval, the start, the term, whether it drafts or auto-posts, and the contract type. It answers: "how often does this fire, for how long, and what have we committed to?"
You can prefill a one-off expense from a template without ever scheduling it. That is why templates are not merged into schedules: they have their own job.
Before this release, the contract half was essentially invisible. It generated expenses and nobody could see what it had committed the property to. That is what changed.
FIXED vs VARIABLE: the core distinction
Every recurring contract now declares a contract type at creation. There are exactly two.
FIXED
The amount is a committed price.
You signed a contract with an elevator maintenance company for $2,350 a month for 36 months. That is a FIXED contract. The number is not an estimate. It is what you agreed to pay, and it is what you will pay.
What FIXED buys you:
- The amount is locked in the sense that it cannot change quietly. Change the price on the template and the contract becomes an amendment: it goes back through the full staff approval chain, and back to the board if the amount is at or above the board floor. See Amending a contract's amount.
- A FIXED contract can never bypass board voting. That escape hatch does not exist for FIXED, and it is not a setting you can find. If the price is committed and it is big enough to need the board, the board sees it.
- The committed total is real and computable: the amount, times the number of occurrences left in the term. Approvers see that number.
Use FIXED for: service contracts, maintenance agreements, landscaping, cleaning, elevator servicing, security, snow removal, pest control, anything where you signed a piece of paper with a number on it.
VARIABLE
The amount moves, and everybody knows it.
The hydro bill. The water bill. Gas. These are recurring, they are real, and nobody can tell you in advance what next month's number is.
What VARIABLE means:
- Occurrences post at the current template amount without running the staff approval chain, as long as the amount is below the board escalation floor. That is the point: you do not want a human clicking approve on a $340 water bill twelve times a year.
- If an occurrence lands at or above the board floor, it still routes to the board. A VARIABLE contract does not get to sneak a large amount past the board just because it is variable. This is the guardrail.
- The one exception to that guardrail is the board-voting bypass, which is an explicit, deliberate, audited setting you can turn on. See Bypassing board voting on a VARIABLE contract. It exists precisely for the utility bill that keeps tripping the floor.
- Because the amount moves, a VARIABLE contract's amount is shown with a
~in front of it in the Scheduled tab, and its committed total reads "Ongoing" rather than a fake precise number.
Use VARIABLE for: utilities, consumption-based bills, anything metered, anything where the invoice tells you the amount rather than the other way around.
Choosing between them
| Ask yourself | Answer | Type |
|---|---|---|
| Did we agree to a specific number? | Yes | FIXED |
| Does the vendor send us whatever the meter says? | Yes | VARIABLE |
| If the number changed, would I want it re-approved? | Yes | FIXED |
| If the number changed, is that just Tuesday? | Yes | VARIABLE |
If you genuinely cannot decide, choose FIXED. FIXED is the stricter, safer default: the worst case is that a price change asks for an approval you did not strictly need. The worst case with the wrong VARIABLE is that a price increase posts to the books with nobody looking at it.
Can I change the type later?
Yes, and it is treated as the serious change that it is.
Flipping the contract type in either direction re-arms approval. The contract goes back through the full staff chain, and to the board if it is at or above the floor. The editor tells you so before you save, with a banner reading "This will re-run approval".
Flipping from VARIABLE to FIXED also clears the board-voting bypass in the same save, because a FIXED contract can never carry one. The editor shows you the bypass toggle greyed out with the note "Cleared on save: a FIXED contract can never bypass the board."
While the re-approval is in flight, the contract generates nothing. Its next run reads Paused.
Why this exists at all
The old model let money drift. A recurring expense could:
- Keep posting forever on an approval somebody gave once, years ago.
- Have its price quietly raised on the template with nobody re-approving it.
- Be saved over by a same-named template, silently, bypassing governance entirely.
- Reach an approver as a bare "Recurring" chip, with no indication that saying yes committed the property to $84,600 over three years.
Every one of those is now closed. The contract has a type. The approval has an expiry date. The price cannot move without going back through approval. The approver sees the total. And when the approval lapses, the contract stops, and somebody gets an email.
What the system records
Every governance event on a contract is written to the audit trail with the actor and the timestamp: the approval being re-armed (and the reason: amendment, contract-type change, or renewal), the approval expiring, a board-voting bypass being turned on, and every occurrence that actually used a bypass to skip a vote.