Rebate Management Setup
Activate when configuring Salesforce Rebate Management for channel incentive programs: volume rebates, growth rebates, market-development funds (MDF), SPIFs, and partner co-op programs. Rebate Management is a distinct feature from CPQ discounting — it calculates after-the-fact incentives based on transactions, not at quote time.
Before Starting
- Confirm Rebate Management license and edition. It is a paid add-on: "Rebate Management is available in Lightning Experience. Available in: Enterprise, Unlimited, and Developer Editions." The object model ships as standard objects (
RebateProgram,ProgramRebateType,TransactionJournal, …) that appear only when the feature is provisioned — none of them are custom objects and none carry a__csuffix. - Identify the source of transactions. Rebates calculate against
TransactionJournalrecords — sourced from Orders, Invoices, a POS feed, or a data warehouse extract. This source drives the ingestion pipeline. - Know the finance control requirements. Most rebate programs require accounting sign-off before payout. Approval routing and GL integration must be designed before program go-live.
Core Concepts
Program → Rebate Type → Benefit → Payout
RebateProgram (API 51.0+) is the top-level container — "The rebate program your organization runs with a single account, all accounts, or specific list of accounts." ProgramRebateType is what is measured: "Provide the rebate types that are part of this program. For example, volume rebate, revenue rebate, or rebate on every transaction." ProgramRebateTypeBenefit "Defines the benefit matrix for the rebate type. For example, 5% or $200." RebateProgramMemberPayout is "The payout calculated for a member for the period," and RebateProgramPayoutPeriod is "The period of the payout calculation."
Eligibility and scope hang off the rebate type: ProgramRebateTypEligibility (note the truncated API name) holds "the rules and criteria to determine rebate type eligibility and terms for calculating payouts," ProgramRebateTypeFilter is "The definition that filters the transaction journals eligible for a rebate type," and ProgramRebateTypeProduct is "a junction between a program rebate type and a product."
Accrual accounting
Between the period start and close, Rebate Management posts accruals — estimates of the liability as transactions come in. On period close, accruals reconcile to actual payouts. Accrual frequency (daily, weekly, monthly) is a finance decision.
Transaction ingestion
TransactionJournal records are the fuel — "The transactions that need to be processed for a rebate program." They come from CG Cloud orders, Revenue Cloud invoices, Data Cloud feeds, CSV loads (ReceivedDocument "Allows partners to upload .CSV document"), or custom integrations. Schema matters — amount, participant, product, and date are what the calculation aggregates. Results land in RebateMemberProductAggregate, which "Stores the post calculation summary of journal transactions by member, period, and rebate type," with RebateMemberAggregateItem as the junction back to each contributing TransactionJournal.
Common Patterns
Pattern: Volume-tier rebate with quarterly payout
RebateProgram with a volume ProgramRebateType, and ProgramRebateTypeBenefit rows defining tier thresholds (1–1000 units → 2%, 1001–5000 → 3%, 5000+ → 5%). TransactionJournal records accumulate through the quarter. At period close, calculation runs against the RebateProgramPayoutPeriod, RebateProgramMemberPayout rows are generated, approval routes to finance, then GL posts via RebatePayment, which "Tracks if the payment has been generated for this member for back end processing."
Pattern: Growth rebate vs prior period
Benefit tied to % growth vs the same participant's prior quarter. Requires reference data on prior period baseline. Flow or a scheduled Apex sets the baseline at period start.
Pattern: MDF with manual claim approval
Participant submits an MDF claim (via portal LWC). The manual, off-calculation amount is a RebatePayoutAdjustment — "Rebate amount adjustment that needs to be given manually" — rather than a calculated RebateProgramMemberPayout. Approval + receipt review before payout. (RebateClaim and RebateClaimAdjustment are the ship-and-debit claim objects, a different program shape.)
Decision Guidance
| Situation | Recommended Approach | Reason |
|---|---|---|
| Quote-time discount | CPQ discount schedules | Applied before deal signs |
| After-sale volume rebate | Rebate Management | Calculates against delivered transactions |
| MDF / co-op claims | Rebate Management with manual payout | Shipped claim workflow |
| Loyalty point rewards | Loyalty Management | Distinct product |
| Simple referral SPIF | Rebate Management flat benefit | Overkill for ad-hoc, use Rebate anyway for audit |
Recommended Workflow
- Provision the license; confirm Rebate Management objects are visible in Object Manager.
- Map transaction source systems; build the
TransactionJournalingestion job (daily recommended). - Design programs: volume, growth, MDF — one
RebateProgramper program for auditability, with aProgramRebateTypeper measure. - Configure
ProgramRebateTypeBenefitthresholds andProgramRebateTypEligibilitycriteria; validate with sample journals through a scratch-org dry run. - Set accrual cadence and validate with finance; set up GL posting integration.
- Build partner visibility: Experience Cloud page showing year-to-date accrued rebate, tier progress.
- Run a full period-close dry run: accruals → calculation → approval → payout → GL post.
Review Checklist
- Rebate Management license provisioned and objects visible
- Transaction ingestion validated end-to-end
-
RebateProgram→ProgramRebateType→ProgramRebateTypeBenefitstructure matches contract - Accrual cadence signed off by finance
- Approval routing in place before first payout
- Partner portal shows accurate year-to-date figures
- Audit report: traceable from payout back to source transactions
Salesforce-Specific Gotchas
- Rebate recalculation is not retroactive unless forced. Fixing a Benefit threshold after accruals have posted requires a manual recalc job; partners may see shifting balances.
- Transaction date drives period assignment. Out-of-order backfills can hit closed periods — either reopen for recalc or post as a next-period adjustment.
- Experience Cloud rebate widgets depend on the Benefit Accrual snapshot. If the snapshot job fails, partner portals show stale numbers with no obvious error.
Output Artifacts
| Artifact | Description |
|---|---|
| Rebate program catalog | Active programs, benefit structures, participants |
| Transaction ingestion spec | Source, schema, schedule, error handling |
| Accrual and payout runbook | Period open/close procedure |
| Partner visibility page | LWC / Experience Cloud layout showing YTD rebate |
Related Skills
admin/cpq-pricing-rules— quote-time discount siblingadmin/experience-cloud-site-setup— partner portal hostadmin/integration-pattern-selection— transaction ingestion