Report refund history and dispute history separately

Start with the requested measure, not the easiest export

Copy the application’s exact questions alongside the period, legal entity, provider account, payment method and currency they cover. Refund amount, number of refund events, number of payments refunded and dispute rate are different measures. Several partial refunds can belong to one payment, so counting refund rows is not necessarily counting refunded payments.

Identify the date basis as well. A payment date, refund date and dispute date describe different events. Preserve all available dates in the working records, then apply the requested basis consistently. If the request leaves this unclear, prepare the separate event histories and mark the calculation unresolved. Do not invent a denominator or present a locally calculated rate as the provider’s own metric.

Classify the event before adding the amount

Stripe describes a formal dispute as a challenge that starts when a cardholder questions a payment with the issuer. The dispute reverses the payment, and Stripe debits the payment amount and a dispute fee. A voluntary refund is a separate return process initiated by the business. Those records answer different questions even when both reduce the balance.

Read the actual refund status before describing funds as returned. Stripe’s refund documentation says refunds draw from available balance: insufficient funds leave card refunds pending, while other payment-method types fail. A requested or pending card refund therefore needs its status retained in the disclosure. The application’s instructions determine whether it wants requested refunds, completed refunds or all states.

For Stripe balance exports, use reporting_category to distinguish disputes, dispute reversals and refund failures rather than labeling every adjustment as a refund. A partial-capture reversal also differs from a later customer refund. Keep fees separate from returned or disputed principal when the requested measure asks for payment amounts. These are Stripe record distinctions, not a universal statement format for another provider.

Explain overlap without hiding either history

Cross-reference the original provider payment against the refund and dispute records. Where both exist, retain both event references and their sequence. The overlap note explains that two categories touch the same payment; it is not permission to delete an event from a requested category.

Likewise, retain a dispute reversal beside the dispute that it relates to. Net balance impact and historical dispute incidence are different questions. Do not silently subtract reversed disputes from a chargeback count unless the requesting provider’s definition calls for that treatment. If a combined count of affected payments is requested, identify unique payment references separately from the two event counts and explain the treatment of overlap.

A case whose references or outcome cannot be matched remains an exception in the packet. Keep the source statement unchanged and attach the explanation separately. Resolving a single open refund-and-dispute case is a different task from assembling this portfolio history.

Deliver a reproducible disclosure

The finished packet should let a reviewer trace each total to its report, filters, period and counting rule. Include the refund summary, dispute summary, overlap notes and any unresolved definitions. A zero supported by a complete report differs from a missing report; label missing coverage rather than entering zero.

For a Prism processing consultation, summarize the history request and which definition or record is unresolved. Scope, responsibilities, fees and terms are agreed before work. The provider determines which history it requires and how it assesses the application; this worksheet neither predicts acceptance nor changes that decision.

Refund and dispute disclosure table

Complete this privately from the original provider records. Keep separate refund and dispute schedules behind the table. A missing definition or unmatched reference is an open item, not a zero. Use non-sensitive internal references and send requested records only through the provider’s designated channel.

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.

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.