The pricing audit trail: what to log for every price change

Someone asks why a product costs what it costs. Not in a hostile way - a supplier on a Tuesday call, a CFO in a margin review, a category lead who inherited the range last month. And the honest answer, in most retail businesses, is a shrug: the price has been that since spring, somebody set it, the file it came from has been overwritten four times since.

That shrug is the problem a pricing audit trail solves. Not compliance theatre - the plain ability to reconstruct a price change months after it happened, from records that were written at the time rather than reasoned out afterwards. Most pricing teams believe they have this. Almost none do, and they find out on the day someone asks.

Why the question is getting louder

The regulatory temperature is rising on both sides of the Atlantic, and it is worth understanding precisely how, because the operational answer is narrower than the headlines suggest.

In the US, the FTC opened public comment on 24 August 2026 on a proposed enforcement policy statement covering personalized pricing, with comments closing on 18 September. The core of it is a disclosure position: using personal data to estimate what an individual shopper will pay, without telling them, may run afoul of the FTC Act's prohibition on unfair or deceptive practices. That builds on the Commission's January 2025 surveillance pricing study, which found intermediaries in this market working with at least 250 clients, grocery retailers among them.

In the EU, a version of this has been law for years and gets far less attention. Article 6(1)(ea) of the Consumer Rights Directive, inserted by Directive (EU) 2019/2161, requires a trader to tell the consumer, before they are bound, that the price was personalised on the basis of automated decision-making. It does not require you to explain how. The proposed Digital Fairness Act would go considerably further, and the direction of travel is not subtle.

Here is the part most teams get wrong. Almost nothing a mid-market retailer does is personalized pricing in this sense. Zone pricing is not. Channel pricing is not. Clearance, loyalty-card pricing on a published offer, and a competitor-matched price are not. Different prices for different groups, set by published rules, are segmentation - a practice as old as the corner shop. Personalized pricing is a price computed from an individual's data to estimate that individual's willingness to pay. If your rules never take an individual as an input, you are on the safe side of the line.

Which is exactly why the audit trail matters more than the disclosure. The valuable thing is not a banner on your checkout. It is being able to demonstrate, from records, that your prices came from published rules and named inputs - and to do that in an afternoon rather than a fortnight.

Four people who ask, and only one is a regulator

Treating this as a legal project is how it ends up as a document nobody maintains. In practice the reconstruct-this-price question arrives from four directions, and the same record answers all of them.

A supplier asks why you sold below the agreed level in week 32. You need the rule that fired, the competitor observation that triggered it, and whether a person approved it.

Your CFO asks why category margin fell 90 basis points in Q2 when nothing was on promotion. You need every price move in that category, ordered by margin impact, with its cause attached.

A category manager asks why a line she has never touched is priced under cost. You need the change history, including the cost update that moved underneath a price that never moved at all - the most common version of this and the hardest to see.

And occasionally a regulator or journalist asks the formal version. That one is rare. The other three happen every month, and a team that can answer them quickly is simply a better-run team.

Seven fields your pricing audit trail must capture

A usable pricing audit trail is not a change log. A change log tells you the price went from 12.99 to 11.49 on 14 August. That is the least interesting fact in the story. Seven things need to be captured at the moment of the change, because six of them are unrecoverable afterwards.

1. The price and its predecessor, with effective dates. Not "changed on 14 August" but "effective from 14 August 06:00 to 3 September 06:00". Retail questions are almost always about a window, not a moment. A log keyed on change events forces you to reconstruct windows by hand; a log keyed on effective periods answers "what was this price on 22 August" directly.

2. Scope. Which SKU, and which stores, zones, markets or channels. A price is rarely one number. If your record collapses a change that hit 40 stores into one row, you have lost the ability to explain the 12 stores where it behaved differently.

3. The rule or recommendation that produced it, by name and version. "Competitor match, KVI tier, floor at 8% margin" is an answer. "Automated" is not. And the version matters: the rule you are running today is not the rule that ran in August, and if you cannot say which one fired, you will end up defending a policy you had not yet written.

4. The inputs as they stood at the time. Cost, the competitor observation with its own timestamp and source, the elasticity or forecast figure if one was used. This is the field everyone skips and everyone regrets.

5. The guardrail that bound the outcome. When a margin floor, a rounding rule, a maximum-move cap or a MAP constraint changes the answer, that is a decision and it should be recorded as one. A price that sat at the floor for six weeks is telling you something, but only if the floor left a mark.

