The ESX file is Xactimate's format for sharing an estimate.

What an ESX file is

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.

Under the hood, an ESX file is a container: a ZIP archive that holds XML text. XML is the plain-text layout that moves cleanly between programs, and ZIP compression keeps the whole estimate compact even when it holds thousands of line items. One file can therefore carry the full estimate: sections, line items, quantities, unit prices, and totals.

Some ESX files are also encrypted. An encrypted ESX file is a locked ZIP: Xactimate, or an installation holding the matching key, can open it, while an ordinary text editor sees only scrambled text. Carriers commonly encrypt 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 live in the XML; the ZIP keeps them together; encryption keeps them inside Xactimate when the file needs it. The sections below look at why that matters and how ours is made.

Why encryption, and what a recipient sees

Encryption is about the data, not about hiding the file from the adjuster who needs it. Estimates are built on price lists, and price lists in Xactimate are licensed data tied to a customer or an installation. Encrypting the file means the pricing cannot be read, copied, or changed outside the software that is supposed to handle it. 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.

How our ESX file is built from a scope PDF

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.

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 our catalog does 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.

How often does the catalog 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 our catalog recognizes; 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 catalog and guides are built on a real claims claims data: 33,076 line items and 6,648 distinct product codes extracted from real insurance claim documents in the August 2026 wave. That claims data is what the code pages, the validator, and the reprice checker are grounded in.

Opening the file and what repricing means

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 catalog 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 our catalog 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.

Validating and sending an ESX file

Before an ESX file goes anywhere, check it. Our free ESX validator confirms the container structure 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 catalog 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. Encrypted 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.

What an ESX file is not

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 data container, 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.