# Sample chargeback evidence packet: a SaaS cancellation case

[By Evidenz](https://evidenz.dev/)  6 min read

A useful chargeback evidence packet connects each statement to a relevant record and preserves facts that support the customer’s complaint. This fictional SaaS cancellation case includes a payment record, account activity, support promise, timeline, and reviewed finding. It is an internal investigation example, not a bank submission or an Evidenz product export.

## A fictional packet you can inspect

**Fictional teaching example. Every identifier, event, excerpt, amount, and conclusion below was created for this guide.** There is no real customer data, bank decision, product export, or measured recovery result. The packet illustrates an internal review; it must not be filed as evidence for a real transaction.

[Download the fictional packet as a PDF (English).](https://evidenz.dev/assets/samples/sample-chargeback-evidence-packet.en.pdf)

The full example also appears below and in this article's Markdown version. You can read the records without a login or JavaScript.

### Case cover

- **Case:** DEMO-CASE-001; review version 1, October 6, 2026.
- **Merchant:** Example Workspace, a fictional subscription software service.
- **Customer account:** DEMO-ACCOUNT-042; subscription DEMO-SUB-009.
- **Disputed payment:** DEMO-PAY-001, EUR 96, collected October 1, 2026 at 08:00 UTC.
- **Service period:** October 1–31, 2026.
- **Complaint:** “I canceled before this renewal and was told I would not be charged.”
- **Working category:** canceled recurring payment; confirm the actual provider code in a real case.
- **Review state:** internal finding prepared; no response submitted in this example.

This case uses one subscriber account to keep the record chain readable. A B2B SaaS investigation also needs the payer-to-company and member-to-workspace relationships. The same review method applies to a B2C SaaS account without pretending those relationships are identical.

## 1. The timeline

All example timestamps are UTC. Each entry points to the source excerpt in the next section.

1. **September 28, 10:12 — E3:** the customer asks support to end DEMO-SUB-009 before October.
2. **September 28, 10:30 — E3:** support confirms that the subscription will end on September 30 and no October renewal will be taken.
3. **October 1, 08:00 — E1:** billing collects EUR 96 for October. The cancellation has not yet been applied.
4. **October 2, 11:05 — E2:** the account signs in and downloads an older invoice.
5. **October 3, 09:20 — E4:** an administrator applies the cancellation.
6. **October 5, 14:00 — E5:** a dispute is recorded for DEMO-PAY-001.
7. **October 6, 09:00 — E6:** the reviewer checks the money movements; no separate refund has completed in the example.

The order matters. The charge preceded the administrative cancellation, but it followed the support promise. A summary that includes only the charge and the cancellation-processing event would miss the most relevant fact.

## 2. The record excerpts

### E1 — Payment and invoice

**Fictional source:** billing ledger, payment DEMO-PAY-001, linked invoice DEMO-INV-010 and subscription DEMO-SUB-009.

> Collected: EUR 96.00. Recorded at: 2026-10-01 08:00 UTC. Service period: 2026-10-01 through 2026-10-31. Customer account: DEMO-ACCOUNT-042.

**Supports:** this amount was collected for the stated period and is linked to the reviewed subscription.

**Does not establish:** that the renewal remained appropriate after the support promise.

### E2 — Account activity

**Fictional source:** account event log for DEMO-ACCOUNT-042.

> 2026-10-02 11:05 UTC: authenticated account session. Action: downloaded invoice DEMO-INV-009 for the September period.

**Supports:** the account was accessible and performed this administrative action.

**Does not establish:** use of an October paid feature, consent to renew, or withdrawal of the cancellation. Downloading an old invoice is different from using the purchased service.

### E3 — The cancellation promise

**Fictional source:** support conversation DEMO-SUPPORT-017, linked to DEMO-ACCOUNT-042 and DEMO-SUB-009.

> Customer, September 28, 10:12 UTC: “Please end this subscription before October. I do not want it to renew.”
> 
> 
> 
> 
> Support, September 28, 10:30 UTC: “I have arranged for this subscription to end on September 30. No October renewal will be taken.”

**Supports:** the customer's account of a cancellation requested and confirmed before the disputed renewal.

**Contradicts:** a proposed statement that the customer never asked to cancel or that the October payment followed the support commitment.

### E4 — The administrative update

**Fictional source:** subscription audit entry for DEMO-SUB-009.

> Cancellation applied by an administrator: 2026-10-03 09:20 UTC. Linked support conversation: DEMO-SUPPORT-017.

**Supports:** the system change happened after the renewal.

**Does not establish:** that October 3 was the first cancellation request or the agreed effective date. It records processing, not the whole agreement.

### E5 — The dispute record

**Fictional source:** case note for DEMO-CASE-001, linked payment DEMO-PAY-001.

> Recorded: 2026-10-05 14:00 UTC. Customer explanation: canceled before renewal. Current review: response not submitted.

This links the allegation to the payment under review. A real packet also needs the actual provider stage, response deadline, timezone, and authorized owner, retrieved from the case rather than copied from this teaching example.

### E6 — Money-movement check

**Fictional source:** reconciliation note saved October 6 at 09:00 UTC.

> No separate refund has completed for DEMO-PAY-001. The card dispute remains in its provider workflow. No off-platform payment has been authorized.

This is a review checkpoint, not a forecast of the final financial outcome. Recheck the live provider state before any real action.

## 3. The finding, including contrary evidence

**Proposed internal finding:** the available example records support the customer's cancellation complaint. E1 confirms collection and E2 confirms account access. E3 shows a specific promise that this subscription would not renew in October. E4 explains why billing and the promise diverged. Neither the receipt nor the invoice download resolves that contradiction in the merchant's favor.

The reviewer should not approve a rebuttal claiming that no cancellation occurred. The case owner should follow the provider's available process for recognizing the valid complaint and reconcile the resulting money movement. A separate refund is not automatically the appropriate action after a dispute has opened.

This is the packet's useful result: a better-supported decision, even when it does not produce a defense. The [cancellation guide](https://evidenz.dev/articles/canceled-subscription-dispute) explains the underlying investigation.

## 4. What to retain and what to submit

Keep the internal packet with its original excerpts, source references, gaps, decision, and review version. In a real case, retain authorized copies sufficient for another reviewer to inspect the assertions; an internal record ID alone is not an attachment the bank can read.

[Stripe's evidence guidance recommends organizing relevant records and explaining their meaning.](https://docs.stripe.com/disputes/best-practices) If a different case warrants a defense, prepare the attachments and narrative that answer its specific complaint. The [response guide](https://evidenz.dev/articles/respond-to-chargebacks) includes a separate fictional rebuttal example for a non-delivery allegation.

[Stripe's response instructions make submission final and do not ask banks to follow external links for evidence.](https://docs.stripe.com/disputes/responding) Put the necessary authorized excerpts in the accepted submission format. The article and its downloadable PDF are educational reading, not evidence about a live customer's payment.

## Who Evidenz is for, and what is available

Evidenz is in development for B2B and B2C SaaS teams investigating subscription payments across billing, account activity, and support. Its intended workflow brings those records into a customer timeline and helps prepare AI-assisted drafts for human review.

The public website, guides, and this fictional sample are available now. Public self-service access and pricing are not available. This sample does not demonstrate released integrations, automatic provider filing, or a completed CE3.0 eligibility check.

If your difficult work resembles the missing link between E3 and E1, the [SaaS product explanation](https://evidenz.dev/articles/saas-chargeback-software) describes the intended approach. You can [join the early-access waitlist](https://evidenz.dev/#hero) while keeping the present availability clear.

## Sources and scope

Sources checked October 2026

Published by Evidenz. Examples are illustrative, not customer results. Check current requirements and the actual case against the linked sources.

- [Stripe: Dispute evidence best practices](https://docs.stripe.com/disputes/best-practices)
- [Stripe: Respond to disputes](https://docs.stripe.com/disputes/responding)

Customer context is our starting point.

Evidenz is being built for B2B and B2C SaaS: a shared customer history across subscription billing, accounts, support, and digital product activity. Join the waitlist for early-access news.

[Join the waitlist](https://evidenz.dev/#hero)

## Keep reading

[5 min read

### Chargeback evidence for subscription businesses](https://evidenz.dev/articles/chargeback-evidence)[6 min read

### How to respond to a chargeback, with a SaaS rebuttal letter example](https://evidenz.dev/articles/respond-to-chargebacks)[5 min read

### Charged after cancellation: investigate a subscription dispute](https://evidenz.dev/articles/canceled-subscription-dispute)[5 min read

### Prepare chargeback evidence files that a reviewer can actually read](https://evidenz.dev/articles/preparing-dispute-evidence-files)

Canonical page: https://evidenz.dev/articles/sample-chargeback-evidence-packet