Business Intelligence Software Cost

Most software categories bill you for the thing you asked for. Business intelligence bills you for the thing you did not know you needed. The licence line is real, it is quotable, and on almost every deployment worth calling a deployment it is the smallest number in the budget. A dashboard sits on modelled data, modelled data sits on a pipeline, and the pipeline sits on a person. Price the first of those and ignore the other three and your number will be wrong by a multiple rather than by a margin.

This verdict prices business intelligence the way a business actually gets billed for it. It takes apart the three licence shapes you will meet, the creator and viewer split that decides your bill more than headcount ever will, the stack of separate subscriptions underneath the dashboard, and the human cost that is the honest centrepiece of the category. It sits alongside our verdict on the true cost of business software, which takes per seat billing apart in general, and our verdict on document management software cost, which is the closest neighbour on this site for a category with meters running underneath the seat price. Put your own numbers through the true-cost calculator and the companion on this page before you shortlist anything.

What business intelligence software actually costs

Ask what BI costs and the useful answer has four parts, and the part on the pricing page is the one that varies least.

There is the licence, which is per seat, per capacity unit, per consumption unit, or some combination of all three. There is the data platform underneath, which is usually a warehouse or at least a consolidated store, and which is a separate vendor with a separate invoice. There is the tooling that moves and shapes data into that store, which is commonly two more subscriptions, one for ingestion and one for transformation. And there is the person who decides what the data means, who is either an employee, a contractor, or an existing member of staff doing it badly in the evenings.

Those four parts scale on four different things. Licences scale with how many people build versus how many people read. The warehouse scales with how much data you hold and how often you query it. Ingestion scales with rows moved. The human line scales with how messy your source systems are, which is a cost you have already incurred and are about to have quantified.

The fifth part, which appears on no invoice at all, is the reporting nobody trusts because the model was never agreed. Everything below prices these with illustrative planning figures, and the companion on this page reprices the whole stack against your own numbers as you read.

The headline: illustrative BI licence prices per seat

Start with the numbers people search for, framed as planning bands rather than quotes. Pricing in this category moves constantly, varies by vendor and region, and is frequently negotiated in ways the public page never reflects.

Viewer or consumer seats commonly land around $12 per user per month. This is read access: open a published report, filter it, subscribe to a scheduled delivery, and in some products comment on it.

Entry self-serve creator seats commonly land around $30 per user per month. One person can connect sources, build a model, and publish. Refresh frequency and dataset size are usually capped.

Standard creator or author seats commonly land around $60 per user per month. This is the working rung for a team that builds seriously: more sources, higher refresh limits, version control on content, and workspace level administration.

Governance add-ons commonly land around $18 per user per month on top, and carry row level security, audit logging, directory provisioning and data lineage.

Embedded developer seats commonly land around $85 per user per month, and sit alongside a separate embedded tier priced on applications, end customers or sessions.

Read that ladder against your own working pattern rather than against a competitor’s stack. Most organisations have far fewer genuine report builders than they assume, and far more readers than any seat count suggests.

Creator seats and viewer seats are different products

The single largest structural mistake in BI buying is treating the seat count as a headcount question. It is not. It is a workflow question, and the answer is usually lopsided.

A creator seat is a modelling environment. The person holding it connects to sources, defines relationships between tables, writes the calculations, decides what a metric means, and publishes something other people rely on. That is a specialist activity, and in most organisations it is done by a small number of people who are good at it.

A viewer seat is a reading room. The person holding it opens what was published, changes a date filter, drills into a category, exports a slice, and gets an email every Monday. That is most of your organisation.

At an illustrative $60 against $12, the creator seat costs five times the viewer seat. Getting the split wrong in either direction is expensive in different ways. Over-licensing creators wastes money on people who will never open the modelling view. Under-licensing them creates a queue at the one person who can change a report, which is how a BI project quietly dies while still being paid for.

The practical move is to list every person who will touch the system and write next to each name the single most advanced thing they will actually do in a normal month. Not the most advanced thing they could imagine doing. The list is usually shorter on the creator side than anyone expects.

The creator and viewer arithmetic that decides your bill

