ERP Pricing Models: How You Pay For ERP Software

In choosing a new enterprise resource planning system, comparing prices can be like comparing apples to oranges, especially if you are considering different types of licenses or deployment models. These ERP system pricing models can range from dead simple to overly complex. Even if they appear simple, understanding how different ERP solution providers arrive at proposed ERP costs can be confusing. Very often, the total is a composite of several different cost elements. Here we explore what some of those different elements are most likely to be. For a complete picture of ERP pricing see our guide ERP Pricing: Understanding the Cost of Enterprise Resource Planning Software.

The most common software pricing model for ERP systems is user-based pricing, both in the traditional on-premise and the SaaS worlds and anywhere in between. As you add more employees or you expand your implementation to a new department or function within your organization, the user count goes up, and so does the cost. You may be tempted to skimp on users, but this can limit the value you derive from the application. 

However, before you decide how many users you need, it is crucial to understand how they are counted. First, you need to determine whether these users are concurrent or named. While pricing by concurrent users was once the norm, today, named users are the more likely method. If you are replacing an aging ERP solution, it is not only essential to understand what is being offered but also what you have today. If, for example, you have a concurrent user license, but your new solution only offers named users, your number of users might change dramatically.

Concurrent ERP Users

The number of concurrent users counts users that are logged into the application simultaneously. In the early days of ERP, this was often based on the honor system but was also subject to audit. Today’s solutions have this kind of policing mechanism built in. If you buy 50 concurrent users, it doesn’t matter who is using the software; when the 51^st user tries to log in, he or she will be turned away. This can be an effective way of keeping the number of users in check when you have workers distributed around the world in very different time zones. The folks in North America will be sleeping when the workers in the Asia Pacific are logging in. You will have a smaller number of concurrent users than named users, but the price per user will generally be significantly higher.

Named ERP Users

If you buy 50 named users, you will identify each by separate login credentials. Theoretically, two different people cannot share a single named user, but this isn’t always the case. The ​“named” user might be a group of people (like material handlers or assembly workers). But two people with the same ​“name” can’t be logged in at the same time, even if only ten other named users are active. If the group also shares a single point of entry (perhaps a kiosk or terminal on the shop floor or warehouse), this works well. If someone else is using the login (i.e., he or she is physically standing at the terminal), the next person waits in line. If the sharing is more virtual, it is much harder to manage, and the integrity of your user count may come into question. Is this a legitimate ​“group,” or are you trying to cheat the system with fewer users?

Full Users or Limited Users

A concurrent or named user generally has access to a full range of functions. However, some of your users may be limited in what they can do. They might have access to selected inquiry-only functions but cannot enter transactions. Or perhaps they are limited to a select few types of transactions like moving inventory or recording hours worked and parts completed on the shop floor. They may often be restricted to ​“self-service” functions like requesting paid time off, filing expense reports, or inquiring about other benefits. 

For access to these types of (limited) functions, you might purchase a specific number of ​“casual” or ​“limited” users. Alternatively, this component of the price might be based on your total number of employees. This is a standard methodology in pricing Human Capital Management (HCM) solutions, mainly because of the need for these ​“self-service” functions. While ERP is very seldom priced based on your total number of employees, if HCM is bundled with ERP, this solution segment might be priced this way.

Expect to pay far less per user for this type of access.

Most ERP solutions are suites of modules, such as general ledger, accounts payable, order management, accounts receivable, inventory control, purchasing, etc. Sometimes select modules are grouped together (e.g., accounting modules); sometimes, they are packaged and licensed individually. Paying a price for the different modules is often used in conjunction with user-based licensing. You might pay a module fee plus users, or users might be confined to specific modules. Some vendors will charge you individually for specific modules or groups of modules (e.g., financial management or production). Others include everything by default.

While all modules might be included in the price per user, there will almost always be an additional charge for an extension. What’s the difference between a module and an extension? In the past, the difference was quite clear. ERP, although an integrated suite of modules, was always a monolithic structure. It was comprised of modules (e.g., general ledger, customer relationship management, accounts payable, inventory management, purchasing, order management, etc.), and indeed, some were optional, but none of these could stand alone. All modules shared a common database, and all were developed using the same tools and technology. They all moved forward in lockstep. This eliminated data redundancy and any need for separate integration efforts, but it made the monolithic structure very rigid.

In the past, a quick rule of thumb was modules were embedded while extensions were more loosely coupled. Extensions weren’t an integral part of (core) ERP. They were separate. They may or may not have been developed using the same tools and technology. They may or may not have shared a common database. They may or may not have been tightly and seamlessly integrated. Just about the only guarantee was that they were optional components that extended beyond ERP’s core functionality.

