What goes in a contract register, and who keeps it?

Most businesses that decide to build a contract register start by listing columns. That is the wrong end. The right first question is who will be looking at it, and what they will be trying to find in a hurry.

There are only three of those people. Somebody asking what we agreed with this customer. Somebody asking what is committing us next quarter. Somebody assembling a data room. A register that answers those three questions is finished; one that captures everything else is a data-entry project that stops being maintained in about four months.

The columns that earn their place

Counterparty, as it appears on the signed document. Not the trading name everybody uses. The entity that signed is the entity that can enforce, and the two are different more often than people expect.

Document and version. Which agreement, on which version of your terms. Without the version the register tells you a contract exists and nothing about what is in it.

Commencement and expiry. Both. A register holding only expiry cannot answer how long something has been running, which is the question that comes up in a dispute.

Notice period and the date it starts. This is the column that pays for the register. An expiry date on its own tells you when the contract ends; it does not tell you the last day you could have done anything about it.

Value, annualised. Contract value flatters short agreements and hides long ones. Annual figures compare.

Owner, by role. Who is responsible for the relationship, named by the job rather than the person.

Where the executed copy lives. One link or one location. A register that identifies a contract you then cannot produce has done half the job.

What to leave out

Anything requiring interpretation. Do not add a column for "risk", or "favourable to us", or "key obligations". Those need judgement, they date badly, and the moment somebody relies on a summary rather than the document, the register has become a liability rather than an index.

The register's job is to find things. What they mean is a different job.

Who maintains it

The person who files the executed contract, as part of filing it. Not the person who negotiated it: their work ends at signature, which is exactly when the row needs creating.

The mechanism that keeps it honest is coupling: the executed document does not get filed until the row exists. Filing is a step somebody wants to complete, so attaching the register to it means the register gets completed too.

Start from the payments, not from memory

Building the first version from what people remember produces the contracts people remember. Building it from accounts payable and accounts receivable produces the ones that are actually running, including the three-year software agreement nobody thinks of as a contract because it arrived as an invoice.

Expect the first pass to surface agreements nobody could name. That is the finding, not a failure of the exercise.

What it looks like working

Somebody asks what we are committed to with a supplier and the answer takes a minute rather than an afternoon. The renewals that get away stop getting away, because the notice date is in front of somebody with enough lead time to act. And when a transaction starts, section four of the data room is already assembled.

The boundary

Building the register, extracting the dates, and keeping it current as documents are filed is administration, and it is work a business can do for itself.

What any clause means, whether a notice has been validly given, and what a contract obliges you to do are questions for your own external adviser.

The register is what makes those questions cheap. "Here is the agreement, here is the version, here is the notice provision and here is the date" is a bounded question. A folder and a hope is not.