Xactimate ESX File: What an .esx File Is (and What It Is Not)

An ESX file is the estimate file format used by Xactimate, the estimating software that restoration contractors, estimators, and insurance adjusters all work with. The three letters at the end of the filename, .esx, tell Xactimate exactly what it is holding: a complete estimate, not a scanned page. Where a scope PDF shows you the document as it was written, an ESX file is structured data a program can open, edit, and reprice.

An ESX file is self-contained: one file carries the whole estimate, built so Xactimate opens, edits, and reprices it as a working estimate rather than a scan of a printed page. One file holds the sections, line items, quantities, unit prices, and totals, and it stays compact even across thousands of line items.

Some ESX files are also locked. A locked ESX file opens in Xactimate, while an ordinary text editor sees only scrambled text. Carriers commonly lock the estimates they issue, because an estimate carries pricing data meant to be read inside the estimating software.

So the short answer to "what is an ESX file" is a plain one: it is the Xactimate-readable container for one whole estimate. Think of a DOCX file for Word. The ESX file is the document, and the software on the other side knows exactly how to open it.

From here, everything else is detail. Sections, line items, quantities, prices, and totals all travel in the one file, and locking keeps them with the software when the file needs it. The sections below look at why that matters and how ours is made.

Three unrelated products share the .esx extension, and one shares the name. VMware ESXi is a bare-metal hypervisor, a server product with an i on the end rather than a file; searching for "ESX" or "ESX validator" returns Broadcom and Dell pages that have nothing to do with an estimate. Ekahau ESX is a Wi-Fi site-survey file from a wireless planning tool. Korg ESX is a music-workstation file.

Xactimate ESX, from Verisk, is a property-insurance estimate. The four do not open each other and there is no conversion between them. If a claims .esx will not open in your hypervisor or your Wi-Fi planner, that is working as intended: it belongs to Xactimate.

The collision is why the plain question "what is an .esx file" returns answers about virtual machines and wireless surveys. In the claims industry the answer is narrower and worth saying plainly: an ESX file is the estimate, and the estimate is what a carrier, an adjuster, or a contractor sends when the numbers have to be worked rather than read.

An ESX file holds the whole estimate as one working document: the sections and line items, each with its quantity and unit price, the folders and trades the carrier grouped them into, and any photos or supporting attachments that were included. Xactimate opens all of it as a single project rather than a set of pages.

Totals are computed by Xactimate from the line items, so a file does not carry a fixed grand total of its own. That is one reason a converted file carries no price-list identity and why the receiving copy of Xactimate owns the repricing.

Locked carrier files open only in Xactimate, so the estimate stays with the software that reads it. How the file imports, and what the reprice prompt means once it is open, is covered below.

Step 1: save the .esx somewhere you can find it. Step 2, on Xactimate desktop: drag the file onto the Projects page, or use Tools, then Data Transfer, then Import. Step 3, on Xactimate online: install the Xactware ClickOnce extension first, then import from the Projects tab, remembering that a project checked out elsewhere stays locked until it is checked back in. Step 4: answer the reprice prompt.

You do not need to redraw anything. The estimate imports with its line items, quantities, and prices intact, and hands repricing to the price list loaded in your copy.

Export is the mirror image. An ESX file is what Xactimate writes when you save or send a project: with the estimate open in Xactimate, use its export or send options, or send it through XactAnalysis, to write out the .esx. The file carries the line items, quantities, and prices, and the receiving copy reprices it on import exactly as above.

If you would rather follow the whole sequence with the screen in front of you, the step-by-step import walkthrough covers the same four steps and what each prompt means.

To edit or reprice one, no. The estimate is Xactimate's own structure and there is no free desktop viewer that turns it back into a working estimate. To inspect one, yes, and nothing needs to leave your machine: view its sections, line items, and totals locally in a free browser ESX viewer, and check the file with a free ESX validator.

That split is the practical answer to the PAA question. Reading a file is a browser job; working it is Xactimate's job. The viewer and the validator are free, need no account, and run against the same file the conversion produces, so what you check with is the same engine that built the file.

Four formats show up around the same estimate, and they are not interchangeable. The table below sets them side by side: what each one holds, whether it can be edited, and which program opens it.

The short version: a PDF is a read-only document, an .esx is the working estimate, an .skx holds only sketch geometry, a .chx is an older Xactimate 27/28 project that current Xactimate still imports, and a scope XML export is structured input a converter reads rather than a substitute for the estimate itself.

The lock is about the data, not about hiding the file from the adjuster who needs it. Estimates are built on price lists, and the lock keeps that pricing inside the software that is supposed to handle it, where it cannot be read, copied, or changed outside the estimating flow. For a carrier sending a scope, it also protects the estimate from being edited before it reaches the estimator.

What the recipient sees is simple. Open the file in Xactimate and the estimate loads with its sections, line items, quantities, unit prices, and totals. If the file arrives without a price-list identity, Xactimate may ask whether to apply the recipient's own list. That question is the intended design: the exported file asks Xactimate to reprice, because your chosen price list does the pricing.

The design is verified, not theoretical: a real import test in Xactimate confirmed the file opens clean. The receiver gets the estimate, their software applies their own pricing rules, and nothing in the file sneaks in a price list, a tax block, or someone else's minimums on the side.

