Refund
A Refund in Salesforce (Refund in the API) is a standard object in Salesforce Order Management and Salesforce Billing that represents money returned to a customer after an Order has been fulfilled or partially fulfilled.
Definition
A Refund in Salesforce (Refund in the API) is a standard object in Salesforce Order Management and Salesforce Billing that represents money returned to a customer after an Order has been fulfilled or partially fulfilled. Each Refund record holds a parent Account, a related PaymentId or PaymentGroupId tracing back to the original tender, an Amount, a Status (Draft, Pending, Processed, Cancelled, Failed), a CurrencyIsoCode, an EffectiveDate, a Type (Cash, Credit, Adjustment), a GatewayRefNumber for the payment processor's confirmation, and an optional reference to the originating Return Order or Credit Memo. Refunds close the financial loop on returns, cancellations, billing disputes, or goodwill credits - every dollar moving from the merchant back to the customer is captured as a Refund record, providing a queryable financial audit trail and a basis for reconciliation against the upstream payment gateway. Refunds integrate with Salesforce Billing's revenue recognition rules to ensure that recognized revenue is appropriately reversed when a refund is processed.
In plain English
“A Refund in Salesforce records money sent back to a customer - for a return, a billing dispute, or a goodwill credit. Each Refund links to the original payment and the gateway transaction so finance can reconcile the books, and to the related Return Order or Case for full audit context.”
Worked example
A customer returns a $200 product they purchased online a week ago. The service agent processes the return through Salesforce Order Management - the system creates a Return Order, marks the Order Product as returned, and triggers a Refund record with Amount = $200, parent Account set to the customer, related PaymentId pointing to the original credit-card payment, Status = Draft. The agent confirms the refund, which submits it to the payment gateway through the configured payment-processor connector. The gateway processes the refund successfully and returns a confirmation; Salesforce updates the Refund's Status to Processed and writes the GatewayRefNumber. The customer's credit card receives a $200 credit within a few business days, and the Refund record sits as the queryable financial record of the transaction reversal.
Why Refund matters
Refunds in Salesforce Order Management are tightly tied to the payment-processor integration. Marking a Refund's Status as Pending triggers a downstream API call to Stripe, Adyen, Braintree, or whichever gateway is configured, and the Refund's Status flows through Pending > Processed (or Failed) based on the gateway response. Direct Status field updates that bypass the integration produce financial records that don't match what actually happened at the gateway - a common source of reconciliation problems for ops teams that fix Refunds manually rather than re-running the integration.
Refunds support both full and partial amounts against the original Payment. A single $1,000 Order can have multiple Refunds totaling up to $1,000 - for example, $200 returned for a defective item and $800 retained for the rest of the order. The PaymentGroup object aggregates Payment + Refund records on a parent Order, providing the running balance and ensuring Refunds never exceed the originally captured Payment amount.
Refunds integrate with Salesforce Billing's revenue-recognition rules. When a Refund is processed against an Order with active revenue schedules (subscription billing, multi-period revenue), the Refund triggers a corresponding revenue reversal in the appropriate accounting period - supporting ASC 606 / IFRS 15 compliance without manual journal entries. This integration is one of the primary reasons commerce orgs adopt Salesforce Billing alongside Order Management.
How to create Refund
Refunds track money returned to customers after an order — returns, cancellations, billing disputes, goodwill credits. Standard object in Order Management and Salesforce Billing. Each Refund links back to a Payment record (the original tender) and optionally to a Return Order or Credit Memo. Provides the financial audit trail for reverse-flow money.
- Confirm Order Management or Salesforce Billing is licensed
Refund is a standard object in those clouds. Standard Sales / Service Cloud doesn't have it.
- Open the Refunds tab (or from an Account → Refunds related list)
App Launcher → Refunds.
- Click New
Top-right.
- Set the Account
Required. The customer receiving the refund.
- Link the original Payment
PaymentId or PaymentGroupId. Traces back to what's being refunded — required for audit and reconciliation.
- Set Amount and Currency
How much, in what currency. Must not exceed the original payment amount.
- Set Status (Draft / Pending / Processed / Cancelled / Failed)
Draft is editable; Processed is the terminal success state.
- Set Type (Cash / Credit / Adjustment)
Cash returns to the original tender. Credit applies as store credit. Adjustment is a write-off, no money moves.
- Set Effective Date
When the refund posts. Drives revenue-recognition reversal.
- Save
Refund is recorded. Salesforce Billing automation may pick it up to reverse recognized revenue and post the gateway transaction.
Required.
Required. Traces to the original tender.
Required.
Required. Draft by default.
- Refund Amount cannot exceed the original Payment Amount. Validation rule fires at save. Multi-line refunds against a single payment require careful tracking.
- Status transitions trigger gateway calls in some configurations. Setting Status = Processed without the actual gateway transaction having succeeded creates a reconciliation gap.
- Refund Type matters for accounting. Cash vs Credit vs Adjustment route through different financial automations — picking the wrong type books revenue incorrectly.
How organizations use Refund
Processes a steady volume of customer-initiated cancellation refunds. Each cancellation creates a Refund linked to the active subscription Payment, the integration auto-submits to Stripe, and revenue recognition reverses the prorated portion of the canceled period - a closed-loop financial workflow with no manual journal entries.
Empowers customer-service agents to issue Refunds up to $500 without manager approval, and above that with an Approval Process. Every Refund is linked back to the originating Return Order and Case, giving finance and ops a queryable audit trail of returns and the reasons behind them.
Uses Refunds to capture goodwill credits when a customer disputes a billing line and the relationship matters more than the dollar amount. Refunds with Type = Adjustment are clearly distinguished from Type = Cash refunds, enabling separate reporting on dispute resolution versus standard returns.
Trust & references
Straight from the source - Salesforce's reference material on Refund.
- Refund in Object Reference for the Salesforce PlatformSalesforce Developer Documentation
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Discussion
Loading discussion…