Summary

  • Asana reported 817 customers generating more than US$100,000 in annualized GAAP revenue at 30 April 2026, up from 728 a year earlier but unchanged from the 817 reported at 31 January. The total is a point-in-time count, not a movement ledger.
  • The company defines a customer as a distinct account that may be a team, company, institution, organization or distinct business unit. It explicitly says one organization may have multiple customers. The 817 therefore cannot be treated as a disclosed count of unique ultimate companies.
  • Fiscal-Q1 revenue rose 9.5% to US$205.095 million and Core customers supplied about 76% of revenue, while the reported net-retention rate for the US$100,000 tier was 96%. Those measures answer different questions and do not reveal account-to-parent concentration.

The noun is carrying too much weight

Customer counts feel more concrete than revenue. A dollar can move with price, currency, usage or contract timing; a customer appears to be a person-sized unit. In enterprise software, that intuition is unreliable. The unit exists because the vendor defines it.

Asana's fiscal-Q1 filing is unusually direct. It calls a customer a distinct account and says that account could be a team, a company, an educational or government institution, an organization, or a distinct business unit of a company. It then adds the sentence that matters: one organization may have multiple customers.

That definition is commercially reasonable. A multinational group may buy Asana separately in marketing, product development and a regional subsidiary. The budgets may be different, the administrators may not share an account and the renewal dates may not line up. Counting each account can reflect how the product is actually sold and managed.

It also means the count is not a corporate census. Three accounts inside one parent do not become three ultimate companies because the table calls each one a customer. Conversely, putting all three under one parent would not prove that their buying decisions are coordinated. The filing supplies the commercial unit and leaves the ownership hierarchy undisclosed.

What 817 proves

As of 30 April 2026, Asana had 817 customers spending over US$100,000 on an annualized basis, compared with 728 a year earlier. That is an increase of 89 accounts, or 12.2% by calculation from the disclosed totals. It is meaningful evidence that Asana serves a sizeable population of high-value accounts.

The threshold has its own perimeter. Asana defines these customers through annualized GAAP revenue in a given quarter, inclusive of discounts. It does not call the number annual recurring revenue, bookings, billings, cash receipts or total contract value. An account can qualify because quarterly recognized revenue annualizes above the threshold. How far above it sits is not disclosed.

The figure also does not provide a revenue floor that can safely be calculated as 817 multiplied by US$100,000. The threshold is a classification rule, not a promise that every account contributes exactly the minimum for a full future year. Nor can the count be divided into Asana's total revenue to recover an average account size. The distribution above the threshold is missing.

Still, the number has real content. It says Asana's commercial system contained 817 separately counted relationships large enough to clear a demanding revenue line. Procurement, deployment and support must operate at that scale. What it does not say is whether those relationships represent 817 independent parent companies, 700 parents with some duplicate business units, or another structure altogether.

A flat total can hide a busy quarter

The year-on-year growth headline obscures a second comparison. Asana reported the same 817 large customers at 31 January 2026 and 30 April 2026. Sequentially, the published total did not change.

That is not evidence that nobody entered or left. Ten accounts could have crossed above US$100,000 while ten others fell below. A parent could have consolidated two business-unit accounts into one. A company could have split one account by geography. An acquisition could have joined two customers under one corporate roof without changing how Asana bills them. The ending count cannot distinguish any of these paths.

This is why a stock number needs a flow ledger. The useful bridge would begin with the opening count and show new paying accounts, existing accounts crossing upward, accounts contracting below the threshold, churn, consolidations, splits and the closing count. It need not name a single customer. Aggregate movements would be enough to show whether breadth is being replenished, compounded or reorganized.

The unchanged sequential total is therefore a monitoring signal, not a verdict. It asks whether the 12% annual expansion is still active underneath the rounded point estimate, or whether the company is now replacing departures and contractions just fast enough to keep the displayed number level.

Retention answers a different question

Asana reported dollar-based net retention of 96% overall, 97% for Core customers and 96% for customers spending over US$100,000. Each was one percentage point above the comparable April 2025 figure. Management said NRR improved for a fourth consecutive quarter.

The public metric is not a current-quarter churn gauge. It is the simple arithmetic average of four quarterly net-retention ratios ending with the latest quarter. Each underlying ratio compares revenue from the same set of customers with revenue from that set in the comparable prior-year quarter. Current revenue includes upsells, is net of contraction and attrition, and excludes revenue from customers that are new in the current period.

