How to Set Up Contract Approval Workflows

A contract approval workflow is the set of rules that decides who must sign off on a contract before it goes out, and in what order. Done well, it is nearly invisible: a standard NDA clears in an hour, a six-figure vendor deal gets the right two people looking at it in parallel, and nobody is guessing who to chase. Done badly, it is the single biggest reason contracts sit for weeks: every deal routes to the general counsel, approvals happen one after another instead of together, and there is no backup when the one approver who matters is on leave. The one thing most teams get wrong is treating approval as a single step. It is not a step. It is a matrix: who approves, based on what, and what happens if they do not respond in time.

Adira, which publishes this guide, sells contract lifecycle management software with approval routing built in. This page works whether or not you ever buy anything from us: the matrix design, the escalation rules, and the legal reasoning below apply just as well on a spreadsheet as inside any CLM tool.

Why approval is where most contract delay actually lives

Ask any legal or procurement team where contracts get stuck, and the honest answer is rarely drafting or negotiation. It is the approval step, where a finished document waits for a signature from someone who has not opened it yet, and two design mistakes cause almost all of it.

The first is routing everything through one person, usually the general counsel, regardless of value or risk; a GC who personally approves every NDA and every seven-figure master agreement becomes the bottleneck by definition, because their calendar is finite and the queue is not. The second is sequential routing: legal signs off, then finance, then the business owner, each waiting for the last person before they even open the document. Three reviewers who could each spend fifteen minutes in parallel instead spend two or three days waiting on each other.

Neither mistake is about individual effort. Both are structural, and both are fixed the same way: decide in advance, not case by case, who needs to look at a given contract and how.

Step 1: Build an approval matrix, not a single approval step

An approval matrix is a table, not a person. It maps a contract's characteristics to who must approve it, and it should key off at least four dimensions.

Contract value. The most common axis, and the easiest to set too low. A threshold of, say, under 5 lakh rupees for finance sign-off and under 25 lakh for a business-unit head is a starting point, not a rule; pick bands based on your own typical deal size. A 20,000 rupee NDA and a 2 crore master services agreement should never travel through the same number of approvers.

Risk type, independent of value. A data processing agreement, an uncapped indemnity, or a deviation from your standard limitation of liability carries risk a value threshold alone will not catch. A low-value contract with unlimited indemnity should route to legal regardless of size; a high-value renewal on unchanged paper should not need the same scrutiny as a new counterparty's first deal.

Deviation from the playbook. If your negotiation playbook sets an ideal, a fallback, and a walk-away position for each key clause, the matrix should ask a narrower question: does this document sit inside the fallback band, or has the counterparty pushed past it? Inside the band, a business owner or junior reviewer can approve using pre-cleared wording. Past it, the approval routes to whoever owns that escalation, usually the person who set the walk-away line. See how to build a contract negotiation playbook for how those positions get written; the matrix turns them into a routing decision.

Contract type. An NDA, an order form, a vendor MSA, and a lease carry structurally different risk even at the same value, and often need different expertise.

Combine these four into a table with, at most, four or five tiers. Twenty tiers is as unusable as no matrix at all; the goal is a rule someone applies in seconds, not a decision tree needing its own manual.

Step 2: Route approvals in parallel, not one after another

Once the matrix says a contract needs legal, finance, and a business-unit head, the default instinct is to send it to each in turn. Resist that. If three approvers each need fifteen minutes and nothing one decides changes what the others are looking at, there is no reason for them to wait on each other. Send the request to all three at once, with a shared deadline.

Sequential routing only earns its place when one approval genuinely depends on another, for example a business owner confirming budget exists before finance signs off on payment terms. Even then, question whether the dependency is real or just habit.

Step 3: Auto-approve what does not need a human at all

Not every contract needs an approver in the loop. If a document is your own unmodified template, on a type and value your matrix already treats as low-risk, a human sign-off adds delay without adding safety. Set an auto-approval rule for that combination: standard paper, inside the fallback band, below the lowest value threshold. The system, or a manual checklist, confirms the document really is unmodified, and it proceeds without waiting in anyone's queue.

This only works if "standard" has a real, checkable definition, not a requester's word. A fast way to confirm a document matches your baseline, clause by clause, is to run it through Weave, Adira's free browser-based contract markup tool, before it enters the queue at all.

Step 4: Define escalation and set an SLA

