What a price-list identity is, and why it matters
Every Xactimate estimate is priced against a price list. Choosing that list is a global change: it reaches every line in the file at once. The list sets labor rates, material prices, tax rules, and minimums across the whole estimate, and the file carries the values it was priced against.
That is why identity matters before one line is touched. A file that carries a baked-in list name claims a location it may not belong to. If the person pricing the job is in a different state than the job site, or the materials buyer is in another one, the estimate should not assume any of them.
The same logic applies to tax. A tax block stamped into the file is a tax claim: it says which jurisdiction and which rate apply. Our .esx exports carry no price-list name, no tax block, and no minimums. The receiving machine's own list does the pricing, every time.
No region is claimed, so no region has to be undone. The estimate can be opened in Xactimate against the list the receiving machine uses, and the pricing decision stays where it belongs: with the person importing the file.
What Xactimate global changes do to an imported file
Xactimate global changes work by applying one choice to many lines at once: a price list, a tax setting, a labor benchmark. For a file you import, the moment of truth is the import itself, because that is when the receiving machine decides which list the estimate is priced against.
With a stamped file, the import has a fixed answer: the list baked into the file. With an agnostic file, the answer is the receiving machine's own list, and the import prompts you to confirm. You see the choice, and you make it.
The prompt is part of the workflow, not a failure of the file. The conversion keeps the estimate's line items, quantities, and unit prices from the PDF, and the receiving list does the repricing on import. One file, one workflow, and the price list stays an import decision instead of a locked-in one.
That is what makes a global change useful for this kind of estimate: it applies your list's rules to every line the file carries, without the file having guessed which list you wanted.
The 2026-09-02 design: no list, no tax, no minimums
As of 2026-09-02, the exported .esx file carries no price-list identity: no price-list name, no tax block, no minimums. Nothing in the file asserts which list, which tax rules, or which minimums should apply to the estimate.
The reasoning is straightforward. The estimator's or materials buyer's location can differ from the job site, so the estimate file itself should not claim one. Downstream, that means the file can be opened against any location's list without carrying a list it cannot stand behind.
The line items, quantities, and unit prices still come from the PDF; the design changes which list prices them, not the content of the estimate. The estimate is what the carrier wrote, ready to be priced by the list you choose.
A real import test in Xactimate confirmed the file opens clean, and Xactimate asked the operator to reprice, which is the intended result: the chosen price list does the pricing.
The same file works for either side of the job. For the contractor, it opens against the list used to write the estimate. For a carrier or a buying adjuster, it opens against the list that machine carries. Nothing has to be re-emitted, and nothing has to be re-typed.
So yes, Xactimate may reprice on import: the honest math
When the receiving machine applies its list, lines that match that list get re-priced against it. That is normal Xactimate behavior, and for our files it is the point: the exported file asks Xactimate to reprice, and your chosen price list does the pricing.
Being honest about the size of that pass: measured across 289 real claim files totaling 7,525 line items, 2,756 line items, 36.6%, carry a code our catalog recognizes. The rest keep their PDF price.
The median estimate file moves 17% of its lines when repriced, and 39 files move none. A repricing pass is usually partial, not a wholesale rewrite. That is why the numbers above are worth checking before you assume every line has moved.
Every line remains visible in the estimate, so a partial repricing is never a black box: lines that match the receiving list move, lines that do not keep the PDF price, and both stay in the file where you can see them.
What never changes: the PDF price on every line
The PDF price is the source of truth. Every line starts with the price from the customer's own PDF. If a product code is not recognized, the PDF price is kept and the line is flagged, and the total never silently changes.
So the workflow is predictable. Lines whose codes match your list may move; codes the list does not know stay exactly as the carrier wrote them, flagged so you can find them in the estimate and price them into your own list if you need to.
A global change and a conversion are different phases of the same job. The conversion trusts the PDF and carries its prices; the global change happens later, in Xactimate, when you decide which list to apply.
The flag on an unmatched line is not a block. It is information: the line keeps its price, the estimate keeps its total, and the flag tells anyone opening the file that this line was carried through from the PDF rather than matched to a catalog code. If it is correct, it stays. If it should move, you know exactly where to price it.
Check the estimate before you import
The reprice checker is a free tool that inspects an .esx before import, so you can see which lines would move under a new list before you commit. The ESX validator checks the file structure, and the code dictionary carries 1,480+ dedicated Xactimate code pages with descriptions, categories, and related links.
The data behind those pages is grounded in a real claims claims data: 33,076 line items and 6,648 distinct product codes were extracted from real insurance claim documents in the August 2026 wave, and the claims data is cited in the guides.
Run both tools before you import, and the repricing pass stops being a surprise: you know which lines can move and which will keep their PDF price, and you know the file structure is clean before Xactimate reads it.
The same approach runs beside the estimate
The no-identity design applies to the sketch side too. Floor plans in a scope PDF export as Xactimate-ready .skx sketch files: one per floor page, or a zip. The first export builds the rooms and takes a few minutes; later exports are fast.
Sketch exports go through the same pipeline as production files, and the full upload-to-download flow is exercised by an automated smoke test every 30 minutes. The sketch file is geometry, not pricing, and it stays that way.
The no-identity approach only works if the estimate carries the PDF prices faithfully, and that is the guarantee behind it: the PDF price is the source of truth on every line. The global change then becomes a decision you make, not something the file decided before you opened it.