# 5. Refunds & Adjustments — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: refunds_adjustments.md — every feature, sub-feature, and rule covered

---

## Test Execution Policy
- Zero tolerance: any deviation from documented behavior = FAILED = bug
- Every bug is immediately logged/reported (Bug ID, feature, sub-feature,
  expected vs actual, severity) and fixed 100% before the group passes
- Feature group passes only at 100% test pass rate

## Coverage Matrix
| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 5.1 Process Refunds | Refund request: the request (the refund request, the user, the amount, the reason) | TC-SA-15-05-001 |
| 5.1 Process Refunds | Refund approval: the approval (the refund is approved, the amount, the reason) | TC-SA-15-05-002 |
| 5.1 Process Refunds | Refund processing: the processing (the refund is processed, the amount is returned) | TC-SA-15-05-003 |
| 5.1 Process Refunds | Refund status: the status (the pending, the approved, the processed, the rejected) | TC-SA-15-05-004 |
| 5.1 Process Refunds | Refund record: the record (the refund, the amount, the reason, the date) | TC-SA-15-05-005 |
| 5.1 Process Refunds | Refund view: the view (the refunds, the period) | TC-SA-15-05-006 |
| 5.1 Process Refunds | Audit logging of the refund processing | TC-SA-15-05-007 |
| 5.1 Process Refunds | Rule: the refund request is the trigger (the refund request, the user, the amount, the reason); the request is the start | TC-SA-15-05-001 |
| 5.1 Process Refunds | Rule: the refund approval is the decision (the refund is approved, the amount, the reason); the approval is the gate | TC-SA-15-05-002 |
| 5.1 Process Refunds | Rule: the refund processing is the action (the refund is processed, the amount is returned); the processing is the execution | TC-SA-15-05-003 |
| 5.1 Process Refunds | Rule: a refund change (a rejected refund re-approved) is recorded (the new status, the reason, the time); it is auditable | TC-SA-15-05-007 |
| 5.1 Process Refunds | Rule: the refunds are visible (the refunds, the period); the processing is managed | TC-SA-15-05-006 |
| 5.1 Process Refunds | Rule: refund processing is audit-logged with the refund, amount, and timestamp | TC-SA-15-05-007 |
| 5.2 Billing Adjustments and Corrections | Billing adjustment: the adjustment (the adjustment, the amount, the reason) | TC-SA-15-05-008 |
| 5.2 Billing Adjustments and Corrections | Billing correction: the correction (the correction, the amount, the reason) | TC-SA-15-05-009 |
| 5.2 Billing Adjustments and Corrections | Adjustment approval: the approval (the adjustment is approved, the amount, the reason) | TC-SA-15-05-010 |
| 5.2 Billing Adjustments and Corrections | Adjustment processing: the processing (the adjustment is processed, the billing is corrected) | TC-SA-15-05-011 |
| 5.2 Billing Adjustments and Corrections | Adjustment record: the record (the adjustment, the amount, the reason, the date) | TC-SA-15-05-012 |
| 5.2 Billing Adjustments and Corrections | Adjustment view: the view (the adjustments, the period) | TC-SA-15-05-013 |
| 5.2 Billing Adjustments and Corrections | Audit logging of the billing adjustments and corrections | TC-SA-15-05-014 |
| 5.2 Billing Adjustments and Corrections | Rule: the billing adjustment is the fix (the adjustment, the amount, the reason); the adjustment is the correction | TC-SA-15-05-008 |
| 5.2 Billing Adjustments and Corrections | Rule: the billing correction is the fix (the correction, the amount, the reason); the correction is the adjustment | TC-SA-15-05-009 |
| 5.2 Billing Adjustments and Corrections | Rule: the adjustment approval is the decision (the adjustment is approved, the amount, the reason); the approval is the gate | TC-SA-15-05-010 |
| 5.2 Billing Adjustments and Corrections | Rule: an adjustment change (a rejected adjustment re-approved) is recorded (the new status, the reason, the time); it is auditable | TC-SA-15-05-014 |
| 5.2 Billing Adjustments and Corrections | Rule: the adjustments are visible (the adjustments, the period); the processing is managed | TC-SA-15-05-013 |
| 5.2 Billing Adjustments and Corrections | Rule: billing adjustments and corrections are audit-logged with the adjustment, amount, and timestamp | TC-SA-15-05-014 |
| 5.3 Refund Policy Enforcement | Refund policy: the policy (the policy, the conditions, the limits) | TC-SA-15-05-015 |
| 5.3 Refund Policy Enforcement | Policy condition: the condition (the condition for the refund, e.g., the 7-day window) | TC-SA-15-05-016 |
| 5.3 Refund Policy Enforcement | Policy limit: the limit (the limit for the refund, e.g., the partial refund) | TC-SA-15-05-017 |
| 5.3 Refund Policy Enforcement | Policy configuration: the configuration (the policy, the conditions, the limits) | TC-SA-15-05-018 |
| 5.3 Refund Policy Enforcement | Policy enforcement: the enforcement (the refund is per the policy) | TC-SA-15-05-019 |
| 5.3 Refund Policy Enforcement | Policy record: the record (the policy, the conditions, the limits) | TC-SA-15-05-020 |
| 5.3 Refund Policy Enforcement | Audit logging of the refund policy configuration and enforcement | TC-SA-15-05-021 |
| 5.3 Refund Policy Enforcement | Rule: the refund policy is the rule (the policy, the conditions, the limits); the policy is the control | TC-SA-15-05-015 |
| 5.3 Refund Policy Enforcement | Rule: the policy condition is the gate (the condition for the refund, e.g., the 7-day window); the condition is the trigger | TC-SA-15-05-016 |
| 5.3 Refund Policy Enforcement | Rule: the policy limit is the boundary (the limit for the refund, e.g., the partial refund); the limit is the control | TC-SA-15-05-017 |
| 5.3 Refund Policy Enforcement | Rule: a policy change (the conditions, the limits updated) is recorded (the new conditions, the new limits, the time); it is auditable | TC-SA-15-05-021 |
| 5.3 Refund Policy Enforcement | Rule: the refund policy is visible (the policy, the conditions, the limits); the enforcement is managed | TC-SA-15-05-018 |
| 5.3 Refund Policy Enforcement | Rule: refund policy configuration and enforcement are audit-logged with the policy, conditions, and timestamp | TC-SA-15-05-021 |

