DivitiLegal: contract review software compared with Spellbook, Ironclad and LegalOn

Overview

What DivitiLegal does

DivitiLegal reads a contract from your side of the table. It finds the clauses that are dangerous and the conditions that are missing, grades each by severity, and produces a protocol of amendments — clause number, current wording, proposed wording, reasoning — ready to send to the counterparty.

The second half of that sentence is the part most tools skip. Flagging a bad indemnity is useful; noticing that the contract contains no limitation of liability at all is what saves money, and absence is harder to detect than presence.

Below is an honest comparison with the established tools in this category, including where they beat us. You will find those places during a trial anyway.

The real cost

What this category costs over a year

Legal AI pricing is the least transparent of any software category we work in. Of the four best-known tools, only partial figures circulate, and the sources disagree with each other by multiples rather than percentages.

Third-party aggregators put Ironclad at a median around $40,000 a year across several hundred recorded purchases, with a range from roughly $15,000 to over $100,000. Spellbook is reported anywhere between $99 and $350 per user per month depending on who is writing. LegalOn estimates run from about $3,000 to $8,000 a year. Luminance publishes nothing; estimates start around £30,000 a year and go well past $100,000.

What those numbers hide is that the implementation cost is the same whichever you buy. Every tool in this category needs to be told what your company accepts, and in most companies that has never been written down. Budget several days of senior legal time before the software produces anything trustworthy. That cost does not appear in any quote and it is not optional.

Where we win

What DivitiLegal does better

Three things, and all three follow from the same fact: this was built for companies whose contracts are in Russian and whose lawyers are arguing about Russian law.

• Russian-language contracts, natively. Clause parsing and risk detection in Russian are the design target, not a localisation layer. The global tools are superb in English and variable elsewhere; if your contracts are in Russian, test that before comparing anything else.
• Absence is a first-class finding. A missing limitation of liability, a missing termination right, a missing penalty cap — these are reported as findings with severity, not left for the reviewer to notice. That is a deliberate design choice and it is where most of the saved money sits.
• Output you can send. The protocol is formatted as a negotiating document — clause number, current wording, proposed wording, why — rather than as an annotated PDF that someone then has to turn into a letter.

Where we lose

What the established tools do better

Five, and two of them should decide against us for some buyers.

• Track record. Ironclad has thousands of public reviews and a decade of enterprise deployments. We have none of that. If procurement needs references at scale, they can supply them and we cannot.
• Workflow and approvals. Ironclad in particular is a contract lifecycle platform, not a review tool: routing, approvals, repository, renewals. If the problem you are solving is the process around contracts rather than the reading of them, that is a different product and we are not it.
• Word-native redlining. Spellbook works inside Word, where lawyers already are. We produce a protocol; if your team negotiates entirely in tracked changes, that difference will be felt daily.
• Market-standard libraries. LegalOn and Luminance can tell you how your clause compares with the market because they have seen the market. We can only compare against your own rules, which is more relevant and less broad.
• English-language work. If your contracts are in English, the argument for a tool with years of English legal training data is strong, and we will say so on the call rather than after the contract is signed.

Four directions

Legal risk is not the only risk in a contract

Most review tools read a contract as a legal document. It is also a financial one, a commercial one and an operational one, and the clauses that hurt a business are rarely the ones a lawyer flags first.

A payment term of ninety days is legally unremarkable and may be the single most expensive line in the agreement. An exclusivity clause is commercially decisive and legally dull. An obligation to respond within four hours is operationally impossible for a team of three and reads like boilerplate.

DivitiLegal reports against four directions — legal, financial, commercial and operational — because the person who has to live with the contract is usually not the person who reviewed it. Separating them means the finance lead sees the payment terms and the delivery lead sees the response obligations, instead of both of them not reading a legal memo.

Severity

Why grading matters more than finding

A protocol with forty findings and no grading is a document nobody reads twice. The reviewer skims it, acts on the first three, and the rest become a liability — because now the company has written evidence that it knew about an issue it did nothing with.

Grading does not have to be precise to be useful. It has to be consistent, so a reviewer learns what 'high' means in practice after ten contracts. We would rather have a blunt three-level scale applied the same way every time than a ten-point score that drifts.

Implementation

What the first weeks look like

Week one: rules. Someone senior writes down what the company accepts and refuses — the liability cap you will not go below, the payment terms you will not exceed, the jurisdictions you will not agree to. This is the work that gets skipped and the work that determines whether the output is trusted.

