Contracts & Signatures
Every other flow in XBuddy moves goods, money or work. This one moves evidence: who agreed to what, when, and who was accountable at each step.
If you are looking for the day-to-day “how do I send this for signature” walkthrough, that is in the Collaboration Flow. This page explains how the lifecycle itself behaves — and why it stops you doing certain things.
Apps involved
- Contract Management — contract lifecycle, legal review, clause risk
- Signatures — e-signature requests, evidence, certificates
- Documents — the underlying files and versions
- Approvals — routing legal review through your approval rules
Three kinds of contract, one set of tools. Sales contracts (from CRM), service contracts (from Service Management) and standalone legal agreements each live with their own app — but all three can be sent for legal review and all three can be signed. You do not have to re-key a contract into a “legal module” to get it reviewed.
Stage 1: The contract lifecycle
A contract does not simply go from “draft” to “signed”. It moves through a defined set of states, and the system refuses transitions that do not make sense.
draft → pending review → under negotiation → pending approval
↓
pending signature
↓
partially signed
↓
executed → active
↓
expiring soon → expiredAt any point a contract can be put on hold and brought back, or terminated — and termination always requires a stated reason, because a dead contract with no explanation is useless six months later in a dispute.
“Expiring soon” and “expired” are not things you set. They are consequences of the calendar, applied automatically. If you find yourself wanting to mark a contract expired by hand, what you actually want is terminate — and the difference matters to your audit trail.
Every status change is recorded with who made it and when. The contract timeline additionally shows signatures, reviews, clause risks and document versions in one place.
Stage 2: Legal review
Legal review is a separate record attached to a contract — not a status on the contract itself. That separation is deliberate: one contract can go through several rounds of review, and you want the history of each.
Raise the review
Anyone with review rights can open a review against any contract, whichever app it came from. The review captures the reviewer, priority, due date and risk level.
Work the review
Reviewers add comments (optionally internal-only, invisible to the requester), work through a checklist applied from a template, and log clause risks rated low, medium, high or critical.
Decide
The reviewer’s assessment and the final decision are two different permissions — reviewing and approving are granted separately, and the system records who decided.
Separation here is by permission, not by identity: someone who holds both rights can still decide on their own review. If your process requires a genuinely independent approver, grant the two permissions to different people.
Review outcomes are: approved · rejected · needs revision.
Stage 3: What can be signed
A common assumption is that e-signature is for contracts. In XBuddy it is configured for 20 document types across the business:
| Area | Documents you can sign |
|---|---|
| Legal | Contracts, service contracts, contract amendments, HR documents |
| Sales | Quotations, sales orders, invoices, delivery notes, customer returns |
| Purchasing | Purchase orders, goods receipts, vendor returns |
| Finance | Bills, expenses, payments |
| People | Payslips, leave requests, timesheets |
| General | Any document in the document library |
Internal signing vs an external provider
| Built-in signing | DocuSign · Viettel · VNPT | |
|---|---|---|
| How signers receive it | Secure link, no account needed | Handled by the provider |
| Evidence | Audit trail and a tamper-evident completion certificate generated by XBuddy | The provider’s certificate, confirmed back to XBuddy |
| Requires a PDF up front | No | Yes |
Signer identity can be verified by email OTP or password, and a biometric option exists on mobile.
Today the mobile biometric option is device-asserted — the app tells the server a biometric check passed, and the server accepts it subject to your signing policy. A server-issued challenge is not yet implemented. If your compliance regime requires cryptographic proof of the biometric event, use OTP or password for those documents.
Signing is not the same as approving. When the last signature lands, XBuddy records the completion and notifies whatever process was waiting — it does not automatically push a workflow to its next step. If a signed document should also close an approval, that link is configured deliberately.
Stage 4: Amendments — changing a contract that is already signed
This is the part most teams get wrong in spreadsheets. Once a contract has been signed, you do not edit it. You issue a separately signed annex.
Annex: draft → pending signature → signed → effective
↑
someone activates it, deliberatelyEverything up to effective is preparation. A draft, pending or even a fully signed annex
changes no numbers at all. Only activation applies it — and when it does, the contract’s
included hours, end date, retainer amount and total value are all recomputed from the full set
of live terms, not patched incrementally.
An effective annex cannot be edited or deleted. If it is wrong, you issue another annex that supersedes it. That is not an inconvenience — it is the entire point. The record of what was agreed, and when, has to survive being wrong.
While an annex is in flight, the parent contract is locked for anything commercial. You can still update notes and internal metadata; changing scope or price forces you down the annex path, with a message telling you so.
Stage 5: AI contract review
XBuddy’s contract AI reads the actual document — extracting the text, splitting it into clauses, and classifying each one. Well-known clause patterns are matched by rule; only the ambiguous remainder goes to the AI model.
Your playbook, not a generic opinion
The valuable part is the clause playbook: for each clause type, your standard position, your acceptable fallback, and your red line. Findings are then specific — “this breaches the liability cap we accept” — rather than generic legal commentary.
The platform ships a starting playbook. Editing an entry creates your own company version; the original stays intact for everyone else.
How the risk score is produced
The AI gives a verdict per clause — meets standard, acceptable fallback, below red line, missing, or unclear. The score is then arithmetic, weighted by how much each clause type matters to you. The model never invents the number, so you can always ask why a contract scored what it did.
Two deliberate behaviours worth knowing:
- A contract the system could not read never scores zero. Unknown risk is not the same as no risk, and the summary says so.
- “Unclear” counts against the score. A clause nobody can interpret is not compliance.
AI proposes; people decide. It can suggest redline wording and score risk, but it cannot accept a redline, edit an executed agreement, or change the playbook it is judged against. A reviewer that could rewrite its own rulebook would always find itself compliant.
Integration Points
| Module | What happens |
|---|---|
| CRM · Service · Procurement · HR | Any contract from any app can be sent for legal review |
| Documents | Source files and every version; external signing providers pull the PDF from here |
| Approvals | Legal review can be routed through your normal approval rules |
| Finance | Contract value and milestone terms drive invoicing |
| Projects | A contract can open the project that delivers it |
| Service Management | Service contract annexes recompute the contract value (Stage 4) |
Related pages
- Collaboration Flow — the day-to-day document, approval and signing walkthrough
- Service Management Flow — service contracts and their billing models
- Business Pack Flow — contracts created from won deals