## 5.1 Process Refunds

### TC-SA-15-05-001 — Refund request: the request (the refund request, the user, the amount, the reason); the request is the start
**Type:** Positive
**Covers:** 5.1 → Refund request: the request (the refund request, the user, the amount, the reason); Rule: the refund request is the trigger (the refund request, the user, the amount, the reason); the request is the start
**Preconditions:** A user has submitted a refund request.
**Steps:**
1. View the refund requests: the requests (the refund request, the user, the amount, the reason), the statuses (the pending, the approved, the processed, the rejected).
2. Verify the request is the trigger and is shown with the user, the amount, and the reason.
**Expected Result:** The refund request is shown — the refund request, the user, the amount, and the reason are visible.
**Priority:** Critical

### TC-SA-15-05-002 — Refund approval: the approval (the refund is approved, the amount, the reason); the approval is the gate
**Type:** Negative
**Covers:** 5.1 → Refund approval: the approval (the refund is approved, the amount, the reason); Rule: the refund approval is the decision (the refund is approved, the amount, the reason); the approval is the gate
**Preconditions:** A refund request is pending.
**Steps:**
1. Review the refund request: the request (the refund request, the user, the amount, the reason).
2. Approve the refund: the approval (the refund is approved, the amount, the reason) — verify the approval is the decision.
3. Reject a different refund request — verify the rejection is recorded with the reason.
**Expected Result:** The refund approval works — the refund is approved (or rejected) and the decision is recorded.
**Priority:** Critical

### TC-SA-15-05-003 — Refund processing: the processing (the refund is processed, the amount is returned); the processing is the execution
**Type:** Positive
**Covers:** 5.1 → Refund processing: the processing (the refund is processed, the amount is returned); Rule: the refund processing is the action (the refund is processed, the amount is returned); the processing is the execution
**Preconditions:** A refund is approved.
**Steps:**
1. Process the refund: the processing (the refund is processed, the amount is returned).
2. Verify the amount is returned to the user's original payment method.
3. The user is notified: the notification (the refund is processed, the amount, the date) — verify the notification is sent.
**Expected Result:** The refund is processed — the amount is returned and the user is notified.
**Priority:** Critical

