Who changed the online price, and which orders used it?

Define which price was changed

A customer asks why the website showed one amount yesterday and another today. A manager asks whether the change was approved. A finance colleague asks which orders used the new amount. These are three different questions, and a screen showing only the current product price cannot answer them. Start by naming the price fields and the contexts in which they apply: base catalogue price, customer-specific agreement, promotion, tax treatment if relevant, delivery charge and final order total. A product page may display an estimate while checkout calculates the amount actually offered. Document which system is authoritative for each figure and which event freezes the amount on an order. Without that map, an audit log may be technically complete yet fail the business question.

Treat a proposed price, an approved price, a scheduled price and a live price as separate states. A spreadsheet uploaded on Monday may specify a Friday start; publishing it immediately would be an operational error even if the number itself were correct. Record the intended effective time and time zone, the scope of products or customers, and what happens to existing baskets or quotes. An effective time should not be inferred from a file modification date or the time a colleague emailed approval. If the business cannot honour future scheduling, it should publish only after the approver confirms readiness and record the actual activation time. The system should make those states visible to staff who resolve customer queries.

A useful change record contains the product or price-rule identifier, old value, new value, currency, applicable segment, proposed and actual effective times, reason, requesting person, approving person, outcome and a reference to the batch or request. OWASP's Logging Cheat Sheet says application logs should capture when, where, who and what, and its business-logic guidance calls for enough context to audit the price computed, coupon and new state for value-moving operations. Those are design principles, not a claim that one universal field list fits every retailer. Include only the details required to reconstruct a legitimate business change. Restrict access to sensitive information and avoid copying tokens, passwords or unnecessary personal data into the record.

Connect approval to the applied change

Approval must refer to the exact change that becomes live. If a manager approves a spreadsheet and someone edits the file afterwards, the approval no longer proves that the published values were reviewed. Give the proposal a stable version or digest, show a readable before-and-after summary, and bind the approver's decision to that version. When a later correction is required, create a new proposal with its own reason rather than silently rewriting history. Small teams may combine job roles in practice, but they can still make the decision traceable: identify who entered the change, who checked it and which exception was used when normal review was unavailable. The owner can then decide where a second check is proportionate to risk.

A bulk import deserves a different review from a one-item edit. Show the number of rows parsed, rejected and proposed for change, together with a sample of high-impact differences. Test for accidental currency shifts, misplaced decimal points, negative prices where not allowed, products outside the campaign and overlapping validity periods. The review screen should state whether rejected rows block the whole batch or only those rows. Store the input file reference, validation result and approved version, but make the customer-facing system read from a controlled published state. A successful upload message says only that a file arrived; it is not evidence that the right prices went live on the right day.

Separate permission to propose from permission to approve and publish where the business can do so. If one person must perform an emergency correction, require a reason and a follow-up review, then flag that route in the change record. OWASP advises that log data should be protected against tampering and that access to logs should be restricted and monitored. Therefore a price editor should not be able to erase the evidence of their own change simply by reopening the product page. A database history table, append-only event store or appropriately protected audit service can each support the goal; choose one whose records can actually be retrieved by staff with a legitimate need.

Trace what each customer actually received

A price-change log tells you what was configured, but it does not by itself prove what each customer saw or paid. Capture the quoted unit price, discount basis, currency and final amount on the order at the point your business treats the offer as accepted. Preserve the version or rule reference used to calculate it. Then support a query from price version to affected orders, with clear boundaries for orders placed before activation, pending baskets and amended orders. The display price may differ from the paid amount because a valid customer agreement or delivery charge applied. Do not label every difference an error. Reconstruct the calculation first and compare it with the terms the customer was shown at checkout.

Consider a worked example. A wholesaler proposes changing a lamp's list price from HK$180 to HK$195 for new orders from 09:00 HKT on a chosen business day. The approver accepts the exact version, and the publishing job records a later actual activation at 09:02. An order accepted at 08:59 retains its earlier quoted amount; one accepted at 09:03 uses the new list price unless an agreed customer-specific price applies. These amounts and times are hypothetical, solely to illustrate a boundary test. The team should query both orders, compare the stored price-rule version and explain any exception. The effective-time rule must be agreed before deployment; the audit record cannot resolve an ambiguous business policy after the fact.

A rollback is itself a new decision, not an erasure of the bad value. If the wrong price was live for a period, record when it started and stopped, which customers completed orders during that window and how the business will handle each category. Some orders may require customer communication, a correction or a refund decision; do not automate that decision solely from a price mismatch. Keep both the original price event and the correction event, their approvers and reasons. This chronology is also important when a cached page or external marketplace remains stale after the source system is corrected. Check each sales channel's actual publication state rather than assuming one database update reached every customer.

Ask for reconstructable evidence

Ask the developer to demonstrate four queries using test records: what changed for one product, who approved the exact version, when each channel applied it, and which orders used that version. Include a rejected import, an emergency edit and a rollback. Compare the audit answer with order snapshots and the page or channel state captured during the test. Review who can read and change the log, how long it is retained under your own policy, and whether log export remains usable when an incident is investigated. OWASP notes that the purpose of a log determines the details needed, so define the business question before collecting every possible field.

The owner need not buy a large governance platform to make a useful start. Choose one high-impact product group, write down its price authority and effective-time rule, and require a before-and-after change record tied to a real approval. Run a small change through the normal path and ask someone who did not enter it to explain the resulting orders. If they must consult private chat messages, current catalogue values and memory to infer what happened, the audit trail is incomplete. Fix that gap before expanding the workflow to all price lists. The outcome to seek is an explainable customer-facing amount and an accountable decision, not a dashboard full of events nobody can interpret.