Here is the arithmetic, because it is the practical payload of this verdict and it is worth doing on paper before you talk to anybody.

Take a twenty five person company. Four people genuinely build reports. Twenty one people read them. On the illustrative bands, that is 4 creators at $60, which is $240 a month, plus 21 viewers at $12, which is $252 a month. Total licences: $492 a month, or $5,904 a year.

Now license the same twenty five people as creators, which is what happens when a vendor quotes a single per user price and nobody asks. That is 25 at $60, which is $1,500 a month, or $18,000 a year. The difference is $1,008 a month and $12,096 a year, on identical usage, for identical dashboards.

Express it as a blended rate and the shape gets clearer. The correct split works out at $19.68 per person per month across all twenty five people. The all-creator quote works out at $60. Blended cost is a function of your creator ratio, and nothing else: at 10 percent creators the blend is $16.80, at 16 percent it is $19.68, at 40 percent it is $31.20.

Every single creator seat you add is $60 a month and $720 a year. Ten seats misclassified upward is $7,200 a year, which is more than most small businesses spend on BI in total.

Capacity pricing and the viewer count where it wins

The second licence shape prices a block of compute and memory rather than people. You reserve a capacity unit, publish content into it, and any number of readers can open that content without a per head charge.

On the illustrative figures used throughout this verdict, a capacity tier lands around $900 a month. Divide that by the $12 viewer seat and you get the crossover: about 75 viewers. Below 75 readers, per seat licensing is cheaper and considerably simpler to administer. Above 75, capacity wins, and the gap widens every time you add a reader because the capacity charge does not move.

At 188 readers, per seat licensing would be $2,256 a month. Capacity is $900. That is a saving of $1,356 a month, or $16,272 a year, and the effective rate per reader falls to about $4.79.

Two cautions keep this honest. Creators almost always still need their own seats alongside capacity, so the capacity charge is added to the creator line rather than replacing the whole licence bill. And capacity is a performance ceiling as well as a licence: a model too large or a refresh too aggressive will saturate it, and the fix is a bigger capacity tier at a materially higher price. Ask what the next tier up costs before you commit to the first one, because that is the number that will actually arrive.

Consumption pricing and the meter that runs on refresh

The third shape charges for what you compute. Queries, refreshes and extracts consume credits, compute hours or query units, and you pay for what you burn.

Consumption pricing is genuinely fair and genuinely dangerous, for the same reason: nobody sets a refresh schedule while thinking about a meter. On an illustrative rate of $2.50 per compute credit hour, six dashboards refreshing hourly and taking 0.4 credit hours per refresh burn 6 times 24 times 30 times 0.4, which is 1,728 credit hours a month, or $4,320. That is a bigger number than the entire licence and stack bill in the twenty five person example below.

Retune the same six dashboards so that two refresh hourly and four refresh twice a day, and the arithmetic becomes 576 plus 96, which is 672 credit hours, or $1,680 a month. Same dashboards, same data, a saving of $2,640 a month and $31,680 a year, purchased entirely with a scheduling decision.

The worked totals later in this verdict assume a warehouse on a flat monthly plan rather than a consumption plan, because that is the easier shape to budget and the more common starting point for a small business. If you are on consumption, treat the refresh schedule as a line item, set a spend alert on day one, and revisit it quarterly. It is the only part of a BI bill that can multiply overnight without anyone signing anything.

Why the licence is usually the smallest line

Now the spine of this verdict. A BI tool does not produce insight from your systems. It produces charts from a model, and somebody has to build the model out of data that has been collected, moved, cleaned and reconciled first.

That chain has four links and the reporting tool is the last one. Data is generated in your operational systems. It is moved out of them into somewhere it can be queried without slowing them down. It is reshaped so that a customer record from one system and an order record from another can be joined without producing nonsense. Then, and only then, it is visualised.

Every link before the last one costs money, and none of it appears on the BI vendor’s pricing page. The warehouse is a separate subscription. The ingestion tool is a separate subscription. The transformation layer is a separate subscription or a separate person. The modelling itself is entirely human.

