Rebate Accrual vs. Actual: The Reconciliation Nobody Runs

Why the rebate you accrued rarely equals what the vendor pays, and the reconciliation that catches the gap before it disappears into GL noise.

Twitter LinkedIn WhatsApp
Ask AI: ChatGPT Claude Gemini Grok
Rebate Accrual vs. Actual: The Reconciliation Nobody Runs

Margin drift is the gap between what a vendor contract says and what the invoice actually charges. Rebate accrual is where that gap hides longest, because both sides of the entry are internal estimates until a check arrives.

Most finance teams book an accrual, wait for the payment, and post the variance to a catch-all account without asking why it moved. This guide is about the reconciliation that closes that question instead of writing it off.

Executive Summary

The problem is not that rebate accruals are wrong. It is that nobody checks whether they were wrong, or in which direction, or why. An accrual is a forecast built on last year's purchase volume and this year's assumed tier.

The actual payment is whatever the vendor's own system calculated, against its own read of the same contract. Those two numbers are produced by different people using different data, and the difference between them is treated as a rounding artifact rather than a signal.

The mechanism is straightforward once named: nobody owns the line-by-line comparison between the accrual schedule and the remittance detail. AP posts the check. Accounting closes the variance to a P&L catch-all. Nobody pulls the purchase history the vendor used, checks it against internal volume, or asks whether a tier was misapplied in either direction.

What changes it is a standing reconciliation, run on a fixed cadence, that treats every accrual-to-actual variance as a finding to be explained rather than an entry to be closed. That single habit converts an invisible leak into a recoverable one, and it costs nothing beyond the discipline of running it.

1. Why doesn't the rebate we accrued match what the vendor actually paid?

The accrual and the actual payment are built from two different data sets. Your accrual assumes a purchase volume and a tier as of the accrual date. The vendor's remittance is calculated later, from its own sales system, against its own read of the tier thresholds and any exclusions.

Timing, product mix, and contract interpretation can each move the number independently, and none of them show up unless someone compares the two schedules line by line.

An accrual is forward-looking by design. It is built at month-end or quarter-end from purchase-to-date volume and a projected run rate, applied against the rebate tier the contract implies for the period.

The actual payment is backward-looking. It is calculated once the period closes, from the vendor's own record of what you purchased, in the vendor's own categorization of which SKUs or spend counted toward the tier.

Those two views rarely agree by construction, not by error. A tier threshold crossed in the last week of a quarter, an excluded product line, or a rebate clause with a different measurement period than your fiscal calendar will each produce a variance that looks like noise but is actually information about how the contract is being read on the other side of the table.

2. What causes the gap between the two numbers, mechanically?

Four mechanisms account for most of the divergence: volume measured at different points in time, product or spend categories excluded by the vendor but not by your accrual model, a rebate tier applied against the wrong threshold, and a measurement period that does not align with your fiscal close. Each produces a variance that nets to a dollar figure but carries no explanation unless the underlying schedules are pulled apart.

None of these four require bad faith on either side. They require nobody checking.

A volume-timing mismatch happens when your accrual counts a shipment date and the vendor's system counts an invoice date, or vice versa, shifting purchases across a period boundary.

An exclusion mismatch happens when the contract carves out certain product lines, freight, or taxes from the rebate base, and your accrual model was never updated to exclude them.

A. Tier misapplication

A volume tier is a threshold: cross a dollar amount and the rebate rate steps up for the whole period, or for spend above the threshold, depending on how the clause is written. See volume tier misapplication for how the step calculation itself goes wrong even when the underlying volume is correct. The two errors compound when they occur in the same period, and a variance review that stops at the top-line number will not separate them.

B. Rebate gap as a category

The dollar difference between what a rebate clause entitles you to and what actually posts to the ledger is its own recurring category, distinct from tier misapplication or timing. A rebate gap can exist even when the tier was applied correctly, if the base volume feeding the calculation was wrong. Treating it as a named category, rather than a subset of general AP variance, is what makes it visible on a recurring basis.

3. Who should own the reconciliation, and when should it run?

The reconciliation belongs with whoever owns vendor contract terms, usually procurement or a controller function, not with the AP clerk who posts the check. It should run on the same cadence as the rebate itself is calculated: monthly if the contract measures monthly, quarterly if it measures quarterly, and always before the variance is closed to the general ledger rather than after.

AP's job ends when the check is posted and the accrual is relieved. Nobody downstream of that step is positioned to ask whether the payment was right, because AP does not hold the contract and accounting does not hold the purchase history.

The reconciliation needs both: the accrual schedule with its assumed volume and tier, and the vendor's remittance detail with its stated volume and tier. Comparing them requires pulling the contract's rebate clause and reading it against both.

Running this after the entry has already closed to the P&L means the variance is buried in a period that has ended. Running it before close means a real discrepancy can still be raised with the vendor while the period is open.

