SaaS agreements in practice: defining scope, pricing, and additional work
SaaS projects often begin as clear and standardised, but end in disputes over what was actually included in the price.
The Software as a Service (SaaS) model, in its standard form, is typically limited to granting access to a system under predefined terms. However, in business solutions (such as ERP, CRM, etc.), this access is combined with additional services — implementation, integrations, data migration, and customisation. In such cases, the agreement becomes hybrid in nature, and the key question is what scope of work is included in the price and when additional fees apply.
The first aspect is functional changes. Client requests are often described as system adjustments, but in practice, some of them require actual development work. It is advisable to define a clear criterion in the agreement: if a change cannot be implemented using standard functionality, it should be treated as additional work and billed either based on pre-agreed rates or a separate proposal. Otherwise, such work may be performed without a clear legal basis for payment or may later become the subject of disputes over additional invoices.
The second aspect is the scope of integrations. The phrase “integration with X system” does not, by itself, define the scope of work. Agreements should specify the technical assumptions on which the integration is based (e.g. availability of APIs, documentation, data structure). It is equally important to provide that if these assumptions are not met, the resulting work is treated as additional services, ordered and paid for separately. This ensures a clear link between scope and pricing from the outset.
The third aspect is the client’s IT environment. During implementation, it may become apparent that existing systems do not meet technical or security requirements. Such work falls outside the SaaS service scope. Therefore, agreements should clearly state that the client is responsible for the compliance of its infrastructure, while any required adjustments or remediation are treated as additional work.
The fourth aspect is user training. The obligation to provide training should be defined quantitatively — by specifying the number of hours or sessions, the number of participants, and the format. It should also be clearly agreed that any additional training is provided only upon separate request and is billed accordingly. Otherwise, training may turn into an unplanned workload not reflected in the agreed price.
The core logic of these agreements is not to rely on abstract obligations, but to define clear boundaries: which services are included, how additional work is identified, and how it is ordered and priced. These boundaries ultimately determine whether a project remains controlled in terms of both scope and cost.
These issues cannot be effectively addressed through generic terms or standard templates alone — each project carries its own risk profile.
If you are working with SaaS solutions or planning their implementation, these aspects are worth evaluating before entering into an agreement.
📩 info@prevence.legal
📞 +370 664 42822
