A

This is where money leaves the building quietly.

The factory runs three shifts. On any given shift, maybe 20 people are actively in the ERP: the procurement officer checking purchase orders, the production planner updating work orders, the accounting team processing goods receipts, a couple of shift leads logging output. That's it. The other 180 are on the floor, running machines, doing work that never touches the software.

Per-user pricing ignores that. It charges as if all 200 employees are logged in simultaneously, which has never happened and never will.

This post is about why that model is wrong, how to spot the fine print before you sign, and what to ask for instead.

How Per-User Pricing Actually Works

ERP vendors price by "user" but almost none of them define "user" the same way. This is not an accident.

Named users are the worst model. You pay a license for each named individual in the system, whether they logged in last week or haven't touched the software in six months. SAP Business One uses named-user pricing. A lot of the enterprise ERP market does too. You buy 50 named-user licenses, those 50 seats are yours whether they're used at 2am or not at all.

Concurrent users are better. You pay for the maximum number of people who can be in the system at the same time. A 20-concurrent-user license lets 20 people log in simultaneously. If a 21st tries, they wait. For factories running shift-based operations, this maps much closer to reality.

The industry mostly sells named users and calls them simply "users." Factories mostly assume concurrent. The gap between those two assumptions is real, and profitable for vendors.

The Three-Shift Math Problem

Imagine a mid-size electronics assembly factory in MM2100 with 200 employees running three 8-hour shifts. Count who actually uses the ERP and when.

Procurement: one person, day shift. Production planning: two people, day shift. Accounting: three people, day shift. Warehouse receiving: two people per shift, six total but never more than two at once. Shift supervisors: one per shift, logging daily output summaries. That's roughly 15 people across all shifts, with a peak of maybe 10 logged in simultaneously during morning handover.

The vendor quotes 200 seats.

The delta between 10 concurrent real users and 200 named seats is where the profit is. At Rp 200,000 per user per month, that gap costs Rp 38,000,000 every month. Rp 456,000,000 per year. For software that 180 of those named users will never open.

What Vendors Don't Put in the Demo

Every ERP demo focuses on features. The interface. The dashboard. How easy it is to approve a purchase order on mobile. Nobody demos the user licensing model until the proposal stage, by which point the team is already excited about the software.

The questions that matter are the ones nobody asks in the demo room.

Ask the vendor to define "user." Named or concurrent? Ask what happens when someone leaves and you want to transfer their license to a new hire. With named-user models, some vendors charge for the transfer. Ask whether view-only users who just check production status count as full users. Often they do. Ask to see the contract definition, not the sales deck definition. These are sometimes different documents with different language.

The Number Nobody Shows You

Here's the math vendors would rather you not run.

A 200-employee factory at Rp 200,000 per user per month pays Rp 40,000,000 monthly in seat licenses. Over five years: Rp 2,400,000,000 in licensing fees alone, before the implementation cost, before the annual support contract, before any customisation.

A factory with 20 active ERP users at any given time, under concurrent pricing, pays Rp 4,000,000 per month. Five-year total: Rp 240,000,000.

The difference is Rp 2,160,000,000 for the exact same software doing the exact same work. You can run your own ERP Fee numbers through our TCO calculator to see exactly how this impacts your OpEx.

This is why the question isn't just "which ERP should we buy." It's also "how is this ERP priced, and does that model match how our factory actually operates."

What to Look For Instead

The pricing model that fits most factories is pay-once, unlimited users. Pay for the implementation. Pay for the infrastructure, whether cloud server or on-premise hardware. Then stop paying per head.

Under this model, a factory with 200 employees pays the same as a factory with 500. The Finance Director can give login access to every shift supervisor, every warehouse operator, every line lead who might ever need to check something, without calculating the marginal cost of each new user. The system grows with headcount at zero additional licensing cost.

Some ERP products are built this way. Most of the enterprise market is not, because recurring per-user revenue is how SaaS companies justify their valuations. That's fine for their shareholders. It's worth knowing when you're the one writing the check.

Before any ERP evaluation, define how many people in your factory will actively use the system, how many will occasionally look at it, and how many will never touch it. Then ask every vendor for pricing built on those numbers, not your headcount. The answers will be clarifying.

A Factory That Asked the Right Questions

Imagine a chemical manufacturer in Delta Silicon with 280 employees. Their ERP evaluation started the way most do: shortlist three vendors, watch the demos, compare features. Two vendors quoted 280 seats. The third asked how many people would actually be in the system at the same time.

The answer was 18. Procurement, production planning, accounting, warehouse, QA. A few more during month-end close.

The third vendor's quote was built around that number instead of the payroll list. The first two vendors' quotes were built around the headcount.

The gap in five-year cost was large enough that the Finance Director spent an extra two weeks doing due diligence before signing anything. That's the right outcome. That's what knowing the right question gets you.

FAQ

Q: If I buy 50 named-user licenses, can I reassign them if someone leaves?

A: Depends on the vendor contract. Some allow license transfers at no charge. Some charge a reassignment fee. Some require you to buy a new license. Read the contract before assuming anything.

Q: Can I start with fewer users and add more later?

A: Usually yes, but expansion pricing may be higher than your original deal. Volume discounts at initial purchase often don't apply to add-ons. Get the expansion pricing in writing before signing.

Q: Our factory uses shared tablets on the floor for production logging. Do those count as users?

A: Ask specifically. Some ERPs count device licenses, not person licenses. A shared tablet used by six operators across three shifts might count as one device license or six named users. The demo will not volunteer this.

Q: What's the difference between full users and light or read-only users?

A: Many ERPs have tiered user types. Full users can create and edit records. Read-only users can view. Read-only access is sometimes free, sometimes half price. If your shift supervisors only need to check production status without editing anything, ask whether a read-only license covers their use case.

Q: Is per-user pricing always worse for factories?

A: Not always. For small operations with under 15 actual users, per-user pricing can be cheaper than alternatives with large flat implementation fees. The math favours per-user at small scale and flips somewhere between 20 and 50 active users, depending on the vendor's rates.

The vendor's sales model is not aligned with your factory's operating model. That's not a criticism, just a fact about incentives. Per-user pricing grows vendor revenue as your headcount grows, which is great for them and irrelevant to the value you're actually getting.

Most factories don't figure this out until year two of a five-year contract.

The question to ask before signing anything isn't "does this ERP have the features we need." It's "how does this pricing model behave when we hire 50 more people next year."

If the answer makes the Finance Director uncomfortable, that discomfort is useful information.