4. How does this reconciliation fit with other accounts payable controls?

Standard three-way matching checks that an invoice agrees with a purchase order and a receipt. It was not built to test a rebate calculated after the fact against a threshold that moves with cumulative volume. The rebate accrual reconciliation is a separate control, run on a separate cadence, against a separate data set: the contract's tier schedule and the vendor's own volume reporting, not the individual invoice.

Three-way matching operates at the transaction level: does this invoice match this PO and this receipt. A rebate is not a transaction, it is a cumulative calculation across many transactions, so a control built to catch line-item mismatches has nothing to compare it against.

N-way invoice matching explained covers what that control does test, and where it stops. The gap between the two controls is exactly where rebate leakage survives: individually correct invoices feeding into a period-end calculation nobody is checking.

A quarterly margin drift review is the broader pattern this reconciliation slots into, treating rebate variance as one input among several rather than a standalone project run once and abandoned.

5. What does a rebate accrual reconciliation actually involve, step by step?

Pull the rebate clause language, the accrual schedule used to book the estimate, and the vendor's remittance detail for the period. Recompute the tier from your own purchase records. Compare that recomputed figure to both the accrual and the actual payment, and document the source of any variance rather than posting it to a catch-all account.

The output is a short memo per vendor per period, not a spreadsheet nobody rereads.

Start with the contract clause itself, not a summary of it. Rebate clauses often specify a measurement period, an inclusion or exclusion list, and a tier structure that resets or carries forward, and each detail changes the correct number.

Recompute the volume independently from your own purchase records, in the same categories the contract specifies, rather than trusting either the accrual model's assumptions or the vendor's remittance summary at face value.

Where the recomputed figure disagrees with either side, that disagreement is the finding. Write down which mechanism produced it: timing, exclusion, tier threshold, or measurement period. A variance with a named cause can be raised with the vendor or corrected in the accrual model. A variance closed to a catch-all account cannot.

6. What happens if this reconciliation never runs?

The accrual-to-actual variance keeps posting to a general ledger account nobody reviews line by line, and the underlying cause, whether a tier misapplication, an exclusion, or a timing shift, repeats every period without correction. Over several periods the cumulative gap can be material even when each individual variance looks small enough to ignore, and by the time anyone asks, the purchase history needed to trace it back is harder to reconstruct.

A single quarter's variance is easy to write off as noise. The same mechanism repeating for six quarters is a pattern, but it only reads as a pattern if someone lines the entries up side by side, which the standard close process does not do.

Because the vendor's remittance detail and your own purchase history both age out of easy access, a reconciliation attempted two years later has to be rebuilt from archived records rather than pulled from the current system, which is part of why this reconciliation is worth running on a fixed cadence rather than as a one-time cleanup.

For a broader view of how this variance shows up at the reporting level, building a gross margin bridge that separates the compliance component from ordinary cost inflation is the mechanism that makes an unexplained gap visible to a board or a sponsor in the first place.

For the wider pattern this sits inside, start with the margin drift guide.

7. Frequently Asked Questions (People Also Ask)

What is a rebate accrual reconciliation?

It is a line-by-line comparison between the rebate amount your accounting team accrued for a period and the amount the vendor actually paid, run against the contract's rebate clause to identify which mechanism, such as timing, exclusions, or tier thresholds, produced any difference between the two.

Why does the accrued rebate almost never match the actual payment exactly?

The accrual is a forecast built from purchase-to-date volume before the period closes. The actual payment is calculated afterward from the vendor's own sales records and its own read of the contract's tier and exclusion terms. Different data sets and different measurement points produce a variance even when both sides are calculated in good faith.

Where should the accrual-to-actual variance be posted?

Not to a catch-all variance account without explanation. Each variance should be traced to a named cause, such as a tier misapplication or a timing mismatch, before it is closed, so that a repeating cause can be identified and corrected rather than re-posted every period.

How often should this reconciliation run?

On the same cadence the rebate itself is calculated under the contract, monthly or quarterly, and before the period's variance closes to the general ledger. Running it after close means a genuine discrepancy can no longer be raised with the vendor for that period.

Is this the same thing as three-way invoice matching?

No. Three-way matching compares an individual invoice to a purchase order and a receipt. A rebate is a cumulative calculation across many invoices measured against a volume tier, so it needs a separate reconciliation against the contract's rebate schedule and the vendor's remittance detail.

Who inside a finance team should own this reconciliation?

Whoever holds the vendor contract terms, typically procurement or a controller function, since the reconciliation requires reading the rebate clause alongside the purchase history. AP, which only posts the check, is not positioned to judge whether the payment itself was calculated correctly.

What is the difference between a rebate gap and a tier misapplication?