### TC-SA-15-05-004 — Refund status: the status (the pending, the approved, the processed, the rejected); the status is the state
**Type:** Positive
**Covers:** 5.1 → Refund status: the status (the pending, the approved, the processed, the rejected)
**Preconditions:** Refunds exist in all four statuses.
**Steps:**
1. View the refunds — verify each refund shows its status (the pending, the approved, the processed, the rejected).
2. Verify the status transitions are correct (pending → approved → processed; pending → rejected).
**Expected Result:** The refund status is shown — the pending, the approved, the processed, or the rejected state is visible for each refund.
**Priority:** High

### TC-SA-15-05-005 — Refund record: the record (the refund, the amount, the reason, the date); the record is the proof
**Type:** Positive
**Covers:** 5.1 → Refund record: the record (the refund, the amount, the reason, the date)
**Preconditions:** A refund has been processed.
**Steps:**
1. Open the refund record.
2. Verify it shows the refund, the amount, the reason, and the date.
**Expected Result:** The refund is recorded — the refund, the amount, the reason, and the date are shown.
**Priority:** High

### TC-SA-15-05-006 — Refund view: the view (the refunds, the period); the processing is managed
**Type:** Positive
**Covers:** 5.1 → Refund view: the view (the refunds, the period); Rule: the refunds are visible (the refunds, the period); the processing is managed
**Preconditions:** Refunds exist across a period.
**Steps:**
1. View the refunds: the refunds, the period — verify the refunds are visible.
2. Verify the view is complete for the period.
**Expected Result:** The refund view works — the refunds for the period are visible.
**Priority:** High

### TC-SA-15-05-007 — Refund processing is audit-logged with the refund, amount, and timestamp
**Type:** Positive
**Covers:** 5.1 → Audit logging of the refund processing; Rule: a refund change (a rejected refund re-approved) is recorded (the new status, the reason, the time); it is auditable; Rule: refund processing is audit-logged with the refund, amount, and timestamp
**Preconditions:** Refunds have been processed and a rejected refund has been re-approved.
**Steps:**
1. Open the audit trail and filter by "refund".
2. Verify entries show the refund, the amount, and the timestamp for the processing.
3. Verify the refund change (a rejected refund re-approved: the new status, the reason, the time) is recorded and auditable.
**Expected Result:** The refund processing is audit-logged with the refund, amount, and timestamp.
**Priority:** Critical

## 5.2 Billing Adjustments and Corrections

### TC-SA-15-05-008 — Billing adjustment: the adjustment (the adjustment, the amount, the reason); the adjustment is the correction
**Type:** Positive
**Covers:** 5.2 → Billing adjustment: the adjustment (the adjustment, the amount, the reason); Rule: the billing adjustment is the fix (the adjustment, the amount, the reason); the adjustment is the correction
**Preconditions:** A billing error exists (e.g., an incorrect charge).
**Steps:**
1. View the billing adjustments: the adjustments (the adjustment, the user, the amount, the reason).
2. Create a billing adjustment: the adjustment (the adjustment, the amount, the reason).
3. Verify the adjustment is the fix and is saved.
**Expected Result:** The billing adjustment is created — the adjustment, the amount, and the reason are the correction.
**Priority:** Critical

### TC-SA-15-05-009 — Billing correction: the correction (the correction, the amount, the reason); the correction is the adjustment
**Type:** Positive
**Covers:** 5.2 → Billing correction: the correction (the correction, the amount, the reason); Rule: the billing correction is the fix (the correction, the amount, the reason); the correction is the adjustment
**Preconditions:** A billing error exists (e.g., a wrong amount was charged).
**Steps:**
1. Create a billing correction: the correction (the correction, the amount, the reason).
2. Verify the correction is the fix and is saved.
3. Verify the corrected billing reflects the correction.
**Expected Result:** The billing correction is created — the correction, the amount, and the reason are the adjustment.
**Priority:** Critical

