Software Acquisition — How Can It Go Wrong?

The way your organisation buys software is a foundational part of software asset management, and it is routinely treated as an administrative detail. That is a mistake with a specific shape: acquisition sits at the very start of the lifecycle, so an error made there is inherited by every process downstream and gets more expensive the longer it survives.

So how does something as apparently simple as buying software go wrong, and does it actually matter?

What are the issues with software acquisition?

Most organisations of any size hold volume licence agreements that give them a preferential rate on named products. The logic is straightforward: everything in scope should be bought through that route and no other. Enforcing it used to be straightforward too, because there was one purchasing path and it went through procurement.

That is no longer the case. App stores let anyone find, download and install software in a couple of minutes. The result may be functionally identical to the title covered by your volume agreement — and it will not be covered by it. You now hold two commercial relationships for the same product, one of which you negotiated and one of which you did not.

Buying through the wrong reseller causes a quieter version of the same problem. The agreement may be correct, the entitlement may be genuine, and it will still be painful to reconcile because the transaction did not land where your records expect it.

Recurring problems worth naming:

• Supplier terms that do not permit a merger or a change of entity without renegotiation
• Merging two different licensing frameworks after an acquisition
• The effort and resources needed to combine two organisations’ software holdings into one position
• OEM entitlement, which generally cannot be transferred at all

The merger and acquisition cases are the ones that hurt most, because they arrive with a deadline and without warning.

Are there deployment considerations?

Buying correctly is only half of it. Once the software is bought, deployment introduces its own ways to become non-compliant.

The wrong version is the common one. Deploy a version your use rights do not cover and you have a compliance exposure created by an engineering decision that nobody thought of as a licensing decision.

Deployment to the wrong device is the other. Where a product is licensed per device rather than per user — which covers a great deal of the Microsoft catalogue and most of the datacentre — installing on an unintended machine converts a routine deployment into a shortfall. Per-core and per-processor metrics make this sharper still, because the cost of the mistake is set by the hardware, not by how many people use it.

The route the original post did not cover: self-service subscriptions

When this was first written, the app store was the concerning new purchasing channel. It has since been comprehensively overtaken.

Today the most common way software enters an organisation without passing procurement is a corporate card and a subscription sign-up page, and the volume is substantial: the average enterprise portfolio now runs to 305 SaaS applications.

AI tools have made this faster again. A team can be using a paid assistant with access to company documents on the afternoon somebody decides to try it, with no contract review, no data processing assessment, and no line in any asset register.

The failure mode is the one described above, just accelerated. Duplicate spend against an agreement you already hold. Terms nobody read. Entitlement records that cannot be reconciled because the purchase never touched a system that keeps records.

Process matters — and it is no longer the only control

Good SAM is people, process and technology, and the original conclusion here was that acquisition problems are fixed with process: make sure people know how software is meant to be bought and who signs it off.

That advice holds. It is also no longer the whole answer, because a lot of what used to require a policy and a hopeful email is now enforced directly.

Give people a sanctioned route. The App-Centre self-service portal lets users request software from a catalogue with manager approval chains behind it. Most unsanctioned purchasing is not defiance; it is somebody needing a tool and finding the official path slower than the card in their wallet. Make the correct route the fast one.

Prohibit what should not be installed. CerteroX SAM carries application blacklisting and prohibition rules, with a Blocked Files log recording block counts per user and per device. That gives you both prevention and the evidence of what was attempted.

Hold entitlement where the deployments are. Licences, transactions, agreements, maintenance records, suppliers and publishers sit alongside the inventory, with assignment modelled per device, per processor and per core, plus downgrade rights and second-use handling. The Effective Licence Position is computed continuously — purchased, used, available, required, variance, exposure — rather than assembled the week an audit letter arrives. A reseller or version mistake surfaces as a variance, not as a discovery during due diligence.

See the subscriptions you never approved. CerteroX SaaS Management converges three discovery signals — identity provider sync from Entra ID and Okta, vendor API connectors, and a browser extension recording domains and time-on-app — to surface applications in use whether or not anyone filed a purchase order. AI tools are classified from application feature tags in the catalogue rather than a fixed list, so the detection set widens as the market does. Overlapping applications are ranked by recoverable saving, which is usually where the duplicate-agreement problem finally becomes visible.

Acquisition is still where SAM either starts well or starts badly. The difference in 2026 is that you no longer have to rely on everyone remembering the policy.

To see a purchase, an entitlement and an installation tied to the same record, book a demo.