Skip to Content

Looking for a Vehicle Valuation or hpi check?

cap hpi's dedicated support

Frequently Asked Questions

What is the process for making New Vehicle Data (NVD) updates?

The process for each data change begins with a submission by email from our manufacturer contacts (excluding ABI and NCAP updates that are sourced from the web). We only take instructions from confirmed contacts, and we do not take data from any other source, for example, online configurator tools, dealers etc.

Our team of Editors will review the submission to understand what the manufacturer is asking us to do. This could be several different actions, for example, create new cap codes, discontinue existing codes, a change to the technical data, equipment or model year etc.

Work items are then created in our internal Workflow tool so we can assign the work to an Editor and track progress. You can see a full list of these in the NVD Status Report.

Our Editors will then enter the change into our internal system and then a quality check is completed before deadlining. When a work item is deadlined, the changes will show in live data the following day.


Why do I sometimes see different information on manufacturer websites/configurators and from dealer contacts?

We only take instructions to amend our database from confirmed cap hpi manufacturer contacts. All of the data requests we are sent are catalogued in our internal Sharepoint site so that we can always provide evidence to show why we made a change but also so that we can check if a customer reports an error. We do not use manufacturer configurators as a data supply as we cannot be sure they contain the most up to date and accurate data, we cannot efficiently store the content as an audit source, and we would not be notified when something has changed.

If a customer reports an issue of this nature to us, we will refer to our source files and advise if our data is correct based on this. There may be occasions where the data is ambiguous, or we haven’t received an update for over 3 months where we will check with our manufacturer contact.

How often does the data get updated?

New Vehicle Data is a daily product and builds every weeknight. This means it is not quite “live”, so if we make a series of changes to our data, they will not be visible in product until the following day.

Why are some cap ids removed from data but not discontinued or deleted?

In some cases, we create a cap id at the request of a manufacturer and then we make the decision that this id should not be in live data. There are multiple possible reasons for this, for example, the pricing and CO2 data is not available for longer than is acceptable, vital technical data is missing or the manufacturer is not yet in a position to take orders on this vehicle and asks us to temporarily remove it from live data.

Some of the ids will eventually come back into data when the missing data is available, or the manufacturer notifies us that the vehicle is available to order. However, some ids will ultimately be discontinued or deleted as they never quite make it to market.

Why are some cap ids deleted?

A cap id can be deleted because of a cap hpi Editor error, for example, a new id is created instead of re-introducing a previously discontinued id that is exactly the same. Most of the time though, the ids are created and then deleted due to a manufacturer issue with supply. They thought the vehicle was going to be sold in the UK and it never has or will be within that model range.

The reason we delete instead of discontinuing is because we know that the vehicle has never been registered in the UK. If we delete a cap id, we cannot reintroduce it with the same cap code.

What is the process for discontinuing cap ids?

The manufacturer is responsible for telling cap hpi that a derivative(s) is no longer available to order as new. They can do this by omitting it from the latest source file (e.g. a price list or brochure) or telling us explicitly that the derivative(s) should be discontinued.

A discontinued date will be added to our data to reflect the date that the derivative went out of production. A run out date can then be added so that the cap id will stay in data if there are any prebuilt stock vehicles left to sell.

Why are some prices showing £0.00?

There are occasions when a manufacturer will ask us to set up a new cap code, but pricing has not been decided or they do not want that to be live yet. They may do this because they would like to get a forecast value (Gold Book) and for this to happen, a cap code must be deadlined in NVD. This means that our NVD customers will still see the id(s) but without a price.

£0.00 must be entered because the forecast team cannot deadline their product if this is left blank.

Note: if delivery prices are showing as £0.00 this could be for the reason stated above or because the delivery price is genuinely £0.00.

How is pricing calculated?

NVD will show basic price, VAT (20%), retail price (basic plus VAT) and delivery price. Pricing does not include VED, first year registration fee or on the road price although these can be found in cap Connect and Valuation Intelligence.

Option/pack based derivative pricing calculation is explained below.

Why do we see option/pack-based derivatives and how are they built?

In some cases, cap hpi will create a derivative including an option or a pack in the derivative naming (usually identified by square brackets). This allows that option/pack to be valued in our valuation products. There is currently no facility for cap hpi to value options independently, they must have a separate cap code and id.

The Valuations teams, NVD and the manufacturer will discuss and agree which packs will be given a separate cap code. This is based on the perceived residual value of the option/pack by our valuation experts. cap hpi will not create a new code unless there is evidence of increased value because of the option/pack being added to the vehicle.

Separate ids are also created if an option results in a reduction or increase in the number of seats. This is specifically related to cars. In LCV data, seat addition or removal may be shown as an option.

In these scenarios, the base cap id from which the pack id is built will have the option/pack removed. This is to ensure that the cap codes are mutually exclusive.  

