Illustration for a hypothetical case study
Suppose a company has spent years writing a system. When it comes time to sell the business, the owner wants to add a separate value for its source code. But some code may have been written for clients, some may depend on others' rights, and revenue from code already being sold may be included in the cash-flow forecast. I would separate those issues before putting a price on IP.
The company, figures, and periods A and B in this part are fictional learning examples, not the accounts or history of any business. THB 1 million in annual subscription revenue is a starting case, not a guarantee of renewal or future cash. Amounts exclude VAT unless stated otherwise.
The word IP needs an answer: a right in what?
For a software company, intellectual property (IP) may concern rights in code, documents, designs, trade names, or knowledge protected by confidentiality measures. But having a file on a computer does not establish ownership. The extent of a right and how it may be used depend on the work, the law, and the relevant contracts. Check item by item rather than treating an entire repository as a saleable asset. Examine employee, contractor, and customer agreements separately; paying a salary does not automatically settle copyright ownership. [Thai copyright law in WIPO Lex]
| Part of the system | Question before calling it company IP | Possible effect on value |
|---|---|---|
| In-house product core | What rights do employee and contractor agreements grant? Who can access and hand over the work? | A buyer may need to close rights gaps before using or transferring it. |
| Code written for a customer | Have rights already been delivered to the customer? Did the company retain rights in reusable parts? | Development cost does not automatically confer a right to resell. |
| Open-source components | What does each version and component's license require on use, modification, or distribution? | Disclosure or distribution duties must be assessed by license and use, not assumed for all licenses. |
| AI models and external services | What usage rights does the company have, which providers does it depend on, and how portable is the system? | The right to call an API is not ownership of the underlying model. |
| Customer data and test sets | For what purposes may the company use, keep, or send the data to a provider? | Possessing data does not always grant the right to sell it or train a model on it. |
| Team documentation and knowledge | Are there documents, versions, test systems, and people able to take over? | Rights may be clear, yet a buyer may still need to invest to keep the system running. |
I would start with an inventory of important software and components, attach traceable evidence of rights, and mark what the company owns, what it can only use, and what remains unresolved. Legal review of actual terms is part of valuation work. A report should not simply state that the company owns everything before checking.
How do build cost, recorded software assets, and sale value differ?
Total assets in a condensed statement do not reveal each software component's carrying amount, account classification, or rights of use and transfer. Examine the asset detail, accounting policies, and contracts. This series' choice not to add an IP asset is a case assumption, not a conclusion drawn from the absence of a line in a condensed statement.
WIPO's ideas on IP valuation focus on benefits arising from rights and a method suited to the available data. Past cost shows resources spent, not that a buyer will reimburse them in full. A system that took years to write may be obsolete; a small component solving a hard customer problem may be more useful. Future benefits and user alternatives matter too.
Recognizing an internally generated intangible asset has conditions. Under TAS 38, research spending is expensed. Development spending may be capitalized only when technical feasibility, intent to complete, ability to use or sell, probable future economic benefits, adequate resources, and reliable cost measurement can all be demonstrated. Costs qualify from the point the criteria are met; amounts previously expensed are not brought back as an asset later. [TAS 38 paragraphs 54, 57, 65, and 71]
In this fictional case, research and maintenance are expensed, while development has not yet met all asset-recognition criteria. There is therefore no IP asset from those activities in the statements. The company has not chosen to expense development that already met all criteria, nor added IP at a hoped-for selling price. A company using a reporting framework for non-publicly accountable entities must check that framework separately; the preceding paragraph is not an accounting instruction for every company.
The absence of IP from a statement does not prove software has no value. Properly expensed research may create knowledge useful later. Conversely, a recorded asset still needs assessment of useful life, amortization, and relevant indicators; its balance is no guarantee of sale value.
Where should IP benefits appear in a business plan?
| IP claim | Evidence to seek | Where it may appear in a forecast |
|---|---|---|
| Reusable across jobs | Delivery time across comparable scopes and quality levels | Lower delivery hours and costs, if quality can be maintained |
| Customers will pay for it | Paid contracts, price tests, and competing offers | Prices and renewal rates supported by evidence |
| Customers find it hard to switch | Migration costs, data rights, and actual reasons for staying | Retention of revenue, without assuming customers are locked in forever |
| More customers without proportionate staff growth | Installation time, service load, and system limits per customer | Incremental costs and investment still required |
| A buyer can take over | Manuals, installation scripts, tests, and operation without a key person | Transition costs, outage risk, and replacement-staff budget |
For example, if a module really reduces delivery hours, that benefit should appear in a defensible forecast of project costs. If subscriptions arise from rights to use a product, their benefit appears in that product's revenue and costs. Discounting the business's total cash flows has already put those benefits in enterprise value. Do not add a second source-code price merely to show that IP exists.
Define the right before valuing it separately
A separate valuation may help negotiate a license, sell a right on its own, or test whether expected product benefits are reasonable. Define which right, in which territory and period, whether it is transferable, and who must maintain the system. Do not add prices for each right to a business whose value already includes revenue from those rights.
Article four will use relief from royalty as a cross-check. It still needs assumptions about what the company would pay for comparable rights if it did not own them, the software's economic life, and ongoing costs required for the right to deliver benefits. Picking a percentage and multiplying ARR without support is not a valuation.
Before using IP to increase a company price, I want one inventory of rights and one body of evidence for benefits. Resolve unclear rights first. Where benefits cannot yet be measured, collect usage and cost data. A complete set of files can begin the review, but cannot finish valuation by itself.
Concepts were checked on October 19, 2026. Business valuation and accounting serve different purposes. Actual conclusions about rights and accounting require the company's contracts, facts, and reporting framework.
