IP Ownership in Stressed Asset Deals: The Question Nobody Asks Until It’s Too Late
Dextra Labs8 min read·Just now--
A resolution applicant wins the bid. Takes over the company. And then discovers the core product was never legally theirs to begin with.
Picture this.
A PE fund spends four months evaluating a distressed SaaS company going through NCLT proceedings. The business has real customers, mid-size enterprises paying decent ARR. The product works. The loan book is serviceable. The resolution price, after the distress discount, makes the numbers look genuinely attractive.
The fund wins the bid. The resolution plan gets approved. They wire the money, take control of the company and start the integration process.
Six weeks later, their legal team is on a call with an external counsel they’ve never spoken to before. The counsel represents the founding CTO, someone who left the company two years ago under circumstances that were, let’s say, complicated. And the counsel has a simple message: the core machine learning models that power the product’s credit decisioning engine were developed by the founding CTO during a period when his employment agreement had an expired IP assignment clause. He’s retained counsel. He believes he has a claim.
The fund didn’t buy a software company. They bought a software company with a disputed core asset and they’re discovering this after the money has moved.
This scenario is not hypothetical. Variations of it are playing out across distressed tech acquisitions in India right now. And the reason it keeps happening isn’t that resolution applicants are careless. It’s that IP ownership audits are consistently treated as someone else’s problem, until they become everyone’s problem.
Why IP Audits Get Skipped
The honest answer is that distressed M&A has a sequencing problem and a priority problem and both work against IP diligence.
The sequencing problem: NCLT timelines are compressed. Resolution applicants are working against deadlines that don’t accommodate thorough review of everything that should be reviewed. Financial due diligence gets done because it’s mandatory and because the bankers won’t let you skip it. Legal due diligence gets done because your external counsel insists. Technical due diligence and within that, IP ownership specifically, gets the time that’s left over after the mandatory work is complete. Often that’s not much time at all.
The priority problem: IP feels abstract. A debt obligation is concrete, you can see it on the balance sheet, you can model the cash impact. A security vulnerability is concrete, you can describe it, you can estimate the remediation cost. IP ownership sits in a different category in most people’s heads. It’s a legal question, not a financial one. The legal team is handling it. Except the legal team is handling the contracts and the regulatory exposure and the employment agreements and the IP ownership question requires someone who understands both the legal structure and the technical architecture well enough to trace which code was written by whom, under what agreement and whether that agreement is actually enforceable.
That’s a specific kind of expertise. It sits at the intersection of technical assessment and legal analysis. Most deal teams don’t have it internally and don’t think to bring it in.
The result: IP ownership audits happen, when they happen at all, as a checkbox. A lawyer asks the company to confirm that all IP is owned by the company. The company confirms. Nobody traces whether that confirmation is actually true.
What “Owned by the Company” Actually Means
Here’s where the technical complexity lives.
Software IP ownership is not a single question. It’s a chain of questions and the chain has to hold at every link.
The founding team question: When the company was incorporated, did the founders execute proper IP assignment agreements transferring any pre-existing work or subsequently developed IP to the company? Founding agreements get signed in a hurry. Sometimes the IP assignment language is missing or incomplete. Sometimes it covers work done after incorporation but not work done before and the core architecture was sketched out in a co-founder’s apartment two months before the company was officially formed.
The employee question: Every developer who contributed materially to the product needs to have had a valid employment or contractor agreement with a proper IP assignment clause. Agreements expire. Clauses get missed in standard templates. Contract developers, especially the ones brought in during crunch periods, often work under agreements that didn’t adequately address IP ownership. The code they wrote may still be in production.
The key person departure question: This is where the founding CTO scenario comes from. When a key technical person leaves, especially under contentious circumstances, their departure agreement matters enormously. Did they sign a separation agreement that confirmed IP ownership remained with the company? Did the existing employment agreement’s IP clause survive their departure? If there were stock buyback negotiations or acrimony around their exit, did anyone actually trace what happened to the IP assignment they’d made?
The open source question: Is there third-party licensed code in the codebase that restricts commercial use or requires attribution? This is technically a licensing issue rather than an ownership issue, but it lands in the same place, the product you’re acquiring may have components you can’t legally use the way the business model requires.
The contractor and vendor question: External development firms, freelancers, offshore development teams, all of these relationships produce code. Was there an IP assignment in every contract? Was it the company that commissioned the work (making work-for-hire doctrine potentially applicable) or an individual founder in their personal capacity?
A proper IP ownership audit for a stressed asset acquisition traces all of these questions systematically, against the actual codebase, against the actual employment and contractor records, against the actual departure agreements. It’s not a document review. It’s an investigation.
The Specific Risk in NCLT Proceedings
Stressed asset acquisitions through NCLT have a feature that makes IP risk particularly acute: the resolution process doesn’t automatically resolve IP disputes.
The IBC framework is designed to resolve financial creditor claims. It provides significant protection to resolution applicants regarding pre-existing financial liabilities, Section 32A is specifically structured to give a clean break on certain prior liabilities. But IP ownership is a different category of claim. It’s not a financial liability of the company. It’s a property rights question about what the company actually owns.
When you acquire a company through the resolution process, you acquire its assets. If the IP in question was never properly owned by the company, because of a failed assignment from a founder, an incomplete contractor agreement, or a departure that wasn’t cleanly documented, you haven’t acquired clean title to that IP. The resolution process doesn’t fix a gap that existed before the company became a corporate debtor.
This is the specific mechanism by which the founding CTO scenario plays out. The resolution plan doesn’t transfer IP to the successful resolution applicant, it transfers whatever IP the corporate debtor actually owned. If the corporate debtor’s ownership was contested or incomplete, that’s what you’ve acquired: contested or incomplete ownership.
For teams working through technical due diligence for NCLT proceedings, this distinction between what the resolution process protects and what it doesn’t is one of the most important structural points to understand before bidding.
What the Audit Actually Looks Like
An IP ownership audit in a stressed asset context has a specific scope that differs from standard IP due diligence in a going-concern acquisition.
The starting point is a codebase contribution analysis. Who wrote what, when and under what agreement? Git history is the primary evidence source. A systematic author analysis of the repository, not just looking at who’s listed in the company’s records as a developer, but who actually committed code, frequently surfaces contributors who aren’t in the official employment records and whose agreements have never been reviewed.
The second layer is agreement tracing. Every identified contributor gets matched against the company’s employment and contractor records. Every agreement gets reviewed for: whether an IP assignment clause exists, whether it’s appropriately scoped (some agreements cover only specific categories of IP), whether it was executed by the right parties and whether anything in the person’s departure changed the analysis.
The third layer is the departure audit. For every material contributor who left the company, especially founders and senior technical staff, the departure circumstances and documentation get reviewed specifically for IP implications. What did the separation agreement say? Was there a stock buyback? Were there any side agreements that might have modified the original IP assignment?
The fourth layer is the third-party code audit, a software composition analysis that identifies all open source and third-party licensed components in the codebase, traces their licences and flags anything that creates commercial use restrictions or copyleft obligations.
The output is a gap analysis: what’s clearly owned, what’s disputed or unclear and what the remediation options are for the gaps. In some cases, gaps can be remediated pre-close, you track down the relevant parties and get proper assignments executed. In other cases, the gaps are material enough to change the bid price or deal structure. In the worst cases, they’re deal-breakers.
The Cost Comparison That Should End the Debate
Here’s the arithmetic that gets skipped in distressed deal rooms.
A thorough IP ownership audit for a mid-size distressed tech company costs somewhere between ₹8 lakh and ₹20 lakh depending on codebase complexity and the number of contributors to trace. It takes two to three weeks. In the context of an NCLT timeline, it needs to start early, but it’s not an activity that blocks the financial or legal work, so it can run in parallel.
The IP dispute in our opening scenario, a founding CTO with a credible claim on the credit decisioning models, is the kind of matter that, in litigation, costs orders of magnitude more than the audit. And that’s before the business impact of operating under IP uncertainty: enterprise customers who pause renewals, investors who pause follow-on commitments, acquirers in a future exit who price in the overhang.
The IP audit is the cheapest insurance available in a stressed deal. It is consistently, almost universally, the last item to be scoped and the first to be cut when timelines compress.
The Honest Takeaway
IP ownership doesn’t feel urgent until it is. And in stressed asset deals, by the time it becomes urgent, you’ve already submitted your resolution plan, the CoC has voted, the NCLT has approved and the money has moved.
The question of what you’re actually acquiring, not what the information memorandum says you’re acquiring, not what management confirms you’re acquiring, but what you have provable, clean, enforceable title to, needs to be answered before the bid, not after the close.
Before you submit your resolution plan, know what you’re actually acquiring. An IP ownership audit is the cheapest insurance in a stressed deal and the one most likely to find something that changes the math before you’re committed to the outcome.
Dextra Labs provides technical due diligence and IP ownership audits for resolution applicants, PE funds and M&A teams evaluating distressed technology assets in NCLT and bilateral stressed asset proceedings.
