At a glance
Count of distinct Credit Memo documents created in the period. In Magento and Adobe Commerce a refund is never a status flip on the order; it is a separate Credit Memo document that points back to the original order. This card counts those Credit Memos, not orders that ended up refunded.
| What it counts | COUNT(creditmemo_id) over creditmemos where created_at falls inside the period. One order can have multiple Credit Memos (partial refunds), each is counted once. Adobe Commerce REST endpoint: GET /rest/V1/creditmemos. |
| API field | entity_id (Credit Memo PK) and created_at from the creditmemos index. The parent order is referenced via order_id. |
| Credit Memo vs order status | The card counts Credit Memo documents. The original order’s status may still read complete even after a full refund, Magento does not auto-flip the order to closed unless the refund covers the whole grand_total. So a status filter of status=refunded (the legacy stub query) misses partial refunds entirely. This is the most common reconciliation question merchants raise. |
| VAT / tax treatment | n/a for a count card. The Credit Memo document itself contains tax_amount but this card sums document count, not value. See Refund Value for the monetary version. |
| Shipping inclusion | n/a for the count. A Credit Memo that only refunds shipping (shipping_amount field) is still one document, still counted once. |
| Discounts | n/a for the count. |
| Cancelled / voided orders | Excluded. A canceled order generates no Credit Memo (cancellation reverses authorisation before capture). Only captured-then-refunded orders produce a Credit Memo. This card does not count canceled; use Cancellation Rate for those. |
| Partial refunds | Each Credit Memo is one count. An order with three partial refunds counts three. Merchants who want “orders that had any refund” need a COUNT(DISTINCT order_id) variant, currently roadmapped as a sibling card. |
| Source channel | All Adobe Commerce channels included (storefront, Admin-created, B2B portal, Marketplace if installed). Off-platform refunds (refund issued by the gateway directly without a Credit Memo) are not counted, those show in stripe.stripe_refund_count but not here. |
| Multi-store scope | Sums across all Store Views by default. Per-Store-View slicing available via store_id filter. |
| Time window | 30D vsP (rolling 30-day, compared to prior 30-day window). |
| Alert trigger | None on this card. Volatility is captured on Refund Rate instead. |
| Roles | owner, operations |
Calculation
Worked example
A mid-market homewares merchant on Adobe Commerce 2.4.7 with B2B Companies enabled, running 14 Apr 26 to 13 May 26 (rolling 30 days). Raw counts pulled fromGET /rest/V1/creditmemos:
| Slice | Credit Memo count | Notes |
|---|---|---|
| All Credit Memos in window | 412 | one document per partial or full refund |
Of which: full refunds (covered original grand_total) | 247 | order’s status typically flipped to closed |
| Of which: partial refunds | 165 | order’s status usually stays at complete |
Of which: shipping-only Credit Memos (subtotal=0, shipping_amount>0) | 38 | ”we owe you the express upgrade you didn’t get” |
| Of which: tax-only adjustments | 12 | post-Avalara reconciliation Credit Memos issued by Finance |
| This card reports | 412 | every Credit Memo counted once |
COUNT(orders WHERE status=refunded), they would see roughly 247, the count of full-refund orders that flipped to closed. The 165 partial-refund Credit Memos and the 38 shipping-only memos are invisible to a status-based count. Operations sees a benign “247 refunds this month” while Finance sees “412 Credit Memos posted this month, $84,200 net refund value”. Two truths, two systems. This card surfaces the document count which is the figure the Finance team needs for posting to the GL.
Comparison to prior 30 days (vsP):
| Window | Credit Memos | Distinct orders | Avg Credit Memos per refunded order |
|---|---|---|---|
| 14 Apr to 13 May 26 | 412 | 358 | 1.15 |
| 15 Mar to 13 Apr 26 | 296 | 281 | 1.05 |
| Change | +39% | +27% | partials accelerating |
Sibling cards merchants should reference together
This count card is the volume signal; pair it with the value, rate, and root-cause cards to interpret it.| Card | Why pair it with Refunded Orders |
|---|---|
| Refund Value | Counts vs dollars. A spike in count with flat value is small partial refunds (often shipping disputes). Spike in value with flat count is one whale refund. |
| Refund Rate | Normalises by order volume so seasonal traffic doesn’t masquerade as a refund problem. |
| Refunds Over Time | Day-by-day shape. A Tuesday spike often signals a Monday batch of pick errors caught next-day. |
| Top Refunded Products | The SKU-level cause. Concentrate Operations attention on the 3-5 SKUs producing 50% of refunds. |
| Return Status | RMA workflow status. Adobe Commerce B2B uses RMA for in-process returns; refunds are the downstream event. |
| Cancellation Rate | Pre-capture cancellations and post-capture refunds are different problems. Cancellation = order never paid for; refund = paid then reversed. |
shopify.refund_count | Same metric on Shopify, where refunds are stored on the order itself rather than as a separate document. Useful for agencies running cross-platform clients. |
stripe.stripe_refund_count | The payment-processor side. If Stripe refund count exceeds Adobe Commerce Credit Memo count, somebody is refunding on Stripe Dashboard without back-filling a Credit Memo, the GL will not match. |
Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin: The canonical Credit Memo grid:Sales > Operations > Credit Memos with the “Created” date filter set to your period. The grid lists every Credit Memo withIf the Credit Memos menu item is missing, the admin user lacks thecreditmemo_id,order #,created_at, andrefundedamount. The row count at the bottom of the grid should match this card.
Magento_Sales::creditmemo ACL. Have a Super Admin add it under System > Permissions > User Roles.
For the order-level view (which orders had any refund):
Sales > Orders with the Status column filtered to Closed (full refunds) plus Status = Complete with the additional condition that the order has a Credit Memo. Adobe Commerce does not expose “has Credit Memo” as a default filter, so an exact reconciliation requires either a custom report or the Sales > Operations > Credit Memos grid.
Other Admin views that look relevant but aren’t:
- Reports > Sales > Refunds in 2.4.6+: aggregates by day, not by document count. Useful for trend, not exact reconciliation.
- Dashboard tile “Last Orders”: limited to 5 rows; not aggregated.
- Reports > Sales > Tax: tax slice only, ignores non-tax Credit Memos.
| Reason | Direction of divergence |
|---|---|
Time-zone. The Credit Memos grid uses the Admin user’s locale timezone (set via Stores > Configuration > General > Locale Options). This card uses UTC unless overridden. A Credit Memo created at 23:00 PST shows on different days. | ±1 day at edges of period |
| Pending Credit Memos. A Credit Memo started in Admin but never submitted (the form was abandoned) does not exist as a document, neither in the grid nor here. No divergence expected. | None |
| Off-platform refunds. A refund issued via Stripe Dashboard, PayPal Resolution Center, or Authorize.Net Virtual Terminal directly without back-filling a Credit Memo in Adobe is invisible here. The merchant’s bank statement will show the refund; this card and the Admin Credit Memos grid will both miss it. | This card under-counts vs bank if off-platform refunds occur |
| Multi-store scope. The Admin Credit Memos grid defaults to “All Store Views”; this card matches that by default. If an Admin user has scope-restricted access (only one Store View), their grid will show fewer rows than this card. | Vortex IQ ≥ scoped Admin grid |
| Sync lag. The OpenSearch index trails the database by 5-15 minutes. A Credit Memo posted in the last quarter-hour may not appear here yet. | Vortex IQ slightly lower than live Admin |
| Soft-deleted Credit Memos. Adobe Commerce does not soft-delete by default, but customised installs sometimes do. A custom delete flag would hide rows from one view but not the other. | Custom-install dependent |
| Card | Expected relationship | What divergence tells you |
|---|---|---|
stripe.stripe_refund_count | Stripe ≈ this card for Stripe-paid orders. PayPal, manual Authorize.Net, and bank-transfer refunds are not in Stripe. | If Stripe shows more refunds than Credit Memos, somebody is refunding on Stripe Dashboard without back-filling Adobe. The GL will not balance. Fix: train the team to always issue refunds via Adobe Admin (which calls the gateway), never directly on the gateway. |
paypal.pp_refund_count | PayPal portion only | Same logic as Stripe, scoped to PayPal-paid orders. |
google_analytics.ga_refund_events | GA4 sees only refund events that the storefront fires, often <50% of total | GA4’s refund attribution is unreliable; do not reconcile, use as directional only. |
Known limitations / merchant FAQs
Why does this card disagree withSales > Orders filtered to status=refunded?
Because Magento and Adobe Commerce do not auto-flip an order to refunded (or closed) on partial refund. A partial Credit Memo leaves the order’s status at whatever it was (usually complete). A status-based filter only catches full refunds; this card catches every Credit Memo. Expect this card to be 30-60% higher than a status-based count for typical merchants.
Is one order with three Credit Memos counted three times?
Yes. The headline metric is Credit Memo count, not refunded-order count. If you specifically want “orders that had at least one refund”, use the COUNT(DISTINCT order_id) variant (currently roadmapped, ping support to enable for your workspace).
A refund was issued on Stripe directly without a Credit Memo, why isn’t it counted?
Adobe Commerce only sees Credit Memos. A refund issued in Stripe Dashboard without going back to Adobe is invisible here. The fix is process-level: train Customer Service to always issue refunds via Adobe Admin (Sales > Orders > [order] > Credit Memo), which then calls the gateway under the hood. This keeps Adobe, the gateway, and the GL in sync.
Why is shipping-only Credit Memos a thing?
Common scenarios: customer paid for express shipping but received standard, the merchant issues a Credit Memo for the shipping difference only (subtotal=0, shipping_amount>0). Adobe Commerce supports this natively in the Credit Memo form. It is one document, one count.
My multi-store Adobe Commerce, can I see Credit Memos per Store View?
Yes. By default this card sums all Store Views. To slice by Store View, configure the manifest filter on store_id. The Admin Credit Memos grid offers the same Store View filter at the top of the page.
Why does the Reports > Sales > Refunds total not match this card?
That report aggregates monetary refund value, not document count. It also re-aggregates from the sales_refunded_aggregated denormalised table which Magento refreshes nightly via magento/module-reports. If the indexer has not run today, the report can be 24 hours stale; this card is 5-15 minutes behind real-time.
Can a Credit Memo exist on a canceled order?
No. Cancellation reverses payment authorisation before capture; there is nothing to refund and Adobe blocks Credit Memo creation on canceled orders. The two state machines are mutually exclusive at the document level.
What about RMA returns? Are those counted here?
RMA is a workflow stage that precedes refund. An order in RMA Pending Approval has no Credit Memo yet, so it does not count. Once the RMA is approved and the refund is issued, a Credit Memo is created and counts here. See Return Status for the upstream workflow.
Why does today’s number sometimes drop?
It does not, Credit Memos are immutable once created. If the count drops between two refreshes, the indexer was running mid-refresh and the cached row count was momentarily inconsistent. Wait one full refresh cycle (15 minutes) and it stabilises.