The result is the pattern that runs through every worked example in this verdict: the licence is a minority of the bill at every size, and the person modelling the data is the largest single line in year one. If you have ever wondered why a BI evaluation that looked affordable turned into a project that stalled, this is the reason. The tool was affordable. The prerequisite was not budgeted.

The warehouse underneath the dashboard

A data warehouse is a database designed to be queried analytically rather than to run your business. Operational systems are optimised for writing single records quickly. Analytics wants to read millions of rows at once. Doing the second thing inside the first system is how you take your order entry down at month end.

For a small business, an illustrative small warehouse lands around $250 a month for compute and storage combined, which buys enough capacity for a handful of daily refreshes across a modest data volume. That number climbs with two things: how much data you retain, and how often something queries it.

The pricing mechanism matters more than the headline. Warehouse compute is commonly billed while a compute cluster is running rather than by rows scanned, which means an idle cluster with a long auto-suspend timer is billing you for nothing. Storage is usually the cheap part. Compute is the part that surprises people, and it is driven by refresh frequency, model size, and whether your reports query the warehouse live or read from an extract.

You can skip the warehouse entirely if all your reporting comes from one system that the BI tool can read directly. That is a real option, it is common, and this verdict treats it as the correct answer for the smallest scenario rather than as a compromise.

Ingestion and ETL tooling as a separate subscription

Getting records out of your operational systems and into the warehouse is its own product category with its own pricing model, and the model is usually volume based.

Managed ingestion tools commonly price on monthly active rows, which is the count of distinct records changed or added in a billing period, rather than on total rows stored. That distinction matters: a table with ten million historical rows and forty thousand changes a month is priced on the forty thousand. It also means the bill tracks how busy your business is, in the same way a capture meter does in document management.

An illustrative small business figure is around $220 a month for a couple of million monthly active rows across a handful of connectors. Adding a third or fourth source system does not just add rows, it adds a connector that may sit on a higher plan, because connectors to accounting platforms, advertising systems and payment processors are frequently gated above the entry tier.

The alternative is writing and hosting your own extraction scripts, which is free in licence terms and expensive in maintenance terms. Somebody has to fix them the morning after a source system changes its interface, and that morning always arrives.

The transformation layer nobody budgets for

Once data lands in the warehouse it is still in the shape your source systems chose, which is a shape designed for those systems and not for you. Transformation is the work of turning it into tables that answer questions.

This is where a business decides that a customer is identified by email rather than by account number, that a cancelled order does not count as revenue, that the fiscal month ends on the last Friday, and that two records with slightly different company names are the same company. Those are business decisions written as code, and they are the actual product of a BI project.

Tooling for this layer is commonly sold as a hosted developer environment with scheduling, testing and documentation, at an illustrative $125 a month for a small team. There is a widely used free and open source path as well, which trades the subscription for hosting and setup effort.

The reason this layer is chronically unbudgeted is that it looks optional from the outside. The BI tool has a data preparation view. You can join tables in it. What you cannot do in it is make those joins reusable, testable and shared, which is what stops three reports from producing three different revenue figures. Skipping this layer is not a saving. It is a decision to rebuild the same logic in every report and to discover the inconsistencies in a meeting.

The person who models the data is the real cost

Here is the honest centrepiece, and it is the part vendors have no incentive to say clearly: the largest single line in a BI project’s first year is almost always a person.

Somebody has to look at your source systems, understand what each field means in practice rather than in the documentation, decide how entities join, define the metrics, build the model, test that the numbers reconcile against something you already trust, and then explain it to the people who will use it. None of that is automatable, because most of it is about your business rather than about data.

You buy that capability in one of three ways. A contractor or consultancy at an illustrative $110 an hour, engaged for a defined project. An employee, whose fully loaded cost is a salary question specific to your market and role level. Or an existing member of staff, which is free on the invoice and expensive everywhere else, because it is a second job done after the first one.

In the illustrative twenty five person example in this verdict, the initial modelling project runs 160 hours, which at $110 an hour is $17,600, and ongoing work runs about 8 hours a month, which is $880 a month and $10,560 a year. Across three years the human line is $49,280 against $17,712 of licences. It is close to three times the software.