Today the distinction between a module and an extension is blurrier, not necessarily because the characteristics of an extension changed, but because ERP and the modules included are developed differently. Rigid, monolithic structures are the dinosaurs of the enterprise software world. Most modern ERP solutions are now developed using a more component-based architecture and therefore, modules may also be loosely coupled.

Every technologist in our audience knows a microservice architecture is defined as an architectural style that structures an application as a collection of loosely coupled services. For those nontechnical readers, think of it as constructing a solution from a set of Lego building blocks. Purists hate this analogy, and yes, it is an oversimplification. But it is an effective analogy that resonates with most business users that don’t have the interest or inclination to dive deep into technical jargon.

Think about how you build a structure from Legos. Each Lego block is made of the same kind of material and is attached (connected) to the other Lego blocks in the same way. In many ways, they are interchangeable. But by choosing different colors and sizes and connecting them with a different design, you can make a unique structure. And once constructed, if you want to change it, decoupling some of the blocks and replacing them doesn’t destroy the parts that are not affected. There is far less disruption introduced than if you had constructed it with a hammer, timber, and nails.

With a good platform, both ​“embedded” modules and extensions can be built much more quickly, and both can be seamlessly integrated. And therefore, with a solid microservices architecture, the distinction between a module and an extension becomes not only a bit blurrier but also a bit more arbitrary. 

The bottom line: Investigate carefully what is included in your subscription or license, in general and for each user. As you expand the scope of your ERP implementation process in terms of features and functions, will you simply be paying for more users, or will there be an additional module fee?

Pricing by module and by the user is often favored as a way of paying for only what you use and because it is perceived as a method by which the buyer can assert some control over the cost. But it can also raise some barriers to growth. As you add functions and users, the cost escalates, and you might be tempted to delay expanding your solution, even when those added functions and/or users become critical to your success. When solution providers offer an all-inclusive license or subscription (i.e., you have full access to all features and functions), it encourages customers to use more of the solution, thereby deriving more value and additional benefits. They will argue added users result from growth and, therefore, can be more easily justified. But when added revenue and profits lag, when the goal is to cut costs, or when the additional ERP implementation costs were not anticipated, customers might drag their feet in paying for more users.

Another alternative to user-based licensing is known as an enterprise license.

Enterprise licenses are far less common. An enterprise license is typically negotiated for a period of time, most likely a year. Each vendor will have a different formula for determining price, so it is essential to read all the fine print and understand what you are buying. Factors that are most commonly used to set the initial price include the functions used think modules, groups of modules, and extensions), the size of the company, and the number of users.

Typically, the most significant advantage to this type of license lies in its predictability, at least for the negotiated term of the contract. It does not restrict the number of users or the functions available and encourages widespread use across your enterprise, which drives more value. And if at the time of renewal, you see that your ERP software solution has enabled your growth, you don’t mind paying more when you renew. Conversely, if your business has declined, your solution provider should gracefully lower your ERP software cost. Unfortunately, this seldom happens in the on-premise and hosted world but is common practice in SaaS subscriptions.

The vast majority of ERP vendors will use some combination of the ERP software pricing models described above. However, there is also a new model that has emerged with SaaS. This new model bases the price on the consumption of resources. Those resources are typically computing power, network bandwidth, and data storage.

Usage estimates may be initially based on functional requirements (which applications are required), company size, the projected number of users, the volume of key business transactions, or some other customized formula. But the real beauty of a SaaS environment is that the actual consumption of resources, including all of the above, along with data storage, can be very accurately measured in real-time. This is the ultimate ​“pay for what you use” scenario.

The type of pricing model chosen for an ERP system can have a significant impact on the overall cost of ERP implementation. Thus, the costs associated with implementation and customization should also be considered when choosing a pricing model. Some ERP providers charge additional fees for implementation, training, and customization services, and these implementation costs will vary depending on the scope and complexity of the project. Cloud-based ERP systems will have higher implementation costs than on-premise deployment.

It’s important to have a clear understanding of all the costs associated with a particular pricing model, including any hidden costs, before making a final decision. A good ERP provider will work with you to explain the implementation costs associated with various ERP pricing models and help you choose the one that’s right for your organization.

While on the surface, many ERP software pricing models can appear similar, when you look under the covers, you might find they can be quite different. User-based pricing is most common, but there may also be added fees or restrictions applied to some or all users. It is crucial to understand how users are monitored and counted. It is also essential to understand how much (or how little) of the application(s) you are authorized to use. If you are entering the SaaS world for the first time, seek to understand if and how your consumption of resources will impact your monthly or yearly cost. In comparing costs across different vendors, be aware of not only how the costs are calculated but also how they are presented, and be careful to compare apples to apples. Our ERP comparison tool helps you compare pricing and implementation costs for ERP systems that best fit your business. And be sure to check out our ERP pricing guide to become an expert on all factors that affect the price of ERP.