When you import an ESX, Xactimate reprices with its own price list
The file keeps your PDF prices until import; then Xactimate reprices recognized lines against the receiving price list.
Repricing, explained: what happens on import
When you open an .esx estimate in Xactimate, the file lands inside a price-list environment: the price list installed on the machine that receives it. Xactimate takes each line item, checks whether it can price that code from the receiving list, and applies the list's unit price to every line it recognizes. That is what repricing means in practice. After import, the numbers on recognized lines come from the receiving price list, not from the PDF that produced the file.
The file itself is built the other way around. ESXPress converts an insurance carrier's estimate PDF, also called the scope, into a Xactimate .esx estimate file: line items, quantities, and the unit prices exactly as they appear in that PDF. Every line carries the price from the customer's own PDF. The conversion is a preservation step; repricing is a separate moment that belongs to import, not to conversion.
That separation is worth being precise about, because it causes most of the confusion around repricing. Two price environments are in play: the one that priced the original scope, and the one sitting on the machine that receives your file. When the file moves from one to the other, the receiving environment re-prices what it can recognize. If you know which lines it can recognize, you know what to expect before you ever click import.
Why the receiver's price list reprices — it is the design
The cleanest way to state it: an ESXPress export carries no price-list identity at all. Since 2026-09-02, the exported .esx file includes no price-list name, no tax block, and no minimums. Nothing is embedded that tells Xactimate which list to use, so the receiver's list is the one that applies at import.
That is intentional. The exported file asks Xactimate to reprice — that is the intended design: your chosen price list does the pricing. We do not pick a list for the file, because a price list is a local decision: the estimator who opens the file works with the list installed on their machine, in their region, for their company. If the file claimed an identity it does not own, the receiving machine would be forced to apply someone else's rules.
A real import test in Xactimate confirmed the file opens clean. The software then asked the operator to reprice, which is exactly the desired result. Nothing about that prompt is unusual — it is the signal that the file arrived neutral, carrying no list identity for Xactimate to fight. The prompt is the design working, not a warning.
What we preserve: PDF prices stay on the line until the receiver decides
The PDF price is the source of truth. Every line carries the price from the customer's own PDF, and that is the rule the converter operates under. It is also the reason the file you hand over starts with numbers you recognize.
The rule has a sharp edge that gets missed: if a product code is not recognized, the PDF price is kept and the line is flagged. The total never silently changes. No line is priced by guesswork, no code is invented, no price is estimated into existence. Unrecognized lines simply keep their PDF price, and the flag makes them findable.
So the honest sequence is: conversion preserves the PDF numbers, import may move the lines the receiver can price, and everything else holds. When you review the file after conversion, the flagged lines are your review list — lines the receiver will not be sure about, and lines worth confirming before the estimate reaches the adjuster or the customer.
What ESXPress cannot do is stop Xactimate from applying its own list on import; no converter can. What we control is the file's content: the PDF's prices, quantities, and codes, with a flag wherever a code is unresolved.
Measured truth: how much actually reprices
Measured across 289 real files and 7,525 line items: 2,756 line items — 36.6% — carry a code our catalog recognizes. The rest keep their PDF price. In other words, most line items in the population we measured do not reprice at all.
The per-file numbers matter even more. The median estimate file moves 17% of its lines, and 39 files move none. A typical file changes roughly a sixth of its lines on import; about one file in seven changes nothing.
Our code coverage is grounded in a real claims claims data: 33,076 line items and 6,648 distinct product codes extracted from real insurance claim documents, from the August 2026 wave. A code that appears in that claims data is recognized; a code outside it is flagged unresolved instead of guessed.
What this means in practice: do not assume a file is stable because the last one was. Coverage varies file to file, and the only way to know what a specific estimate will do on import is to check that specific estimate.
Check before you import: the reprice checker
The reprice checker shows you, before Xactimate ever opens the file, which lines carry a code the ESXPress catalog recognizes and which ones fall back to their PDF price. It is part of the public toolset on the site: a free code search, an ESX validator, the reprice checker, a profit calculator, a glossary, and guides.
The result is effectively a pre-import answer to the reprice question. If the checker shows most of a file's lines are recognized, expect the receiver's list to move a meaningful share of them. If it shows a thin share — or none — the file will arrive mostly as the PDF priced it.
Pair the check with the code dictionary: 1,480+ dedicated Xactimate code pages, one per trade code, with a description, a category, and related links to other codes. When a line is flagged, look the code up, confirm what it is, and decide whether you want the receiver to price it at all.
Run the ESX validator on the same file to confirm the structure before delivery, and the guides cover the conversion workflow end to end. Checking on the way out beats explaining a moved total after the file has already gone.
How to avoid surprises on the job
Build the check into your workflow before the file reaches Xactimate: run the reprice check, note the share of recognized lines, and pull the flagged list. Flagged lines are the unresolved-code lines — the ones to verify against the PDF before the estimate is submitted.
Keep the source PDF in reach when you review the imported result. When a line moved, you can see exactly what it was before and what the receiver applied. When it did not move, the flag tells you it was held at the PDF price on purpose.
Two facts to carry into every import: the receiver decides, and the file is neutral. A real import test in Xactimate confirmed the file opens clean, and repricing on import is the intended design — the receiver's list does the pricing. If the total after import differs from the PDF total, the difference came from that decision, not from the conversion.
The pipeline behind the export is monitored continuously: an automated upload, convert, and download smoke test runs every 30 minutes, and sketch exports travel the same path as production files. The point is not that conversions never change; the point is that the only changes on import are the ones Xactimate makes on lines the PDF's codes let it recognize.
Frequently asked questions
Does repricing change the total of my estimate?
It can — and when it does, that is Xactimate's choice, not the converter's. On import, the receiving price list reprices the lines it recognizes, and those new unit prices can raise or lower the total. The conversion itself never silently changes a total: the line prices you get from ESXPress are the PDF's. Once Xactimate reprices, the numbers belong to the receiver's list.
Why does the receiver's price list reprice at all?
Because the exported file carries no price-list name, no tax block, and no minimums. The exported file asks Xactimate to reprice — that is the intended design: your chosen price list does the pricing. A real import test in Xactimate confirmed the file opens clean, and the software asked the operator to reprice, which is the desired result.
What happens to lines whose codes are not recognized?
The PDF price is kept and the line is flagged. The total never silently changes for those lines, and no code is guessed to fill a gap. The flag is how you find them in the file, and the PDF is how you verify them. An unrecognized code is an unresolved code — visible, reviewable, never silently priced.
How do I know which lines will reprice before I import?
Run the reprice check on the exported file and read the share of lines that carry a code our catalog recognizes. Across 289 real files and 7,525 line items, 2,756 lines — 36.6% — carry a recognizable code, so a typical file has a visible minority of lines that can move on import.
How many files actually change after repricing?
Measured across 289 real files, the median estimate file moves 17% of its lines, and 39 files move none. Most line items in the measured claims data keep their PDF price; the files to watch closely are the ones where a large share of codes land in the recognized set.
Can I keep my PDF prices after import?
The conversion always preserves them — every line carries the price from your PDF, and unresolved lines keep it, flagged. For recognized lines, Xactimate applies the receiver's list at import, and that is the design. Review the flagged lines before import and compare the imported result against the PDF afterward, so no movement is a surprise.
Is the reprice checker free?
Yes. It is one of the public tools on the site, alongside the free code search, the ESX validator, the profit calculator, the glossary, and the guides. The code dictionary behind the checks covers 1,480+ dedicated Xactimate code pages.