One of those questions that looks like it should have a one-click answer and does not. Here is exactly what Confluence Cloud can and cannot do with numbers, and how to pick between the three ways out.
Short answer. A normal Confluence table cannot add anything up: there is no formula engine behind it, and the number on the page is whatever somebody typed. A Confluence database can show a total at the bottom of a field, including Sum and Average. Neither can calculate a value per row, so nothing in Confluence Cloud gives you a column that multiplies price by quantity. You have three ways out, and the right one depends on how often the numbers change.
What Confluence actually does
It is worth separating two things that look similar on a page, because the answer is different for each.
Tables
The classic table you get from the editor is a layout element. It stores text, numbers, links and macros in cells, it merges cells, it sorts columns for the reader. It does not compute. There is no cell reference, no formula bar, nothing that recalculates when a value changes. If a total sits in the bottom row, a person put it there, and it stays wrong until a person notices.
This is not an oversight anyone forgot about. The request to add spreadsheet behaviour to Confluence tables is one of the older open items in Atlassian's public tracker, and it is still open.
Databases
Databases are the newer structured-data feature, and they do calculate, within limits. Each field can show a calculation at the bottom, and for number fields the list is genuinely useful:
| Field type | Calculations available |
|---|---|
| Number | Sum, Average, Min, Max, Count values, Count unique values, Count empty, Percent empty |
| Everything else | Count values, Count unique values, Count empty, Percent empty |
The calculation can be saved as part of a view, so the total is there for the next reader rather than something each person switches on. Worth knowing before you plan around them: databases are not available in the Atlassian Government environment.
The part that catches people out
Everything above is an aggregate: one number summarising a whole field. What most people actually want on the second day is a calculated column: line total equals price times quantity, margin equals revenue minus cost, each row computed on its own.
Confluence Cloud does not do that. Not in tables, and not in databases either. There is an open request for computed fields in databases, so this may well change, but nothing ships today, and planning a process around a feature that does not exist is how teams end up maintaining numbers by hand for a year.
So the honest summary of the platform is: totals yes, if you use databases. Per-row arithmetic no, whatever you use.
The three ways out
1. Turn the table into a database
Free, native, and the right answer when the data is genuinely a list of records: inventory, requests, contacts, anything with the same fields repeating down the page. You get the aggregates above, plus sorting and filtering that survive being reopened.
It is the wrong answer when the thing on the page is not a list. Budget breakdowns with subtotals, comparison matrices, anything with merged cells and a shape of its own does not become a database without being redesigned first.
2. Install an app that adds formulas
Several Marketplace apps bring spreadsheet behaviour into the page: calculated columns, grouping with sums per group, charts on top. If your numbers change weekly and people read them inside Confluence, this is the path that actually solves it, and it is worth the licence.
Price it for the team you will have next year, not the one you have today, because Marketplace pricing steps up by user tiers and a table app is billed for every user on the site, not just the people who use it.
3. Take the numbers to a spreadsheet
Unfashionable and often correct. If the calculation happens once a quarter, or the result belongs in a report that lives in Excel anyway, moving the data out is cheaper than teaching the wiki to do arithmetic.
The catch is how the data gets there. Copying a table by hand looks fine until merged cells are involved: the copy keeps the visual shape, a cell spanning two columns pushes later values sideways, and the totals come out wrong in a way nobody notices, because the number still looks like a number.
How long the manual way takes
Say a quarterly report pulls numbers from eleven tables across a space. Copying one table, fixing the columns that slid, and checking the total takes about four minutes when nothing is merged and closer to ten when something is. Call it an hour and a half, once a quarter, plus the time spent later finding out why the finance figure disagrees with the wiki.
An hour and a half four times a year is not a crisis. It is, however, six hours of work whose only output is retyping numbers that already exist, and it is the kind of task that quietly grows as the space does.
Picking between them
If the data is a list of records and you need a total at the bottom, use a database. It is free and it is native. If people need live per-row formulas inside the page, buy an app, because that is a real gap and no amount of cleverness closes it. If the numbers leave Confluence anyway and end up in a spreadsheet, get them out cleanly and do the arithmetic where arithmetic belongs.
If your case is simpler than all of this, one table with five rows and a total you retype twice a year, retype it. That is a perfectly good answer and it costs nothing.
Disclosure: I build Confluence apps. One of ours covers only the third option: it takes one table, a page, or every table in a space into Excel or CSV, and keeps the columns aligned when cells are merged, which is exactly where copying by hand goes wrong. It does not add formulas to your pages, and if that is what you need, one of the table apps above is the honest recommendation instead. There is a browser demo that shows the merged-cell problem on a real budget table, no install needed.
Top comments (1)
I really appreciate the practical honesty of this piece. Instead of pretending Confluence tables are spreadsheets, you draw a clear line between what the platform actually supports and what users often assume it supports.
The distinction between aggregates and calculated columns is especially useful. “Totals yes, if you use databases. Per-row arithmetic no” is probably the most important takeaway because it prevents people from choosing a database expecting it to solve a completely different problem.
A few highlights stood out to me:
I also appreciate the final recommendation to simply retype a small total when it only happens twice a year. There's something refreshingly sensible about recognizing that not every problem needs automation, an app, or a new data architecture.
The broader lesson here is that choosing the right tool isn't about forcing every workflow into the platform you already use. Sometimes the best productivity decision is understanding exactly where that platform's boundary is—and crossing it deliberately when the work requires something else.
Clear, pragmatic, and genuinely useful for anyone who has ever stared at a Confluence table wondering why it can't behave like a spreadsheet.