Qlik NPrinting Pricing: NPrinting License Cost and the CALs It Quietly Consumes

Qlik has never published a list price for NPrinting, and it still does not. There is no rate card, no per-report tier and no self-serve checkout, so every NPrinting budget starts as a guess and ends as a sales conversation. What you can pin down before that conversation are the costs NPrinting imposes on licenses you already own, and those are large enough to change the shape of a quote.

The short version: NPrinting is licensed through the Qlik NPrinting Server, and each NPrinting Engine consumes one production QlikView Named User Client Access License for its own service account. Run three Engines for throughput and three production CALs are gone before a single report reaches a human being. Every quote in this article comes from Qlik's own documentation, read on 4 September 2026.

How much does Qlik NPrinting cost?

Nobody outside Qlik can answer that with a number, which is why the top of the search results for this question is a row of Qlik Community threads where people ask it and nobody answers. Licensing runs through the NPrinting Server. Qlik NPrinting Designer and Qlik NPrinting Engine do not activate separately, because they inherit their entitlement from that server license. So the only question that has a dollar answer is what your NPrinting Server entitlement covers, and that comes from your account team.

That leaves you negotiating without a floor price, which is a weak position. The way to fix it is to arrive already knowing the two variables that drive the size of the deployment: how many Engines you need, and what each Engine costs you in QlikView licensing. The second one is documented publicly, and it is the part almost nobody prices in.

The hidden cost: every NPrinting Engine holds a production CAL

Qlik's NPrinting help states the requirement plainly. Connecting NPrinting to QlikView needs, in Qlik's words, "A named user Client Access License (CAL) that is manually assigned to the Qlik NPrinting Engine service user active directory account". That CAL is not shared with a person. It belongs to a Windows service account that exists only so the reporting engine can open QlikView documents.

So the first report you generate has already cost you one Named User CAL, permanently, for a user who never logs in. If you sized your QlikView estate by counting humans, your count is short by one per Engine.

Can I use a test QlikView CAL for NPrinting?

No, and Qlik closes that door explicitly: "A valid named user CAL from a production QlikView Server must be used for the Qlik NPrinting Engine service user account. If the CAL from a test QlikView Server is used, it will cause personal edition to appear in the QlikView Desktop title bar." Personal edition cannot open documents created elsewhere, so the connection fails and the failure looks like a broken install rather than a licensing choice.

This is worth knowing before you design the deployment, because using a spare test license for a robot account is exactly the sensible-looking economy an administrator would try first. It costs a production CAL whether you like it or not.

How many CALs does Qlik NPrinting use?

One per Engine, and Qlik is unambiguous about it: "In the case of a multiple Qlik NPrinting Engine installation, you must set a different Windows user and a different QlikView Desktop Named CAL license for each Qlik NPrinting Engine." Multiple Engines are the standard answer to slow report generation, so the fix for a throughput problem is also a licensing purchase.

The last row is the one that catches people. A test or staging NPrinting environment still needs a CAL from a production QlikView Server, so a non-production deployment consumes a production license.

What happens if two NPrinting Engines share a CAL?

The failure is loud and it hits users who have nothing to do with reporting. Qlik documents the behavior directly: "If you use the same QlikView Desktop Named CAL license two or more times, the QlikView Server will disconnect all QlikView Desktops but one." The second Engine does not quietly refuse to start. The server starts dropping QlikView Desktop sessions, which is an outage for analysts who were working normally.

That makes CAL reuse the single worst economy available here. It looks like it saves a license, it is hard to diagnose because the symptom appears on unrelated machines, and it is why the per-Engine CAL count belongs in the deployment plan rather than in a footnote.

Which Qlik NPrinting versions are still supported?

Two of them, and the window is tighter than most teams assume. Qlik's NPrinting product lifecycle page gives every release a 24 month support life. Here is where that leaves you in September 2026.

Two things follow from that table. First, an NPrinting deployment carries a mandatory upgrade roughly every two years, and upgrade labor is a recurring cost that belongs in the total rather than in a one-off implementation line. Second, if you are on February 2024 you are already unsupported, which is a fact worth checking before you negotiate anything, because it weakens your position and it is easy to be wrong about.

What actually drives an NPrinting quote

Bring four numbers to the conversation and you can size the deal yourself instead of being sized by it.

• Engine count. Driven by report volume and the window you have to generate in. This sets both the NPrinting Server entitlement and the CAL count.
• Source platform. QlikView sources carry the per-Engine CAL requirement. Qlik Sense sources do not: Qlik documents a RootAdmin privilege and Qlik Sense certificates installed on each Engine machine instead.
• Existing CAL headroom. Whether you have spare production Named User CALs or have to buy them. Since Qlik discontinued new stand-alone QlikView licensing, existing sites buy additional CALs against an entitlement and genuinely new deployments cannot go this route at all.
• Server footprint. Qlik's guidance is a dedicated service account per Engine, and in practice a dedicated Windows server to go with it.

That last one is a real infrastructure line, not a rounding error. Each Engine wants its own machine, its own domain service account and its own patch cycle, and somebody has to keep those boxes current for the two years until the next mandatory upgrade. Teams that have moved the rest of their stack onto managed server provisioning and zero-downtime deploys often find the NPrinting tier is the last set of hand-maintained Windows servers they own, which is worth counting honestly when you compare the total against a cloud reporting option.

How this compares to the rest of your Qlik bill

NPrinting sits on top of a license structure that is already unusual. QlikView is priced on Client Access Licenses of four different types, and Qlik has stopped selling new stand-alone QlikView licenses altogether, which is covered in detail in our breakdown of QlikView pricing and CAL licensing. The current cloud product works on a completely different basis: capacity rather than seats, with three published prices and no per-user charge above the entry tier, which we work through on the Qlik Sense pricing page.

The practical consequence for an NPrinting budget is that it may be the last thing you buy on the old model. If your QlikView estate cannot grow through new license purchases, and your reporting tier needs a production CAL per Engine to scale, then report throughput is capped by an entitlement you can no longer extend. That is a strategic constraint rather than a line item, and it is the reason the NPrinting question so often turns into a platform question. If you are already weighing that move, Qlik vs Power BI compares where each platform puts its costs.

If the job is really just getting numbers to people

We build an AI data analyst, so treat this section accordingly. A lot of NPrinting deployments exist to answer a modest question: a group of people need specific figures on a schedule, and somebody built a pixel-perfect report to deliver them. That is a legitimate use case, and where the output genuinely has to be a formatted, branded document going to hundreds of recipients, NPrinting does a job that a query tool does not.

Where it gets expensive is when the reports are mostly a workaround for the fact that people cannot ask questions themselves. Then you are paying for a server tier, a CAL per Engine, a two-year upgrade cycle and a report backlog, all to deliver numbers somebody could have asked for directly. Agentsql connects read-only to the Postgres, MySQL, Snowflake or BigQuery database you already run, turns a plain-English question into SQL, runs it, and shows the SQL so an analyst can check the logic. There is no service account holding a license and no scheduled job to maintain.

The honest test is what happens when someone wants a number that is not on the report. If the answer is a ticket and a wait, the reporting tier is solving distribution while leaving the actual bottleneck in place. Our pricing is one flat monthly figure with no per-Engine licensing behind it.