Meet the ESX converter that reads insurance scope PDFs

What an .esx file actually is

The short version: .esx is the file type Xactimate uses for a full estimate. It is not a PDF, not a spreadsheet, and not a text dump of line items. It is a container built to hold the whole estimate when it moves between a carrier, an adjuster, and a contractor — the line items, the quantities, the unit prices, an optional sketch, and images such as a JPG of the loss.

Inside the container sits an XACTDOC: an encrypted structure that keeps the estimate's content together — line items, quantities, unit prices, and any attached images. Because the payload is encrypted, a .esx file does not open as readable text the way a CSV or a PDF does. If someone sends you a .esx file, you cannot just click and read it; you open it in the software it was built for.

The container can also carry a sketch. Floor plans in a scope PDF are usually images, and ESXPress exports those as Xactimate-ready .skx sketch files — one per floor page, or a zip when a claim has several — so the drawing moves with the estimate. The sketch export was live-tested: the first export builds the rooms (a few minutes), and later exports are fast. Sketch exports go through the same production pipeline as every conversion.

One thing our exports deliberately do not carry is a price-list identity. Since 2026-09-02, an ESXPress .esx file carries no price-list name, no tax block, and no minimums. Xactimate's receiver applies its own list when importing. The outcome was verified in a real import test: the file opened clean and Xactimate asked the operator to reprice — which is the intended design.

Why does the container matter to you? Because the estimate survives as data, not as a picture of a document. The person on the other side opens the file, sees structured line items, applies their list, and adjusts what is actually there — instead of re-keying a scanned scope into a fresh estimate by hand.

Why an ESX converter for insurance is different

Search for 'esx converter' and you will find tools that convert files with the .esx extension that have nothing to do with insurance. The extension is shared: some converters treat .esx as just another file format to change into something else. They are not wrong about the letters; they are aimed at another audience.

The mismatch costs time, not letters. Someone who needs an estimate converted hands a carrier scope PDF to a generic file converter and walks away with nothing usable. An ESX converter for insurance has one specific job: read an insurance carrier's estimate PDF — the scope — and put its actual content into the Xactimate container: the line items, the quantities, and the unit prices.

The difference in one line: a real ESX converter starts from the estimate, not from the extension. ESXPress converts an insurance carrier's estimate PDF (scope) into a Xactimate .esx estimate file — line items, quantities, and the unit prices — and it does that by reading the document, not by renaming one.

Three things to check in any converter before you trust it with a claim: does it use the prices from the estimate itself, does it tell you when it could not match something, and does the output open in Xactimate on the receiver's side? Every other feature is detail.

Why start from the PDF at all? Because the scope is the written record of what the claim pays for. If a converter guesses prices, fills codes from a different catalog, or rounds quantities, the file stops matching the claim. ESXPress treats the PDF price as the source of truth on every line — and when a product code is not recognized, the PDF price is kept and the line is flagged. The total never silently changes.

How ESXPress converts a scope PDF

Scope PDFs carry the claim in trade terms: line descriptions, product codes, quantities, unit prices, and sometimes an image or two. ESXPress reads those and carries them into the container without changing the numbers. The work breaks into a short pipeline — you upload the scope PDF, ESXPress reads the line items, quantities, and unit prices from the document, matches each item against the Xactimate code catalog, and exports a .esx file that holds what the document says. No re-keying, no round trip through a spreadsheet.

The pricing rule is the part worth reading twice. 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 — the total never silently changes. Measured across 289 real claim files with 7,525 line items, 2,756 line items (36.6%) carry a code our catalog recognizes; the rest keep their PDF price.

The flag matters more than it sounds. A flagged line is not a failure; it is the converter telling you exactly which lines Xactimate may reprice against the receiver's list and which lines will stay at the price from the PDF. You see the split before you send the file, not after the adjuster finds it.

The same measurement shows what reprice really means in practice: the median estimate file moves 17% of its lines, and 39 files move none. A converted file can lean entirely on the PDF's own prices — and it still opens and reads as the claim it came from.

Reliability is part of the product here. Every conversion runs through the same production pipeline the sketch export uses, and that pipeline is covered by an automated upload-to-convert-to-download smoke test every 30 minutes. When a file leaves the system, it was produced by the same machinery that just passed the last smoke test.

Your price list, applied on import

An .esx file exported by ESXPress carries no price-list name, no tax block, and no minimums. That is deliberate. Xactimate's receiver applies its own list when importing, so the estimate is priced on the receiver's terms before it is opened for editing.

A real import test in Xactimate confirmed the file opens clean. The exported file asks Xactimate to reprice — and that is the intended design: your chosen price list does the pricing. The receiver, not a stamp baked in at conversion time, decides which list applies.

This matters for two people at once. The contractor importing the file gets his own list and his own labor rates. The carrier adjuster who opens the same file gets hers. Neither has to reconcile against a price list the other side never used.

One more consequence of the neutral design: the file is not tied to a region or a tax jurisdiction. It leaves the converter as a plain estimate — items, quantities, prices — and picks up the receiver's pricing context at import, not at export.

The practical result on import: Xactimate reprices the lines it recognizes from the receiver's list, and lines with no recognized code keep the price from the PDF. The file is neutral about who is reading it; the numbers still come from the claim.

Check the file before it leaves your desk

A .esx file is a container, so a glance is not enough — you want to know what is inside before you send it. The free ESX validator and the reprice checker on this site are built from the same catalog the converter uses, so you can run the same judgment the software will run on import.

A validator answers the questions you would otherwise forward to the adjuster: whether the file holds what the scope said, and whether anything in it will surprise Xactimate when it opens.

The code dictionary behind those checks is public and free: 1,480+ dedicated Xactimate code pages, each with a description, category, and related links — the drip edge page is a good example — plus a free code search, an ESX validator, a reprice checker, a profit calculator, a glossary, and guides.

That catalog was built from real claims, not from a catalog the converter generated by itself. A claims data of 33,076 line items and 6,648 distinct product codes was extracted from real insurance claim documents in the August 2026 wave, and the guides cite that claims data throughout.

A practical routine takes minutes: run the validator on the new file, run the reprice checker to see which lines will move under the receiver's list, and compare the totals against the scope PDF. If the number in the PDF is the number in the file, the conversion did its job.

What to do with the .esx file once you have it

Import it into Xactimate. The file opens, the receiver's list is applied, and lines with a recognized code can reprice against that list; lines the catalog did not recognize keep the price from the PDF — the same lines the converter flagged at export.

Keep the source PDF alongside the .esx file. The PDF is the claim's own record, the .esx is the working copy — and when a line is flagged, the PDF is the reference that settles it.

For a contractor without Xactimate in-house, the file is still the deliverable: the carrier or the third-party adjuster opens it on their side. What you can do without the software is check it first — review the reprice breakdown, compare it to the PDF, and send the file with that summary.

Where you go next depends on where you stand. Read about the full PDF-to-ESX flow, see how the underlying data was built and measured, or look at the reliability story before you run a real claim through the converter. Each link below is a live page, not a placeholder.