Where Are Your Contracts? Building a Single Source of Truth

Ask a general counsel how many live contracts the company has and you will get a range rather than a number. Ask which of them auto-renew this quarter and the range gets wider. Ask for the executed copy of the master services agreement with your third largest supplier, the one with the signatures and the stamp paper, and somebody will start searching an inbox. None of this reflects badly on anyone. It reflects the fact that in most Indian companies the contract portfolio has never been assembled, only accumulated.

This article makes a single argument, and it is a slightly unfashionable one. Before you buy workflow automation, before you evaluate clause extraction, before you promise the board a reduction in contracting cycle time, you have to build a repository that the organisation actually treats as authoritative. Repository discipline is not the boring precursor to the interesting part of contract lifecycle management. It is the part that determines whether the interesting part ever works, and skipping it is the most reliable way to end up eighteen months later with an expensive system nobody uses and a shared drive that is still the real answer.

The reason is structural. Every capability people want from contract management is a function that reads the repository. Renewal alerts need to know which agreements are live and when they end. Obligation tracking needs the executed text and the commitments in it. Approval routing needs to know what the standard position is, which means knowing what you have signed before. Reporting to an audit committee on contractual exposure needs a denominator. If the underlying record is partial, stale, or contested, every one of those functions produces confident output from incomplete input, which is worse than producing nothing, because people believe it.

What a Single Source of Truth Actually Means

The phrase gets used loosely enough to have lost most of its content. A shared folder called Contracts is not a single source of truth. Neither is a well-organised set of subfolders, nor a document management system that everybody has access to, nor even a searchable archive of every PDF the company has ever signed. Those are places where contracts happen to be. The distinction is worth setting out properly, because teams that get it wrong build the wrong thing very carefully.

A single source of truth has four properties. First, for any given agreement there is exactly one authoritative executed copy, and everyone in the organisation knows which one it is. Second, that copy carries structured information about itself, so the system can answer questions without anyone opening the file. Third, somebody is accountable for it by name. Fourth, and most easily forgotten, the organisation actually goes there. A repository nobody consults is not a source of truth, it is an archive with good intentions.

One authoritative executed copy, not a folder of candidates

The commonest failure is subtle. A team stores the contract diligently, but what they store is the final negotiated draft, or the version circulated for signature, or a scan of the first two pages with the signature block plus a separate Word file containing the schedules. Six months later, in a dispute about a service level, the question is what the parties actually signed, and the answer requires an archaeology exercise across three systems and two former employees. The repository held documents. It did not hold the agreement.

In India this matters for reasons that go beyond tidiness. Execution formalities carry legal weight. Stamp duty is largely a state subject and rates and requirements differ across states, and an instrument that is not duly stamped can attract objections when a party tries to rely on it, including on admissibility in evidence. The law on how and when that defect can be cured has attracted significant judicial attention in recent years, so confirm the position in force and applicable in the relevant state rather than working from a recollection of the older rule. Certain categories of document also require registration, and some classes of instrument are carved out of the electronic execution regime under India's information technology legislation, which is why the answer to whether an e-signed document is enforceable is genuinely document-specific. All of this collapses into a practical point: the executed version, with its stamping and its signatures and its annexures, is the object that has legal consequences. Storing a near-identical draft alongside it and letting the two blur is how a company discovers, at the worst possible moment, that it cannot cleanly evidence its own contract.

A folder tells you where a contract is. A system of record tells you what it commits you to, and who has to act.

Document store versus system of record

The difference is not the storage technology, it is whether the contract has been converted into data the organisation can act on. A document store answers one question: where is the file. A system of record answers a different class of question entirely, and answers it without anyone reading anything.

The right-hand column is the one that changes conversations with finance, procurement and the audit committee. It is also the column that only exists if somebody decided, deliberately, what to capture.

The Metadata Schema That Survives Contact With Reality

Here is where most repository projects are lost, and they are lost by enthusiasm rather than neglect. Somebody designs the ideal schema. It has fifty-two fields. It captures governing law, jurisdiction, every liability sub-cap, insurance thresholds, assignment restrictions, change of control triggers, audit rights, data processing terms, exclusivity, most favoured nation clauses and three flavours of termination right. It is intellectually excellent, and it is dead within a quarter, because a busy commercial manager uploading a purchase order addendum on a Friday will not fill in fifty-two fields, and a legal team of four cannot fill them in on his behalf across a thousand agreements.

The design constraint is adoption, not completeness. Every additional mandatory field increases the probability that the record is never created at all, and a missing contract is infinitely worse than a contract with thin metadata. So split the schema into two tiers and be disciplined about the boundary.

Migrating a Legacy Portfolio Without Boiling the Ocean

The second place these projects die is the backfile. A company with fifteen years of trading has thousands of documents somewhere, and the instinct is to declare that the repository will be complete before it goes live. That instinct produces a migration project with no natural end, consuming a legal ops resource you did not have and delivering nothing usable until it finishes, which it does not.

Migrate in waves, and choose the waves by what generates decisions rather than by what is oldest or easiest.

