Distributors managing 20 or more vendor programs spend weeks every period assembling reconciliations that auditors will test in a day. Aurgus is vendor rebate reconciliation software built for wholesale distribution — every accrual tied to its source, every settlement compared automatically, every calculation reproducible on demand.
$600/month — see full pricing ↗The reconciliation problem is not an accounting problem. It is an assembly problem. When the data lives across ERP exports, PDFs, and manually maintained spreadsheet tabs, the work before the entry consumes the close.
Tiered rebate structures depend on cumulative YTD purchase volumes. A mid-year program change — a new tier bracket, a retroactive rate adjustment, a vendor adding a product category — forces you to recompute from January 1. In a spreadsheet, that is a rebuild, not an update.
Your ERP accrual, your rebate-module estimate, and your finance spreadsheet are each computed from a different data snapshot at a different time. All three are "correct" by their own logic. None of them match. The reconciliation is the work of explaining why.
Defending a rebate accrual to auditors means reconstructing the calculation from PDFs, condition records, and the person who built the file. When PCAOB-inspected firms ask for calculation lineage on vendor rebate estimates — which they increasingly do — screenshots and formula references are not an answer.
Not sure how deep your ERP gap runs? Take the 2-minute ERP Rebate Gap Assessment →
Accruals are recorded continuously; vendor checks and credit memos arrive quarterly or annually. Matching each settlement to the accrual it closes — and computing the true-up entry — requires a comparison that most teams run manually, line by line, each time a check lands.
Aurgus replaces the manual assembly work with a continuous, event-sourced calculation. The reconciliation is not produced at close — it is a by-product of normal operation.
Upload your vendor rebate contracts once. Aurgus encodes every tier, threshold, retroactive rule, and effective date. Mid-year changes are appended as events — the original terms are preserved, and the system recomputes history automatically without destroying what was there before.
As ERP data lands — from SAP, NetSuite, Dynamics, or any CSV export — Aurgus recomputes each vendor's earned rebate against current YTD purchase volume. The accrual balance is always current; it is not assembled at the end of the period from a stale export.
Each accrual event is tagged to the agreement, the tier bracket, the condition record, the source purchase row, and the data snapshot that produced it. "Show me how that $3.87M was calculated" is answered by querying the event log — not by calling the analyst who ran the spreadsheet.
When a vendor check or credit memo arrives, it is recorded as a settlement event. Aurgus computes the difference between what was accrued and what was received. The true-up entry and its calculation are produced as part of normal operation — not a separate reconciliation sprint.
Every calculation event is exportable as a CSV with full lineage to source purchase rows. What auditors receive is the same governed output the controller reviewed at close — not a reconstruction produced after the fact.
| Reconciliation task | Spreadsheet | Aurgus |
|---|---|---|
| Recompute vendor tiers from YTD purchase history | Manual rebuild each period | Runs as data lands |
| Mid-year program change → retroactive recalculation | Full master file rebuild | Recompute from stored event chain |
| Accrual-to-settlement matching | Manual line-by-line each settlement | Settlement event appended; diff computed |
| Audit lineage: entry → source PO line | Assembled the week auditors arrive | Side-effect of normal operation |
| Multi-vendor, multi-location portfolio | One tab per vendor; one file per location | Single governed ledger across all programs |
| Number reproducibility | Requires the analyst who built it | Queryable from the calculation event log |
Under ASC 705-20, vendor rebates received by a distributor reduce cost of goods sold (COGS) — not revenue, not other income — as the underlying goods are sold. The standard requires that rebates contingent on cumulative purchase volume be accrued systematically and adjusted when estimates change (ASC 705-20-25-10 through 25-12).
What that means operationally: the accrual balance on your books must be supportable by a calculation that traces back to actual purchase data and contract terms. That is a reconciliation requirement. When audit teams test vendor rebate balances, they are asking two questions:
The second question is a reconciliation question. A well-structured accrual estimate that cannot be reproduced from source data is not defensible under PCAOB inspection standards — a standard that now explicitly flags vendor rebate estimates as a high-risk variable consideration area.
The direction of the entry is determined by the nature of the arrangement, not the form of payment.
| Arrangement type | Codification | Entry direction |
|---|---|---|
| Purchase rebate / volume allowance received from vendor | ASC 705-20 | Reduce COGS → Inventory as goods sell |
| Customer rebate / promotional allowance paid to customer | ASC 606-10-32 | Reduce revenue → Variable consideration |
| Advertising/promotional services at fair value from vendor | ASC 705-20 exception | Other income — fair value of service only |
Aurgus encodes the COGS direction rule into the calculation engine and produces a reconciliation — accrual to purchase data to settlement — that is the documentation auditors need. Your CPA reviews a governed output. They do not rebuild it.
Bring one vendor program as a workbook. Watch it calculated, reconciled, and traced to source, live. No annual commitment. No enterprise sales process.
Book a demo →Written to answer the questions practitioners actually search — and the ones auditors actually ask.
Rebate reconciliation in accounting is the process of matching every accrued rebate amount — the estimate recorded in the books during the period — against the actual consideration received from a vendor (check, credit memo, or offset against payables).
The reconciliation confirms that: (1) the accrual was calculated correctly from purchase data and contract terms, (2) the settlement matches what was earned, and (3) any difference is explained as a true-up entry.
Under ASC 705-20, the reconciled amount reduces cost of goods sold (COGS), not revenue — so the reconciliation also validates the direction of every entry. For wholesale distributors, this process runs across every active vendor program every period.
Wholesale distributors typically reconcile supplier rebates in five steps:
With 20 or more active vendor programs, this process becomes a multi-week manual assembly task when done in spreadsheets. Dedicated rebate reconciliation software replaces steps 1–4 with a continuous, automated calculation — producing a reconciled ledger as a by-product of normal operation rather than a month-end sprint.
A rebate accrual is an estimate: the amount a distributor believes it has earned under a vendor agreement as of a point in time, recorded as a receivable or cost reduction before the vendor has paid.
Rebate reconciliation is the validation step: comparing that accrual to the supporting purchase data, the contract calculation, and the eventual vendor settlement to confirm the estimate was correct — or computing a true-up if it was not.
Accruals are recorded every period. Reconciliation closes the loop when settlements arrive — and when auditors review the balance. Many distributors close the books with accurate-enough accruals but discover the underlying calculation is not reproducible. That reproducibility gap is what auditors test.
ASC 705-20 (Accounting Standards Codification Topic 705-20, "Accounting for Consideration Received from a Vendor") requires that cash consideration received from a vendor — including purchase rebates and volume allowances — be recognized as a reduction of cost of goods sold (COGS), not as revenue or other income, unless a narrow exception applies.
Under ASC 705-20-25-10, a rebate contingent on cumulative purchase levels must be accrued systematically as purchases are made, provided the amount is probable and reasonably estimable. This creates a reconciliation obligation: the accrued COGS reduction must tie back to the purchase data and contract terms that support the estimate.
When auditors test vendor rebates under PCAOB standards, they are testing both the direction of the entry (COGS, not revenue) and the supportability of the accrual balance — which is a reconciliation question. A balance that cannot be traced to its source calculation is not defensible, regardless of whether the number itself is approximately correct.
Primary guidance: ASC 705-20-25-1 through 25-12. Not accounting advice — verify with your auditors.
Spreadsheet-based rebate reconciliation breaks down at scale in predictable ways:
Rebuilds instead of updates. A mid-year program change — retroactive tier adjustment, new product category, buying group realignment — requires rebuilding the master file from January 1. There is no stored event chain to recompute from; the entire spreadsheet is the state.
Lineage lives in formula logic. The audit trail for a cell value is the formula behind it, which requires the person who built the spreadsheet to explain it. When that person is unavailable, the number cannot be defended to an auditor.
Version control is informal. The file submitted to auditors may not match the version finance modeled two weeks earlier — and there is no automatic record of what changed between them.
At 20 or more active vendor agreements, the assembly work before close becomes the bottleneck — not the accounting entry itself.