Price History and Price-Change Data for Pricing and Elasticity Models

This page sits in the tables, time series and transactional data hub. It covers the price and outcome layer. Product descriptions and attributes belong to licensed product catalogs and descriptions, and pipeline stages belong to sales CRM pipeline histories.

What a pricing training set has to contain

A usable pricing dataset links three things at the same grain: the price that was offered, the price that was paid, and what the customer did in response. Most company exports hold only the middle one, which is invoiced revenue. Invoice lines alone show what sold at what price. They cannot show what did not sell, so every demand curve fit on them starts out biased toward the deals that closed.

Ask for these layers separately and keep their keys joinable:

• List and price-book history. Every version of list price per SKU, customer segment, region and currency, with valid-from and valid-to dates. In SAP this sits in condition records (condition tables and KONP), and in Salesforce CPQ price book entries or Oracle Advanced Pricing price lists.
• Price-change events. Who changed a price, when, and from what to what. In SAP, change documents store a header row (CDHDR) and item rows (CDPOS) that carry the old and new field values [3]. That makes them a natural source of price-change events.
• Quotes and quote lines. Requested quantity, quoted unit price, discount percentage and type, approval level, competitor named, quote status and expiry. Treat won, lost, expired and superseded quotes as one table.
• Realized transactions. Invoice-line net price after on-invoice discounts, plus off-invoice items such as rebates, chargebacks, free goods and payment-term discounts, which make up the "pocket price."
• Volume outcomes. Units shipped, returns and credits, and for B2B contracts the actual volume against the committed volume.
• Context covariates. Promotions, stock-outs, channel, seasonality, input-cost indices and capacity. These map to price, promotion and calendar covariates for time series.

Why lost quotes and discount reasons matter more than volume

Lost quotes are the only direct record of price rejection, so a dataset without them cannot estimate willingness to pay. Win-only data teaches a quote-recommendation model that every price it saw was acceptable. The model then drifts upward until sales overrides it. A useful benchmark is a loss-reason field that is filled in for at least the lost quotes you plan to train on.

Discount reason codes do the same job for the transactions that closed. A 12% discount granted for a competitive match is a different signal from 12% granted for volume, for an end-of-quarter push or to fix a pricing error. Without the reason, the model learns one blended discount behavior. Ask the supplier how reason codes were enforced. Free-text "per manager" entries tell you little.

For B2B quoting in particular, see RFQ and quote histories for industrial quoting agents and freight rate quote and award histories. Both have similar won/lost structures with domain-specific fields.

Getting identification right: endogeneity and exogenous variation

Observed prices are usually set in response to expected demand, so a naive regression of volume on price often produces elasticities that are too small or even upward-sloping. Sellers raise prices when demand is strong and cut them when it is weak, which ties price to unobserved demand shocks. More rows do not fix this. Variation in price that was not caused by demand does.

When you scope a dataset, ask whether it contains any of these sources of exogenous variation:

For each source, the supplier should be able to explain why the price changed. If nobody at the supplying company can, treat the variation as endogenous until shown otherwise. Plan to hold out a later time window for evaluation, because pricing regimes change and a random row split leaks future price-book versions into training.

Normalization: currency, units of measure and pack sizes

Price fields are only comparable after you normalize currency, unit of measure, pack size and the price basis. Skipping this is the most common silent error in pricing data. A unit price of 4.20 can mean per each, per case of 12, per kilogram or per 1,000. In ERP data the pricing unit and the order unit are often different fields, such as the condition pricing unit versus the sales unit.

Ask the supplier to deliver, or document, the following:

• Transaction currency, the FX rate actually applied, and its source and date.
• Base unit of measure plus the conversion table from order unit to base unit per SKU.
• Pack-size and SKU-supersession mapping, so a 6-pack replaced by an 8-pack does not look like a 25% per-unit price cut.
• Whether prices are gross or net of tax, freight and surcharges, and Incoterms for B2B lines.
• Contract-price overrides and the precedence rule between a customer contract and the list price.

Getting these keys right is the same discipline described in what to specify about table grain, keys and history. It also overlaps with ERP transaction and master data for AI training.

Competition-law handling for price data

Price data from a single supplier used inside your own pricing is mostly a licensing question. Pooling recent, identifiable prices from several competitors is a competition-law question, and the US safe harbors that practitioners used to lean on are gone. In February 2023 DOJ withdrew policy statements whose information-exchange safety zone relied on a third party managing the data, data at least three months old and enough contributors that no single one dominated a statistic [4]. The DOJ and FTC have since also withdrawn their competitor collaboration guidelines [5].

