How contract volume determines which tool features actually matter
Dylan Conkle
Every contract tool has roughly the same feature list. Templates, e-signature, renewal reminders, version history, approvals, integrations, invoicing. Read three vendor pages in a row and they blur together.
What actually separates a good fit from an expensive one is not the list. It is which items on the list you need right now, and that is mostly decided by one number: how many active agreements you are carrying.
This post walks through what breaks first at three sizes, roughly 10, 50 and 200 or more active agreements, and which features fix each break. The point is not to sell you the biggest tier. It is to stop you paying for features you will not use for two years, and to stop you skipping the one that is about to cost you money.
Count agreements, not clients
Most MSPs size their tooling by client count, because that is the number they know. It is the wrong number for contracts.
A client with a master services agreement and two statements of work has three documents. Each can carry its own term, its own renewal date and its own billing schedule. An MSP with 40 clients can easily be carrying 90 agreements, and every one of them is something that can renew at the wrong rate, be signed in the wrong version, or bill the wrong amount.
So before you evaluate anything, count signed agreements currently in force. That number tells you which of the sections below you are in.
Around 10 agreements: almost anything works
At this size the process lives in one person's head, and that is fine. Ten agreements that renew annually works out to under one renewal a month on average. One owner can hold that.
What you need at this stage is short:
- A template you trust. The paper matters more than the software when you are small, because the clauses you sign now (auto-renewal, notice periods, liability) are the ones you will be living with at 50.
- E-signature with a real audit record. Signer name, timestamp, IP address, how they were verified. You want this from the first agreement, not retrofitted later.
- A reminder per renewal date. A calendar entry is genuinely enough when there are ten of them.
What breaks first here is not a tool problem. It is a template problem: an agreement with no clear notice period, or an auto-renewal clause nobody read. If you are going to spend money at 10, spend it on the paper.
What you can skip: approval workflows (there is nobody to approve), PSA and accounting integrations you will not maintain, and anything priced per document that assumes volume you do not have yet.
Around 50 agreements: the spreadsheet stops being trustworthy
Fifty annual agreements is about one renewal a week. That is the point where the calendar reminder stops being a system and starts being a hope.
Four things tend to break in roughly this order.
Renewal dates in a spreadsheet. The spreadsheet does not fail loudly. It fails when an agreement gets amended or extended, the date in the document moves, and the row does not. The reminder then fires for a renewal that already happened, or never fires at all. The fix is a renewal date that is read from the signed agreement and lives with it, and a reminder that arrives in an inbox without anyone opening a screen.
Version sprawl. By 50 you have revised some SOWs. Somewhere there is a file called something like Acme_SOW_v3_FINAL_signed.pdf, and somewhere else there is a v4 that was sent but never signed. When a client disputes scope, the first question is which version is in force, and email search is a poor answer. What fixes it is version history on the agreement itself: every saved change recorded, comparable side by side, with the signed version clearly distinguished from drafts.
Signature chasing. More agreements out at once means more of them sitting unsigned. At 10 you remember who owes you a signature. At 50 you need one place that shows everything out for signature and how long it has been there, plus a way to nudge the signer without writing a fresh email each time.
Scope that is described instead of counted. If a SOW says "support for all workstations" rather than "42 workstations at a set rate", every later question about billing turns into an argument. Fifty agreements is about where those arguments start eating real time. Structured managed units (a count and a rate per line) are the fix, and they matter even more at the next stage.
At this size, the features worth paying for are: dates and terms read from the signed document, per-agreement reminders, version history, and a clear view of what is out for signature. Integrations start to be useful here but are rarely the bottleneck.
200 or more agreements: billing drift and approvals
At 200 annual agreements you are looking at roughly four renewals a week, every week. Renewal tracking is no longer optional, but by now most MSPs have some version of it. The two problems that get expensive at this size are different.
Billing drift between the SOW and the invoice. When the invoice is built separately from the SOW, every change has to be made twice: once in the agreement and once in billing. A client adds 12 seats mid-term, the amendment gets signed, and the invoice keeps billing the old count. Or the reverse: billing picks up the change but the agreement never does, and at renewal nobody can show the client what they agreed to.
Drift is quiet. It does not produce a missing invoice anyone would notice. It produces an invoice that is wrong by a seat or a fee, every month, until a reconciliation nobody scheduled turns it up. As a simple illustration, a client underbilled by five seats at $25 each is $1,500 a year. Across 200 agreements, you do not need many of those to matter. The fix is generating the invoice from the agreement's own units and rates, so there is one set of numbers rather than two that have to agree.
Approvals once there is a team. At 200 agreements, the owner is no longer the only person sending contracts. A service manager sends a renewal, an account manager sends a SOW with a discount, someone edits a notice period to close a deal. None of that is wrong, but somebody should have seen it before the client did. An approval step that holds a document until a named approver signs off is how you get that, and it is worth checking what the approval actually covers: a tool that approves the body text but lets someone change the auto-renewal term afterwards is approving the wrong thing.
Integrations become load-bearing. With this many agreements, re-keying clients, device counts and invoices between systems is a part-time job. This is where PSA, RMM and accounting integrations start paying for themselves. Ask every vendor which record moves in which direction, and on what trigger, because "integrates with" covers everything from a nightly read to a real-time write.
What breaks first, at a glance
| Active agreements | What breaks first | Feature that fixes it |
|---|---|---|
| Around 10 | The template itself | A maintained template, e-signature with an audit record |
| Around 50 | Renewal dates in a spreadsheet, version sprawl, signature chasing | Dates read from the signed agreement, per-agreement reminders, version history, one view of what is out for signature |
| 200 or more | Billing drift between SOW and invoice, unreviewed sends | Invoices generated from the agreement's units, an approval step, integrations that name their direction |
The tiers overlap, and a fast-growing MSP can hit the 200 problems at 120 agreements. Use the table as an order of failure, not a set of hard thresholds.
How to use this in an evaluation
Buy for the stage you are about to reach, not the one three steps ahead. If you are at 30 agreements and adding a few a month, the 50 problems are what to test in a demo. Approval chains and deep integrations can wait until there is a team that needs them.
In practice that means three questions, matched to your size:
- At any size: what does the signature record contain, and can I see a sample?
- Heading toward 50: where does the renewal date come from, and what reaches an inbox without anyone logging in?
- Heading toward 200: show me a signed SOW becoming an invoice, then show me what happens to that invoice when the SOW is amended.
The longer list, written as a checklist you can run on a call, is in the MSP contract software buyer checklist.
Where XClause fits
XClause is built for the 50 and 200 stages. Each signed agreement carries its own renewal reminders, at any mix of 90, 60, 30, 15 and 7 days, sent to your team, the client or both, on every plan, and the contracts list filters to everything renewing or ending in the next 60 days. Contracts keep a version history you can compare against the current version, and restore from while nobody has signed. Internal approval is optional and can cover all outbound documents, MSAs only or SOWs only. When you switch invoicing on for a SOW, its invoice is drafted from the SOW's managed units when the last signature lands, and it is only emailed if you turn on auto-send. The renewal tracking cost page has the detail.
If you are at 10 agreements, the Starter plan covers up to 15 clients and two team members, and honestly a good template matters more than any of the features above. If you are past that, Pro removes the client and team limits.