The first contract spreadsheet I ever inherited had 47 columns.

Forty-seven. I counted. Some of them were reasonable: counterparty, effective date, renewal date. Some of them were aspirational: “Strategic Tier,” “Risk Score (1-5),” “ESG Flag.” And some of them were just sad — empty columns titled things like “Negotiation Notes,” “Indemnification Cap,” and “Original Drafter,” each one populated for maybe 4% of the rows.

The person who built it was long gone. The person who inherited it before me had given up. By the time it reached my desk, the spreadsheet was a museum of someone else’s good intentions.

I rebuilt the whole thing around twelve fields. That was four years ago. We’ve never needed more.

This post is what I learned about contract metadata the hard way: which fields earn their keep because somebody actually uses them, and which ones are just data-entry theater that makes the repository look impressive in a screenshot.

Why metadata bloat happens in normal companies

Nobody sets out to build a 47-column nightmare. It accretes.

Here’s the usual sequence. Someone in legal ops sets up a tracker with eight reasonable fields. Then finance asks for two more. Then procurement wants vendor categorization. Then someone in security wants a data-processing flag. Then a VP reads a McKinsey article on contract analytics and asks for risk scoring. Then a consultant runs a workshop and produces a list of “44 questions your contract data should answer.”

Each request is reasonable in isolation. None of them come with a person who promises to actually populate the field or use the output.

Two years later you have a repository where most columns are 30% full, nobody trusts the data, and the renewal team still keeps a separate spreadsheet because the official one is unreliable.

The trick is to remember what metadata is for. It’s not an inventory of every possible attribute a contract could have. It’s the smallest set of fields that lets you answer the questions you actually get asked, week after week, by people who need a real answer.

The test I use for every field

Before a field goes into the repository, it has to pass three checks:

1. Somebody asks for this information at least once a quarter. Not “could imagine asking.” Actually asks.
2. There is a clear, repeatable way to fill it in. If two reasonable people would put different values in the same row, the field will become noise.
3. Somebody is responsible for keeping it current. Fields with no owner rot.

A field that fails any of these is data-entry theater. It exists to make the repository look thorough, not to do work.

The 12 fields I actually track

Here’s my whole list. This handles a portfolio of around 800 active contracts across procurement, sales, NDAs, and the random one-offs that don’t fit anywhere.

1. Counterparty name. The company on the other side. Standardize this — “Acme, Inc.” and “Acme Corporation” should not be two rows. Pick one form and stick to it.

2. Contract type. Keep the list short. Mine has seven values: MSA, SOW, Order Form, NDA, DPA, Vendor Agreement, Other. The moment you have twenty contract types, nobody can categorize anything consistently.

3. Internal owner. One name. The person inside the company who answers the question “what is this contract for?” Not the department. A person. If the person leaves, you reassign — but a department-level owner means nobody owns it.

4. Effective date. When the obligations start. Often different from the signature date, which is why I don’t bother tracking signature date.

5. Expiration date. When the term ends, assuming nothing renews.

6. Auto-renewal? (yes/no). A single boolean. Most of your renewal pain lives here.

7. Notice deadline. The actual date by which someone has to act if they don’t want the contract to roll. This is the field that saves you money. If the contract requires 60 days written notice and expires December 31, this field reads October 31. Calculate it once when you load the contract. (I wrote separately about why this is the date that matters, not the renewal date itself.)

8. Annual value. What we pay or get paid each year, in dollars. Round to the nearest thousand. You don’t need cents. You don’t even really need hundreds.

9. Payment terms. Net 30, Net 60, monthly, annual upfront, etc. Short text field. Finance asks for this constantly.

10. Governing law. The state or country whose law governs the agreement. You will need this the first time a dispute looks possible, and you will not want to be opening PDFs to find it.

11. Document link. A direct link to the signed PDF in whatever repository you use. Shared drive, DMS, contract tool — doesn’t matter. The point is: from the row, one click gets you to the document.

12. Status. Active, Expired, Terminated, Superseded. Four values. This is what lets you filter “show me everything live right now” without trusting the date math alone.

That’s it. Twelve fields. Every one of them gets used by a real human being asking a real question, on a regular cadence.

