Supplier price-list version control for restaurants: activate the right list

Version control answers a question that a price table alone cannot: which commercial statement was authorised for this item, unit, site, and date? A supplier may send a complete list, a partial update, a workbook with several tabs, or a document whose effective period is unclear. If the restaurant overwrites the old file, it loses the context needed to explain an invoice that was correct under an earlier version. If it activates every attachment automatically, a draft or wrong-location tab can become the reference by accident. Record the source as received, then make the activation decision visible.

Define the identity and scope of a list

Start with a list identifier that is stable inside the restaurant, then preserve the supplier’s filename, document number, message, or portal reference. Capture received date separately from stated effective date. Add supplier identity, account or contract scope, covered locations, ordering channel, currency, tax or charge fields as supplied, and the unit basis for every line. A list can be valid for one site and not another, or for a negotiated customer account without being a general catalogue. If the document says “current” but gives no boundary, record that limitation and route it for local clarification instead of inventing a start date.

• Keep product code, supplier description, internal identity, pack configuration, purchase unit, comparison unit, and price basis in separate columns.
• Record whether the line is a base price, allowance, delivery charge, deposit, rebate, surcharge, or another operator-defined component.
• Mark the locations, menus, accounts, order routes, or contract terms covered; do not apply a local list to every restaurant by default.
• Preserve the original file and an immutable capture date while storing a readable line extract for operational review.
• When a line is missing, ambiguous, or duplicated, flag the question and owner rather than filling it from a familiar item name.

Approve and activate deliberately

The approval is a business control, not a claim that the supplier’s figures are objectively correct. The restaurant’s chosen reviewer can check list identity, scope, pack and unit mapping, effective dates, negotiated terms, tax presentation, and conflicts with an existing active version. Record the review outcome, operator-defined authority, date, and any conditions. Activation should have a clear boundary: one list becomes active for a defined scope while another is superseded, pending, or limited. GOV.UK’s procure-to-pay material is useful context for accurate records and traceable changes, but it does not set your restaurant’s roles or a universal list-approval deadline.

Clearly labeled illustrative example: two overlapping list versions

A repeatable supplier price-list version process

1. 1Capture the source. Save the supplier file, portal reference, message, or document as received and assign an internal list identifier and capture date.
2. 2Describe the boundary. Record stated effective and end dates, supplier account, currency, location, channel, contract context, and any missing or ambiguous scope.
3. 3Normalize the line identity. Map product code, description, pack, purchase unit, comparison unit, and price components while keeping source wording visible.
4. 4Review conflicts. Compare the candidate list with the current version and check dates, sites, items, units, terms, charges, and any operator-defined exception rule.
5. 5Approve and activate. Obtain the accountable local approval, record conditions and effective boundary, activate the intended version, and mark other versions pending or superseded.
6. 6Use and preserve history. Link the active list to orders and invoice review, investigate out-of-scope lines, and retain every state change and affected transaction reference.