What an initial modelling project actually involves

The 160 hour figure is not a guess pulled from nowhere, it is a shape, and it is worth breaking it into pieces so you can size your own version against it honestly.

There is discovery, which is sitting with the people who ask the questions and finding out what they actually want to know, as opposed to what they say they want on a dashboard. There is source investigation, which is opening each system and finding out what its fields really contain, including the free text field where somebody has been recording something important for three years.

There is the pipeline build, which is connecting sources and getting data landing reliably on a schedule. There is the modelling itself, which is the joins, the grain, the date logic and the metric definitions. There is reconciliation, which is the unglamorous and non-negotiable work of proving the new revenue number matches the number the finance function already believes.

Then there is the report build, which is the only part anybody pictures when they imagine a BI project, and it is a small fraction of the total. And there is handover, which is documentation plus the training that decides whether anyone opens the thing.

Halve those hours if you have one clean source and no joins. Double them if your data has never been reconciled, if two systems disagree about who a customer is, or if nobody can currently say what your best selling product was last quarter.

Ongoing maintenance is not optional

A model is not a deliverable, it is a living thing, and the maintenance line is the one most often left out of a business case entirely.

Source systems change. A field gets renamed, a new product category appears, a payment processor changes how it reports fees, somebody starts using a status value that did not exist when the model was built. Every one of those breaks something or, worse, silently changes a number without breaking anything.

The business changes too. A new revenue stream needs a definition. A reorganisation changes how you want to group results. A question that mattered last year stops mattering and a new one takes its place.

An illustrative 8 hours a month at $110 covers keeping the pipeline running, fixing what breaks, and absorbing a modest stream of change requests. It does not cover a significant new subject area, which is a project of its own. Businesses that budget zero for this line do not avoid the cost. They pay it in reports that quietly go stale, and then in a rebuild eighteen months later.

Why BI projects stall, and what the stall costs

The characteristic BI failure is not a cancelled contract. It is a live subscription attached to dashboards nobody opens, and it happens for a predictable reason.

The tool is bought on the strength of a demo that used clean sample data. Real data arrives and it is not clean. The person who was going to model it has a day job. The first dashboards get built quickly on whatever data is easy to reach, which means they are built on a single system rather than on the join that would have made them useful. Somebody spots a number that disagrees with the finance figure, trust evaporates, and usage falls to the two people who built it.

The cost of that stall is not zero, it is the whole licence bill plus the whole stack bill, running against no benefit. In the twenty five person example, that is $492 a month in seats and $595 a month in stack subscriptions, which is $1,087 a month and $13,044 a year of pure carry.

The pattern is avoidable, and the avoidance is a sequencing decision rather than a purchasing one. Get one number right, end to end, and get it agreed by the person who already owns that number. Then build outward. Our manual on running a software trial makes the same argument about evaluations generally, and it applies with particular force here.

Embedded analytics is a different licence class

If you want to show dashboards to your own customers inside your own product, you have left internal BI and entered a different commercial arrangement, and the price reflects that.

Internal licensing prices access for your staff. Embedded licensing prices your right to redistribute the vendor’s software as part of something you sell. The vendor is pricing against the value your product captures rather than against your headcount, which is why the units change: per application, per end customer, per session, per dedicated capacity, and developer seats above the ordinary creator rate.

On the illustrative figures here, an embedded tier lands around $1,400 a month plus embedded developer seats around $85, so two developers make it about $1,570 a month. Compare that with $900 a month of capacity serving 188 internal readers and the premium is obvious.

The terms matter as much as the rate. Embedded contracts commonly govern how much you may rebrand, whether the vendor’s name must appear, how many end users may be served before the tier steps up, and what happens if your customer count grows quickly. Ask specifically what triggers the next tier and what the next tier costs, because a successful product quarter should not produce an unbudgeted licensing event.

Governance and row level security as a tier gate

Row level security is the rule that says a regional manager sees their region and not the others, from the same report, without a second copy of it. It sounds like a feature and it behaves like a gate.

