Chain of Title for Used Software

chain of title used software licence documents and invoice

Chain of title for used software licences: documents buyers should request. Chain of title is the documentary trail that follows a software licence from the first lawful acquisition to the current buyer. In a used software transaction, receiving an activation key is not enough. The buyer should be able to show who originally acquired the licence, how the right was transferred, how many seats are included and why the seller no longer keeps a simultaneous right of use.

What chain of title means for used software
Why documentation matters more than the key
European framework: exhaustion and second-hand software
Minimum documents to request
How to review invoices and contracts
Warning signs before buying
Purchase checklist for IT, procurement and finance
How to archive chain of title after purchase
Where Licendi fits into a safer purchase

What chain of title means for used software

Chain of title is the documentary trail that follows a software licence from the first lawful acquisition to the current buyer. In a used software transaction, receiving an activation key is not enough. The buyer should be able to show who originally acquired the licence, how the right was transferred, how many seats are included and why the seller no longer keeps a simultaneous right of use.

This traceability matters when companies buy Microsoft Office, Windows, Project, Visio, SQL Server or other professional software on the secondary market. The saving can be meaningful, but it only works if the file can survive internal review, supplier audit questions or accounting checks. A clear chain of title turns a cheap purchase into a defensible purchase.

The practical rule is simple: any right you cannot explain with documents is a risk. If the supplier can provide invoices, contracts, transfer statements and deinstallation evidence, the transaction has a stronger base. If the offer is only a key and a verbal promise, a low price is not enough.

Why documentation matters more than the key

A key may activate a product, but it does not prove by itself that the buyer received a legitimate right to use it. With second-hand software, the question is not only whether the program works today. The question is whether the company can justify the purchase months or years later. Documentation should therefore be treated as part of the product.

The file should answer four questions: who owned the licence before, what right was transferred, how many licences were transferred and what happened to the previous installations. When those answers are documented, procurement, IT, finance and legal can make a decision with less friction. When they are missing, the organisation is relying on assumptions.

This approach also protects serious sellers. A seller that provides a deinstallation declaration, keeps invoices and separates transferred licences from retained licences avoids duplication and later disputes. Chain of title is not only a buyer demand; it is discipline for both sides.

European framework: exhaustion and second-hand software

In the European Union, resale of certain used software is linked to exhaustion of the distribution right. The best-known reference is the Court of Justice ruling in UsedSoft v Oracle, read together with Directive 2009/24/EC on computer programs. These references do not make every key resellable, but they provide a framework for reviewing lawfully acquired perpetual licences.

The buyer should check that the original right was granted for an unlimited period or was economically equivalent to a sale, that the price remunerated the value of the copy and that the first acquirer stopped using the software. The buyer should also review licence type, territorial scope, volume packages and possible limitations tied to hardware, education or subscription terms.

That is why generic answers are weak. The real question is not whether used software is legal in the abstract, but whether this exact lot, with this exact evidence, can reasonably be transferred. A professional purchase works case by case and archives the basis for the decision.

Minimum documents to request

The first document is the original invoice or equivalent proof of purchase. It should show supplier, buyer, date, product, edition, quantity and, where available, contract number or licence reference. Without proof of origin, the chain starts broken and the buyer accepts a risk that is difficult to price.

The second block is transfer documentation. This may include an assignment agreement, sale statement, certificate from the secondary supplier, ownership history and, for volume transactions, details of how many units are transferred. The goal is to connect the current buyer to the previous holder without unexplained gaps.

The third block is deinstallation or non-use evidence. The seller should declare that it has stopped using the transferred copies and does not keep active installations linked to the same right. In larger companies, this declaration should be supported by internal inventory records or confirmation from the IT owner.

document checklist for buying legal used software licences — Minimum documents to request

How to review invoices and contracts

A useful invoice must be legible, coherent and specific enough. Check that the product name matches what is being bought, that the quantity is not hidden in a vague bundle and that the date is consistent with the version. If the licence comes from a volume agreement, ask for the extract that identifies the transferred products and seats.

You should also check whether the selling entity matches the entity named on the invoice. If mergers, name changes or previous transfers occurred, request documents that explain those steps. Chain of title does not require only one owner, but every change should be understandable. A gap may not automatically destroy the transaction, but it should be resolved before payment.

In contracts, look for restrictions on assignment, internal use, territory, subscription, maintenance, education, public sector or OEM rights. Some clauses are incompatible with clean resale; others only mean that non-transferable services must be separated from the licence itself. The key is not to confuse a perpetual licence with surrounding rights that may not travel with it.