A tier misapplication is a specific cause: the wrong threshold or rate was applied to a period's volume. A rebate gap is the resulting dollar difference between contractual entitlement and what actually posted, which can also be caused by exclusions, timing, or a measurement period mismatch, not tier errors alone.

Can this reconciliation be done in a spreadsheet, or does it need software?

The reconciliation itself is a spreadsheet exercise: pulling the contract clause, the accrual schedule, and the remittance detail into one comparison. What is missing in most companies is not tooling but the standing habit of running it every period rather than only when a number looks unusually large.

What is the legal risk if we discover a vendor underpaid a rebate?

Raising a documented variance with a vendor is a commercial conversation, not a legal one, provided the contract clause is read correctly. This is general information, not legal advice, and any dispute over contract interpretation should be reviewed with counsel before a formal claim is made.

Executive Summary

The problem is not that rebate accruals are wrong. It is that nobody checks whether they were wrong, or in which direction, or why. An accrual is a forecast built on last year's purchase volume and this year's assumed tier. The actual payment is whatever the vendor's own system calculated, against its own read of the same contract. Those two numbers are produced by different people using different data, and the difference between them is treated as a rounding artifact rather than a signal. The mechanism is straightforward once named: nobody owns the line-by-line comparison between the accrual schedule and the remittance detail. AP posts the check. Accounting closes the variance to a P&L catch-all. Nobody pulls the purchase history the vendor used, checks it against internal volume, or asks whether a tier was misapplied in either direction. What changes it is a standing reconciliation, run on a fixed cadence, that treats every accrual-to-actual variance as a finding to be explained rather than an entry to be closed. That single habit converts an invisible leak into a recoverable one, and it costs nothing beyond the discipline of running it.

1. Why doesn't the rebate we accrued match what the vendor actually paid?

The accrual and the actual payment are built from two different data sets. Your accrual assumes a purchase volume and a tier as of the accrual date. The vendor's remittance is calculated later, from its own sales system, against its own read of the tier thresholds and any exclusions. Timing, product mix, and contract interpretation can each move the number independently, and none of them show up unless someone compares the two schedules line by line. An accrual is forward-looking by design. It is built at month-end or quarter-end from purchase-to-date volume and a projected run rate, applied against the rebate tier the contract implies for the period. The actual payment is backward-looking. It is calculated once the period closes, from the vendor's own record of what you purchased, in the vendor's own categorization of which SKUs or spend counted toward the tier. Those two views rarely agree by construction, not by error. A tier threshold crossed in the last week of a quarter, an excluded product line, or a rebate clause with a different measurement period than your fiscal calendar will each produce a variance that looks like noise but is actually information about how the contract is being read on the other side of the table.

2. What causes the gap between the two numbers, mechanically?

Four mechanisms account for most of the divergence: volume measured at different points in time, product or spend categories excluded by the vendor but not by your accrual model, a rebate tier applied against the wrong threshold, and a measurement period that does not align with your fiscal close. Each produces a variance that nets to a dollar figure but carries no explanation unless the underlying schedules are pulled apart. None of these four require bad faith on either side. They require nobody checking. A volume-timing mismatch happens when your accrual counts a shipment date and the vendor's system counts an invoice date, or vice versa, shifting purchases across a period boundary. An exclusion mismatch happens when the contract carves out certain product lines, freight, or taxes from the rebate base, and your accrual model was never updated to exclude them. ### A. Tier misapplication A volume tier is a threshold: cross a dollar amount and the rebate rate steps up for the whole period, or for spend above the threshold, depending on how the clause is written. See [volume tier misapplication](/glossary/volume-tier-misapplication) for how the step calculation itself goes wrong even when the underlying volume is correct. The two errors compound when they occur in the same period, and a variance review that stops at the top-line number will not separate them. ### B. Rebate gap as a category The dollar difference between what a rebate clause entitles you to and what actually posts to the ledger is its own recurring category, distinct from tier misapplication or timing. A [rebate gap](/glossary/rebate-gap) can exist even when the tier was applied correctly, if the base volume feeding the calculation was wrong. Treating it as a named category, rather than a subset of general AP variance, is what makes it visible on a recurring basis.

3. Who should own the reconciliation, and when should it run?

The reconciliation belongs with whoever owns vendor contract terms, usually procurement or a controller function, not with the AP clerk who posts the check. It should run on the same cadence as the rebate itself is calculated: monthly if the contract measures monthly, quarterly if it measures quarterly, and always before the variance is closed to the general ledger rather than after. AP's job ends when the check is posted and the accrual is relieved. Nobody downstream of that step is positioned to ask whether the payment was right, because AP does not hold the contract and accounting does not hold the purchase history. The reconciliation needs both: the accrual schedule with its assumed volume and tier, and the vendor's remittance detail with its stated volume and tier. Comparing them requires pulling the contract's rebate clause and reading it against both. Running this after the entry has already closed to the P&L means the variance is buried in a period that has ended. Running it before close means a real discrepancy can still be raised with the vendor while the period is open.

