Back to index Before you start A contract always sits on top of a template . The template holds the vendor, the amount, the tax, the GL account, and the line items. The contract holds the cadence and...
Last updated
A contract always sits on top of a template. The template holds the vendor, the amount, the tax, the GL account, and the line items. The contract holds the cadence and the term.
So there are two ways in:
Both paths open the same contract editor with the same fields. There is exactly one contract editor in the product, so the two surfaces can never disagree.
One contract per template. If the template already has a live contract, you will be blocked. See the blocked state below.
The drawer is titled Recurring schedule, with an overline reading New Recurring Contract (or Edit Recurring Contract if you are changing one).
How often it fires. The options are:
A stepper reading Every [ N ] month(s) (or week(s) for the week-based frequencies).
This multiplies the frequency. Monthly with an interval of 1 is every month. Monthly with an interval of 3 is every three months. Weekly with an interval of 2 is every two weeks.
Leave it at 1 unless you actually need it.
You cannot pick this. It reads Today on a new contract, and shows the real start date on an existing one. The helper says why: "Contracts always start today; the next run is computed forward from now."
Under it you will see the property's timezone, marked (from property). That is read-only too. It comes from the property's location, and it is the timezone the generation actually runs in.
A two-option selector: FIXED or VARIABLE.
The editor spells out what each one means, right there under the buttons:
FIXED: the amount is a committed price. Any price change is an amendment and re-runs the full approval, including the board when at or above the floor.
VARIABLE: occurrences post at the current template amount without staff re-approval; amounts at or above the board floor still route to the board.
If you are not sure which to pick, read Understanding recurring contracts first. This is the most consequential choice on this screen.
Three options. The term is what the board and your approval chain are actually approving, so choose it deliberately.
No end (open-ended)
Approval renews every 12 months.
The contract runs indefinitely, but the approval on it does not. Twelve months after it was approved, the approval lapses, generation pauses, and you have to re-submit. This is deliberate: an open-ended commitment should get a fresh look once a year.
End on date (dated)
Approval covers the term and expires on that date.
Pick a date. The contract generates until that date and then the approval expires. You get an End date field. You cannot pick a date in the past.
After N occurrences (finite)
Approval covers exactly those occurrences and expires when the last one posts.
You get a stepper reading After [ N ] occurrences. The system computes the end date for you from the frequency and interval and shows it: "Ends Jun 30, 2027 (computed)".
This is a convenience over "End on date". It is the same thing underneath: 12 monthly occurrences becomes an end date 12 months out.
Two options:
Draft for review
Creates a DRAFT expense a human approves.
Each occurrence lands as a draft. Somebody has to open it and submit it. Use this when you want eyes on every instance, for example when the invoice needs to be matched to a receipt.
Auto-post to GL
Each occurrence posts to the books on its own, automatically. This is the point of a recurring contract for most people: you approved the contract, so you do not want to re-approve every single month's identical expense.
Auto-post does not mean unapproved. The contract itself still goes through approval. Auto-post means the occurrences under an already-approved contract post without re-entering the chain. The moment the approval lapses or the amount changes, that stops.
This toggle only appears when the contract type is VARIABLE. It is off by default.
Post occurrences without a board vote even above the board threshold. Every use is written to the audit log.
Turn it on and you get a warning panel titled "No board guardrail while bypass is on". Read Bypassing board voting on a VARIABLE contract before you use it.
The footer caption on a VARIABLE contract reads: "Bypass board voting is off by default; every enable is audited."
At the bottom of the editor there is a five-fact strip that updates live as you change the fields above. This is your preview of what you are about to commit to.
| Fact | What it shows |
|---|---|
| Frequency | The cadence in plain language, for example "Monthly on the 1st". |
| Next run | The date the next occurrence will actually post. Reads Paused if generation is currently held (for example while a re-approval is in flight). |
| Ends | The end date, or Open-ended. |
| Remaining | How many occurrences are left, or Approval renews every 12 months for an open-ended contract. |
| Committed total | The full amount this contract commits the property to. Ongoing for an open-ended or variable contract, where no honest total exists. |
Committed total is the number that matters. It is the per-occurrence amount times the occurrences remaining. A $2,350 monthly contract with 36 months on it does not commit you to $2,350. It commits you to $84,600. Approvers now see that number, and so do you, before you save.
The footer has Cancel and a submit button. The submit label changes with the situation:
The footer caption on the left tells you what is required: "Contract type and term are required before the schedule can be saved."
You will get a Schedule created confirmation.
The first expense the contract generates goes into the approval chain, and to the board if the amount is at or above the board floor. Approvers are told that they are approving the whole contract, not one month's expense. They see the committed total.
Once it is approved, the contract shows an Approved · covers recurring badge, and the editor explains:
This contract's first generation cleared approval. Future same-amount generations post automatically without re-entering the approval chain. Amending the committed amount on a FIXED contract re-triggers approval.
Until that approval lands, the editor shows "This contract needs approval" and nothing posts.
If the template already has a live contract, the save is rejected and you will see a red panel at the top of the contract section:
Only one active schedule is allowed per template. Deactivate the existing schedule before starting a new one.
It carries an Open existing contract link that takes you straight to the contract that already exists. Nothing is created, and nothing is overwritten. Go look at the existing one first: nine times out of ten it is the contract you were about to re-create.
To genuinely replace it, deactivate the existing contract first (delete it from the Scheduled tab, which is a soft deactivation that leaves all previously generated expenses untouched), then create the new one.
The creation of the contract and its first approval are recorded in the audit trail. If you turned the board-voting bypass on at creation, that is recorded too, with your name and the time. Every subsequent change to the contract is recorded with a reason.