At a glance
The day-by-day count and value of Credit Memos created over the last 90 days, plotted as a time series. Lets Operations spot batch postings, weekly cycles, post-promotion return waves, and supplier-defect spikes that aggregate-only cards smooth away.
| What it counts | For each day in the 90-day window: COUNT(creditmemo_id) and SUM(creditmemo.grand_total) where created_at falls in that day (UTC by default). Two parallel time series shown on the same chart with dual axes. |
| API field | entity_id, created_at, grand_total, base_grand_total from GET /rest/V1/creditmemos. |
| Why daily over weekly | Many supplier-defect waves and shipping-incident batches play out on a 1-3 day cycle. Weekly bucketing hides the within-week pattern (especially the Mon-Tue Customer Service catch-up after weekend RMAs). Daily granularity is essential for incident-correlation. |
| VAT / tax treatment | The value series uses grand_total (tax-inclusive). Toggle the chart to subtotal for tax-exclusive product-only refund value. |
| Shipping inclusion | Included in grand_total series. Filter to product-only via subtotal toggle. |
| Discounts | Already deducted, the customer-paid net is what grand_total represents. |
| Cancelled / voided orders | Excluded (no Credit Memo possible on canceled orders). |
| Currency | Mixed-currency grand_total for visual scale. Toggle to base_grand_total for FX-neutral history. |
| Channels / sources | All Adobe Commerce sources: storefront, Admin-created, B2B portal, Marketplace if installed. Off-platform refunds invisible. |
| Multi-store scope | All Store Views aggregated; per-Store-View filtering available via the chart legend. |
| Time window | 90D rolling. Sentiment alert is at the aggregate level; this card is exploratory rather than alerting. |
| Alert trigger | None on this card directly. Use Refund Rate for alerting; use this card to investigate the shape behind the alert. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Adobe Commerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A B2B-leaning industrial-supplies merchant on Adobe Commerce 2.4.7. Snapshot taken 13 May 26, looking back 90 days. Aggregate stats over the window:| Metric | Value |
|---|---|
| Days in window | 90 |
| Total Credit Memos | 1,143 |
Total refund grand_total | $284,600 |
| Mean Credit Memos / day | 12.7 |
| Median Credit Memos / day | 11 |
| Standard deviation | 7.4 |
| Days above mean + 2σ (>27 memos) | 6 |
| Date | Credit Memos | grand_total | Likely cause |
|---|---|---|---|
| 18 Feb 26 | 41 | $14,200 | Backlog catch-up; new CS hire’s first week |
| 24 Feb 26 | 38 | $12,700 | Weekend backlog (Mon AM batch) |
| 6 Mar 26 | 52 | $28,900 | Single B2B account returned a $24k bulk shipment, plus weekly DTC catch-up |
| 19 Mar 26 | 31 | $9,400 | Post-promotion return wave (5-day delay after 14 Mar promo end) |
| 14 Apr 26 | 47 | $19,300 | Supplier sizing-error wave (uniform line, see Refund Value example) |
| 28 Apr 26 | 36 | $11,800 | Continued uniform-line returns |
- Day-of-week bias is strong. Monday averages 18 Credit Memos vs Sunday’s 3. CS teams batch-post on Monday morning after the weekend’s RMAs queue up. This is a posting artifact, not a real refund spike.
- Tuesday is the second-highest day for the same reason; carry-over from Monday’s backlog.
- Friday afternoon spikes appear before holiday weekends (President’s Day Friday 14 Feb showed 24 vs Friday baseline 14). CS clears the queue before time off.
- The 6 Mar single-day $28,900 spike is one large B2B return masking the daily count. The dollar series shows a clear spike; the count series shows a moderate spike. Reading both axes catches this.
- The supplier-error wave starting 14 Apr is the most actionable signal. The uniform-line refunds are still elevated 4 weeks in (28 Apr at 36, well above mean+2σ). Operations should check if the corrective action (sizing chart correction, supplier rework) is landing.
- Cross-link with Top Refunded Products filtered to the post-14 Apr window: the top 10 refunded SKUs should now be uniform-line items if our hypothesis is correct.
Sibling cards merchants should reference together
| Card | Why pair it with Refunds Over Time |
|---|---|
| Refund Count | Aggregate of this card’s count series. |
| Refund Value | Aggregate of this card’s value series. |
| Refund Rate | The normalised version. Useful when order volume itself swings (Black Friday, January). |
| Top Refunded Products | The SKU concentration behind a daily spike. |
| Cancellations Over Time | Sister card for pre-capture cancellations; pairing reveals whether spikes share a cause. |
| Orders Over Time | The denominator shape. Lets you visually rule out “more orders, more refunds”. |
| Revenue Over Time | Promotion windows show in revenue; the post-promotion return wave shows here 7-21 days later. |
shopify.refunds_over_time | Cross-platform peer. |
Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin:
Reports > Sales > Refunds with “Show By” set to “Day”, date range matching this card. The chart and table show daily refund value (using base_grand_total). The count series is not shown; for daily count Admins must use the Credit Memos grid.
Sales > Operations > Credit Memos sorted by Created descending; export to CSV and group by date for a daily count. Adobe Commerce admin does not natively chart the count series.
Why our number may legitimately differ from Adobe Commerce Admin:
| Reason | Direction of divergence |
|---|---|
| Time-zone. Daily buckets in Admin use Store View locale; this card uses UTC by default. A Credit Memo posted at 23:30 PST on Monday lands on Monday in Admin and Tuesday in this card. | Bucket-shift on day boundaries |
Currency. Admin’s value series uses base_grand_total; this card defaults to mixed grand_total. Toggle the chart to base_grand_total for like-for-like. | Material for multi-currency stores |
Reports indexer lag. The Refunds report relies on the sales_refunded_aggregated table, refreshed nightly. Today’s Credit Memos may not show until tomorrow’s index run. This card refreshes every 5-15 min. | Vortex IQ ahead by ~12 hours on most-recent day |
| Off-platform refunds invisible to both | Both views miss gateway-only refunds without Credit Memos. |
| Sync lag at recent-end | This card 5-15 min behind real-time. |
| Card | Expected relationship | What divergence tells you |
|---|---|---|
stripe.stripe_refunds_over_time | Stripe’s daily series should track this card’s value series for Stripe-paid orders | Days where Stripe is materially higher mean somebody refunded on Stripe Dashboard; days where this card is higher mean Credit Memos posted for non-Stripe payment methods (PayPal, manual). |
paypal.pp_refunds_over_time | PayPal’s subset | Same pattern, scoped to PayPal. |
Known limitations / merchant FAQs
Why is Monday always the highest day? CS teams batch-post weekend RMAs on Monday morning. The customer’s actual return decision happened over the weekend; the Credit Memo is dated when CS clicks “Submit”. This is a posting artifact. To see “true” daily refund pressure, look at when the order was placed (not when the Credit Memo was created) using the cohort-refund variant. Can I see this by Customer Group (B2B vs DTC)? Yes. Apply a Customer Group filter via the chart legend. Useful when you suspect a single channel is driving the pattern. A single-day spike, real or batch posting? Three diagnostic checks: (1) does the count series spike but value series stay normal? Then it is many small partial refunds, often a backlog clear. (2) Does value spike but count not? Then it is one whale refund, drill into Top Refunded Products for the SKU. (3) Both spike together? Real event, possibly a supplier defect or a faulty batch shipment. Why is Sunday always so low? CS doesn’t process refunds on Sundays for most merchants. The data is correct; the operational rhythm is the cause. Use 7-day rolling rather than daily for trend. My multi-currency, the value series looks weirdly wavy, why? The default uses mixed-currencygrand_total. A day with one large refund in USD plus normal day in GBP looks like a spike if you’re reading the chart in GBP-mental-model. Toggle to base_grand_total for FX-neutral comparison.
Why does today’s last data point look low?
Because today is incomplete. The day-to-date count cannot match a full day. Most charts dim or annotate “in progress” on the trailing day. If yours doesn’t, ignore the trailing data point or annotate it manually.
The 90-day window doesn’t include my Black Friday spike, can I extend?
The default is 90 days. The card supports 180-day and 365-day views via the manifest. Beyond that, OpenSearch index retention defaults to 13 months; older data needs a custom backfill query.
Can I overlay an event marker (promo end, supplier change, system upgrade)?
Yes via the Vortex IQ workspace annotations. Mark events on the timeline and they overlay across all time-series cards (this one, Revenue Over Time, Orders Over Time) for incident-correlation.
Why don’t stripe.stripe_refunds_over_time and this card always match day-by-day?
Even on a Stripe-paid order, the day a Credit Memo is posted in Adobe and the day the refund hits Stripe’s API can differ by a few seconds (Adobe calls Stripe API; the API call returns; both write timestamps). On day boundaries, this matters. Aggregate over 7 days and they match closely.