What to Ask Your ERP Vendor About Rebate Accounting (Before Signing Anything)

Last updated: November 11, 2026

The rebate module demo goes well. The vendor’s sales engineer walks through the rate table setup, shows how purchase volumes accumulate against agreement thresholds, and runs a summary report. The team is satisfied: yes, the system tracks rebates. The evaluation moves forward.

What just happened is not a governance review. It is a functionality review. And in the context of rebate accounting under ASC 705-20, those are two very different things.

This article is about the gap between them — and the five questions that surface it.

---

Why the Standard Demo Does Not Answer the Right Question

Consider an illustrative scenario: a mid-sized wholesale distributor signs off on an ERP renewal after a solid demo. Twelve months later, the company is in a settlement dispute with a manufacturer over whether a mid-year tier threshold was crossed. The ERP shows the current accrual balance. It does not show the rate that was in effect when the threshold was crossed, because that rate was updated and the prior version was overwritten. There is no audit trail connecting the COGS entry to the original agreement terms. The dispute takes months to resolve.

The demo never covered this scenario because ERP demos are designed to show normal operation. They show rate entry, volume accumulation, and reporting. They do not show what happens when:

• An agreement’s terms change mid-year and the prior terms need to be auditable
• An auditor asks for period-end documentation linking a COGS entry to its source agreement
• A retroactive tier threshold is crossed and the accrual for prior periods needs to be recast
• A year-end settlement reconciliation requires comparing the manufacturer’s calculation against the distributor’s line by line
• A rebate program spans multiple product lines, divisions, or ERP modules

These scenarios don’t come up in a standard demo. They come up under audit pressure and during settlement disputes — which is exactly when the gap becomes expensive.

Under ASC 705-20-25-1, rebates from vendors are required to reduce the cost of products purchased from that vendor. The accounting treatment is not optional and not estimable without documented agreement terms. Under ASC 705-20-25-10, if the amount of a rebate cannot be reasonably estimated, the rebate should be recognized only when it is received. The governance infrastructure — version-controlled terms, period-end audit trails, settlement reconciliation workflows — is what makes “reasonably estimated” defensible. Without it, the accrual is a number without a foundation.

---

Five Questions to Ask Your ERP Vendor

The following questions are designed to separate a system that tracks rebates from a system that governs them. Ask each one in the demo or the renewal conversation. Listen for the difference between a good answer and a sales answer.

---

Question 1: When a rebate agreement’s terms change mid-year, what happens to the prior-period history?

What a good answer sounds like: The system version-controls agreement terms. When a rate is updated, the prior version is retained with a timestamp and a record of who made the change. Prior-period accruals are calculated against the terms that were in effect at the time, not the current rate.

What a sales answer sounds like: You update the rate in the system and it’s reflected going forward.

Why it matters: If overwriting a rate erases the prior version, there is no audit trail for the period when the old terms were in effect. Under ASC 705-20-25-1, the accrual must reflect the terms of the agreement. If the terms can’t be reconstructed, neither can the accrual. Any future dispute about what was owed in a prior period becomes unresolvable.

---

Question 2: What does the period-end accrual audit trail look like — specifically, what can I show an auditor that connects the COGS entry to the source agreement and the volume data?

What a good answer sounds like: The system maintains a per-agreement ledger showing each period-end accrual entry: the amount, the rate used, the volume assumption driving the calculation, and the user who posted it. This can be exported and provided directly to an auditor.

What a sales answer sounds like: You can run the rebate report and filter by vendor or program.

Why it matters: A report is not an audit trail. A report shows the current state of the data. An audit trail shows how each entry was derived and when. The difference becomes critical under ASC 705-20-25-10, where the supportability of an accrual estimate depends on documented assumptions — not just a final number.

---

Question 3: Does the system support retroactive tiering — and if so, how does it handle the cumulative recast?

