Landscapt (CRM)
Contracts
Ongoing billing agreements — monthly amounts, seasonal overrides, sub-properties, and how signing and invoicing actually work.
On this page
What a contract is
A Contract (Landscapt → Accounting → Contracts) is the ongoing billing agreement behind recurring service — a monthly amount, a billing day of month, whether it bills a month ahead of service, and whether it renews automatically. It's separate from a Package, which defines the service cadence template, and from the Invoices the contract actually generates — see the See also section below.
Each contract belongs to one client and is built from three pieces:
- Invoice line items — one or more entries pulled from the services catalog (or typed as a custom line) that become the description on every invoice this contract generates.
- A monthly amount grid — twelve fields, one per calendar month (January–December), each independently editable. "Auto Fill" copies January's amount into all twelve if you want a flat rate; otherwise leave months at $0 to skip billing entirely in that month.
- Billing settings — billing day of month, whether to bill a month in advance, payment type, PO number, and two switches: Auto Generate (eligible for the automatic invoicing cron) and Active.
Status lifecycle & signing
Status is a dropdown on the contract itself — there is no e-signature integration behind it. Marking a contract "Signed" is a manual confirmation, not a document that gets sent out for a client to click and sign.
| Status | What it means |
|---|---|
| Draft | Just created. Nothing has been sent or agreed to yet — safe to edit freely. |
| Sent | The proposal went to the client. Also where a signed contract lands automatically if you edit its price, dates, or line items (see the callout below). |
| Signed | You (or the client) confirmed the terms. Sets signed_at and signed_by, and fires the “Contract Signed” automation/Zapier trigger. |
| Active | The contract is live and, if Auto Generate is on, eligible for automatic monthly invoicing. |
| Expired | Past its end date. The expiry-warning email/notification fires 3 days before this, for any active, non-auto-renewing contract. |
| Cancelled | Terminated before or at its end date. No further invoices generate. |
Editing a signed contract un-signs it. If you change the monthly amount, the monthly-amounts grid, the invoice line items, or the start/end dates on a contract that's already Signed, the app automatically reverts its status to Sent and clears signed_at / signed_by. The idea: the daily invoicing cron bills off those exact fields, so a client's signature shouldn't stay attached to terms they never actually agreed to. Re-confirm (mark Signed again) after making the change.
Because the signed-date is a tracked field, it's also one of the Zapier/automation triggers — "Contract Signed" fires the moment a contract's status is set to Signed, which is what makes contract signing a distinct, reportable event rather than just a status label.
Billing mechanics
Two paths create an invoice from a contract, and both use the same logic:
- Automatic, via a daily cron. Every contract that is Active, has Auto Generate on, and whose Billing Day of Month matches today (or the last day of the month, if the configured day is higher than the month has days) gets an invoice created.
- Manual, via the "Create Invoices" bulk action on the Contracts list — select one or more contracts and bill them right now, ignoring their configured billing day (but not the active/amount checks below).
Both paths follow the same rules:
- The invoice amount comes from that calendar month's entry in the monthly-amounts grid; if a month was never explicitly set, it falls back to the contract's flat monthly amount. A month explicitly set to $0 is skipped — no invoice is created for it.
- Bill 1 Month in Advance shifts everything one calendar month forward: the invoice is dated and amount-matched to next month instead of the current one. This is what lets a contract invoice in, say, late June for July's service.
- Idempotency is enforced per contract, per calendar month — a contract already invoiced this month is skipped, so re-running the cron or clicking Create Invoices twice can never double-bill.
Why bill a month in advance? For recurring service, invoicing after the work is done means chasing payment on a moving target — the crew has already spent the labor and materials, and now collections is racing next month's visits. Billing a month ahead flips that: the client pays before the month's visits happen, so a late or disputed payment is caught before more service gets delivered on an unpaid account, not after. It's a cash-flow and collections-risk decision, not just a scheduling preference.
Billing frequency options
Every contract has a Billing Frequency value in the data model — it's stored, shown in Contract reports, and returned by the API — but there is currently no field in the Contract dialog to set it; new contracts default to Monthly and it isn't exposed for editing after that.
| Frequency | When it makes sense |
|---|---|
| Weekly | Short-term or trial arrangements — rare for landscape maintenance, more common for a temporary snow-season add-on. |
| Biweekly | Every-other-week billing cadence, occasionally used for lighter recurring service loads. |
| Monthly | The default and by far the most common — matches how most maintenance and package programs are sold and how the automatic invoicing cron actually runs (see the callout below). |
| Quarterly | Larger commercial accounts that prefer fewer, bigger invoices instead of a monthly drip. |
| Annual | Prepaid or single-invoice-per-year agreements, e.g. a lump-sum snow contract. |
| One-time | A contract that isn't really recurring — used to formalize terms for a single large job without pretending it repeats. |
The actual invoicing cadence is monthly, regardless of this field. Both the automatic cron and the manual "Create Invoices" action check the contract once per calendar month against a Billing Day of Month — there's no separate weekly/quarterly/annual invoicing path today. If your contract truly bills less often than monthly, the practical way to represent that is via the monthly-amounts grid: put the full period amount in the one month it should invoice and leave the other months at $0 (see the worked example below for the seasonal version of this).
Worked example: multi-property commercial contract
A property management company owns 5 sites and wants one contract, one monthly invoice, and a summer-heavy price — full mowing season rate April–October, a reduced fall/winter rate the rest of the year.
- Add each of the 5 sites as a Property on the ONE client record first (More menu → Add Property, on the client's detail page — see the Clients guide, linked below). This is a single client billed as one account across multiple addresses, not several separate client records — if the sites actually need independent jobs, invoicing, or estimates instead of one shared bill, that's the parent/child client hierarchy (sub-accounts) instead, a different feature covered in the Clients guide.
- Create the contract against that client. In Contract Details, check Include Sub Properties by Default — this is on by default and documents that the contract covers every property on the client's account, not just one address.
- Set the invoice line items to the services covered across the sites (e.g. "Weekly Mowing — 5 Properties", "Spring Cleanup — 5 Properties").
- In the monthly-amounts grid, enter the combined total for all 5 sites in each month — April through October at the full mowing-season rate, November through March at the reduced rate. There's no per-property line-item breakdown on the invoice itself; the grid holds one number per month, so that number needs to already be the sum across every site the contract covers.
- Set Billing Day of Month and, if the management company expects to be invoiced ahead of each month's service, turn on Bill 1 Month in Advance.
Sub-properties is a billing-scope flag, not an auto-aggregation feature. Turning it on tells the contract it's meant to cover every property on the client's account instead of issuing a separate contract per site — but the monthly amount you enter is still one flat number per month. It won't sum up per-property pricing for you, so double-check the combined total by hand whenever a property is added to or removed from the client.
See also
- Jobs & Packages — a package defines the recurring service cadence and visit counts; a contract defines the ongoing billing terms on top of it.
- Invoicing — what a contract actually produces: the draft invoices created by the cron or the manual "Create Invoices" action.
- Clients — adding properties to a client, and when to use the parent/child (sub-account) hierarchy instead.