At a glance
The total monetary value refunded in the period. Aggregates Credit Memogrand_totalacross every Credit Memo created in the window. Magento and Adobe Commerce treat refunds as separate Credit Memo documents, the order’stotal_refundedfield is the cumulative sum of all Credit Memos against that order, but this card sums the memo values directly so partial refunds and shipping-only refunds are all captured.
Calculation
Worked example
A B2B+DTC apparel merchant on Adobe Commerce 2.4.7 with the B2B Companies module enabled. UK-based, GBP base currency, single Store View. Period: 14 Apr 26 to 13 May 26. Credit Memo population for the window: 188 Credit Memos. Value breakdown (sum across all 188 Credit Memos in GBP):
Comparison to prior period:
The card’s headline number is up 59% but the more telling slice is the 20% jump in average refund value. Operations should investigate whether high-AOV B2B orders are starting to come back. Drilling into the breakdown:
- B2B refunds (Customers in any Adobe Commerce Company entity): £21,400 of the £46,220, or 46% of refund value. B2B is typically <10% of refund value because B2B orders rarely refund (they raise credit notes against future POs instead).
- Cause: the merchant launched a new wholesale uniform line on 1 Apr 26 with a sizing chart that turned out to be misaligned (suppliers ran 1 size small). 12 B2B accounts returned bulk shipments through April. The pattern is visible in Top Refunded Products, where 6 of the top 10 refunded SKUs are uniform line items.
- Action: pause the uniform line on the Adobe catalogue, update the sizing chart, contact affected B2B accounts with replacement quotes. Forward to Procurement to chase the supplier on the sizing claim.
- GL reconciliation note for Finance: the Credit Memo
grand_totalincludes £7,650 of refunded VAT. Net refund to book against revenue is £38,570; the £7,650 reverses the VAT liability (HMRC will see this on the next return). The card’s headline £46,220 is the customer-side figure; Finance should use the breakdown row. - Cross-check Stripe:
stripe.stripe_refund_valuefor the same period shows £41,800. The £4,420 gap is PayPal-routed refunds (£3,210) plus 2 manual bank-transfer refunds (£1,210). Sums add up.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin:Reports > Sales > Refunds (Adobe Commerce 2.4.6+). Set the date range to the same period and the “Show By” to “Day” or “Month”. The total at the bottom of the report is the figure to reconcile against. Note that this report usesFor the document-level audit:base_currency(FX-converted) so it will not match this card’sgrand_totalmixed-currency total for international merchants.
Sales > Operations > Credit Memos, sum the “Refunded” column. The grid total at the bottom matches SUM(grand_total) of every Credit Memo in the period.
Why our number may legitimately differ from Adobe Commerce Admin:
Cross-connector reconciliation (when both connectors are connected for this merchant):
Known limitations / merchant FAQs
Why does this card use Credit Memogrand_total instead of orders.total_refunded?
Because total_refunded on the order is a running cumulative; an order refunded in three tranches has a single total_refunded field that grows over time, with no record of the per-event amounts. To get a clean “refund value posted in this period” number, you must sum each Credit Memo’s grand_total by the memo’s own created_at. The legacy stub query SUM(total_refunded) WHERE status=refunded was incorrect for partial-refund cases and is replaced by Credit Memo-side aggregation.
The merchant says we refunded £50,000 but the card shows £46,220, gap?
The £3,780 gap is most often: refunded VAT booked separately by Finance, manual gateway-side refunds without Credit Memos, or a handful of adjustment_negative restocking fees the merchant treats as “refund-in-spirit” but which reduce the customer-paid figure. Walk through the breakdown row (subtotal, shipping_amount, tax_amount, adjustment_negative, adjustment_positive) and reconcile component by component.
Why is shipping refund value separated out?
Because shipping refunds are operationally different. A shipping refund usually means the carrier failed (express upgrade not delivered) which is a fulfilment problem, not a product problem. Knowing 4% of refund value is shipping vs 75% being product lets Operations route the issue correctly.
Multi-currency, can I see refund value in my base currency?
Yes. The card shows grand_total (mixed currency, useful for trend) by default. The breakdown row shows base_grand_total (FX-converted at order time) for accounting. Both are exposed via the API endpoint.
Does this include voucher / store credit refunds?
Yes if the Credit Memo records them as adjustment_positive. Adobe Commerce supports refunding to “Store Credit” instead of to the original payment method; the Credit Memo’s grand_total includes the store-credit portion. If you only want cash refunds, filter on creditmemo.refund_to_store_credit_amount=0 (configurable in the manifest).
Can a Credit Memo be issued on a canceled order?
No. Cancellation reverses authorisation pre-capture; nothing was paid, so nothing can be refunded. Adobe Commerce blocks Credit Memo creation on canceled orders. Cancellation value is captured separately on Cancellation Rate.
Why doesn’t Stripe match this card exactly?
Three causes: (1) PayPal and Authorize.Net refunds are in this card but not in Stripe; (2) manual bank-transfer refunds posted as Credit Memos are in this card but not in Stripe; (3) Stripe-Dashboard-issued refunds without back-filling are in Stripe but not in this card. Sum (Stripe + PayPal + manual) should equal this card to within 1% if process is clean.
My 90-day refund value is £200k, my 30-day is £46k. Why isn’t 30-day a clean third?
Because refunds are seasonal too. Returns spike after Black Friday, January, and post-Christmas. A 30-day window in mid-April is structurally lower than a 30-day in mid-January. Use day-of-week and month-on-month comparisons rather than expecting linear scaling.
A Finance audit shows the GL refund line is higher than this card. What’s wrong?
Most likely Finance is including VAT in the GL refund line at full value (no VAT carve-out) while this card’s GL-friendly view (grand_total - tax_amount) excludes refunded VAT. Or Finance is including unfunded “goodwill” credits that were issued as in-store credit rather than cash refunds. Walk the breakdown.