What a good answer sounds like: When a volume threshold is crossed that triggers a higher tier rate, the system automatically recasts the full period-to-date accrual at the new rate, with the revised calculation documented in the audit trail alongside the original.

What a sales answer sounds like: You can configure tier levels in the rate table and the system will apply the right rate once the threshold is reached.

Why it matters: Configuration tells you what the system can be set up to do. The question is what the system actually does when the threshold is crossed in month seven of a twelve-month program. A retroactive tier recast can materially change the accrual for all prior periods in the year. If the system doesn’t handle the recast automatically — or doesn’t document it — the distributor carries the error manually. That manual correction is a gap. It’s also an ASC 705-20 exposure, because an underdeclared accrual represents understated COGS in the periods before the recast.

---

Question 4: What does the year-end settlement reconciliation workflow look like?

What a good answer sounds like: The system has a settlement module or formal workflow where the manufacturer’s settlement statement can be entered and compared line by line against the distributor’s calculation, with exceptions flagged and a documented resolution path.

What a sales answer sounds like: You can run a reconciliation report at year-end.

Why it matters: A report is output. A workflow is a process. The question is whether the system supports the act of reconciliation — entering the manufacturer’s number, comparing it to the accrued amount, identifying the variance, documenting the resolution — or whether it only supports generating a report that a human must then reconcile manually in a spreadsheet. The latter is not a settlement workflow. It is a data export.

As documented in Rebate Accrual Close Failures: What Goes Wrong at Period-End, the settlement step is where most rebate accounting errors become visible. A system without a settlement workflow doesn’t prevent those errors; it just doesn’t surface them until they appear as a check that doesn’t match.

---

Question 5: How does the system handle rebate programs that span multiple product lines or business units?

What a good answer sounds like: The rebate program is defined at the agreement level. Eligible SKUs can be selected from any product classification or business unit within the system. Volume accumulates across the full eligible pool automatically, with no manual aggregation required.

What a sales answer sounds like: You can configure multiple rate tables, one per product line.

Why it matters: Multiple rate tables is a workaround. It means the rebate program as the manufacturer designed it — a single program covering your entire eligible purchase volume — has been fragmented across multiple system constructs to accommodate the ERP’s data model. The result is that cross-unit volume accumulation requires manual aggregation, the settlement document doesn’t match the ERP’s output, and the audit trail is split across multiple program records. The question is whether the program definition in the ERP matches the program definition in the agreement. If it doesn’t, every accrual calculation is a reconciliation problem waiting to happen.

---

How CAS Advisors Can Use This Framework

A CAS partner engaged for close support or systems advisory work at a distribution client can run these five questions as a governance diagnostic without waiting for an ERP renewal.

The process is straightforward: for each question, assess whether the client’s current ERP gives a good answer or a sales answer. The sum of the gaps is the governance gap. A client whose ERP gives sales answers to all five questions is operating with a rebate accounting infrastructure that cannot be audited, cannot support a settlement dispute, and cannot produce defensible accrual entries under ASC 705-20-25-1 and 705-20-25-10.

That gap is not a configuration problem, as explored in What Governed Rebate Accounting Looks Like. It is an architectural one. Configuration adjusts what a system does within its design. A system designed to track rebates without governing them cannot be configured into a governance tool.

The ERP Rebate Gap Assessment maps this diagnostic directly — it identifies which of the five governance dimensions a given ERP system supports and where the gaps require a supplemental layer.

---

Running the Diagnostic Without the Vendor Conversation

If your client is not in an active ERP renewal, you don’t need a vendor conversation to run this diagnostic. The gap assessment identifies the same governance dimensions based on how the system currently behaves — not what the vendor claims it can do.

The five questions above are most useful as a framework for conversations your client’s team has already had (or should have) with their ERP vendor. The answers — whatever they are — tell you exactly where the rebate accounting risk sits and what it would take to close it.

That is the starting point for any serious rebate governance engagement.

Run the ERP Rebate Gap Assessment →

For current Aurgus pricing, see aurgus.com/pricing/.