Dispute activity and dispute rate measure different dates
The date determines which disputes belong in the numerator. Stripe's dispute activity groups disputes by when they arose and compares them with successful payments in the selected period. Its dispute rate attributes disputes to the dates of the original charges, so the rate for a payment cohort can increase when disputes arrive later. The same calendar window therefore answers two different questions. Match the provider's definition, payment population, timezone and as-of date before comparing percentages, and count qualifying dispute records rather than their fees, debits or reversals.
For: An owner or operations lead at a research-only merchant comparing dispute reports whose totals or percentages differ despite using the same calendar period.
Dispute activity asks how many disputes arose in the period relative to its successful payments. Those disputes can concern payments from earlier periods. Stripe's dispute rate asks how many disputes belong to the successful payments charged in the selected period. It follows that payment cohort even when its disputes arise afterward. A cohort is simply the defined group of payments selected by their charge dates.
For the Stripe definitions described here, write the calculations in words before using the report: activity is disputes arising in the selected window divided by successful payments in that window; rate is disputes attributed to charges in the selected window divided by successful payments in that charge-date window. Express the ratio as a percentage if the denominator is nonzero. A window with no qualifying successful payments does not yield a meaningful percentage from division by zero.
Keep both definitions when both questions matter. Dispute-date records help identify incoming case workload, although workload should also retain the actual case count. Charge-date cohorts help connect later disputes to the payment period in which the original orders occurred. Neither view alone proves why customers disputed. A calendar label on two reports does not make their numerators equivalent.
Follow each dispute back to the original payment
Within authorized records, associate each qualifying dispute reference with its payment reference, original charge date and dispute date. Select the date field for the named metric instead of using the export's default sort order. Keep the account, payment-method scope and timezone consistent with the provider view being reconciled. Record any exclusions in that view so the denominator does not silently include a different population.
For activity, filter the dispute records by dispute date; do not also discard them because their original charge predates the window. For rate, select the successful charge cohort first and associate the disputes belonging to it as of the report date; do not discard a dispute simply because it arrived after the charge-date window closed. Applying both date filters at once can remove exactly the later cases that distinguish the metrics.
Use successful payment counts for the documented denominator. Failed attempts, saved payment methods, order totals and net payout amounts are different units. If your available export cannot identify successful payments or connect a case to its charge date, retain the case list and label the cohort calculation unresolved. Do not fill the missing denominator with an unrelated store-order count.
Do not turn the financial history into a case count
A dispute can have several financial movements while remaining the same case. A debit, fee and later reversal are not three new disputes. A balance export is useful for reconciling money, but counting its lines does not establish a dispute numerator. Keep a distinct case list tied to the provider's dispute references and classify balance movements separately.
When combining exports, check for repeated records of the same case, including records whose status changed between exports. Preserve those observations as history, but do not count them as newly opened disputes merely because they are separate rows. A case reference, a payment reference and a balance-transaction reference identify different things; do not use one interchangeably with another.
Stripe says both won and lost disputes count toward its dispute rate. A favorable outcome or funds being reinstated therefore does not justify subtracting that case from this metric. The financial result and the incidence of a dispute answer different questions. Use another provider's or network program's actual definition if it treats qualifying events differently.
Keep the observation date when a cohort changes
Stripe's measuring guide says cardholders can dispute charges up to 120 days after payment, sometimes later. A recent charge-date cohort is consequently still developing: its original charge window can remain fixed while new disputes are associated with it. Do not treat 120 days as a guaranteed closure date for every case or method.
Save the as-of date alongside the charge window and definition. When comparing an earlier report with a later one, retain both and identify the additional case references that changed the later numerator. If the population or filters also changed, name that separately. A later higher rate for the same charge period does not by itself demonstrate that the earlier report was wrong.
Compare periods with their observation age visible. A recent cohort has had less time to receive disputes than an older one. That difference limits an apparent improvement; it is not a reason to invent a predicted final rate. Keep observed results separate from forecasts and preserve unresolved mismatches until the report's actual records explain them.
Use the definition to resolve the disagreement
Once the worksheet is complete, classify the difference: a different date basis, a different successful-payment population, duplicate case rows, financial movements counted as cases, or a later as-of date. Resolve the identified mismatch and retain the definition with the report. If none explains it, give the provider the named report, filters and unresolved non-sensitive comparison rather than claiming its number is wrong.
Exact card-network monitoring definitions are a separate question. This worksheet does not establish entry thresholds, account safety or eligibility, and it does not make Stripe's Dashboard metric a universal network rule. Use any actual provider notice and the applicable program definition for that assessment.
If the observed cases suggest a recurring checkout or order-communication issue, a Prism checkout-review consultation can start from the symptom and the measurement definition. Describe the storefront question and confirm scope, responsibilities, fees and terms before work. Keep account exports and customer case files out of the public inquiry; an informational review cannot guarantee a future dispute rate or processing approval.
Dispute metric definition record
Complete a separate sheet for each metric you compare using your actual report and authorized case records. Enter the definition and non-sensitive findings, not customer information or raw account exports. A disagreement is explained only when the date basis, counted population and observation date are known; an absent denominator remains unresolved.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Dispute metric definition record. The last column is for temporary notes.
Definition field
What to record from real records
Interpretation check
Your definition or finding
Named metric
What to record from real recordsThe provider, exact report label and whether the report uses dispute date or charge date.
Interpretation checkActivity and rate can use the same calendar window while counting different disputes. Do not rename both as one generic rate.
Cohort and timezone
What to record from real recordsThe start and end boundaries, timezone, account and applicable payment-method filters.
Interpretation checkA charge-date cohort follows the original payments. Activity follows incoming disputes, including disputes of older payments.
Counted event type
What to record from real recordsThe qualifying dispute-record definition and the successful-payment count used as denominator.
Interpretation checkExclude fees, reversals, refunds and failed payment attempts from a dispute count. Do not substitute payout value or store-order count for successful payments.
Unique case references
What to record from real recordsIn authorized records, map each counted case to its original payment and retain both dates. Enter only the reconciliation outcome here.
Interpretation checkRepeated snapshots and multiple balance movements do not create additional cases. Use the provider definition when deciding which records qualify.
As-of date
What to record from real recordsThe report generation or observation date alongside the original charge window.
Interpretation checkA later report can include later disputes of the same payment cohort. Preserve the earlier observation instead of overwriting it.
Provider definition
What to record from real recordsThe official definition used and any report-specific inclusions or exclusions stated by the provider.
Interpretation checkStripe says won and lost disputes count toward its rate. Another provider or network program requires its own definition.
Reason for the difference
What to record from real recordsThe verified date, filter, duplicate-record or maturity difference; otherwise the exact missing field.
Interpretation checkStop at the supported explanation. A corrected calculation does not establish the cause of disputes or a safe threshold.
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
These activity and rate definitions are Stripe's documented measures, not universal rules for every provider or network monitoring program.
Later disputes can change charge-date cohorts. No observation period, dispute outcome or percentage here establishes guaranteed account safety or future performance.
Keep case references and underlying customer records in authorized systems. Do not send card data, credentials, bank records or account exports through the public consultation form.
Measuring disputes | Stripe Documentation — checked 2026-09-29. Stripe distinguishes dispute activity by dispute date from dispute rate by charge date, each against successful payments. Later disputes can change recent cohorts; disputes may arrive after 120 days, and both won and lost cases count toward the rate. This does not establish a universal monitoring threshold.
Get help with store operations
Need help with the order, email or fulfillment step itself?