That matters because estimate files travel across regions. A price list stamped into a file belongs to the place it was made, not the place the job is. A file without that stamp lets the receiving Xactimate do its job with the list it already has.

None of this is abstract for the people who run restoration claims every day. A file that opens clean, carries only the estimate, and hands pricing back to the receiver's software is the whole reason the format exists.

ESXPress takes an insurance carrier's estimate PDF, usually called a scope, and converts it into a Xactimate .esx file: the same line items, the same quantities, and the unit prices from the PDF itself. Nothing about the total is guessed, and nothing is filled in later. When the scope is available as scope XML instead (Xactimate's or any other system's), the same .esx is built from structured data, no OCR, no reading step at all, and line items, rooms, and notes carried through exactly as written.

The PDF price is the source of truth. Every line carries 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, so the total never silently changes. If the code is recognized, the line becomes a genuine Xactimate line an adjuster can work with.

The flagged lines are the ones worth a quick look. A line that keeps its PDF price is still a real line with the right quantity and price; the flag just means we do not recognize that specific code, so the total stays exactly as the PDF measured it. Nothing is dropped, and nothing is repriced behind your back.

Where a converter stops once the PDF has been transcribed, ours keeps going. A converter can only move what is already on the page; the dashboard conversion runs a 93-rule completeness check and restores what the carrier omitted, flagged, priced, and never silently changed.

How often does the reference recognize a code? Measured across 289 real claim files and 7,525 line items, 2,756 of those line items, which is 36.6%, carry a code we recognize; the rest keep their PDF price. The median estimate file moves 17% of its lines, and 39 files move none at all. Those are real numbers from real claims, not a promise about your file.

The exported file also carries no price-list identity. Since 2026-09-02 our .esx output has no price-list name, no tax block, and no minimums; the receiver's Xactimate applies its own list on import. That is what makes the file usable outside the region it came from.

If the scope includes floor plans, we export those too, as Xactimate-ready .skx sketch files: one per floor page, or zipped together. The first export builds the rooms and takes a few minutes; later exports are fast. Every sketch export goes through the same pipeline as production, and the whole upload-to-download path is exercised every 30 minutes by an automated smoke test, so a broken conversion gets caught quickly.

The reference and guides are built on the claim scopes processed through ESXPress. That work is what the code pages, the validator, and the reprice checker are grounded in.

Open one of our .esx files in Xactimate and you may see the program ask whether to reprice. That prompt is the point, not a problem. The file carries the PDF prices, and Xactimate offers to apply the price list of whoever is opening the estimate.

The split is deliberate. The estimate lines belong to the job: the codes, the quantities, the work performed. The price list belongs to the person paying: the carrier, the contractor, the adjuster. Our files keep the two separate, so nobody carries one region's pricing into another region's job.

If you want to know in advance how many lines might move, use the free reprice checker. It runs the same recognition logic against the reference and shows which lines our engine recognizes and which will keep their PDF price, the same measurement behind the 36.6% figure. Prices come from your PDF, never guessed; the checker simply shows how much of the estimate lands on catalog codes.

What does it mean for you to keep the PDF price? If the receiving software reprices, the lines we recognized move to the receiver's list. The rest stay at the PDF price, because that is what the carrier actually wrote. Either way you can see exactly which lines moved, and the reprice checker previews it before the file goes anywhere.

Before an ESX file goes anywhere, check it. Our free ESX validator checks the file and flags anything a recipient's Xactimate would reject. It needs no account and no customer data.

Then lean on the glossary when the jargon turns up. Our free code dictionary covers 1,480+ dedicated Xactimate code pages, each with a description, category, and related links, plus a free code search. When a line says RFG|RFGDRIP, you look it up instead of guessing what it covers.

The validator and the code dictionary are free and public, and both are fed by the same code reference the conversion itself works from. That means the tool you check a file with is the same engine that built it, not a separate guess.

On sending: an ESX file is a claim document. Locked or not, send it only to the people who need it, exactly as you would handle the source PDF. Our exported files add no price-list name, no tax block, and no minimums, so what you send is the estimate itself, with nothing extra attached.

If any claim on this page still feels uncertain, the reprice page, the conversion flow, and the trust and transparency page explain the same facts in more depth. What you are left with is one small, structured file that opens in the software the whole industry works in.

It is not a PDF, and it is not a picture of one. It is not a spreadsheet either, no matter what your file manager suggests. An .esx is a structured estimate file, and it behaves like itself inside Xactimate.

It is also not a price-list file. A common misunderstanding is that the ESX file sets the prices. It does not. It carries line items and the prices written by whoever produced it; our files keep the PDF prices, and the software applying its own list on import can reprice the lines it recognizes. That is why the same estimate can exist in two states: as the carrier priced it, and as the receiver prices it.

A close cousin is the .skx file, which holds sketch work, not the estimate. When a scope's floor plans matter, the two files travel together: the .esx for the priced estimate, the .skx for the rooms. Neither replaces the other.

Finally, it is not a file only adjusters can use. Contractors, estimators, and project managers with Xactimate can open it, and people without Xactimate can still validate it with free tools before it goes anywhere, or look up any code in the public dictionary.