Summary

  • GitLab said its Q1 FY27 paid Consumption Run Rate would have been closer to US$15 million after excluding certain one-time credit incentives, rather than the “nearly US$20 million” discussed on 2 June.
  • CRR exceeded US$20 million by 30 June, but the later perimeter included Flex, a buying programme made available after the earnings call. GitLab supplied no constant-definition bridge between the observations.
  • GitLab calls CRR a new internal early signal that is not material to current financial performance and whose methodology will evolve. It is not identified as revenue, ARR, RPO, bookings, deferred revenue or cash.

The series changed before it became a series

On 8 July, GitLab furnished investors with an unusually useful correction to an unusually young metric. Paid Consumption Run Rate, or CRR, had first been disclosed for the quarter ended 30 April. On the 2 June earnings call, management discussed that observation as “nearly US$20 million.” Five weeks later, GitLab said the calculation now excluded certain one-time credit incentives granted to paying customers. Had that treatment been applied at the end of Q1, CRR would have been “closer to US$15 million.”

Neither endpoint is exact. Nearly US$20 million could sit above or below a round number; closer to US$15 million is also an approximation. It would therefore be false precision to report a US$5 million reduction or a 25% cut. GitLab did not restate recognised revenue, reverse a sale or announce a loss. It revised the historical reference point for an internal operating measure.

That distinction softens the accusation but sharpens the analytical problem. A new KPI is useful only if readers know what enters it, what leaves it and whether the ruler stays fixed between dates. GitLab disclosed enough to show that the ruler moved. It did not publish enough to reconstruct the movement.

The company describes CRR as paid Consumption Run Rate and says it is an early signal for recently launched consumption products. It does not publish a formula detailed enough to reproduce the value from usage, prices, commitments and credits. Nor does it identify CRR as GAAP revenue, annual recurring revenue, remaining performance obligations, bookings, billings, backlog, deferred revenue, cash or guidance. The safest reading is exactly the one GitLab offers: a new internal indicator whose definition and methodology are expected to evolve.

Two perimeter decisions, two different dates

The July update made two changes visible. First, GitLab incorporated Flex into CRR. Flex is a consumption-based buying programme that became available after the June call, and GitLab said it had closed the first agreements. The accompanying slide says Flex commitments are reflected in paid CRR.

Second, the calculation now excludes certain one-time credit incentives granted to paying customers. GitLab expressly ties the recast Q1 reference—closer to US$15 million rather than nearly US$20 million—to adjusting for those incentives.

Those statements must not be collapsed into one explanation. Flex could not have caused the Q1 comparator to move because GitLab says the programme became available after the earnings call. The historical adjustment concerns incentives. Flex changes the later perimeter.

This is why the next observation cannot be plotted without qualification. GitLab says continuing paid-consumption growth took CRR above US$20 million at 30 June. That is constructive evidence: customers were paying for more consumption, and a new programme had begun closing agreements. But the later number includes an instrument absent from the opening disclosure, while the historical number was recalculated to remove an instrument previously included. The line between the two points contains both commercial change and measurement change.

A constant-perimeter bridge would separate them. GitLab could show Q1 and 30 June under the same product set, the same Flex treatment and the same incentive rule. It could then provide a second bridge for new products and buying programmes. Without that reconciliation, “closer to US$15 million” to “above US$20 million” is a direction of travel, not a clean growth rate.

Credits are neither automatically revenue nor automatically fiction

The word “credit” invites an overreaction. One reader may treat every incentive as fake demand; another may treat it as economically identical to cash paid without a concession. The filing supports neither position.

GitLab says the incentives were one-time and were granted to paying customers. It does not disclose their aggregate amount, whether they expired, whether unused amounts were refundable, whether they were tied to contractual commitments, how they affected invoicing, or whether and when they entered recognised revenue. The company evidently concluded that excluding them made CRR a more useful signal. That is a measurement judgement, not evidence of misconduct.

The relevant commercial question is whether an incentive buys durable paid behaviour. A temporary allowance can reduce adoption friction, let a customer test agentic workloads and accelerate the first production use. If consumption persists after the credit ends, the concession may have acquired a valuable cohort. If use disappears at the boundary, the early run rate overstated the paid economic habit. Aggregate CRR cannot answer that question.

This is why future disclosure should separate gross measured use, customer cash or contractual payment, credits consumed, credits excluded and subsequent paid retention. A single run-rate number compresses those states. The compression is tolerable when the definition is stable and the cohort evidence is visible. It is much harder to price when both are moving.

The company is much larger than the experimental indicator

The first-quarter accounts keep the adjustment in proportion. GitLab reported US$264.2 million of revenue, up 23% year on year, and US$149.2 million of operating cash flow. Dollar-based net retention was 117%. It had 10,831 customers above US$5,000 of ARR and 1,519 above US$100,000. Total remaining performance obligations were US$1.1 billion, including US$724.1 million current.

At 30 April, current deferred revenue was US$532.983 million and non-current deferred revenue US$23.991 million. Cash, cash equivalents and short-term investments totalled US$1.3575 billion. These figures describe a scaled subscription-software company with a substantial installed base, contract ledger and liquidity position.

They are not a reconciliation to CRR. Revenue is recognised under accounting rules. RPO concerns transaction price allocated to unsatisfied obligations. Deferred revenue records consideration received before performance. ARR and dollar-based net retention use GitLab's subscription definitions. CRR concerns an early consumption surface. Placing the numbers in one article does not make them interchangeable.

The contrast matters in both directions. A change in CRR does not imply GitLab restated its US$264.2 million of Q1 revenue or its US$1.1 billion RPO. Conversely, strong revenue, retention and cash do not prove the new consumption series is comparable. The wider business provides counterevidence against alarmism; it does not repair the missing bridge.

Disclosure was the right act; comparability is the unfinished one

GitLab deserves credit for revisiting the first comparator in public. It could have announced that CRR had passed US$20 million and left the earlier “nearly US$20 million” in circulation. Instead, it identified the incentive treatment, supplied an approximate adjusted Q1 reference and warned that the metric would continue to evolve.

That candour is not the end of governance. When a company introduces a KPI into the market, it creates a measurement promise even if the metric is non-GAAP and immaterial. The promise is not that the definition will never improve. It is that changes will be dated, explained and bridged well enough for readers to distinguish business movement from ruler movement.

The July update meets the first two tests. It does not yet meet the third. We do not know the exact credit amount, the constant-definition Q1 value after adding Flex, the comparable 30 June value without Flex, the division between realised consumption and programme commitments, or the split by product and cohort.

Until those receipts appear, CRR should be treated as a useful watch signal rather than a valuation denominator. Above US$20 million may mark promising adoption. Closer to US$15 million may be the better historical base. The defensible conclusion is not that one number is false and the other true. It is that GitLab is still deciding what the number should contain.

Sources