The pack/option derivative will have the features of the pack listed as standard equipment. This also includes any other options that have to be selected along with the pack in question.

Example of base and pack-based derivatives:


How are option/pack-based derivatives priced?

These derivatives are priced by adding the price of the option/pack on to the base derivative’s retail price. If there are cost option dependencies these will also be added to the price.

In some cases, further options may have to be shown at a discounted price, in order to make the total price calculate correctly. For example, if a pack is only available in combination with metallic paint, and the metallic paints can cost either £500, or £750 depending on the colour. The cost of the cheaper paint (£500) will be added to the list price of the pack-based model, and those paints will be shown at zero cost. But then the paint which was £750 on the base version, would then be shown as £250 on the option based model.

Why are manufacturers and model ranges all in upper case?

Manufacturers and model ranges are all in upper case so that we can provide consistency in our dataset across all manufacturers.

Why are multiple model years present within the same model range?

In most cases, the model year should be the same for all cap ids within the same model range. However, there are times where the model years will be different. This can happen when we are asked to create new ids on a new model year but have not yet been asked to update the rest of the range. We may also be asked to update the model year of only part of the range as the remaining cap ids are going to be discontinued.

The model years could also be different as we have made an error in our inputting process. In these cases, a query should be sent to the Business Helpdesk for us to investigate.

How is “Power Output” on electric vehicles decided?

We display peak system power. Even though this may only be for a short period (and in some cases a limited number per charge) we database the most power it can deliver.

In WLTP data, why is the “maximum” figure sometimes the lowest value?

In WLTP data, “maximum” refers to the state of maximum fuel/energy consumption. Within the WLTP test this is referred to as “Test Energy High” (TEH), which you can think of as the worst-case scenario regarding the efficiency. For an ICE car, the highest possible CO2 figure (measured in grams per kilometre) corresponds to the lowest possible figure for fuel consumption if you are measuring in terms of miles per gallon. It is an inverse relationship; as one goes up, the other goes down.

For example:

WLTP – MPG – Comb – Max      44.8 (worst case)

WLTP – MPG – Comb – Min       45.6 (best case)

WLTP – CO2 (g/km) – Comb – Max         142 (worst case)

WLTP – CO2 (g/km) – Comb – Min         140 (best case)

CO2 emissions of 142 means a corresponding fuel consumption of 44.8 MPG. Whereas a CO2 of 140 corresponds to a fuel consumption of 45.6 MPG. The “Max” figure is the larger number for CO2, but the smaller number for MPG.

There is a similar relationship between Electric Consumption and Electric Range. As electric consumption (measured in kWh/100km) increases, the Electric Range decreases.

WLTP - EC (kWh/100km) - Comb – Max              24.5 (Worst Case)

WLTP - EC (kWh/100km) - Comb – Min              23.2 (Best Case)

WLTP - Pure Electric Range (km) - Comb – Max   298 (Worst Case)

WLTP - Pure Electric Range (km) - Comb – Min               317 (Best Case)

Again, in this example, the “Max” figure for Electric consumption of 24.5 kWh/100km, corresponds to the “Max” Range 298 km. The higher consumption leads to a lower range. The “Min” Consumption (23.2) corresponds to the “Min” range (317). Lower consumption leads to higher range.

Why are dates so important?

Dates are integral to the whole cap hpi new vehicle data set. When a cap code is created, an introduction date is set. From this point onwards, all changes across all parts of the data (e.g. price, model year, equipment, technical etc) will have an effective from date that ends the previous date period.

The dates must be sequential and cannot overlap.

Dates can differ across the different data sets. For example, if there is a technical data change a new date period will be created. If the vehicle price and equipment do not change a date period will not be created in this part of the database.

Dates can be added in the past, present or future depending on the instruction from that manufacturer.

Why are there Cars in the LCV data?

It is relatively common for a vehicle designed as a commercial vehicle, can include some versions within the line-up, which are homologated as cars. This is dependent on the number of seats, the payload, and the side windows behind the driver’s seat.

While these may be homologated as cars for taxation purposes, they may still only be sold through commercial dealerships, or they may be intended for commercial purposes (Taxis or Airport Shuttle Buses for example). If it is determined that the intended purpose of the vehicle is for commercial use as opposed to use as a personal, private vehicle, then it will be included in the LCV dataset.

There are flags in the technical data files to identify vehicles which are taxed as cars.

What are “Ghost models?”

Within LCV data, we create “Ghost models” purely for valuation purposes.

OEMs will often offer Chassis or Platform Cab models which have a flat platform or bare frame on the rear of the vehicle. This is intended for a 3rd party to convert the Vehicle into something of the customer’s choosing. This could include a Dropside, Tipper, Box van or Luton Van.

