Service Agreements
Build, send, sign, amend, and bill against the Code-aligned Service Agreement instrument.
Overview
The Service Agreement is the platform's keystone module. It generates a CICC-aligned written agreement covering scope, fees, payment schedule, milestones, client obligations, complaint handling, termination, limitation of liability, and the procedural-fairness-letter surcharge clause. It supports multi-party signing (client, optional co-counsel, optional third-party payer, optional sponsor, optional designated person), per-party email rotation, change requests, decline-to-sign with negotiation, amendments, and post-signing bill generation.
The Service Agreements module is Premium. Basic tenants can see the sidebar entry; the landing page renders a Premium-upsell card with a direct path to subscribe.
Templates
The template library carries over a hundred curated Service Agreement templates spanning study, work, visit, sponsorship, refugee, citizenship, business-immigration, and provincial pathways. Each template seeds scope.included, scope.excluded, milestones, a default payment schedule, and a typical professional fee range with a recommended midpoint. Tenants may publish their own templates under Settings → Templates and apply them in three modes: fill empty (only blank fields populated), replace (overwrites scope and fee), and add component (appends a Service Component on a multi-service agreement).
AI Populate
AI Populate extracts the agreement skeleton from documents you provide: IRCC letters, passport pages, identity documents, language test certificates, intake notes. The extractor is Claude with a strictly typed tool schema. Upload up to ten documents, tag each with a role (client primary, family member, sponsor, etc.), and add a short prompt with any context the documents don't carry. The extractor returns a recommended template, recommended Service Components, recommended family members, recommended scope items, and proposals for individual fields. You review each proposal with a checkbox before applying.
AI Populate counts against your daily AI quota (50 calls/day on Premium). The recommended-fee field includes a clear rationale; if the AI couldn't find an explicit dollar amount in your documents, it returns null rather than guessing.
Signing flow
When you click Send for signature, the agreement transitions to awaiting_signature, materializes party rows with per-party portal tokens, and dispatches an invitation email to every signer. Tokens are HMAC-signed and unique per party. The first party to sign moves the agreement to partially_signed; the last party (typically the RCIC counter-signing from the dashboard) moves it to fully_signed. At that point, the platform encrypts the PDF under your tenant DEK, uploads it to the agreement-pdfs bucket, attaches the PDF to the client's copy email, and triggers the post-signing automations: bill creation if Bill on Signing is enabled, Transfer Room activation if the matter is eligible.
Per-party initials are captured on every material clause (configurable signature mode: none, slot-1 only, material-only, all clauses, or a custom list). The slot-1 client types initials once on the sign view and the platform stamps every section heading on the rendered HTML and the signed PDF. Other parties don't initial. The signed PDF carries an audit certificate appended to the last page with each signer's IP/24, token hash prefix, and UTC timestamp; the same data lives in the audit ledger which is INSERT-only.
Change requests and decline
On the public sign view, the client may either request changes (a structured form with section-by-section comments) or decline to sign (with a free-text reason). A change request lands on the lifecycle view; you can keep the original (reject the request), reopen to draft (returns the agreement to the builder and invalidates every existing signature), or amend after negotiation (a tenant-only action that opens a separate flow with the meeting invitation and a fresh resend after agreement). Decline to sign produces a status of declined_negotiable or declined_terminal depending on whether the client's reason left room for negotiation; from declined_negotiable, you can invite the client to a Personal-Invites meeting, re-send the agreement as-is, or amend in builder.
Amendments
Once an agreement is fully signed, you can amend it. The Amendment button on the dashboard opens a section picker; you choose which clauses to amend (parties, definitions, and signatures are forbidden — those are auto-included), the builder reopens with only the affected sections visible, and you send the amendment through the standard signing flow. The amendment is a legal instrument that names the parent agreement by its reference and signature date; the visible amendment document never displays its own -A<n> reference. Picking any fee-related clause (fees, payment_schedule, milestones, PFL surcharge, government fees, etc.) reveals all three of fees, schedule, and milestones in the builder.
Bill on Signing
When Bill on Signing is enabled (Settings → Billing), the moment an agreement reaches fully_signed the platform auto-creates a Bill in the Single Bills module and emails it to the client. You configure the scope (first installment from the payment schedule or full professional fee), include or exclude government fees per agreement, and set the reminder cadence. The Bill carries Stripe Checkout for online payment and offline-method instructions (e-Transfer email, cheque payee + address, wire details) for tenants who prefer those channels. Amendments only auto-bill when the amendment touched a fee-related clause.
Customize articles
Settings → Customize articles lets you hide non-locked clauses, add custom clauses at three insertion points (after fees, before signatures, or at the end), and override individual clause bodies. Seven clauses are locked and cannot be hidden, added around, or overridden: parties, definitions, engagement, fees, payment schedule, signatures, entire agreement. Customizations apply to every new agreement created from that point; existing agreements are unaffected. A loud maroon legal-advisor warning sits at the top of the page — the platform does not vet your customizations.
Bilingual rendering
The official language of the matter (set in Client Instructions) decides the rendered language of the agreement. English produces an English PDF, French produces a Quebec-French PDF. The Service Agreement portal accepts both languages on the client side: a picker in the portal header lets the signer pick fr-CA or English (the legal text underneath was rendered server-side at finalize). On Premium, a per-clause runtime-translation modal lets the signer view any clause translated into eight additional languages.