6. The human decision. Who reviewed it, when, and - critically - what they changed. More on this below.

7. The publish event. When the price actually reached the shelf edge or the site, and confirmation that it landed. The gap between approved and live is where a surprising share of margin leakage lives, and it is invisible unless both timestamps exist.

The two parts that are genuinely hard

Everything above sounds like a schema exercise. Two of the fields are not, and they are the two that decide whether the trail is worth anything.

Point-in-time inputs

A competitor price observed six days ago is not today's competitor price, and a cost that was updated last Thursday is not the cost the rule saw last Wednesday. If your audit record stores a reference to the competitor table rather than the observed value, then every time that table refreshes, your history quietly rewrites itself. Six months later you reconstruct a decision and it makes no sense, because you are reading August's rule against February's inputs.

Store the observation, not the join. The competitor price as observed, the source it came from, the timestamp of the observation - copied into the record at decision time. It costs storage. It is the difference between an audit trail and a plausible-looking fiction.

The same applies to cost. Landed cost moves for reasons that have nothing to do with pricing - a supplier letter, a currency revaluation, a freight reallocation - and when it moves under a static price, margin changes without a single price change to point at. Teams routinely spend a week hunting a margin gap that a cost-effective-date field would have explained in a minute.

Capturing the override

Overrides are the most valuable rows in a pricing log and the ones most reliably lost. Recommendations arrive, a manager disagrees with fourteen of them, edits the numbers, and publishes. The final file records the published price. The recommendation is gone, the disagreement is gone, and with them the single richest source of information about where your rules are wrong.

Record the proposed price and the approved price as separate values on the same row, always, even when they match. Then override rate becomes a metric you can read by rule, by category, and by person. A rule overridden 40% of the time in one category and 3% everywhere else is not a compliance finding, it is a bug report - and it will not get filed unless the data exists to notice it.

The comment field matters too, though it will be sparsely filled and you should not pretend otherwise. Make it optional, make it one line, and accept that the useful ones will be a minority. Even a 20% fill rate on overrides beats reconstructing intent from memory.

Retrofitting this without a re-platform

Nobody replaces their pricing stack to get an audit trail. There are three honest levels, and the first two are worth doing.

Level one: append-only files. If pricing lives in spreadsheets, stop overwriting them. Every pricing cycle writes a new dated file that is never edited, with columns for proposed price, approved price, and approver. Add the competitor value and the cost as literal numbers, not lookups. This is unglamorous and it works. The failure mode is discipline, and the fix is that the file is produced by the process rather than saved by a person at the end of it.

Level two: a price-history table. One row per SKU per scope per effective period, in whatever warehouse you already have, fed from wherever prices are actually set. Most teams can stand this up in a sprint. It will not capture rules or overrides unless the upstream process emits them, so pair it with level one.

Level three: a system that logs natively. This is the version where the record is a by-product of the work rather than an extra step. In rules-based pricing, the rule that produced each recommendation is named on the row, the guardrail that bound it is visible, and the review and approve step captures proposed against approved with the approver attached - before anything publishes. That is the design principle behind Retailgrid generally: explainable, auditable, rules-based, because a recommendation you cannot account for six months later is a recommendation you will not defend.

What this does not fix

Worth being clear about the limits. An audit trail does not make a pricing strategy good. It will faithfully record a bad rule producing bad prices for two years, and the completeness of the record is no comfort at all.

It does not substitute for the disclosure obligations themselves - if you genuinely do personalise prices from individual data, logging it does not discharge the duty to say so, and that is a conversation for counsel, not for a pricing analyst.

And it does not answer "was this the right price". It answers "how did this price come to exist", which is a smaller question and a prerequisite for the larger one. Teams that can answer the smaller question tend to get better at the larger one faster, because their post-mortems start from evidence instead of recollection.

Where to start this week

Pick one category. Take the last ninety days of price changes in it and try to reconstruct five of them at random - the rule, the inputs as they stood, who approved, when it went live. Time yourself.

If you can do all five in under an hour, your trail is in better shape than most and you should spend the effort on override capture instead. If you stall on the second one, you have found the gap, and you now know which of the seven fields is missing rather than guessing.

Then fix that one field. Not the schema, not the platform - the field. The teams that get this right almost never did it as a project; they did it one column at a time, usually starting the week after somebody asked a question they could not answer.

If you want a second pair of eyes on where your pricing decisions currently lose their paper trail, we are happy to walk through it - no deck, just the reconstruct-five-changes exercise on your own data.