One discipline holds the whole sequence together: record what is not in the repository, wave by wave, in writing. A repository with a documented coverage boundary is a professional instrument. A repository whose coverage nobody has ever stated is a trap, because the first time a colleague searches it, finds nothing, and concludes there is no such agreement, the omission becomes an assertion.

Ownership, Access and the Political Part

Repositories decay for human reasons more often than technical ones. Two decisions carry most of the load.

Every contract has one named owner

Not a team, not a function, not a shared mailbox. A person. The owner is the individual who will be asked whether to renew, who receives the notice-window alert, and who is accountable if a commitment in that agreement is missed. Distinguish this from the legal owner, who is the lawyer accountable for the terms. Both matter, and conflating them is how legal ends up owning commercial decisions it has no basis for making. Build in a reassignment step for when people change roles, because they will, and an unowned contract is the one that slips.

Access should be broad by default, restricted by exception

There is a strong instinct in legal teams to lock a contract repository down tightly. Resist most of it. If a category manager in procurement cannot see the agreement governing her own supplier, she will keep her own copy, and the moment a parallel copy exists you no longer have a single source of truth. Sensitive categories genuinely warrant restriction: employment and settlement agreements, transactions under negotiation, anything covered by a confidentiality undertaking that limits internal circulation, and matters subject to privilege considerations. Everything else should be visible to the people who have to operate it. Access control is a tool for the exceptions, not the default posture.

The Honest Limits of AI Extraction

Automated extraction is genuinely useful and it is oversold, and being clear-eyed about both halves saves a great deal of pain. On a clean, text-based PDF of a reasonably standard commercial agreement, extraction of parties, dates, term length and value works well and will save a legal ops team weeks. That is a real benefit and worth having.

Now consider the actual Indian backfile. A significant portion of it is scanned, sometimes at low resolution, sometimes photographed on a phone at an angle. Signature pages are appended separately. Schedules are handwritten or amended in ink. Stamp paper appears as a first page with text partly obscured. Amendments and addenda modify terms in a document filed nowhere near the parent. Renewal mechanics are expressed in prose that a human lawyer reads twice, not in a field. Extraction accuracy on that population is materially worse than on the clean sample used in the vendor demonstration, and the failures are not evenly distributed. They cluster exactly where documents are old, unusual or badly scanned, which correlates uncomfortably well with where the surprises live.

Measuring Whether the Repository Is Actually Being Used

Adoption is the only metric that matters, and it is not the same as the completeness figure that gets reported upward. A repository can be ninety percent complete and functionally dead. Watch for signals of actual use rather than of past effort.

• Time from execution to repository entry. If the median is measured in weeks, the repository is a reporting exercise rather than an operating system. Target days, and watch the tail rather than the average.
• Proportion of new agreements entering through intake rather than being added retrospectively. Retrospective entry means the workflow is being routed around and the repository is catching up rather than participating.
• Read activity by the business, not by legal. If only the legal team ever opens it, the business is still working from its own copies, and you have not eliminated the shadow portfolio.
• Renewal decisions made before the notice window rather than during or after it. This is the outcome measure the whole exercise exists to produce, and it is the one worth reporting to a board.
• Number of contracts with no named owner, and the age of that gap. A rising unowned count is the leading indicator of decay, usually following a reorganisation.
• Requests to legal that could have been self-served. A steady stream of what did we agree with this vendor questions means the repository is either incomplete, unfindable, or invisible to the people asking.

Report these honestly, including the uncomfortable ones. A general counsel who tells an audit committee that the repository covers live agreements above a stated value threshold and that the remainder is scheduled is in a far stronger position than one who reports completeness and is later asked about the agreement that was not there.

Where My Agreements Fits

CourtMesh's contract lifecycle application, My Agreements, is built around the sequence described here rather than around the demonstration-friendly parts. Contract intake and a pipeline view give you the single entry point that wave zero depends on, so new agreements stop entering the organisation through individual inboxes. Multi-stage approvals record who cleared what, which is the approval history the table above says a document store cannot give you. Obligation and renewal tracking is what turns captured dates into surfaced actions, and counterparty management keeps agreements grouped against the entity you are actually dealing with rather than against whichever spelling of its name was typed that day.

It sits alongside the rest of the platform, which matters for counterparty work specifically. The same organisation you are contracting with can be screened for litigation and insolvency exposure across the Supreme Court, the 25 High Courts, the District Courts and tribunals, drawn from official government portals, and placed on a private watchlist scoped to your organisation so that new matters against a key supplier surface while the contract is live rather than at renewal. Contract risk and counterparty risk are the same question asked twice, and they are worth holding in one place.

The limits should be stated as plainly as the capabilities. No system can guarantee that every agreement your company has signed is in it, because that depends on what your people put in. Extraction assists capture, it does not certify it. CourtMesh does not give legal advice and will not tell you whether a clause is acceptable or whether to renew. What it does is give the portfolio a single home, structured fields that can be acted on, and dates that arrive before the decision closes rather than after.