Does an EagleView ESX file build a complete Xactimate estimate?

No, and the reason is a distinction worth holding onto. EagleView describes ESX as a project file carrying the full estimate, including line items and pricing, so the file can contain estimate data. What it cannot do is decide the final claim scope, which is the part an estimator argues with a carrier about. An ESX file is how a measurement report gets into Xactimate without an estimator redrawing the roof. You check a box when ordering, the file arrives, and you drop it into a new Xactimate project.

That is the whole mechanism. What follows is what it carries, where it stops, and why the stopping point is the interesting part.

What does an ESX file contain?

EagleView's own description, as of September 2026, is that ESX is a digital project file containing the full estimate associated with a property, covering measurements, sketches, photos, line items and pricing, in a format that is easy to share, review and approve.

The word doing the work there is sketches. Anyone who has estimated a storm claim knows the sketch is the slow part. Getting the roof drawn accurately in Xactimate, facet by facet, is where an hour goes, and it is the step most likely to be wrong in a way nobody catches until an adjuster does.

A file that arrives with the geometry already drawn removes that hour. That is a genuine, measurable saving on every claim job, and it is why the format exists.

How do you order and import one?

Ordering, per EagleView's published guidance as of September 2026: search the property address on its portal, choose the report type such as Full House or Roof Report, check the optional ESX file box, and complete the order. If the report already exists, the Order History section lets you upgrade a previous order to include the ESX file rather than ordering the property again.

That upgrade path is worth knowing before you need it. Offices that decided against ESX at order time often assume they have to re-order the whole report later. They do not.

Importing: drag and drop the file into the Xactimate New Project window, or select Choose File and upload it. EagleView states that once imported, the measurements and sketches are available in Xactimate so you can move straight into the estimate.

What does the ESX file not carry into Xactimate?

It does not write your estimate, and the distinction matters commercially rather than technically.

An ESX import gives you an accurate sketch and the measurements attached to it. What happens next is scoping: which line items apply, what the damage actually requires, what is included and what is supplementary, which price list version is in force, and how all of that is going to read to the person reviewing it.

None of that is geometry. All of it is judgment, and it is the judgment that decides what the job is worth. We took the general version of that argument apart in what a measurement report gives you and what it does not.

The same is true of anything on the claim that is not the roof surface. Interior damage, detached structures, contents, code upgrades. A roof measurement file is silent on all of it by design.

Where does this leave the rest of your workflow?

With a gap on either side of it, and the gaps are where the retyping lives.

Think about the full path of a storm job. A call comes in. Somebody captures the address, the carrier, the date of the event and the claim number. A report gets ordered. The ESX arrives and gets imported. An estimate gets built. It goes to the carrier. Something comes back. A supplement gets filed. Eventually a job gets scheduled and a crew turns up.

The ESX file automates exactly one link in that chain, and it is the only link with a vendor incentive behind it. The rest is a person copying a claim number between four systems, and it stays that way whether or not you use ESX.

Six of those seven rows are a person. That is the honest picture, and it is not a criticism of EagleView or Xactimate, both of which do their own job well. It is what happens when each tool in a workflow is excellent at its own step and nobody owns the joins.

The joins are the part worth building, because they are the part specific to how your company runs a claim. What your intake captures. Where the claim number lives. Which field tells a scheduler that a job is cleared to start. The wider version, where the same information gets retyped between tools that all work fine on their own, is in why roofing software still needs manual data entry.

One practical note if you are standardising. Hover's developer documentation lists ESX among the formats its API can return, alongside JSON, PDF, XLSX, SKP and XML. The format is not tied to a single provider, so a decision to build your workflow around ESX does not lock you to one measurement vendor.