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.
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:
Distinct orders affected: 358 (some orders had 2 or 3 Credit Memos each).
Why the difference matters: if the merchant runs the legacy report query
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):
The card’s headline number is up 39% but the deeper signal is the rise in average Credit Memos per refunded order from 1.05 to 1.15. That’s a 10% jump in partial-refund frequency, often a sign that warehouse pick errors or wrong-size shipments are increasing. Operations should drill into Top Refunded Products to see which SKUs are driving the partial-refund pattern.
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.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.
Cross-connector reconciliation (when these connectors are connected for this merchant):
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.