Because the vehicle is unlikely to be re-sold, used as a bare Chassis/Platform, and because the value is highly dependent on the type of body built onto the back, the “Ghost” models are there for valuation purposes.

Because these are not official vehicles on OEM price lists, the NVD data attached is limited to a price, and a small number of technical data. Converters are not working to a fixed spec, so equipment, dimensions and weights can vary in the final built vehicles. Because there is no fixed spec, NVD will not show any details as there is no way of verifying it.

Why are “Mild Hybrids” not showing as “Hybrid” fuel type?

The classification of Mild Hybrids is inconsistent throughout the industry. While some cars with a mild hybrid system are taxed as alternative fuel for VED/BiK purposes, others with the same technology are not. The legislation is based on how a vehicle is registered, and not directly by whether or not it has a Mild Hybrid system. It is also possible for these vehicles to be re-classified in the future.

As a result, Mild Hybrid models have been set up in the same way as standard ICE-only Petrol or Diesel cars. There is a flag in technical data to identify if they are taxed as alternative fuel vehicles or not. This flag has an effective date, which allows it to be changed in the future if that is necessary.

Why is some technical data showing “N?”

We will never be provided all technical data for all models. This is especially true when a vehicle is first introduced, as we often release data in advance of actual production, and some data may not be confirmed until production has started. If we are expecting data to be confirmed later, we will leave some fields blank.

In some cases, we know the information will never be available. For example, we do not expect a maximum roof load to be measured for a convertible car. Sports cars are not designed to have a towbar fitted, so there is no maximum towing weight. Some cars are not offered with roof rails, so we cannot show the height including roof rails.

If we know the data will never be provided, we may set this as “Not available” which appears as “N” in the data.

With WLTP data, certain fields only apply to certain fuel types. For example, a Battery only Electric Vehicle will never have any CO2 emissions or fuel consumption figures. In this case though, it was decided that adding hundreds of “Not available” technical entries to every ID was not actually providing useful information. For that reason, WLTP fields that do not apply based on the fuel type, are left blank.

WLTP data will only be set “not available” if the OEM had supplied it for a model in the past, but then ceases to provide the data in later updates.

Why can’t I see all the option relationship rules for Porsche?

At the start of 2021, we issued a communication to inform customers of a change in the way we database option relationships for Porsche.

The process we follow for documenting option relationships for all manufacturers is to take the build rules that are documented on their source files (e.g. price lists, brochures etc) and database these in our system. This process is triggered by the manufacturer alerting us to a change in their data. We can then catalogue the file and refer to these in the event of a customer query or any other investigation into data accuracy.

When building option relationship rules for Porsche, we were directed to the website configurator and asked to build a vehicle and use this to database the rules. This process was problematic for the following reasons:

  • It leaves us with no audit trace or source file to catalogue in the event of a customer query.
  • It makes this work require disproportionally more resource than any other option relationship work we do (due to the manual nature of configurating every feasible build).
  • We cannot be sure when something has changed as we are not notified in the usual manner.

With the support of Porsche, we have agreed to scale down their option relationships to cover only what is documented on their source files as well as any logical “one of” rules e.g. paints, wheels, audio systems, steering wheels etc.

Due to the highly customisable nature of the product, Porsche have asked that all customers interact directly with a Porsche Centre to get the latest vehicle and option availability, CO2 and pricing.

Can you make changes to a discontinued derivative?

Depending on the request, we can make some changes to discontinued derivatives.

If we have made a mistake in the data, we will correct this.

After the discontinuation date, we cannot add new date periods to reflect a change to the technical data.

If the derivative is still in data on run-out (stock only) we can:

  • amend historic dates for technical, vehicle and option pricing.
  • add new date periods (must not exceed run-out date) to reflect a change to vehicle and/or option pricing. However, we cannot discontinue anything or add anything new.

Why does cap Connect not display the data I expect to see?

If you have checked the NVD Workflow Prioritisation report on the subscriber area but the data you expect to see is not live in cap Connect it could be an issue with the “Specification Date”.

Connect defaults to the specification date that covers the current date. To see a change in the future, please click on the “Change” button and select the correct date.



If you still believe the data to be incorrect, please send a query to the Business Helpdesk.

Why isn’t all equipment listed, for example, accessories?

The equipment listed in our data must be factory fitted. If an item is listed as an “accessory” or “dealer fit”, they will not be listed in cap data.

Why can I sometimes see new cap codes, but prices, technical data and equipment are missing?

In most cases, Manufacturers will send a request for a new cap code along with the pricing, technical data and a full list of equipment. However, there are times when we do not receive all of this information initially. The Manufacturer may be targeting a particular month to get forecast values but doesn’t yet have all of the data. In these cases, we will create a cap code (which enables an RV to be set and published) and then update the remaining data shortly after. We will actively chase this missing data and if it is not received in a reasonable time frame, we may remove the code temporarily from our data.