Funding for cloud ERP, CRM and business applications: why a licence isn’t the same as implementation
Jacek Szafader September 30, 2026 You're reading:
- A familiar scenario in every funding round
- The basic distinction: a licence is not an implementation
- Why this distinction matters for grant funding
- Why cloud software causes confusion
- The two routes set out in grant programme rules
- Questions to ask the supplier before drafting the application
- Documents to request
- Warning signs
- What an IT supplier should not promise
- How to approach it
A guide for companies preparing a grant application to implement an ERP, CRM or other business application
A familiar scenario in every funding round
A mid-sized manufacturing company plans to implement a cloud ERP system, such as Microsoft Dynamics 365 Business Central. The same project often includes a CRM system for sales and service — Microsoft Dynamics 365 Sales or Dynamics 365 Customer Service — customer enquiry handling in Dynamics 365 Contact Center, Power Platform applications to automate processes, or Copilot features to support teams in their day-to-day work.
A grant programme offers funding for software purchase and implementation, bringing an investment that once seemed years away into next year’s plans. The consultant starts drafting the application. Two days later, they send a question that sounds straightforward but can hold up the project for a fortnight:
Can a cloud subscription be recognised as an intangible asset?
Behind that question lies a very real concern for the finance director. If the project’s largest cost item turns out to be ineligible — or is challenged only when the grant expenditure is reviewed — the entire financial case needs to be recalculated. This is not excessive caution. It is simply part of being responsible for a company’s finances. The question usually lands with the IT suppliers, which is where a second misunderstanding arises. A software supplier is neither a statutory auditor nor the body assessing the grant application, so it cannot determine the accounting treatment. What it can provide, however, is factual information about the delivery and licensing model. Without that information, nobody else can answer the question either.The basic distinction: a licence is not an implementation
It sounds obvious, yet it is the most frequently overlooked part of the picture. In an ERP, CRM or any other business application project, the customer pays for two fundamentally different things, supplied by two different parties under two different arrangements. One is a product from a global software vendor. The other is a service delivered by a local implementation team.
Bundling them into a single line item may make commercial sense: the customer sees one price and signs once. In a grant-funded project, however, it is a straightforward route to trouble, because that single figure cannot readily be broken down later.
In simple terms, the distinction looks like this:
What is included | Who the customer pays | Nature of the cost |
|---|---|---|
System subscriptions, such as Microsoft Dynamics 365 Business Central | Microsoft — with subscriptions ordered, activated and invoiced through a partner | A per-user fee for access to the service during the paid subscription term |
Implementation, data migration, integrations, training and post-go-live support | The implementation partner | A service delivered to a project schedule and formally accepted in stages |
The cloud software licensing agreement is between the customer and the software vendor directly. For Microsoft applications — Dynamics 365 Business Central, Dynamics 365 Sales, Dynamics 365 Contact Center, Power Platform or Microsoft 365 Copilot — this is the Microsoft Customer Agreement. The partner is not a party to that agreement.
The partner acts as an authorised reseller: it orders, activates and invoices the subscription, but it does not set the terms or have the freedom to change them. This is the part of the budget that the customer pays to the software vendor through the partner.
Implementation is something entirely different. It is the work carried out by the team: analysing processes, configuring the system, migrating data, building integrations, testing, going live, training users and providing post-go-live support. The customer pays the implementation partner for this work under a separate agreement, with its own schedule and acceptance milestones.
A licence without implementation provides access but little else. An implementation without a licence has nothing to configure. They depend on each other, but they remain two distinct components.
Why this distinction matters for grant funding
Each component may be treated differently when costs are assessed for eligibility, and some may extend beyond the eligible expenditure period. A subscription continues after the project ends. Implementation finishes when the work is formally accepted. Support begins only after go-live.
If all of this is rolled into one amount on one invoice, neither the accounting team nor the funding body can reliably separate it after the fact.
Itemising costs is therefore not a cosmetic change to the proposal. It is essential to preparing an application that can stand up to scrutiny when the grant expenditure is reviewed.
The same principle applies regardless of what the company is implementing: an ERP system such as Microsoft Dynamics 365 Business Central, a CRM based on Dynamics 365 Sales, customer enquiry handling in Dynamics 365 Customer Service or Dynamics 365 Contact Center, low-code applications on Power Platform, or Copilot licences.
In each case, the company buys a subscription from the software vendor and implementation work from the partner separately. The main difference may simply be their relative share of the budget. With Business Central, implementation and data migration usually account for the largest portion. With Copilot or Power Platform, the subscription itself may carry more weight.
Why cloud software causes confusion
For twenty years, buying a system followed a familiar pattern. You purchased a licence, recognised it as an asset and amortised it.
The cloud model does not follow that pattern. Under SaaS, the model in which most business applications are sold today, you do not acquire a copy of the software. You purchase the right to access a service for the paid subscription term. There is no physical medium, no version you own forever, no transfer of economic copyright and no right to modify the code.
Grant programme rules have caught up with this distinction and typically address the two cases separately: digital technology acquired as an intangible asset, and access to software treated as the purchase of a service.
These are two different ways of accounting for expenditure, with different implications for the budget and for the project’s sustainability period — the period during which its results must be maintained. Which one applies depends on the contract terms and the accounting treatment, not the product name in the proposal.
The two routes set out in grant programme rules
The following is a guide to the concepts, not an interpretation of the rules. Every funding round has its own binding terms. The decision rests with the applicant’s accounting team and the body administering the funding round.
Software recognised as an intangible asset
Under this route, the software must meet the criteria for recognition as an intangible asset under the Polish Accounting Act. It must be an asset of the applicant, be subject to amortisation and remain linked to the project, usually until the end of the sustainability period.
Programme rules allow long-term or perpetual licences under this approach. The application must describe the nature of the licence — including whether it is exclusive or non-exclusive — as well as its territorial scope, permitted uses, payment arrangements with the supplier and the planned period of use.
This is a natural fit for a perpetual licence installed locally, such as an on-premises ERP system.
Cloud software treated as a service
If a subscription does not meet the criteria for recognition as an intangible asset, access to the software may be treated as the purchase of a service.
This has an important budget implication: eligible expenditure usually includes only the cost of using the system during the eligible expenditure period. The company must fund charges incurred after the project ends from its own resources.
The system itself will generally still need to remain in use until the end of the sustainability period so that the project’s results are maintained.
Standard business applications sold through cloud subscriptions fit the second model. This applies to ERP systems such as Microsoft Dynamics 365 Business Central Online, CRM solutions such as Dynamics 365 Sales, customer service in Dynamics 365 Contact Center, applications built on Power Platform and Copilot licences.
This is neither a drawback nor an obstacle. It simply requires a different calculation. Problems arise when the application assumes the first model but the contract follows the second.
If recognition as an intangible asset is a mandatory requirement, the only technically viable option may be an on-premises version with a perpetual licence. That means a different delivery model, a different cost structure and different operational implications. It is worth pricing both options before making a decision.
Questions to ask the supplier before drafting the application
Before the consultant starts writing, it is worth getting answers to a few questions from potential suppliers. Each can be addressed in a single email, and the answers will also help when comparing proposals.- What licensing model does the system use, and who are the parties to the licensing agreement?
- Is the licence exclusive or non-exclusive? What term and territory does it cover?
- Does the proposal list licensing, implementation, training and support as separate cost items?
- Can the subscription term be aligned with the project delivery period?
- Which activities end when the implementation is formally accepted, and which generate recurring costs after go-live?
- What documents can the supplier sign to support the grant expenditure claim?
Documents to request
A well-prepared business application supplier should be able to provide a complete set of documents for the consultant to include in the application and for the accounting team to use when accounting for grant expenditure.- An itemised proposal separating subscriptions and licences, implementation, training and support.
- A separate implementation agreement and a separate licence order.
- An implementation schedule clearly stating the delivery period and acceptance milestones.
- Invoices with separate line items rather than a single bundled amount.
- Written confirmation of the licensing model and subscription terms, including usage rights, user numbers, the term and the nature of the licence.
Warning signs
Several things should raise a red flag before you sign the contract.- A single proposal line item described as “system implementation, including licences”.
- A supplier that confirms the accounting classification of a cost in writing without any qualifications.
- No specified subscription term or clear implementation start and end dates.
- Post-implementation support included in the implementation price without its value being shown separately.
What an IT supplier should not promise
An honest supplier’s answer to the intangible asset question should be along these lines:
“We provide the facts about the delivery model and the documents that substantiate them. Your accounting team or auditor determines the accounting treatment, while the body administering the funding round determines whether the cost is eligible.”
A supplier that promises more is taking on responsibility it is not equipped to bear. The risk still remains with the grant recipient.
That is why the order matters in grant-funded projects: first, a clear description of the model and an itemised cost breakdown; next, an accounting decision on the customer’s side; and finally, the description in the application.
Reversing that order leads to corrections when the grant expenditure is reviewed.
How to approach it
Do not start by asking whether the software qualifies as an intangible asset. Start by breaking the project down into its components: what is the software vendor’s product, what is the implementation partner’s service, what ends at formal acceptance and what continues after go-live.
Only once the project has been broken down this way can the accounting team and consultant make an informed decision, supported by the supplier’s documentation.
If you are planning a grant-funded ERP, CRM or other business application implementation and need an itemised proposal that will stand up to scrutiny when your grant expenditure is reviewed, we would be happy to work through it with you and your consultant.
We work with Microsoft Dynamics 365 Business Central, Dynamics 365 Sales and Contact Center, Power Platform and Copilot every day, so we can illustrate the cost structure using a concrete example.
It is usually an hour-long conversation that saves weeks of revisions.