--- title: "One contract" slug: workspace/contract url: https://projectri.com/docs/workspace/contract section: workspace audience: workspace app_route: "/[slug]/[user]/contracts/[id]" permissions: [contract.view, client.contract, contract.sign, contract.burn.view] mobile: "/contract/[id]" updated: 2026-09-08 source: Projectri documentation --- # One contract A single agreement end to end — terms, rate card, burn, billing and revenue schedules, projects, documents, amendments, retainers and signatures. ![One contract](https://projectri.com/docs-shots/workspace-contract.png) ## What it is One contract, with everything that governs the work under it. The header states what it is and whether it is signed, a burn bar above the tabs answers *how much of this is left*, and the tabs hold the terms, the rate card binding, the two schedules, the projects it funds, the files, the amendments, any retainer and the signature trail. ## How to get there Open a row on [Contracts](/docs/workspace/contracts). Reading the page needs `contract.view`. Which tabs exist depends on who is reading: | Tab | Needs | |---|---| | Terms, Rate card, Projects, Documents, Signatures | `contract.view` | | Billing schedule, Amendments | `contract.burn.view` | | Revenue schedule | `report.financial` | | Retainer | `finance.retainer.view` | The money tabs are **absent, not empty**, for a reader without the key. A revenue schedule rendered as a column of em-dashes still tells you how long the engagement is and how it is phased, which is most of what the figure would have said. Editing anything needs `client.contract`. Signing needs `contract.sign`. Raising a signature request additionally needs the `client.esign` plan feature; schedule and revenue writes need `commercial.billing_runs`; retainer writes need `commercial.retainers`. ## How to use it ### Read the burn bar 1. The bar sits above the tabs and is the one figure on the page that moves without anybody editing anything. 2. **Consumed** is approved, billable time and expense at *bill* rates, plus each expense's markup. Submitted-but-unapproved hours are not counted — a burn number that moved when a manager was slow would stop being trusted. **Invoiced** is the schedule rows a billing run has invoiced. 3. The headline says *Inside budget*, *Approaching the value* or *Over the contract value*. Over budget, it also states the overrun in money and per cent, and says that a change order is the instrument that raises it. 4. The figures are in the **reporting currency**, not necessarily the contract's. When the two differ the bar says so: each row is converted at the rate frozen when it was written, so the figures do not move when the rate does. ### Edit the terms 1. Open **Terms**. Name, reference, kind, value, currency, dates, billing type and revenue-recognition rule live here, along with budget governance. 2. **When the value is spent** is the budget policy. *Warn* tells everyone and stops nobody; *Block new time* refuses new time once the value is spent; *No budget governance* records the value and never checks it. **Warn at** is in basis points — 8000 is 80%. 3. Press **Save changes**. ### Bind a rate card 1. Open **Rate card**. 2. Bind a card and every hour on a project under this contract is priced from it whatever the project or company default says, as long as the work is dated inside the contract period. 3. Leave it unbound and hours fall through to the project's card, then to the company default effective on the date of the work. ### Attach the projects it funds 1. Open **Projects** and press **Attach a project**. 2. Set each project's share of the value. **Split evenly** does it for you. 3. The allocation must total **100%** before the contract can be signed. A contract with no projects attached at all is a valid pre-signature state. ### Build the billing schedule 1. Open **Billing schedule** and press **Add a row**. 2. A row is triggered **On a milestone**, **On a cadence**, **On acceptance** or **On percent complete**, and carries an amount and a due date. 3. **Mark ready to bill** moves a Pending row to Ready. Only Pending rows can be marked ready by hand — Invoiced belongs to a billing run, never to a person. 4. The screen warns when the schedule bills more than the contract is worth, or less: the shortfall is money nobody is scheduled to ask for. Neither is refused — a partly entered schedule is ordinary. ### Generate and record revenue 1. Open **Revenue schedule** and press **Generate schedule**. 2. It writes straight-line monthly rows across the contract period, with the rounding remainder on the last month so the rows sum to the value exactly. It is safe to run twice: existing rows are never overwritten and a closed month is never touched. Afterwards the button reads **Fill missing months**. 3. **Recognise** records the recognised figure for one period. It is refused on two independent grounds — the row's own lock, and the company's period close. ### Sign it 1. Press **Sign** in the header. The button is absent, not disabled, when the state forbids it. 2. The dialog states the consequence before it asks anything: after this, the value, currency, dates, rate card and revenue-recognition rule are frozen, and an amendment is the only instrument that moves them. The exchange rate is frozen at the same moment, so this contract's reported value will not move when the rate does. 3. Type **who signed it, on the client's side**, and the date. A signature without a name is not evidence, which is the entire reason finance asks for the file. 4. Press **Sign and freeze**. The signature is refused if the project allocation does not total 100%, and the dialog tells you that before you get there. ### Amend a signed contract 1. Open **Amendments** and press **Raise a change order**. It is blocked on an unsigned contract — edit the contract itself — and on a closed one. 2. Give it a title, a change in value, a change in days or a new end date, an **Effective from** date and the lines that describe what changes. Work logged before the effective date keeps the price it was logged at; an amendment never reprices the past. 3. **Send for internal review**, then **Approve internally**, then **Send to the client**, then **Record the client's answer**. Those are four separate permissions on purpose. 4. Approving the client's answer writes an amendment contract for the value, rebuilds the affected baselines and moves what the contract is worth. It cannot be reopened. ### Put the paperwork on file 1. Open **Documents** and press **Attach a file**, choosing its kind — accepted quote, counter-signed, amendment or other. 2. Each upload records a SHA-256 of its bytes, so the question is not whether a file exists but whether it is the one that was signed. ### Send it out for e-signature 1. Open **Signatures** and press **Request a signature**. 2. Name the parties — each with a name, an address and a role of *Signs*, *Approves* or *Copied in* — and choose whether they sign in order and whether their email address is verified with a code. At least one party has to actually sign. 3. Press **Send for signature** and pick the document. The file is hashed as it is sent and nothing can change it afterwards. Sending a corrected version means withdrawing the request and raising a new one. 4. Each party gets a link to a signing page at `/s/` that needs no Projectri account. The trail records every step — sent, opened, read, code sent, email verified, signed, declined, expired, withdrawn — and an **Audit certificate** when it completes. 5. **Withdraw** stops every outstanding link immediately. There can only be one open request against a contract at a time. ## What it affects - **Every hour logged under it.** The bound rate card prices the work; the budget policy decides whether more work may be logged once the value is spent. - **The reported burn.** Approving somebody's timesheet moves this contract's consumed figure. Nothing else does. - **Billing runs.** A Ready schedule row is the instruction a billing run acts on. Marking one ready is the moment somebody asserts the client has accepted the work. - **Revenue reports.** Recognised rows are what the revenue reports sum, month by month. - **The client record.** The contract's value counts towards the client's Contract value figure, converted into the reporting currency. - **Baselines.** An approved change order rebuilds the affected project baselines as well as moving the value. - **Audit.** Signing, converting from a quote, uploading a document and every signature-request step are written to the [audit log](/docs/admin/audit-log). ## On mobile The Expo app opens the same contract at the burn bar, at the size of a headline, with what governs the work underneath it. The billing schedule is present and read-only — knowing three milestones are ready to bill is worth having on the move, and marking one ready is a judgement about whether a client has accepted work. The revenue schedule is absent entirely. A signed contract states who signed it and when, and says in words that the terms move only by amendment. ## Limits and gotchas > [!WARNING] > Signing is the point of no return. Value, currency, billing type, > revenue-recognition rule, rate card, start and end dates, budget policy, > expense policy, kind and parent are all frozen, and the exchange rate with > them. Nothing on this page unsigns a contract; an amendment is the instrument. - Notes stay editable after signature. The seal covers what was agreed, not how it is administered. - Saving a sealed field returns a conflict whose message names the fields and says an amendment is the instrument. That message is the server's own and is shown verbatim. - The burn bar clamps at 100% of the value. An overrun is drawn as its own marked segment and stated in words, so "we are 40% over" is said rather than implied by a bar that ran off the end. - An unsigned contract in another currency is converted at *today's* rate, so its burn moves when the rate does. A signed one froze its own base value. - The **reporting currency** the burn is stated in cannot be changed once any time, expense or invoice row has been written in it. The refusal explains that switching would reinterpret every historical figure rather than convert it. - Configuring a retainer and posting a manual draw against one are separate permissions. A draw moves a balance a client is billed from with no time entry behind it, so its note is required. - The signature trail is readable on any plan. `client.esign` gates raising a new request, and that write answers a payment-required error without it — evidence a tenant already has does not disappear on a downgrade. ## Related - [Contracts](/docs/workspace/contracts) — the register this page opens from. - [Quotes](/docs/workspace/quotes) — where a draft SOW usually comes from. - [Timesheets](/docs/workspace/timesheets) — the approvals that move the burn. - [Billing runs](/docs/admin/billing-runs) — what a Ready schedule row feeds. ## Related - [Contracts](https://projectri.com/docs/workspace/contracts.md): The register of what the firm is bound to — every MSA, statement of work and order form, its lifecycle state, its value and whether it is still inside its period. - [Quotes](https://projectri.com/docs/workspace/quotes.md): What is out with clients and what they did with it — send a quote on a private link, watch it be opened, and turn the accepted one into a statement of work. - [Timesheets](https://projectri.com/docs/workspace/timesheets.md): Who has filled their timesheet in for this period and who has not, plus the queue where submitted time is released for billing. - [Invoicing](https://projectri.com/docs/admin/billing-runs.md): Assemble a period's billing from approved time, expenses, fixed fees, milestones and retainer draws, review what it proposes per client, then issue it as invoices.