Every approval tier needs a deadline and a rule for what happens when it passes. A common structure: same-day for low-value, standard-paper approvals; two business days for mid-tier; a scoping conversation, not a fixed deadline, for anything that has already triggered a playbook escalation. Publish these numbers, since an approver who does not know they are expected to respond within two days has no reason to prioritise the request.

Escalation is what happens when the deadline is missed, not a vague hope someone notices. A missed SLA should auto-notify a named backup or the approver's manager, not silently reset the clock. Without that path, a missed approval just sits, invisibly, until someone downstream asks where the contract is.

Step 5: Build in delegation and keep an audit trail

An approval matrix that names one person per tier breaks the moment that person takes leave. Every approval role needs a named backup, decided in advance, not improvised the week someone is out, the same principle that makes contract intake work when a reviewer is unavailable: a single point of failure is a design flaw, not bad luck.

Keep a record of every approval decision: who approved, when, at what tier, and whether it followed the standard matrix or was an escalated exception. This is not paperwork for its own sake. If a contract is ever disputed, the record of who actually authorised it is often the first thing anyone asks for, and it matters more once you look at what Indian company law says about who can bind a company at all.

The legal reason approval workflows matter more than they look like they should

It is tempting to treat an approval workflow as pure process hygiene, a way to move faster with less chaos. In India, it is also a control on who is actually authorised to commit the company, and what happens when someone acts, or appears to act, outside that authority.

Section 21 of the Companies Act, 2013 sets the baseline for who may sign a contract on a company's behalf:

"Save as otherwise provided in this Act, a document or proceeding requiring authentication by a company or contracts made by or on behalf of a company, may be signed by any key managerial personnel or an officer or employee of the company duly authorised by the Board in this behalf." Source: Section 21, Companies Act, 2013

That sentence is the legal basis for the entire idea of an approval matrix: authority to sign traces back to a Board authorisation, not to a job title someone assumed came with the power to commit the company. When your matrix says a business-unit head can approve up to a certain value, that authority needs to actually exist as a Board-delegated power, on paper, not just as a rule inside a workflow tool.

Some approvals cannot be delegated at all. Section 179(3) lists matters the Board must decide by resolution at an actual meeting, including to borrow monies, to invest the funds of the company, to grant loans or give guarantee or provide security in respect of loans, to approve the financial statement, and to approve amalgamation, merger or reconstruction. A loan agreement, a guarantee, a merger agreement, cannot be waved through by a workflow approval alone, however senior the approver. Flag these types for board-level sign-off as a fixed rule, not a discretionary escalation.

The risk runs the other way too: a company can end up bound by an approval never properly authorised internally. In Lakshmi Ratan Cotton Mills Co. Ltd. v. J.K. Jute Mills Co. Ltd. (Allahabad High Court, AIR 1957 All 311), a director borrowed money on the company's behalf without the board resolution the articles required to delegate that power. The company argued it was not bound because the internal formality had not been completed. The court held it liable anyway, applying the doctrine of indoor management: an outsider dealing in good faith with someone who appears to hold authority is entitled to assume internal steps were followed, without checking the company's internal records first. Case text: Indian Kanoon.

Read together: a documented, Board-traceable matrix protects the company both ways. It stops an unauthorised person from creating an obligation the company did not intend, and gives the company a clear record if a counterparty later claims an approval was valid when it was not. A workflow tool with no delegation of authority behind it is a checklist, not a legal control.

Red flags in an approval workflow

Normal	Red flag	Why it matters
A tiered matrix routes by value, risk, deviation, and type	Every contract goes to the general counsel, regardless of size	The GC becomes the bottleneck, and low-risk deals wait behind high-risk ones
Approvers review in parallel, with a shared deadline	Legal, then finance, then the business owner, each waiting on the last	Three 15-minute reviews turn into days of dead time between handoffs
Every approval role has a named backup	One person is the only route for a tier	Leave or a busy week stalls every contract in that tier
A missed SLA auto-escalates to a backup or manager	A missed deadline just sits until someone asks	Delay stays invisible until it has already cost real time
Section 179(3) types, loans, guarantees, mergers, are flagged for board-level sign-off	A senior approver clears a loan or guarantee as a routine approval	The approval may not satisfy the Companies Act, exposing the decision to challenge
Delegated authority traces to an actual Board resolution	A job title alone is treated as proof of signing authority	Section 21 requires Board authorisation behind the signature, not assumed authority
Auto-approval applies only to unmodified paper, checked against a baseline	Auto-approval is set by contract type alone, unchecked	An edited document ships as pre-approved because nobody compared it to the baseline
Every approval is logged: who, when, which tier	No record beyond an email thread or a verbal yes	A disputed contract has no reliable trail showing who authorised it