In most products, row level security, single sign on, directory provisioning, audit logging and data lineage sit either on the top licence rung or in a governance add-on priced per user. At an illustrative $18 a user per month, that is $450 a month and $5,400 a year across twenty five people, which is close to what the licences cost in the first place. Those figures sit outside the worked totals below, which assume no governance add-on.

The mistake worth avoiding is buying the tier for a requirement you have not written down. The right sequence is to decide, in a sentence, who must not see what, and why. If the answer is that salary data must not be visible to the wider team, that is a real requirement and it decides your tier. If the answer is that it would be tidier, that is a preference and it costs $5,400 a year.

The opposite mistake is worse and more common: solving the problem by building a separate report per audience. That works until there are eleven of them and one gets edited.

Connectors, refresh limits and the small print that becomes a bill

Two pieces of small print turn into money more often than anything else on a BI pricing page, and both are easy to check before you sign.

Connector coverage is the first. Every product lists an impressive number of connectors, and the list is not the question. The question is whether the connector to the specific system you depend on is on your plan, whether it supports the objects you need rather than just the basic ones, and whether it is a native connector or a generic interface that somebody will have to configure. A generic connector is a maintenance commitment wearing a checkbox.

Refresh frequency is the second. Entry plans commonly cap scheduled refreshes at a small number per day, and the cap is usually where an entry plan becomes an upgrade. If your operations team needs numbers that reflect this morning, a daily overnight refresh is not a minor inconvenience, it is a mismatch. Establish the cap on each plan and match it to the actual decision cadence of the people using the reports, not to an aspiration.

Both of these are worth confirming in writing rather than from a comparison table, because both change between releases and both are exactly the kind of detail a sales conversation glosses over pleasantly.

Buying BI before you have one clean source

There is a version of this purchase that goes badly regardless of budget, and it is buying analytics as a way of avoiding a data problem.

If your customer list lives in three places and disagrees with itself, a dashboard will render the disagreement faster and in colour. If your product categories were never standardised, a chart will group them wrongly with total confidence. Reporting is an amplifier, and what it amplifies is whatever is already there.

The honest sequence is to fix the identifying fields first. Decide what identifies a customer, a product and an order. Get the source systems to agree on those, or accept that the transformation layer will have to reconcile them and budget the hours for it. Our manual on migrating to new software covers the same reconciliation problem from the other direction, and the work is the same work.

None of this means waiting for perfect data, which never arrives. It means picking one subject area, getting it genuinely right, and reporting on that alone until it is trusted. A single reliable number beats a wall of unreliable ones, and it costs a fraction as much to produce.

Users who need numbers but not a seat

Before you count seats, count the people who could be served without one, because this is one of the few places in BI with genuine pricing leverage.

Scheduled delivery is the first lever. A person who needs one report every Monday morning may be adequately served by an emailed export, and in many products a subscription recipient does not require a full viewer seat. Confirm that, because it varies and it is worth real money at scale.

Publish to web or link sharing is the second, for genuinely non-sensitive content. Embedding a small number of summary charts in an internal wiki can serve a wide audience cheaply. It also has no access control worth the name, so it is right for aggregate figures and wrong for anything with a customer name in it.

The third lever is the definition of a billable user itself. Ask whether a person who only receives an alert counts. Ask whether an external accountant or board member counts. Ask what happens to a seat when somebody leaves and whether it can be reassigned mid-term. Those answers change the contract more than the discount conversation will, and our manual on negotiating SaaS pricing covers the rest of that conversation.

The free tier is real, and it has one hard edge

Free and near free BI tiers are not a trap and they are not a demo. For a specific and reasonably common situation they are the correct answer, and this verdict will say so plainly.

That situation is one clean data source, one person building, and a small number of readers. If your sales, orders and customers all live in one platform, and that platform can be read directly, a free or entry tier will give you a real modelling environment, real charts, and something you can share. The whole stack below the licence disappears, because there is nothing to join and nowhere for it to land. In the smallest worked example below, this shape costs $7,664 across three years and most of that is one person’s time.

The edge is consistent across products and it is sharp. Free tiers commonly restrict scheduled refresh to manual or infrequent, cap dataset or row size, exclude row level security, exclude single sign on, and treat sharing as a link rather than as managed access. Several of those you can live with. The one you cannot is the moment you need to join a second system, because that is when you need somewhere for both to live, and free tiers are not where that happens.

