Startup Revenue Time-Basis Audit: 1,012 Claims Checked for MRR, ARR, and Period Clarity

ProvenStartups is the Organization author and publisher.

Table of Contents

• ·What does the audit show?
• ·How should the counts be read?
• ·What exactly was matched?
• ·How can the result be reproduced?
• ·How should a matched phrase be interpreted?
• ·What are the audit limits?
• ·How can this audit be used in practice?
• ·What files and citation identify the result?
• ·What are the frequently asked questions?

What does the audit show?

The audit found a monthly time-basis token in 496 of 1,012 claims, or 49.0%. Annual language appeared in 245 claims, or 24.2%. Cumulative or lifetime language appeared in 115 claims, or 11.4%. Daily or weekly language appeared in 36 claims, or 3.6%. No recognized token appeared in 309 claims, or 30.5%.

These figures describe disclosed time-basis language, not verified revenue truth. The categories are text-match families, and overlap is allowed. Do not add the signal counts together or treat the percentages as parts of a single, mutually exclusive pie. The audit’s distinctive value is narrower and more useful: it quantifies whether a claim discloses a recognizable cadence without standardizing amounts or deciding whether the underlying claim is true.

The result is dated 2026-09-26 and covers n=1,012 claims.

How should the counts be read?

Each row below reports one independent text-matching result. The evidence columns preserve the observed split across four labels: verified, founder, creator, and unproven.

“Monthly,” “annual,” “cumulative/lifetime,” and “daily/weekly” indicate that at least one listed token was found. “No recognized token” means that none of the listed token families was recognized by the matching method. It does not mean the claim is false, unsupported, or without revenue. It only means that the prescribed text signal was absent.

The evidence split should also be read descriptively. It shows how the matched or unmatched records are distributed across the named labels. It is not a probability, confidence score, or independent assessment of truth.

What exactly was matched?

The method uses case-insensitive text matching. It looks for the following exact token families:

• ·Monthly: MRR, /mo, /month, per month, monthly
• ·Annual: ARR, /yr, /year, per year, annual, annually, yearly
• ·Cumulative/lifetime: lifetime, all-time, to date, total, totalled, cumulative
• ·Daily/weekly: /day, per day, daily, /week, per week, weekly

An equivalent regex representation is:

``regex (?i)(\bMRR\b|/mo\b|/month\b|\bper month\b|\bmonthly\b) (?i)(\bARR\b|/yr\b|/year\b|\bper year\b|\bannual(?:ly)?\b|\byearly\b) (?i)(\blifetime\b|\ball-time\b|\bto date\b|\btotal(?:led)?\b|\bcumulative\b) (?i)(/day\b|\bper day\b|\bdaily\b|/week\b|\bper week\b|\bweekly\b) ``

In plain English, (?i) means that capitalization is ignored. Each vertical bar means “or.” Word boundaries such as \b keep a token from being treated as part of a longer word. The slash forms are matched as written. The method does not infer a cadence from an amount, a currency symbol, a chart, or surrounding business context.

The four regex lines are independent. If the same text contains tokens from two families, it can be counted in both corresponding rows. If it contains none of the listed tokens, it belongs in the no-recognized-token result for this audit.

How can the result be reproduced?

The public CSV and JSON contain the five aggregate output rows. They verify the published table; full regeneration requires the 1,012 coded revenue fields in the private repository.

1. 1.Confirm the manifest reports n=1,012 and version 2026-09-26.

1. 1.With the coded source records, run the four case-insensitive regex families against each revenue field.

1. 1.Record every family that matches; do not stop after the first match.

1. 1.If no listed token matches, record the claim under “no recognized token.”

1. 1.Compare the counts with the CSV or JSON, keeping overlapping signals separate.

The method page supplies collection context. The downloads do not expose restricted row-level source text.

This reproduction process checks whether the same tokens are found. It does not convert one time basis into another, resolve ambiguous wording, or validate a revenue amount.

How should a matched phrase be interpreted?

A matched phrase is evidence of disclosed wording, not evidence that the wording is accurate.

For example, text containing MRR receives a monthly match. Text containing ARR receives an annual match. Text containing lifetime receives a cumulative/lifetime match. Text containing per week receives a daily/weekly match. Text containing tokens from more than one family receives more than one family match.

That interpretation remains mechanical even when the wording is historical or comparative. A phrase can contain a recognized token while describing an earlier period, comparing two periods, or using the term in a way that requires additional context. The method does not decide which interpretation is intended.

A claim with no recognized token should be treated as lacking one of the specified textual signals, not as a failed business claim. Uncommon phrasing may communicate a time basis without using any listed token, and that phrasing may therefore be missed.

What are the audit limits?

The central limit is scope. This is a text audit, not a truth audit. It checks whether specific words or forms appear; it does not verify the amount, the source, the date represented by the amount, or the accuracy of the claim.

The token list is also deliberately finite. It includes the monthly, annual, cumulative/lifetime, and daily/weekly terms listed above. Other wording can be meaningful to a reader while remaining outside the recognized vocabulary.

Historical and comparative uses are another limit. The appearance of monthly, ARR, total, or any other token does not establish that the claim describes current recurring revenue. It only establishes that the token was present in the audited text.

The percentages should not be used as a mutually exclusive distribution. Because overlap is allowed, adding signal counts can create a misleading total. The no-token figure should likewise be read as a classification result from this method, not as a judgment about whether a claim is true.

Finally, the result is tied to the dated population of 1,012 claims. It is a report of that audit, on 2026-09-26, rather than a claim about every startup revenue statement.

How can this audit be used in practice?

The audit can help readers identify whether revenue claims disclose a recognizable time basis before comparing or grouping them. A claim with a monthly token can be separated from one with annual language; a cumulative/lifetime match can be kept distinct from recurring-cadence wording; a daily/weekly match can be flagged for its own interpretation.

The no-recognized-token count provides a direct way to find claims that need closer reading. Those records may use uncommon wording, rely on context, or simply omit a recognizable cadence. The result creates a review queue without declaring those claims false.

The evidence split offers another practical view. Readers can inspect how each text-match family is distributed across verified, founder, creator, and unproven labels. This supports clearer disclosure analysis while preserving the distinction between evidence labels and text signals.

For related reading, consult the projects page and ARR vs revenue. The audit itself does not standardize amounts, convert MRR to ARR, or substitute one revenue concept for another.

What files and citation identify the result?

The audit artifacts are available as CSV, JSON, and manifest.

Citation: ProvenStartups, “Startup Revenue Time-Basis Audit: 1,012 Claims Checked for MRR, ARR, and Period Clarity,” n=1,012, date=2026-09-26, file: startup-revenue-time-basis-audit.csv.

What are the frequently asked questions?

Does 49.0% mean that about half of the revenue fields use monthly language?

It means 496 of the 1,012 audited claims contained at least one monthly token from the defined list. It does not establish the truth, quality, or amount of those claims, and it should not be combined with the other signal counts as a single partition.

Does “no recognized token” mean that a claim has no revenue?

No. It means the prescribed token families did not match the text. The claim may use uncommon phrasing or provide insufficient cadence wording for this method.

Can one claim appear in more than one category?

Yes. Overlap is allowed. Text containing tokens from multiple families can receive multiple matches, so the rows must be interpreted independently.

What does this audit standardize?

It standardizes only the recognition of the listed text tokens and the reporting format for the dated population. It does not standardize amounts, convert time bases, or determine whether any revenue statement is true.