Fixing an approval clause: a bad line vs a better one

Bad: "All contracts require appropriate internal approval before execution."

What is wrong: no threshold, no named approver, no timeline, no backup. "Appropriate" is not a rule anyone can apply consistently, so in practice everyone routes everything to whoever they think is safest, usually the general counsel.

Better: "Contracts are approved under the current approval matrix, published at [link]. Approvers for a given tier act in parallel, with a response required within that tier's SLA. Where a named approver is unavailable, their designated backup approves instead, and the substitution is logged. Contracts within Section 179(3) of the Companies Act, 2013, including borrowing, guarantees, or mergers, require a Board resolution and cannot be cleared through the standard matrix. Every approval decision, including the tier applied and any escalation, is recorded against the contract."

What changed: a specific, published matrix replaces an undefined standard; approvals run in parallel with a real deadline; a named backup closes the single-point-of-failure gap; the Companies Act carve-out is explicit; and every decision is now auditable.

How this connects to the rest of the process

An approval matrix is only as good as the negotiation playbook feeding it. If the playbook has not defined a fallback band for a clause, the matrix has nothing reliable to check a deviation against, and every contract ends up escalating by default. Build or update the negotiation playbook first, then set matrix thresholds against its fallback positions. Approval is also usually the single biggest lever in overall cycle time; see how to reduce contract turnaround time for where it ranks against the other levers.

US and global contrast

The mechanics, tiered matrices, parallel review, auto-approval, named backups, travel well across markets, and most US-focused guidance covers exactly this ground. What it typically skips is the authority question above. US corporate law generally lets bylaws and officer titles establish signing authority more informally, and indoor-management-style doctrines exist but get less emphasis in process design. In India, Section 21's Board-traceable requirement and Section 179(3)'s non-delegable matters mean a matrix is not just a speed optimisation. It is the record that shows a contract was authorised the way the Companies Act requires.

A quick test you can run today

Pull the last five contracts your team signed. For each one: can you name who approved it, when, and under what authority, in under thirty seconds, without opening an email thread? If the answer is no for more than one, the workflow is running on memory and goodwill, not a matrix, and that gap is exactly what Section 21 and the indoor management doctrine above turn into real exposure.

FAQ

How many approval tiers should a matrix have? Three to five: a self-serve or auto-approve tier for low-risk standard paper, one or two mid-tiers by value and risk, and a top tier for anything that hits a playbook walk-away line or a Section 179(3) matter requiring the Board. More than that usually means the matrix is replacing judgment instead of structuring it.

Should legal ever be the only approver on a contract? Rarely, and only for genuinely legal-only risk, such as litigation settlements. Most contracts benefit from parallel review by legal, finance, and the business owner, each catching something the others would miss.

What is the difference between an approval matrix and a negotiation playbook? The playbook defines what "acceptable" looks like clause by clause: ideal, fallback, walk-away. The matrix decides who signs off once a document is measured against that playbook. A matrix without a playbook has nothing objective to check deviation against; a playbook without a matrix has no defined path to approval.

Can a junior employee's approval ever bind the company if they were not actually authorised? It can, if the company's own conduct made it reasonable for the other side to believe that person had authority, a doctrine the Indian Contract Act, 1872 addresses through agency by estoppel under Section 237. This is exactly why a matrix needs to trace back to real Board delegation under Section 21, not an assumed title, so the company's own conduct never creates that impression by accident.

Do all approvals need to happen inside CLM software? No. A shared spreadsheet with a documented matrix, named backups, and a manually logged decision trail covers most teams well past a hundred contracts a month. Software earns its place once parallel routing and an audit trail that survives a dispute become too much to track by hand reliably.

What contracts absolutely cannot be approved through a standard workflow, no matter the value? Anything within Section 179(3): borrowing money, investing company funds, granting loans or guarantees, approving financial statements, or approving a merger, amalgamation, or acquisition. These need an actual Board resolution passed at a meeting, not a workflow sign-off, regardless of how senior the approver is.

This guide gets you a working approval matrix, the mechanics that remove serial bottlenecks, and the Companies Act basis most approval-workflow guidance leaves out. It does not tell you where your value thresholds should sit, or whether a specific past approval would hold up if challenged. Those depend on your facts, your Board resolutions, and your Articles of Association, and are not legal advice. Talk to a lawyer before relying on where those lines sit for your own team.