Week two: calibration against contracts you have already signed. Run twenty agreements whose outcome you know. Where the tool disagrees with what you did, either the rule is wrong or the earlier decision was — both are worth finding out, and this is usually the most uncomfortable week.

Week three onward: live review, with a lawyer still reading everything. The point of this period is not speed; it is building the evidence that the protocol can be trusted. Teams that skip it either over-trust the output or quietly stop using it.

Evaluation

How to run a trial that tells you something

Four conditions turn a vendor demo into an actual test.

• Use contracts you have already negotiated. You know what the problems were. Compare the findings against what your lawyer actually raised.
• Include one contract that is missing something important. Absence detection is where these tools differ most and where demos never go.
• Include your worst document. A scanned PDF, an amendment to an amendment, something drafted by a counterparty with a template from 2011.
• Ask what happens when it is unsure. A tool that returns a confident protocol on a document it could barely parse is more dangerous than one that says it could not read page four.

Failure modes

Why these deployments fail

The software usually works. The project fails for one of four reasons, in rough order of frequency.

• Nobody wrote the rules. The tool was pointed at contracts with a generic standard, the findings did not match what the company actually cares about, and within a month the lawyers stopped reading the protocols.
• It was sold as a replacement. Headcount was planned against it before anyone measured what it catches. The first missed issue then becomes a crisis rather than an expected limitation.
• Nobody owns the output. Protocols are generated and filed. Documented knowledge of an unresolved risk is worse than not having looked.
• The perimeter question came last. Three months in, someone asks where the contracts are being processed, and the answer ends the project.

Scope

What contract review AI does not fix

Worth stating plainly, because the category is sold as risk reduction and it is a reading tool.

• A bad commercial position. If you have no leverage, the tool will tell you clearly that the terms are one-sided and you will sign them anyway. That is useful information and it is not a saved risk.
• Contracts nobody sends to legal. The agreements that cause problems are usually the ones signed by someone who did not think it needed review. A review tool cannot read what it is not given.
• Obligations after signature. Deadlines, renewals, notice periods — tracking those is contract lifecycle management, a different product category with different vendors.
• A lawyer who will not argue. The protocol is a negotiating position. If nobody sends it to the counterparty, nothing changes except that you now know.

Due diligence

What to ask any vendor in this category

Including us. These are the questions whose answers differ between tools.

• What is the total first-year cost for our volume, including everything that is not per seat?
• Where are our contracts processed and stored, and what happens to them if we leave?
• Can we define our own rules, or only adjust yours?
• Will you run ten of our contracts before we sign anything?
• How does the tool report that it could not read part of a document?
• Does it flag missing clauses, or only clauses that are present?
• Who do we talk to in month two when the findings look wrong?

Head to head

DivitiLegal against LegalOn, point by point

Six axes that actually decide this purchase, with LegalOn as the reference point because it is the one most teams compare everything else against.

• Scope. LegalOn covers the legal workday — review, playbooks, matters, translation, entities, board materials. We cover one job. Broader is better if you are replacing several tools; narrower is better if you are solving one problem and do not want a platform migration.
• Price transparency. Neither of us publishes a price list: LegalOn ends at a demo request, we quote per deployment. That is a point against both of us and in favour of any vendor in this category that does publish.
• Missing clauses. Most review tools are good at flagging what is written and weaker on what is absent. Finding the condition that should be in the contract and is not is the part we built the product around; ask LegalOn and every other vendor to demonstrate it on your own contract rather than on their sample.
• Language. LegalOn ships a translation module and serves international teams. If your contracts move between languages, test both on a real bilingual agreement before deciding.
• Output. Ours ends in a protocol of amendments you can send. Ask any vendor what you are left holding when the review finishes — a list of flags, a redline, or something a counterparty can actually receive.
• Maturity. LegalOn has verticals, case studies and a security page. We have none of that published. For procurement that runs on a vendor questionnaire, LegalOn clears it and we do not, and that is on us.

Where we would tell you to choose LegalOn: you need the suite, your procurement requires published security documentation, or your team is already running their playbooks. Where we would argue for DivitiLegal: the job is review from your side of the table, the answer has to arrive as amendments rather than as annotations, and you would rather pay for one thing that works than for a platform you will use a tenth of.

Either way, run the same contract through both. In this category a demo on the vendor's sample agreement tells you almost nothing, and LegalOn, Spellbook and we will all look good on a document chosen by us. LegalOn's own pricing page is the place to start their side of that conversation.