4. How does this reconciliation fit with other accounts payable controls?

Standard three-way matching checks that an invoice agrees with a purchase order and a receipt. It was not built to test a rebate calculated after the fact against a threshold that moves with cumulative volume. The rebate accrual reconciliation is a separate control, run on a separate cadence, against a separate data set: the contract's tier schedule and the vendor's own volume reporting, not the individual invoice. Three-way matching operates at the transaction level: does this invoice match this PO and this receipt. A rebate is not a transaction, it is a cumulative calculation across many transactions, so a control built to catch line-item mismatches has nothing to compare it against. [N-way invoice matching explained](/guides/n-way-invoice-matching-explained) covers what that control does test, and where it stops. The gap between the two controls is exactly where rebate leakage survives: individually correct invoices feeding into a period-end calculation nobody is checking. A [quarterly margin drift review](/guides/the-quarterly-margin-drift-review-a-control-design-pattern) is the broader pattern this reconciliation slots into, treating rebate variance as one input among several rather than a standalone project run once and abandoned.

5. What does a rebate accrual reconciliation actually involve, step by step?

Pull the rebate clause language, the accrual schedule used to book the estimate, and the vendor's remittance detail for the period. Recompute the tier from your own purchase records. Compare that recomputed figure to both the accrual and the actual payment, and document the source of any variance rather than posting it to a catch-all account. The output is a short memo per vendor per period, not a spreadsheet nobody rereads. Start with the contract clause itself, not a summary of it. Rebate clauses often specify a measurement period, an inclusion or exclusion list, and a tier structure that resets or carries forward, and each detail changes the correct number. Recompute the volume independently from your own purchase records, in the same categories the contract specifies, rather than trusting either the accrual model's assumptions or the vendor's remittance summary at face value. Where the recomputed figure disagrees with either side, that disagreement is the finding. Write down which mechanism produced it: timing, exclusion, tier threshold, or measurement period. A variance with a named cause can be raised with the vendor or corrected in the accrual model. A variance closed to a catch-all account cannot.

6. What happens if this reconciliation never runs?

The accrual-to-actual variance keeps posting to a general ledger account nobody reviews line by line, and the underlying cause, whether a tier misapplication, an exclusion, or a timing shift, repeats every period without correction. Over several periods the cumulative gap can be material even when each individual variance looks small enough to ignore, and by the time anyone asks, the purchase history needed to trace it back is harder to reconstruct. A single quarter's variance is easy to write off as noise. The same mechanism repeating for six quarters is a pattern, but it only reads as a pattern if someone lines the entries up side by side, which the standard close process does not do. Because the vendor's remittance detail and your own purchase history both age out of easy access, a reconciliation attempted two years later has to be rebuilt from archived records rather than pulled from the current system, which is part of why this reconciliation is worth running on a fixed cadence rather than as a one-time cleanup. For a broader view of how this variance shows up at the reporting level, [building a gross margin bridge](/guides/building-a-gross-margin-bridge-that-separates-inflation-from) that separates the compliance component from ordinary cost inflation is the mechanism that makes an unexplained gap visible to a board or a sponsor in the first place. For the wider pattern this sits inside, start with the [margin drift](/guides/contract-compliance-controls-p2p) guide.

Questions & Answers

What is a rebate accrual reconciliation?

It is a line-by-line comparison between the rebate amount your accounting team accrued for a period and the amount the vendor actually paid, run against the contract's rebate clause to identify which mechanism, such as timing, exclusions, or tier thresholds, produced any difference between the two.

Why does the accrued rebate almost never match the actual payment exactly?

The accrual is a forecast built from purchase-to-date volume before the period closes. The actual payment is calculated afterward from the vendor's own sales records and its own read of the contract's tier and exclusion terms. Different data sets and different measurement points produce a variance even when both sides are calculated in good faith.

Where should the accrual-to-actual variance be posted?

Not to a catch-all variance account without explanation. Each variance should be traced to a named cause, such as a tier misapplication or a timing mismatch, before it is closed, so that a repeating cause can be identified and corrected rather than re-posted every period.

How often should this reconciliation run?

On the same cadence the rebate itself is calculated under the contract, monthly or quarterly, and before the period's variance closes to the general ledger. Running it after close means a genuine discrepancy can no longer be raised with the vendor for that period.

Is this the same thing as three-way invoice matching?

No. Three-way matching compares an individual invoice to a purchase order and a receipt. A rebate is a cumulative calculation across many invoices measured against a volume tier, so it needs a separate reconciliation against the contract's rebate schedule and the vendor's remittance detail.

Margin Drift Resources