### TC-SA-15-05-010 — Adjustment approval: the approval (the adjustment is approved, the amount, the reason); the approval is the gate
**Type:** Negative
**Covers:** 5.2 → Adjustment approval: the approval (the adjustment is approved, the amount, the reason); Rule: the adjustment approval is the decision (the adjustment is approved, the amount, the reason); the approval is the gate
**Preconditions:** A billing adjustment is pending.
**Steps:**
1. Review the billing adjustment: the adjustment (the adjustment, the user, the amount, the reason).
2. Approve the adjustment: the approval (the adjustment is approved, the amount, the reason) — verify the approval is the decision.
3. Reject a different adjustment — verify the rejection is recorded with the reason.
**Expected Result:** The adjustment approval works — the adjustment is approved (or rejected) and the decision is recorded.
**Priority:** Critical

### TC-SA-15-05-011 — Adjustment processing: the processing (the adjustment is processed, the billing is corrected); the processing is the action
**Type:** Positive
**Covers:** 5.2 → Adjustment processing: the processing (the adjustment is processed, the billing is corrected)
**Preconditions:** A billing adjustment is approved.
**Steps:**
1. Process the adjustment: the processing (the adjustment is processed, the billing is corrected).
2. Verify the billing is corrected (the user's balance/billing reflects the adjustment).
3. The user is notified: the notification (the adjustment is processed, the amount, the reason) — verify the notification is sent.
**Expected Result:** The adjustment is processed — the billing is corrected and the user is notified.
**Priority:** Critical

### TC-SA-15-05-012 — Adjustment record: the record (the adjustment, the amount, the reason, the date); the record is the proof
**Type:** Positive
**Covers:** 5.2 → Adjustment record: the record (the adjustment, the amount, the reason, the date)
**Preconditions:** A billing adjustment has been processed.
**Steps:**
1. Open the adjustment record.
2. Verify it shows the adjustment, the amount, the reason, and the date.
**Expected Result:** The adjustment is recorded — the adjustment, the amount, the reason, and the date are shown.
**Priority:** High

### TC-SA-15-05-013 — Adjustment view: the view (the adjustments, the period); the processing is managed
**Type:** Positive
**Covers:** 5.2 → Adjustment view: the view (the adjustments, the period); Rule: the adjustments are visible (the adjustments, the period); the processing is managed
**Preconditions:** Billing adjustments exist across a period.
**Steps:**
1. View the adjustments: the adjustments, the period — verify the adjustments are visible.
2. Verify the view is complete for the period.
**Expected Result:** The adjustment view works — the adjustments for the period are visible.
**Priority:** High

### TC-SA-15-05-014 — Billing adjustments and corrections are audit-logged with the adjustment, amount, and timestamp
**Type:** Positive
**Covers:** 5.2 → Audit logging of the billing adjustments and corrections; Rule: an adjustment change (a rejected adjustment re-approved) is recorded (the new status, the reason, the time); it is auditable; Rule: billing adjustments and corrections are audit-logged with the adjustment, amount, and timestamp
**Preconditions:** Billing adjustments have been processed and a rejected adjustment has been re-approved.
**Steps:**
1. Open the audit trail and filter by "billing adjustment".
2. Verify entries show the adjustment, the amount, and the timestamp for the processing.
3. Verify the adjustment change (a rejected adjustment re-approved: the new status, the reason, the time) is recorded and auditable.
**Expected Result:** The billing adjustments and corrections are audit-logged with the adjustment, amount, and timestamp.
**Priority:** Critical

## 5.3 Refund Policy Enforcement

### TC-SA-15-05-015 — Refund policy: the policy (the policy, the conditions, the limits); the policy is the control
**Type:** Positive
**Covers:** 5.3 → Refund policy: the policy (the policy, the conditions, the limits); Rule: the refund policy is the rule (the policy, the conditions, the limits); the policy is the control
**Preconditions:** Super Admin is logged in.
**Steps:**
1. Configure the refund policy: the policy (the policy, the conditions, the limits).
2. Verify the policy is the rule and is saved.
**Expected Result:** The refund policy is set — the policy, the conditions, and the limits are the control.
**Priority:** Critical

### TC-SA-15-05-016 — Policy condition: the condition (the condition for the refund, e.g., the 7-day window); the condition is the trigger
**Type:** Negative
**Covers:** 5.3 → Policy condition: the condition (the condition for the refund, e.g., the 7-day window); Rule: the policy condition is the gate (the condition for the refund, e.g., the 7-day window); the condition is the trigger
**Preconditions:** The refund policy has a 7-day window condition.
**Steps:**
1. Set the policy condition: the condition (the condition for the refund, e.g., the 7-day window).
2. Request a refund within the 7-day window — verify the condition is met and the refund is allowed.
3. Request a refund outside the 7-day window — verify the condition is not met and the refund is blocked (or flagged for exception).
**Expected Result:** The policy condition is enforced — the refund is allowed within the 7-day window and blocked outside it.
**Priority:** Critical

### TC-SA-15-05-017 — Policy limit: the limit (the limit for the refund, e.g., the partial refund); the limit is the boundary
**Type:** Edge
**Covers:** 5.3 → Policy limit: the limit (the limit for the refund, e.g., the partial refund); Rule: the policy limit is the boundary (the limit for the refund, e.g., the partial refund); the limit is the control
**Preconditions:** The refund policy has a partial refund limit (e.g., 50% after day 7).
**Steps:**
1. Set the policy limit: the limit (the limit for the refund, e.g., the partial refund).
2. Request a full refund that exceeds the limit — verify the limit is applied (only the partial refund is allowed).
3. Verify the limit is the boundary and is enforced.
**Expected Result:** The policy limit is enforced — the refund is limited to the configured boundary (e.g., the partial refund).
**Priority:** Critical

### TC-SA-15-05-018 — Policy configuration: the configuration (the policy, the conditions, the limits); the enforcement is managed
**Type:** Positive
**Covers:** 5.3 → Policy configuration: the configuration (the policy, the conditions, the limits); Rule: the refund policy is visible (the policy, the conditions, the limits); the enforcement is managed
**Preconditions:** Super Admin is logged in.
**Steps:**
1. Configure the refund policy: the policy (the policy, the conditions, the limits), the conditions (the condition for the refund, e.g., the 7-day window), and the limits (the limit for the refund, e.g., the partial refund).
2. Save; verify the refund policy is live and the refunds are per the policy.
3. View the refund policy — verify the policy, the conditions, and the limits are visible.
**Expected Result:** The policy configuration is saved — the policy, the conditions, and the limits are configured and visible.
**Priority:** Critical

### TC-SA-15-05-019 — Policy enforcement: the enforcement (the refund is per the policy); the refund is recorded
**Type:** Positive
**Covers:** 5.3 → Policy enforcement: the enforcement (the refund is per the policy)
**Preconditions:** The refund policy is live; a refund is requested.
**Steps:**
1. A refund is requested — verify the policy is enforced (the condition is met, the limit is applied, the refund is per the policy).
2. Verify the refund is recorded.
**Expected Result:** The policy enforcement works — the refund is per the policy (the condition is met, the limit is applied).
**Priority:** Critical

### TC-SA-15-05-020 — Policy record: the record (the policy, the conditions, the limits); the record is the proof
**Type:** Positive
**Covers:** 5.3 → Policy record: the record (the policy, the conditions, the limits)
**Preconditions:** The refund policy has been configured.
**Steps:**
1. Open the policy record.
2. Verify it shows the policy, the conditions, and the limits.
**Expected Result:** The policy is recorded — the policy, the conditions, and the limits are shown.
**Priority:** High

### TC-SA-15-05-021 — Refund policy configuration and enforcement are audit-logged with the policy, conditions, and timestamp
**Type:** Positive
**Covers:** 5.3 → Audit logging of the refund policy configuration and enforcement; Rule: a policy change (the conditions, the limits updated) is recorded (the new conditions, the new limits, the time); it is auditable; Rule: refund policy configuration and enforcement are audit-logged with the policy, conditions, and timestamp
**Preconditions:** The refund policy has been configured, changed, and enforced.
**Steps:**
1. Open the audit trail and filter by "refund policy".
2. Verify entries show the policy, the conditions, and the timestamp for the configuration and enforcement.
3. Verify the policy change (the new conditions, the new limits, the time) is recorded and auditable.
**Expected Result:** The refund policy configuration and enforcement are audit-logged with the policy, conditions, and timestamp.
**Priority:** Critical