In the EU, the Commission's 2023 Horizontal Guidelines treat exchanges of commercially sensitive information, including exchanges routed through third parties or algorithms, as a central risk, so check them with EU counsel before pooling prices. If your model or product will serve several sellers in the same market, the training data becomes a possible hub.

Practical controls buyers commonly apply, as of October 2026, include:

• Lag competitor-identifiable prices and never ship current or future price intentions.
• Aggregate across enough sellers that no one seller's price can be backed out, and suppress small cells.
• Keep each client's raw prices out of other clients' features and recommendations.
• Restrict access to raw multi-seller price data to a clean team, and log who queried what.
• Have counsel review the data flow before training, not after deployment.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Commercial sensitivity, de-identification and license scope

Price and margin data is among the most commercially sensitive tables a business holds, and commercial interests are a main barrier to getting real company datasets at all [1]. Expect suppliers to ask what the data will be used for, by whom and for how long. Expect use-scoped terms: data vendors commonly license business data for AI under tiered licenses that forbid raw redistribution [2].

Customer names and account identifiers usually need to be replaced with stable pseudonymous keys, so that repeat-purchase behavior survives while identity does not. Contract text attached to quotes often contains names, emails and phone numbers in free-text fields. Automated tools such as Presidio help with this but warn that they cannot guarantee finding every item of sensitive information [6]. Plan for a sampled manual check.

SourceX removes or replaces personal details such as names, emails, phones and account numbers before delivery, records the method used and checks a sample; no method is perfect. Every dataset is rights-reviewed for ownership and consents and delivered under a license that defines the records, uses, term and delivery.

Illustrative quote-line record

A single denormalized quote-line record shows how offered price, realized price and outcome connect at one grain. Use it as a request template when you describe the data you need.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "quote_line_id": "QL-7f3a91",
  "quote_id": "Q-20240311-0412",
  "customer_key": "CUST-pseud-58c2",
  "customer_segment": "mid_market_distributor",
  "region": "US-Midwest",
  "sku": "VALVE-2IN-SS316",
  "requested_qty": 400,
  "order_uom": "EA",
  "base_uom_per_order_uom": 1,
  "currency": "USD",
  "list_price_version": "PB-2024-Q1",
  "list_unit_price": 182.00,
  "quoted_unit_price": 151.06,
  "discount_pct": 17.0,
  "discount_reason_code": "COMP_MATCH",
  "competitor_named": true,
  "approval_level": "regional_manager",
  "quote_created_at": "2024-03-11T14:02:00Z",
  "quote_expires_at": "2024-04-10T23:59:00Z",
  "status": "lost",
  "loss_reason_code": "PRICE",
  "won_order_id": null,
  "invoiced_net_unit_price": null,
  "off_invoice_rebate_pct": null,
  "shipped_qty_90d": 0,
  "input_cost_index_at_quote": 1.12
}

The fields that make this record useful for models are status, loss_reason_code, discount_reason_code, list_price_version and input_cost_index_at_quote. A won line would fill won_order_id, invoiced_net_unit_price and off_invoice_rebate_pct, linking the quote to the realized pocket price.

Delivery format and refresh for price histories

Pricing data is best delivered as versioned, partitioned tables rather than flat exports, because price books and quotes are revised over time. Ask for Parquet or Delta tables partitioned by month and keyed on stable IDs. Open protocols such as Delta Sharing transfer Delta Lake and Parquet data over REST APIs and cloud object storage without copying files by email [7]. SourceX delivers through private, access-controlled workflows, never email attachments, and only after an executed agreement and supplier approval.

If the use case is dynamic pricing, plan for ongoing refreshes, since a model trained on one year of a price regime degrades when list prices change. Event-level price changes also feed timestamped business event sequences. Realized volumes feed sales and order histories for demand forecasting. How price data itself is valued is covered in what drives the price of licensed enterprise data.

How SourceX sources price and quote histories

SourceX sources operational datasets from US companies on request; it does not hold them in stock, and a request does not guarantee a match. You describe the data you need, such as quote lines with won and lost outcomes, discount reason codes and price-book versions, rather than naming businesses. SourceX then looks for US businesses that hold it, and every release is approved by the supplying company. The process runs Find, Assess (data and licensing permissions), Agree (pricing and allowed uses in a license), Transact and Manage, and nothing is contracted until a supplier agrees. You can describe your pricing data requirement to SourceX at any stage of scoping.

Request price and quote histories for your pricing models

SourceX sources operational datasets, including sales histories and finance workflows, from US companies, and manages licensing and ongoing purchases. Each dataset is rights-reviewed and delivered under a license defining records, uses, term and delivery, and terms are agreed per deal. Tell SourceX what pricing data you need.