A reported 96% therefore says that the published average of same-customer revenue ratios remains below the expansion line. It does not say the latest quarter alone declined by 4%, and the whole-number presentation cannot show the size of management's claimed sequential improvement.

More importantly, NRR does not repair the identity problem. If one corporate parent owns several separately counted accounts, a same-customer comparison can preserve those account units without revealing the common parent. If a new business unit becomes a new customer, its revenue is excluded from the current-period new-customer portion of the ratio even though it may belong to an organization Asana already serves elsewhere.

Customer count and NRR can therefore move in different directions without contradiction. One measures how many accounts clear a threshold at a date. The other measures averaged revenue change for prior-period account sets. Neither discloses unique ultimate organizations.

The wider quarter was stronger than the denominator alone

Asana's fiscal-Q1 revenue rose US$17.828 million to US$205.095 million, a 9.5% increase. The filing attributes the increase primarily to new paying customers and a continued mix shift toward the higher-priced Enterprise+ plan. Core customers—those with at least US$5,000 in annualized GAAP revenue—rose from 24,297 to 26,103 year on year and contributed approximately 76% of quarterly revenue.

The Core count also rose by 175 from the 25,928 reported in January. That sequential movement is modest, but positive. Revenue from Core customers grew 10% year on year, according to the results release.

These facts provide counterweight to an overly bearish reading of 96% retention. Asana added revenue, increased its Core population and shifted mix toward a higher-priced plan. A company can grow while an installed cohort contracts if new accounts and upward threshold crossings more than replace the loss. That can be a healthy acquisition engine, an expensive treadmill or a transition between the two. The disclosed totals do not decide which.

The answer depends on customer acquisition cost, renewal quality, discounting, selling effort and whether newly admitted accounts later expand. The filing gives the output totals but not the parent-level path. Calling every account a separate company would make that acquisition engine look more diversified than the evidence permits.

AI consumption widens the accounting boundary

Asana now describes its core work-management product as tiered and seat based, while AI Teammates and AI Studio operate on a consumption basis. That distinction matters because account value can rise through more seats, a higher plan, additional consumption or some combination.

Management said customers are increasingly using the AI products and tied improving fundamentals to AI adoption, customer expansion and efficiency. The filing does not disclose AI Studio or AI Teammates revenue, usage, customer count, gross margin or retention separately. It is therefore impossible to assign the 89-account year-on-year increase, the Enterprise+ mix shift or the one-point NRR improvement to AI.

A business-unit account may be a natural entry point for consumption software. One department can adopt an agentic workflow before a parent procurement office standardizes the product. That is a plausible commercial route, not a disclosed fact about Asana's 817 accounts. The missing parent hierarchy makes it harder to tell whether AI is opening new enterprises, spreading through existing parents or merely adding a new charge inside already counted accounts.

The right proof would connect product consumption to an account and then, in aggregate, connect accounts to unique parents. Without that bridge, product momentum and enterprise breadth remain parallel narratives.

A privacy-safe bridge is possible

Asana does not need to publish customer names or contract terms. It could disclose the number of unique ultimate parent organizations represented within each revenue tier, the distribution of accounts per parent, and the share of tier revenue concentrated in parents with more than one account. Bands would be enough: one account, two accounts, three to five, and more than five.

A second table could reconcile the large-customer count across the quarter. A third could show NRR at account level and, if operationally feasible, at consolidated parent level. The two rates would not need to match. Their difference would be informative because it would show whether account splits, cross-business-unit selling or parent consolidation materially changes the picture.

There are legitimate complications. Parent hierarchies change. Franchise, joint-venture and public-sector structures do not always have one obvious controller. Separate business units may make genuinely independent decisions. A vendor should not collapse them casually. The answer is not a false master record; it is a disclosed methodology, uncertainty band and correction policy.

The judgment

Asana's 817 is neither empty nor self-explanatory. It is a valid count under a stated commercial definition. It establishes that hundreds of substantial accounts use the platform. It does not establish hundreds of unrelated corporate groups, independent budgets or uncorrelated renewal decisions.

That difference matters more as Asana sells across departments and adds consumption-priced AI products. Success inside one parent can produce several accounts and real revenue. It can also create concentration that a surface count hides. Markets should not choose between celebrating the number and dismissing it. They should preserve its unit.

The next proof is not a larger integer alone. It is a bridge showing how many commercial accounts belong to how many ultimate organizations, how those accounts entered or left the threshold, and whether revenue from existing parents compounds after new-account replenishment is removed. Until then, 817 means 817 Asana-defined customers—nothing less, and not necessarily 817 companies.

Sources