The 30 fields I refuse to add

Here are the fields people have asked me to add over the years, grouped by why I said no.

Fields that sound useful but nobody uses

• Signature date — Effective date is what governs. Signature date is trivia.
• Original drafter — Interesting once. Never asked again.
• Negotiation start date — Same.
• Number of rounds of redlines — A vanity metric for legal ops dashboards.
• Days to signature — See above.
• Counterparty signatory name — Sits in the PDF. Pull it from there when you need it.
• Our signatory name — Same.
• Counterparty address — In the PDF.
• Counterparty contact email — Changes constantly. Will always be stale.

Fields that two people will fill in differently

• Strategic tier (Tier 1 / Tier 2 / Tier 3) — Nobody agrees on the criteria.
• Risk score (1-5) — Same.
• Business criticality — Same.
• Relationship health — A feelings field. Skip.
• Complexity rating — Skip.
• Negotiation difficulty — Skip.

Fields that belong in the document, not the metadata

• Indemnification cap amount — Pull it from the contract when you need it.
• Limitation of liability multiplier — Same.
• Insurance requirements — Same.
• Warranty period — Same.
• SLA credits — Same.
• IP assignment terms — Same.
• Non-compete duration — Same.

These are the fields that sound impressive in a CLM demo. In practice, populating them requires someone to read every contract carefully, and the moment a contract gets amended, the metadata is wrong.

If you ever truly need this data across the portfolio, run a project to extract it for a specific question. Don’t carry it as a column.

Fields that duplicate something else

• Renewal date — I track expiration date and notice deadline. Renewal date is redundant.
• Term length in months — Calculable from effective and expiration. Storing it invites contradictions.
• Days until expiration — Calculable. Don’t store derived values.
• Year signed — Same.
• Quarter signed — Same.

Fields that exist for someone who isn’t actually going to look

• ESG flag — Asked for once by a director. Never opened the report.
• Diversity supplier flag — Same. (When this matters, procurement owns it in their own system.)
• Data classification level — Security owns this in their tooling.
• Cross-border data transfer flag — Same.
• Subprocessor list — Lives in the DPA, which lives in the document.

That’s thirty fields I happily skip. The repository is smaller, faster to maintain, and — this is the important part — actually accurate.

Two rules that keep the list from growing

Rule one: a new field needs a named requester and a named maintainer. When someone says “we should also track X,” I ask two questions. Who will ask for this in a report? Who will fill it in for every new contract going forward? If those two names don’t exist, the field doesn’t exist.

Rule two: a field gets pulled if it’s empty more than half the time after six months. I do this audit twice a year. If a column is 60% blank, it’s not a field — it’s an aspiration. Aspirations don’t belong in the repository.

Start low-tech

If you’re rebuilding your repository this month, you don’t need software for any of this. A single Google Sheet or Excel file with twelve columns will handle a few hundred contracts comfortably.

Add some basic discipline:

• A header row that defines each field.
• Data validation on the columns that should be lists (contract type, status, auto-renewal).
• A separate tab with the rules — what counts as a Tier 1 type, what status means, who the field owners are.
• A monthly habit of opening the sheet and looking at the contracts expiring in the next 120 days.

You can graduate to a contract tool later, when the volume or the team size justifies it. The fields don’t change. A tool just gives you better alerting, searchable PDFs, and fewer chances to break the sheet.

What to do this week

Pull up whatever you currently use as your contract list. Count the columns. For each one, write down:

• The last time someone asked you for that information.
• The percentage of rows where it’s actually filled in.
• The name of the person who would fill it in for a new contract today.

Anything that fails on two of those three gets cut. Move the data to an archive tab if you can’t bear to delete it. Then look at your remaining list and ask: do I have all twelve of the fields above?

You’ll probably find you’ve been tracking five fields you don’t need and missing two that you do.

The repository gets smaller. The data gets more accurate. And the next person who inherits it from you won’t have to stare at a forty-seven-column spreadsheet wondering which of the empty columns are load-bearing.

---

I’m Dave, and I write about contract management the way it actually works. No jargon, no sales pitch, just what I’ve learned from 15+ years of doing this job. If this was useful, stick around.