Our verdict on free versus paid CRM tiers makes a similar argument in a different category, and the underlying principle is the same: a free tier is a real product with a defined edge, and the only mistake is not knowing where the edge is.

Training and the dashboard nobody opens

A licence bought and not used is the most expensive form of software there is, and BI has a higher rate of it than most categories, because reading a dashboard well is a skill and nobody is taught it.

The failure is quiet. People open the report once, cannot find the filter that matters to them, do not know whether the figure is this month to date or last complete month, are unsure whether it includes tax, and stop coming back. They then ask a person for a number, which is exactly the workflow the tool was bought to replace.

Budget the training and budget the definitions. A one page description of what each metric means, what it includes and excludes, and when it refreshes, is worth more than a feature. So is a short session with each team that uses their own numbers rather than a generic tour.

There is a cost test here worth applying. On the illustrative bands, a viewer seat is $144 a year. If a person opens the report twice and stops, you have not lost $144, you have lost the reason you built the report. Adoption is not a soft measure in this category, it is the entire return, and it is bought with hours rather than with licence tiers.

A worked three year total at three business sizes

Illustrative planning figures throughout, on the bands above: viewers at $12, entry creators at $30, standard creators at $60, capacity at $900 a month, warehouse at $250 a month, ingestion at $220, transformation at $125, and analyst work at $110 an hour. No governance add-on and no consumption based warehouse in any of the three.

A three person consultancy, one clean source. One entry creator at $30 and two viewers at $12 is $54 a month, or $1,944 across three years. No warehouse, no ingestion tool, no transformation layer, because there is nothing to join. Setup runs 16 hours at $110, which is $1,760, and ongoing work runs about an hour a month, which is $110 a month and $3,960 over three years. Year one is $3,728, years two and three are $1,968 each. Three year total: $7,664, or about $70.96 per person per month. Licences are about 25 percent of it.

A twenty five person company joining two systems. Four standard creators at $60 is $240 a month and twenty one viewers at $12 is $252, so $492 a month and $17,712 across three years. Warehouse $250, ingestion $220 and transformation $125 make $595 a month and $21,420 over three years. Setup runs 160 hours at $110, which is $17,600, and ongoing work runs 8 hours a month, which is $880 a month and $31,680 over three years. Year one is $41,204, years two and three are $23,604 each. Three year total: $88,412, or about $98.24 per person per month. Licences are about 20 percent.

A 200 person company with embedded dashboards. Twelve creators at $60 is $720 a month, capacity for 188 internal readers is $900, an embedded tier is $1,400 and two embedded developer seats at $85 are $170, so $3,190 a month and $114,840 across three years. A larger warehouse at $2,400 a month is $86,400, ingestion at $950 is $34,200, transformation at $400 is $14,400. Initial modelling runs 400 hours at $110, which is $44,000, and an analytics engineer at an illustrative fully loaded $8,500 a month is $306,000 over three years. Three year total: $599,840, or about $83.31 per person per month. Licences are about 19 percent.

Notice what does not drive the spread. Per person per month, the twenty five person company costs more than the three person consultancy and more than the 200 person company, which is not what headcount would predict. It is driven by how many systems have to be reconciled and by how much human modelling that takes.

Signs your BI spend has drifted

Five signatures recur, and four of them are about people rather than about the tool.

Creator seats outnumber people who have published this quarter. Pull the list of content authors and compare it with the licence list. On an illustrative $60 seat, four dormant creator seats are $2,880 a year.

Viewer seats exceed people who logged in this month. The same test on the cheaper seat, which matters at scale rather than in absolute terms. Above about 75 viewers, the question stops being seat hygiene and becomes whether capacity pricing is now cheaper.

Warehouse compute has grown without the data growing. That is usually a refresh schedule, a query hitting live rather than reading an extract, or a compute cluster that never suspends.

The same metric appears with two values in two reports. That is a missing transformation layer showing up as a trust problem, and it will cost more to fix later.

