ESX File Won't Import Into Xactimate? Here Is How to Fix It

An .esx file that will not import is rarely a mystery, and it is never bad luck. Xactimate is telling you which layer broke: the file itself, your Xactimate setup, the line data inside the estimate, or the price list on the machine that opens it. The mistake almost everyone makes is retrying the same file. A second attempt does not change the answer. Naming the failure does.

Below is the diagnostic path we walk contractors through when a file bounces. It has four branches. Find yours, and the fix is usually minutes of work instead of a lost afternoon.

Name the Failure First

Failed imports fall into four buckets, roughly in the order we see them:

• The file is refused. Xactimate will not take it at all, usually with a message about the file format.
• The import command is missing. There is no way to even start the import, because that feature sits behind a permission in your Xactimate setup.
• It opens, but the lines are wrong. Items are missing, unpriced, or flagged, and the totals do not match the source.
• It opens and every number moves. The estimate reprices the moment it lands, sometimes line by line, sometimes all at once.

The bucket matters, because the fix lives in a different place for each one. A refused file is a file problem. A missing command is an account problem. Wrong lines are a data problem. A reprice is usually a price list answer, and often not a problem at all.

Failure One: Xactimate Refuses the File Entirely

The classic symptom is a dialog that says the file format is invalid, or an import that dies the moment you select the file. It is the least subtle failure, and it comes from one of three places.

The file was not built the way Xactimate's importer expects. An ESX file is a package with a specific internal shape, the same shape Xactimate writes when it exports one of its own projects. A tool that assembles a file from scratch, without that structure behind it, can produce something that looks fine in a file list and reads as noise to the importer. This is the most common cause we see on files from cheap or first-generation converters.

A code field carries a character that is not allowed. Code references in Xactimate follow a strict pattern. One stray symbol that leaked in from a description, like a plus sign or a bracket sitting inside a code, is enough to fail the whole file. Our free validator exists partly because of this failure class: it checks code shape and flags characters Xactimate rejects.

The file was altered on the way to you. Renaming it, re-compressing it, or passing it through a tool that rewrites it can break the package. Email scanners, cloud drives with their own sync behavior, and the well-meaning helper who zips everything are all repeat offenders.

The fix order is the same in all three cases. Download the file again into a plain local folder, run it through a validator before you touch Xactimate, and if it still fails, go back to whatever produced it and export a fresh copy. Do not hand-edit the file. Nobody wins that fight.

Failure Two: The Import Command Is Not There

This one confuses people because nothing is broken. You open Xactimate, look for the import command, and it is simply not in the menu.

Importing a project file in Xactimate desktop runs through Tools, then Data Transfer, then Import. You point it at a folder rather than a single file, then pick the data inside it. Two things trip people up here.

First, if Data Transfer is missing, that is a permission, not a corrupted install. Xactware's own help documentation is blunt about it: "Data Transfer is not available for all users. If you do not see it, contact your instance administrator to update your security group in Xactimate Admin." In a multi-estimator shop, that is an admin ticket, and it is worth knowing before you spend an hour blaming the file.

Second, when you do import, select the folder. A file buried two levels deep inside a project directory is a common reason an import comes up empty. Put the .esx at the top level of a simple folder and point the import at that folder.

Failure Three: It Imports, but Lines Are Missing or Flagged

Now the file opens and a different kind of trouble starts: a line item will not price, an item shows up flagged, the sketch is blank, or the line count does not match the scope you started from.

Line items in a Xactimate estimate are tied to their price list through a set of identity fields. When those fields arrive incomplete, the line has no home, and Xactimate handles it the way it handles any stranger: it drops it, flags it, or prices it at a default.

There is a right way and a wrong way to deal with a line that cannot be grounded. The wrong way is guessing a code so the file imports clean. The right way is what the file should have done in the first place: keep the price printed on the source document, and flag the line for a human. A flagged line is honest. An invented code is a landmine that shows up in an adjuster's review three weeks later.

If you are on the receiving end of a file with missing lines, do not repair it by hand. Ask the source for a regenerated file, or convert the original scope again. Line-level surgery inside an estimate is how small errors become large ones.

Failure Four: Everything Reprices on Import

This is the failure that is usually not a failure, so it gets its own section.

An ESX file does not carry your prices. When you open one, Xactimate prices the lines from the price list loaded on your machine, for the month that list covers. That is by design. Two contractors in two states should see two different totals for the same scope, because their material and labor pricing is different. A repriced total is not automatically a wrong total.

What you are reading is the shape of the change, not the fact of it. A normal reprice moves the total by a few percent, and the same handful of lines give back most of the difference. A broken reprice looks different in three ways:

• Large blocks of lines land on the same price. That usually means those lines arrived without valid code identities and were priced at a fallback.
• Every line moves by the same ratio. That points at a price list mismatch between the sender and you, not at the line data.
• The total moves by multiples, not percent. That is the signature of a file whose lines could not be matched and got defaulted instead.

The fix for a broken reprice is not in Xactimate. It is in the file: lines need to be matched to real Xactimate SEL codes, and any line that cannot be matched should keep its printed price and be flagged rather than defaulted. A tool that claims to match every line, with no flags and no uncertainty anywhere, is telling you that it guesses. Check any file with a reprice check before you build a supplement on top of it.

What Xactimate's Own Documentation Says

A few of these answers are not opinions. They are written down in Xactware's own help center, and it is worth reading the mechanics in the source's words. The table below quotes each one and translates it into what it means on your Monday morning.

The Five-Minute Pre-Import Check

Run this list before the file ever meets Xactimate. It catches nearly everything above at the door.

1. Confirm what you actually have. A PDF renamed to .esx, or a half-finished download, fails before it starts. Check the size, and confirm it came from a source that produces real ESX files.
2. Move it to a plain folder. Local drive, top level, no cloud sync, no zip wrapper.
3. Validate the structure. The free ESX validator checks the file package, the required sections, and the shape of every code, right in your browser, and the file never leaves your machine. Thirty seconds here beats an hour of guessing later.
4. Set your price list before you import. Know which region and month you are pricing in, so the first total you see is your own and the reprice prompt is not a surprise.
5. Decide merge or open first. Importing into an existing project and opening a fresh one are different operations, and picking wrong duplicates groups or buries lines.
6. Check three numbers right after the import. Line count against the source, the three biggest line items, and the total. If the count is short, stop and fix the input before you build anything on top of it.

When to Regenerate Instead of Repair

One rule covers most decisions: if the problem is in the file, regenerate the file. Structural failures, missing lines, and defaulted prices all trace back to how the file was made, and none of them are reliably fixable by hand afterwards.

Choose tools by what they do when they cannot be certain. A conversion that keeps the price printed on the source document and flags the line for review is telling you the truth about its own confidence. A conversion that silently fills every gap is hiding it, and the gap reappears later, usually in front of an adjuster.

That is the standard we hold our own conversion to. A carrier scope arrives as a PDF or a scope XML export, and every line comes out either matched to a Xactimate SEL code or flagged with its printed price intact. Nothing on the estimate gets invented, and nothing gets dropped quietly.

If you only need the click path, our step-by-step import walkthrough covers it screen by screen. Use this page when the walkthrough's happy path is not what happened to you.

Ready to stop rebuilding scopes by hand? Start free, 5 conversions a month, no card required →

Review required: AI-assisted content requires professional review, verify every line item, price, and total against your actual scope before submission.

Related: validate an ESX file free, and why Xactimate reprices an estimate.