Warning signs before buying

The first warning sign is an offer based only on keys, without invoice or origin statement. The second is an unusually low price for a product that still has demand and active use. The third is pressure to close before documents can be reviewed. In used software, commercial urgency should never replace diligence.

Be careful with mixed lots that combine versions, languages, countries, OEM channels, education licences and volume rights without explanation. The more diverse the lot, the more important the breakdown becomes. A serious supplier should be able to separate products, quantities and documents by line.

Another warning sign is refusal to document non-use. If the seller cannot state that it has stopped using the licences, the buyer risks acquiring a duplicated right. The transaction should make clear that the right moves; it does not multiply.

Purchase checklist for IT, procurement and finance

IT should validate product, edition, compatibility, language, architecture, activation requirements and deployment plan. It should also record where the licence will be installed and who will hold keys and certificates. A well-documented purchase loses value if the software is later deployed without internal control.

Procurement should verify supplier, commercial terms, invoice, legitimacy warranty, delivery timeline and activation support. Finance should archive the file, connect it to the invoice and decide how the asset is recorded. Legal should review the chain of title, contractual limits and transfer declaration.

The best practice is to create one case file with all those elements. It does not need to be complex. A clean folder, consistent file names and a control table are enough for many small and medium businesses. The important point is that an audit answer should not depend on searching old emails.

used software licence purchase review process — Purchase checklist for IT, procurement and finance

How to archive chain of title after purchase

After purchase, keep the invoice, contract, transfer declaration, seller deinstallation evidence, keys, activation instructions and relevant correspondence. Add an internal note with purchase date, responsible person, assigned users and file location. This note helps reconstruct the story when staff changes.

The file should be kept for as long as the licence is used and for the reasonable retention period set by internal policy. If the licence is resold later, that file becomes the basis of the next chain of title. Buying well today makes future resale or audit defence easier.

Review the inventory periodically. If a used licence is reassigned from one device to another, record the change. If it is retired, keep the retirement note. Traceability does not end at activation; it continues throughout the useful life of the licence.

Where Licendi fits into a safer purchase

At Licendi, buyers can find Microsoft licences and professional software at competitive prices, with a process focused on clarity and practical use. When a company buys Office or Windows licences, it is not only looking for savings. It needs to know what it receives, how to activate it and which documents to keep.

Before buying, check compatibility, edition, seat count and device requirements. If you need to equip new workstations, a reviewed licence can reduce costs without changing the whole IT environment. If compliance is the priority, archive the documents from day one and avoid informal purchases outside procurement.

Chain of title is a way to buy with discipline. It does not remove every legal question, but it turns the decision into a verifiable process. In business software, verifiable evidence is always worth more than a cheap promise.

A practical purchase file model

A strong purchase file starts with an internal cover sheet: supplier, date, product, edition, quantity, price, procurement owner and technical owner. External documents should then appear in chronological order. Start with the original invoice or contract, add intermediate assignments, include the seller deinstallation statement and close with the invoice issued to the buyer. That order lets the transaction be read as a complete story.

Add a simple control table with columns for document received, date, issuer, product, quantity and comments. If a document is missing, do not hide the gap. Record it and explain how the risk was mitigated. A perfect file is not always possible, but an honest and organised file is far better than a folder full of unexplained PDFs.

Questions to ask the supplier before paying

Before payment, ask whether the licence is perpetual, whether it comes from a corporate purchase, whether it has been transferred before, whether any installations remain active, whether OEM or education restrictions exist and what support is offered if activation fails. Request written answers. The quality of those answers says a lot about the supplier.

Also ask exactly which documents will be delivered before final acceptance. Avoid vague phrases such as standard documentation. Request a closed list: invoice, certificate, transfer declaration, non-use evidence, activation instructions and support contact. That makes delivery measurable and avoids disputes after payment.

How buyers should handle incomplete evidence

Not every missing item has the same weight. A missing marketing brochure is irrelevant, while a missing original invoice can be decisive. Classify gaps as critical, important or minor. Critical gaps affect origin, quantity or right to transfer. Important gaps affect activation, internal allocation or future audit clarity. Minor gaps are formatting or convenience issues.

If a gap is critical, the safer decision is to pause. If the gap is important but explainable, document the explanation and lower the risk appetite accordingly. If the gap is minor, keep the note and proceed if the commercial and technical case still makes sense.