Nobody has changed a report definition in six months. Either the business has not changed, which is unlikely, or the reports have stopped tracking it, which means you are paying for a snapshot of last year’s questions.

How to trial BI on your own data, not on the demo

The demo used clean sample data with the joins already built. That is not a criticism of the vendor, it is what a demo is. It also tells you nothing about the only question that matters.

Run the trial on your worst realistic case rather than your best. Pick two systems that have to be joined, take a real extract of each, and try to produce one number that you already know the correct answer to. Revenue for a completed month is ideal, because finance can confirm it in a sentence.

Time the whole thing and write down where the hours went. If it took eleven hours and eight of them were spent reconciling customer records, you have learned that your project is a data reconciliation project with a reporting tool attached, which is the most valuable finding an evaluation can produce.

Also test the boring things. Schedule a refresh and confirm it ran overnight. Add a colleague as a viewer and watch them find the report without help. Export to a spreadsheet and check whether that action requires the more expensive seat. Then delete the workspace and check what the export actually contains, because a BI tool holding your only copy of your modelling logic is a risk worth pricing.

What to ask a BI vendor before you sign

Take these in writing, because every one of them has moved a real bill.

What exact actions require a creator seat rather than a viewer seat? Ask specifically about export, personal copies, alerts and ad hoc queries.

Do subscription recipients and alert recipients require a licence? And do external parties such as an accountant or a board member?

What is the capacity tier price, what is the tier above it, and what happens when we saturate the first one?

If pricing is consumption based, what is the unit, what is the rate, and can we set a hard spend cap rather than an alert?

Which connectors we depend on are on the plan we are quoting, and are they native or generic?

What is the scheduled refresh cap on each rung, and is it per dataset or per tenant?

Is row level security on this plan, or is it an add-on, and at what per user rate?

What is the annual prepay discount, the renewal uplift and the notice period? Renewal uplift is where a good first year quote gets recovered.

What do we get out if we leave? Reports, models and transformation logic, in what format, and can we read them without the product.

The bottom line

Business intelligence is the category where the pricing page is least informative, and the reason is structural rather than dishonest. The licence is a real cost and a knowable one: an illustrative $12 for a viewer, $30 for an entry creator, $60 for a standard creator, $18 a user for governance, $85 for an embedded developer, or capacity at around $900 a month once you pass about 75 readers. Get the creator and viewer split right and you will halve or better a quote that came in at a single blended per user rate.

But the licence is a minority of the bill at every size in this verdict, at 25 percent, 20 percent and 19 percent of three year totals. What sits underneath is a warehouse, an ingestion tool and a transformation layer, roughly $595 a month for a small business joining two systems, and above all a person who decides what the data means. In the twenty five person example, that person costs nearly three times the software.

So budget in that order. Ask how many systems must be reconciled before you ask what a seat costs. If the answer is one, and the source is clean, buy the cheapest thing that works and spend the difference on nothing at all. If the answer is two or more, price the pipeline and the hours honestly, because that is the project, and the dashboard is the easy part at the end of it.

Run your own creator and viewer counts through the companion above and the true-cost calculator before you shortlist, and read our verdict on CRM cost and our verdict on accounting software cost if the systems you are about to join are the ones on this site we have already priced.

VetLoft is paid for by its readers rather than by the vendors it writes about, and this verdict is published on that basis: educational material only, and not procurement, data engineering, security or accounting advice for your organisation. Every seat rate, capacity charge, consumption rate, warehouse figure, hourly rate and multi year total on this page is an illustrative planning number chosen to show how the layers in this category stack up, not a quotation from any vendor, contractor or employer, and none of them should be read as what you will be charged. Licensing shapes in business intelligence change more often than in most categories, definitions of a billable user differ between products and between releases of the same product, and a seat boundary that holds today may move at your next renewal. Data protection obligations, access control requirements and records duties vary by industry and jurisdiction and are not addressed here; establish your own position with a qualified professional before connecting a system that holds personal or regulated data. Confirm seat definitions, refresh caps, connector coverage, capacity thresholds, embedded terms, export rights and renewal pricing directly with each vendor in writing before you commit.