A rebate audit trail that survives the second question.
The PBC list just landed, or the CFO asked the short version: “support this rebate accrual balance.” And the support is a spreadsheet, a folder of agreement PDFs, and one analyst who remembers why Q2 was adjusted. That combination answers the first question. It rarely survives the second — show me the transactions behind this number, and show me you’d get the same answer if you ran it again. This page is about what a rebate audit trail actually has to be, structurally, to hold.
What an auditor asks for in a rebate audit.
Strip away the engagement-letter language and the rebate-accrual ask is four things. Every one of them is a test of structure, not of effort.
- 1
The balance, decomposed to transactions.
Not a summary that ties to the GL — the composition of the balance. Which agreements contribute what, which customers, and underneath that, which source transactions generated each accrual. Sampling starts here: the auditor picks accruals and expects each one to resolve to real rows.
- 2
The rate and terms that authorized each accrual.
For each sampled accrual: which agreement clause applied, what rate, what tier, what eligibility. Crucially, the terms as they stood when the calculation ran — not whatever the current configuration happens to say today.
- 3
Who approved changes, and when.
Rates change mid-year. Tiers get renegotiated. Accruals get trued up. The auditor wants the change history with an approver and a timestamp on each change — evidence of control, not just evidence of arithmetic.
- 4
Evidence the same query gives the same answer twice.
The quiet one, and the one that kills spreadsheet defenses. In a walkthrough or reperformance, the auditor re-runs your support. If the number moved because a formula recalculated or a batch reran, the evidence isn’t evidence — it’s a moving target.
Most rebate audit trails fail for three structural reasons.
Not because anyone was careless. Because the systems holding the numbers were never built to preserve evidence — they were built to produce this month’s number.
- The numbers are recomputed live from current configuration. Most rebate reports — spreadsheet or ERP — calculate from whatever the rates, tiers, and customer assignments say right now. Change a rate in October and the January report quietly changes with it. History becomes unreproducible, which means it was never really history.
- Corrections are made by editing, which destroys the trail. A wrong accrual gets fixed by overwriting the cell, re-running the batch, or updating the record in place. The correction is right; the evidence of what was previously reported — and why it changed — is gone. When the auditor asks “why did this move between Q2 and Q3,” there is nothing to point at.
- The person who knew is gone. The linkage between the balance, the workbook, and the agreements lives in one analyst’s head. Turnover converts a functioning process into an unreconstructable one overnight. Tribal knowledge is not an audit trail; it’s a single point of failure with a notice period.
A real rebate audit trail is a property of the data model.
You can’t bolt a trail onto a system that overwrites. Four structural properties separate systems that can support an accrual balance from systems that can only report one.
- 1
Append-only events — corrections reference, never replace.
Every accrual, adjustment, and reversal is written once and never mutated. A correction is a new event that references the original (a supersedes chain), so the record shows what was reported, what replaced it, and when. “What did we believe on March 31” stays answerable forever.
- 2
Inputs captured at calculation time.
Each calculation event carries a snapshot of what it used: the rate, the tier, the agreement terms, the customer assignment — as of the moment it ran. Changing a rate today creates new events going forward; it cannot rewrite what past calculations used. This is the property that makes reperformance possible. This is rebate calculation lineage, and it’s the load-bearing concept behind everything on this page.
- 3
One canonical number across every surface.
The accrual on the agreement screen, in the period report, and in the export are all reads of the same events — not three independent computations that happen to agree this week. When every surface derives from one ledger, “which number is right” stops being a question.
- 4
Drill from any total to the source transaction rows.
From the period-end balance, to the per-agreement accruals inside it, to the individual calculation events, to the source transaction rows and the rate each one matched. Not a reconciliation exercise — a click path. If reaching the source rows requires an analyst and a weekend, the trail exists in theory only.
The questions that make any vendor show you, not tell you.
Every rebate platform claims an audit trail. Most mean an audit log — a record that changes happened, not support for the numbers. Five questions separate them, in a demo, in minutes.
- “Can I click from the accrual balance down to a source transaction row?” Not “can you export a detail report” — can you drill, live, from the total to the rows. If the answer involves a services engagement or a data warehouse, the lineage is derived, not native.
- “If I change a rate today, does yesterday’s report change?” The single most honest tell. If yes, the system recomputes from current configuration and cannot reproduce history — whatever the audit-trail slide says.
- “Show me a correction. What happened to the original number?” If the original is gone — overwritten, re-run, replaced in place — corrections destroy evidence. You want to see the original and the correction side by side, linked.
- “Run this report twice. Byte-identical?” Same report, same period, same data, run twice — does it produce the same output? Reports regenerated live from mutable state drift. Reproducibility is a yes/no property; make them demonstrate the yes.
- “Where do I see who approved this agreement’s terms, and each change since?” Approval history should sit on the agreement, with names and timestamps — not in an email thread the vendor suggests you keep.
Where Aurgus stands on every one of those questions.
Aurgus was designed from the ledger up so that the audit trail is the data model, not an export. The mechanisms below are how that shows up on screen when you audit rebate accruals.
- 1
An event-sourced ledger underneath every number.
Accruals, adjustments, reversals, and settlements are append-only events. Corrections are new events carrying a reference to the event they supersede. Nothing is edited in place; the history of what was reported, and what replaced it, is structural.
- 2
A per-agreement reconciliation check, on screen.
Each agreement view shows the reconciliation between its stated totals and the sum of its underlying events — continuously, not as a quarter-end project. If the views ever disagree with each other, the check says so on the screen — continuously, not as a quarter-end discovery.
- 3
A value buildup that decomposes the number.
Any accrual total opens into its buildup: which agreement clause, which rate, which tier, which source transactions. The decomposition an auditor samples against is the same view your team uses every day — one canonical number, one path down to the rows.
- 4
Human approval gates on every financial action.
Agreement terms, term changes, adjustments, and settlements pass through an explicit human approval, recorded with the approver and timestamp. The control evidence auditors ask for accumulates as a side-effect of operating, not as documentation written after the fact.
Rebate audit trails, honestly answered.
- What is a rebate audit trail?A rebate audit trail is the chain of evidence that connects a rebate number — an accrual balance, a settlement, an adjustment — back to the source transactions that generated it, the rates and agreement terms that authorized it, and the people who approved changes along the way. The defining property is reproducibility: run the same question against the same period twice and get the same answer, with the support attached. A report that recomputes from current configuration is not an audit trail, because yesterday’s number can change under your feet. See calculation lineage for the underlying concept.
- What do auditors ask for on rebate accruals?A typical PBC list for rebate accruals asks for: the population of active rebate agreements and their terms; the period-end accrual balance decomposed by agreement and customer; support tying a sample of accruals to source transactions and to the rate that applied; evidence of who approved agreement terms and any changes, with dates; and a walkthrough of how the calculation works. For a sample, auditors commonly reperform the calculation — take your inputs, apply the stated terms, and check they get your number. If your support is a spreadsheet plus a narrative, reperformance is where it breaks. Related: variable consideration audit defense.
- How do I prove a rebate accrual is correct?Decompose it. A defensible proof runs: this balance is the sum of these per-agreement accruals; each per-agreement accrual is the sum of these transaction-level calculations; each calculation applied this rate from this agreement clause to this source row; the rate and terms in effect at calculation time are captured, not inferred from today’s configuration; and every change to terms carries an approver and a timestamp. If any link in that chain lives only in an analyst’s head or an unversioned workbook, you don’t have proof — you have a story that depends on who is still employed. See also ASC 606 rebate compliance.
- What’s the difference between an audit trail and an audit log?An audit log records that actions happened: user X edited record Y at time Z. Useful, but it doesn’t support a number. An audit trail supports the number itself — it lets you reconstruct any reported figure from preserved evidence: the source transactions, the inputs as they were at calculation time, and the chain of corrections. Most systems that advertise an audit trail ship an audit log. The test: can the system show you what a calculation used, or only that somebody changed something?
- Can spreadsheets provide a rebate audit trail?In principle, with heroic discipline — versioned files, never editing in place, documented inputs per period. In practice, almost never. Spreadsheet formulas recompute from current cell values, so historical outputs aren’t preserved; corrections are made by overwriting, which destroys the prior state; and the linkage from a cell to a source transaction is convention, not structure. Spreadsheets also fail the turnover test: when the analyst who built the workbook leaves, the trail leaves with them. Spreadsheets are fine as an analysis surface. They are a weak system of evidence — which is why purpose-built rebate accrual software exists.
Other places the evidence has to hold.
Walk in with the chain, not the binder.
Thirty minutes on your current rebate evidence trail — what your support actually shows, where it breaks under reperformance, and whether the structural fix is worth a conversation. No pitch theater.