The ₹47 Lakh Auto-Renewal
A manufacturing company in Ahmedabad had a 3-year contract with a logistics provider. The contract had an auto-renewal clause: if not terminated 90 days before expiry, it automatically renewed for another 3 years at the same rates.
The contract was managed by the procurement manager who had signed it. He left the company 18 months later. The contract file was in his email. Nobody else knew the renewal date. The 90-day termination window passed. The contract auto-renewed.
By the time the new procurement manager discovered the auto-renewal, the company was locked into another 3 years at rates that were 22% above market. The cost of the oversight: ₹47 lakhs in above-market payments over 3 years.
This is not an unusual story. It's the predictable outcome of managing contracts in email inboxes and spreadsheets - systems that have no memory, no alerts, and no continuity when people leave.
The Contract Management Problem
Most Indian companies manage contracts in one of three ways:
Email folders: Contracts are stored as PDF attachments in email threads. Finding a specific contract requires searching email. Renewal dates exist only in the contract document itself. When the person who manages the contract leaves, the institutional knowledge leaves with them.
Shared drives: Contracts are stored as PDFs in a shared folder structure. Better than email, but still no alerts, no metadata, and no workflow. The renewal date is in the document - you have to open it to find out.
Excel trackers: A spreadsheet with contract names, parties, start dates, end dates, and renewal dates. Better than the above, but Excel doesn't send alerts. Someone has to check the spreadsheet regularly. And Excel doesn't scale - a company with 200+ contracts has a spreadsheet that nobody maintains properly.
All three approaches share the same fundamental flaw: they're passive. They store information but don't act on it. A contract management system needs to be active - it needs to know what's coming and tell the right people at the right time.
The Contract Data Model
The foundation of a contract management system is a data model that captures everything relevant about each contract.
Core contract record:
contracts:
id (UUID)
title (e.g., "Logistics Services Agreement - FastMove Logistics")
contract_type (vendor | customer | lease | employment | NDA | other)
counterparty_name (name of the other party)
counterparty_type (vendor | customer | landlord | employee | other)
owner_id (FK → users - the internal person responsible)
department (procurement | legal | finance | operations | HR)
status (draft | active | expired | terminated | renewed)
-- Key dates
execution_date (date contract was signed)
effective_date (date contract becomes effective)
expiry_date (date contract expires)
renewal_type (manual | auto | evergreen | none)
renewal_notice_days (days before expiry that notice must be given)
renewal_term_months (length of renewal period)
-- Financial
contract_value (total contract value in INR)
annual_value (annual value for multi-year contracts)
payment_terms (e.g., "Net 30", "Monthly in advance")
-- Documents
primary_document_id (FK → documents - the signed contract)
-- Metadata
created_at, updated_at, created_byKey clauses table: Important clauses extracted from the contract - termination rights, liability caps, exclusivity provisions, price escalation clauses. These are stored as structured data, not buried in the PDF.
Obligations table: Recurring obligations under the contract - monthly reports, quarterly reviews, annual audits, insurance certificate renewals. Each obligation has an owner, a due date, and a recurrence pattern.
Amendments table: Every amendment to the original contract is stored as a separate record linked to the parent contract, with its own effective date and document.
The Renewal Alert Engine
The most critical feature of a contract management system is the alert engine. Alerts must be:
Timely: Sent far enough in advance to allow meaningful action. For a contract with a 90-day termination notice requirement, the first alert should go out 120 days before expiry.
Escalating: If the first alert is ignored, subsequent alerts should go to more senior people. A contract approaching its termination window without a decision should escalate from the contract owner to their manager to the department head.
Actionable: Every alert should include: contract name, counterparty, expiry date, termination notice deadline, current annual value, and a direct link to the contract record. The recipient should be able to take action immediately.
Alert schedule design:
For a contract with a 90-day termination notice requirement:
- •Day -120: First alert to contract owner. "Contract expiring in 120 days. Termination notice deadline: [date]. Please review and decide on renewal."
- •Day -100: Reminder to contract owner if no action taken.
- •Day -95: Alert to contract owner's manager. "Contract approaching termination deadline. Owner has not yet taken action."
- •Day -90: Critical alert to contract owner, manager, and department head. "TERMINATION NOTICE DEADLINE TODAY. Contract will auto-renew if no action taken."
- •Day -60: If contract is being renewed, alert to start negotiation. "Contract renewing in 60 days. Initiate renewal negotiation."
- •Day -30: Final reminder. "Contract renewing in 30 days."
Alert delivery: Alerts should be delivered via email (primary), in-app notification, and optionally SMS for critical deadlines. Email is not enough on its own - emails get buried. In-app notifications ensure the alert is seen when the user logs into the system.
The Renewal Decision Workflow
When a contract is approaching renewal, the system should guide the owner through a structured decision process:
Step 1: Renewal assessment (triggered at Day -120)
The contract owner reviews the contract and answers:
- •Is the vendor/service still needed?
- •Is the current pricing competitive? (Compare against market rates)
- •Has the vendor performed satisfactorily? (Link to vendor performance records)
- •Are there any issues to address in the renewal negotiation?
Step 2: Decision (due by Day -100)
The owner selects one of:
- •Renew as-is
- •Renew with negotiation (specify negotiation objectives)
- •Terminate (specify reason)
- •Escalate for decision (if above owner's authority)
Step 3: Negotiation (if applicable, Days -100 to -30)
If renewal with negotiation is selected, the system tracks:
- •Negotiation objectives (price reduction target, term change, scope change)
- •Negotiation status (not started, in progress, agreed, failed)
- •Key negotiation milestones and deadlines
Step 4: Execution (Days -30 to 0)
- •If renewing: upload signed renewal/amendment, update contract record
- •If terminating: upload termination notice, update contract status
Handling Auto-Renewal Contracts
Auto-renewal contracts are the highest-risk category. The system should flag every auto-renewal contract prominently and treat the termination notice deadline as a hard deadline - not a soft reminder.
Auto-renewal contract identification: When a contract is entered into the system, the owner must specify whether it has an auto-renewal clause and the notice period. This is a required field, not optional.
Auto-renewal dashboard: A dedicated view showing all auto-renewal contracts sorted by termination notice deadline. Contracts within 30 days of their termination deadline are highlighted in red.
Termination notice generation: When an owner decides to terminate an auto-renewal contract, the system should generate a draft termination notice (from a template) pre-populated with the contract details. The owner reviews, approves, and the system records the notice as sent.
Contract Analytics
Beyond renewal management, a contract management system should provide analytics that help the business make better decisions:
Spend by vendor category: Total contract value by vendor type (logistics, IT, facilities, professional services). Helps identify concentration risk and negotiation leverage.
Contract expiry calendar: A calendar view showing all contracts expiring in the next 12 months, with their values. Helps procurement plan negotiation resources.
Vendor performance vs. contract value: For vendors with performance tracking, correlate performance scores with contract value. High-value, low-performance vendors are priority renegotiation targets.
Auto-renewal exposure: Total value of contracts that will auto-renew in the next 12 months if no action is taken. This is a risk metric that CFOs and procurement heads should review quarterly.
The Migration Challenge
The hardest part of implementing a contract management system is migrating existing contracts. Most companies have contracts scattered across email, shared drives, and physical files. The migration process:
Step 1: Contract inventory (2–4 weeks)
Identify all active contracts. This requires input from every department - procurement, legal, finance, HR, operations. Create a spreadsheet with contract name, counterparty, approximate expiry date, and location of the document.
Step 2: Document collection (2–4 weeks)
Collect the actual contract documents. For physical contracts, scan them. For email attachments, download them. Organise by contract.
Step 3: Data extraction (4–8 weeks)
For each contract, extract the key data: parties, dates, value, renewal terms, key clauses. This is the most time-consuming step. For a company with 100+ contracts, consider using a contract review service or AI-assisted extraction tool.
Step 4: System entry and validation (2–4 weeks)
Enter the data into the system. Have a second person validate each entry against the original document.
Step 5: Alert configuration (1 week)
Configure alerts for all active contracts. Verify that alerts are firing correctly by checking a sample of upcoming renewals.
The total migration effort for a company with 100–200 contracts is typically 3–4 months. It's a significant investment - but it's a one-time investment that prevents ongoing losses from missed renewals.
See how IdeaSprout Legal & Compliance manages contract renewals →