Matching a deduction to an accrual
Oracle's rules try an open AR credit first, then unpaid accruals by PAD number. See what that order depends on and which deductions fall outside it.
If your finance team is deciding whether to rely on rule-based matching of customer deductions to promotional accruals, we would first test your deduction mix against the order the rules follow: an open AR credit first, then an unpaid accrual found through a PAD number. That recommendation rests on Oracle’s Trade Management and Receivables documentation, which sets out the sequence and its scope.
When a deduction shows up as a short pay against a promotion
If your retailers and distributors short pay invoices and cite a promotion, the first question is what reference they give you. Oracle’s Trade Management documentation says distributors cite a promotion ID or a pre-authorized (PAD) debit memo number on claims against offers and price protection agreements. If your deductions arrive without either reference, we would treat them as a separate population from the start.
Oracle’s documentation says deductions are created in Oracle Receivables, and you can view and settle them in Oracle Trade Management. If your open items sit on one side of that split and your accruals on the other, matching has to connect them.
What do the rules check, and in what order?
Oracle’s Trade Management documentation says the Rule Based Settlement Engine concurrent program first looks to match deductions with an Accounts Receivables credit. If it cannot find a credit match, it looks to match deductions with unpaid accruals based on the PAD number the distributor provided on the claim. The accrual step is therefore a fallback, and it depends on the distributor supplying that number.
The rules are configured, not assumed. Oracle’s documentation says you enter values in fields to define rules for automatic matching of claims and deductions with open AR credits and unpaid accruals due to customers. Thresholds set in that setup determine which possible matches with open credits or unpaid accruals are found.
Scope matters too. Oracle’s documentation says the trade profile values determine customer eligibility and the threshold for unearned payments for offers, and that they affect all promotional claims and deductions except those related to Scan Data offers. Where a claim or deduction is linked to accruals and settled by credit memo, Oracle’s Trade Management documentation says entries are created for Debit Liabilities and Credit Receivables.
Does your deduction mix fit this logic?
The decision is whether enough of your deductions carry the references and sit inside the scope this logic expects. The table is our proposal for how to frame it.
| Option | We would choose it when | What we would check first |
|---|---|---|
| Rule-based matching, credits then accruals | Most promotional deductions carry a PAD or promotion reference | Sample recent deductions and count those with a reference |
| Rule-based matching with manual review of exceptions | Some deductions carry no usable reference | Who reviews the unmatched items and how fast |
| Separate path for Scan Data offers | Scan Data offers are part of your promotion program | Which deductions relate to those offers |
| Hold off on configuration | The deduction mix is mostly non-promotional | Which reason codes fall outside promotional claims |
What to do this quarter
These steps are our proposal.
- Pull a sample of recent deductions and tag each as promotional, Scan Data related or other.
- Count how many carry a PAD number or promotion ID.
- Name one owner for unmatched deductions and one record per exception.
- Draft the threshold values you would test, and have finance approve them.
- Measure matched versus unmatched items before and after any configuration change.
What this means for a bottleneck worth $1M or more
When deductions tied to promotions hold up cash and clutter your open items, the matching order is only one part of the domain. We would redesign the whole flow as one domain: rules for the predictable matches, AI for the messy remittance and claim text, and people for consequential decisions such as write-offs. AI never decides alone. See how this fits deductions and disputes and how we work in our approach.
Limits of this evidence
The sources do not show match rates, accuracy, time saved or how often PAD-based matching succeeds. Only Oracle documentation describes the matching logic, and it does not cover what happens to a deduction with no PAD number and no AR credit match, nor match rates. No threshold values or recommended configurations are given. They include no customer outcomes, timelines or costs.
Questions buyers ask
In what order does Oracle try to match a deduction?
Oracle's documentation says the Rule Based Settlement Engine first looks for a matching Accounts Receivables credit. If it finds none, it looks for unpaid accruals based on the PAD number the distributor provided on the claim.
Are Scan Data offers covered by rule-based settlement?
Oracle's documentation says the trade profile values do not affect claims and deductions related to Scan Data offers.
What does a distributor cite on a promotion claim?
Oracle's documentation says distributors cite a promotion ID or a pre-authorized (PAD) debit memo number on claims against offers and price protection agreements.
Sources
Sources give context. Dates show when each was last checked.