From a carrier scope PDF to Xactimate without the retyping.
ESXPress takes your carrier scope PDF to Xactimate - line items, quantities, and unit prices from your PDF, then Xactimate reprices on import, by design.
The scope PDF to Xactimate workflow
Every repair job starts the same way for an adjuster: the carrier's scope lands in your inbox as a PDF. That PDF is the adjustment - line items, quantities, and the unit prices, all already decided. The work left for you is getting it into Xactimate without rebuilding the estimate by hand. That is the step ESXPress does, and it is the whole product: scope PDF in, Xactimate file out.
The workflow has three parts. First, the scope PDF goes to ESXPress. Our conversion reads the carrier's estimate and produces a Xactimate .esx estimate file: line items, quantities, and the unit prices, carried over from the PDF you sent. No line is guessed, and no price is invented. If a product code is not recognized, the PDF price is kept and the line is flagged - the total never silently changes. That rule is fixed, not a setting.
Next, you bring the .esx into Xactimate. This is where one design decision matters more than any other: the file we export carries no price-list name, no tax block, and no minimums. Since 2026-09-02 the export has been deliberately price-list-agnostic. If we stamped a price-list identity into the export - the way many converters do - the estimate would inherit prices, taxes, and minimums from a list you did not choose. We deliberately do not do that.
Third, Xactimate imports the file and asks you to reprice. That is the intended result, and it is worth saying plainly: "The exported file asks Xactimate to reprice - that is the intended design: your chosen price list does the pricing." A real import test in Xactimate confirmed the file opens clean, and the software then asked the operator to reprice, exactly as it should.
One clarification saves a lot of confusion later: the conversion does not change the scope numbers. Line by line, what the PDF shows is what lands in the .esx at conversion time. Repricing happens later, at import, only on lines whose codes Xactimate links to your list, and it is always visible on screen before you accept it.
From that point the estimate is yours inside Xactimate: your price list, your tax settings, your labor minimums, your markup. The job we do is getting you to that point from a scope PDF to Xactimate without rebuilding the estimate line by line.
Why Xactimate reprices your lines on import, and why that is correct
The first thing many adjusters ask when they open a converted .esx is: why is Xactimate asking to reprice? The short answer is that repricing is what import is for. Xactimate prices an estimate against the price list active in that install. When a file arrives with no price-list identity - which is exactly how we build it - the receiver applies its own list, and line prices can change. This is the intended design, not a conversion defect.
The alternative is worse. A converter that bakes a price-list name, a tax block, and a set of minimums into the file hands you an estimate priced by someone else's list, in a tax jurisdiction that may not match the job site, with labor floors you never agreed to. You would then have to find and undo all of it. Repricing on import is the clean version of the same step.
And repricing is far more limited than people expect. Measured across 289 real claim files and 7,525 line items, 2,756 line items - 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.
When the estimate is done, nothing about that reprice is hidden. Xactimate shows which lines it updated and what your list returned. If a line should not have moved, it is a one-line edit inside Xactimate, not a problem to hunt for in the file we sent. That is how a reprice should feel - a reviewable step at the end of the workflow, not a surprise inside the file.
So the realistic picture is this: most lines hold the price from the PDF, and on the lines where the code resolves, Xactimate shows what your own list says. Both sets of numbers are visible in the estimate, and you review before anything ships. Nothing changes behind your back.
One more thing worth knowing: some converters treat ESX as a different file format. We do not. The export is a standard .esx that Xactimate opens natively, and the floor-plan export is a standard .skx. The import test above is the evidence - the file opened clean, and the reprice it asked for was the expected behavior.
The PDF price stays the source of truth
When we say the estimate is built from your PDF, we mean it literally. Every line carries the price from the customer's own PDF. We never invent a price, never pull one from a lookup table that might not apply to this job, and never round anything to fit. If the scope shows a line at a certain amount, the .esx carries that same amount.
Unrecognized codes get the same treatment. The PDF price is kept and the line is flagged as unresolved, so you can see exactly where the catalog could not tie the code to a known product. The total never silently changes. At conversion time, the number in the file is the number from the PDF, and any later change to a line is Xactimate showing its own list - a visible, reviewable step.
That discipline is backed by real data. The code dictionary behind the conversion was built from 33,076 line items and 6,648 distinct product codes extracted from real insurance claim documents in the August 2026 wave. We cite the same claims data in our guides, and it is the reason the catalog recognizes the codes it recognizes.
Here is the practical test for any estimate we produce: put the .esx next to the carrier PDF and compare line by line. Every amount on the left has a match on the right at conversion time. Where they later differ, it is Xactimate showing its own list after import, not the conversion changing a number. Keep that separation in mind and a supplement review stays easy to defend.
Practically, what you receive is a faithful copy of the scope in Xactimate format. That matters when a scope comes back for a supplement, when a reviewer asks why a number moved, or when the estimate is compared against the carrier PDF line by line. The paper trail stays intact.
Sketch export: floor plans as .skx files
Insurance scopes often carry floor plans alongside the line items, and those plans are part of the estimate: the rooms and their areas drive the measurements. ESXPress exports the floor plans from your scope PDF as Xactimate-ready .skx sketch files - one per floor page, or a zip containing all of them.
The first export builds the rooms, which takes a few minutes; later exports are fast. The .skx files open in the sketch side of Xactimate, ready to be adjusted with the tools you already use. This was live-tested on 2026-09-04, and sketch exports run through the same pipeline as production conversions.
For a restoration company moving several scopes a month, this is where the time goes: the floor plan is usually the slowest part of rebuilding an estimate. Arriving with the room outlines already drawn means you start at the editing stage instead of the drawing stage.
Multi-floor claims benefit the most. A scope with a main level, a lower level, and an attic arrives as separate floor pages, or zipped together, so each one lands where the estimator expects it. The room outlines are drawn; the remaining work is adjusting them to the inspection and letting Xactimate compute the areas. It is the difference between starting an estimate and finishing one.
Code references, checkers, and guides that ship with the conversion
Codes are the vocabulary of every scope, and vocabulary is where conversion quality is decided. ESXPress ships a public code dictionary: more than 1,480 dedicated Xactimate code pages, each with a description, category, and related links - the drip edge page for the RFG trade is a good example. A code search, an ESX validator, a reprice checker, a profit calculator, a glossary, and guides sit alongside it.
Use them before and after a conversion. Search a code you do not recognize, run the reprice checker to see which lines carry a code the catalog knows - the same lookup behind the 36.6% - or validate the .esx before you send it anywhere. The guides pull from the same claims claims data, so the numbers you read there match the numbers behind your conversion.
The glossary covers the terms that show up in scopes and in Xactimate alike, and the guides walk through the same material with the claims claims data behind them. Run the validator on an exported file before it leaves your desk, and lean on the glossary when a scope uses a term the office spells differently. Small checks before sending are what keep a converted estimate moving without questions.
Everything on this page is measured, not asserted. The upload, convert, and download flow runs an automated smoke test every 30 minutes, and the conversion numbers above come from real claim files rather than a demo set. That is the same standard the product holds every day.
Frequently asked questions
Will Xactimate reprice my lines when I import the file?
Yes, and that is the intended design. The exported .esx carries no price-list name, no tax block, and no minimums, so the receiver applies your own price list on import. A real import test in Xactimate confirmed the file opens clean, and the software then asked the operator to reprice - the expected result. How much actually moves is limited: across 289 real claim files, 2,756 of 7,525 line items (36.6%) carry a code our catalog recognizes, and the median file moves 17% of its lines.
Do I need Xactimate to use ESXPress?
No. The conversion is ours: you upload the scope PDF, we produce the .esx estimate file and the optional .skx sketch files. Xactimate is optional, and its role is viewing, editing, and finalizing the estimate on your price list. Without Xactimate you can still run the result through our ESX validator and reprice checker, or hand the file to an adjuster or contractor who works in Xactimate.
Is ESXPress a replacement for Xactimate?
No - we complement it. ESXPress turns a scope PDF into the file Xactimate opens; Xactimate is where the estimate gets priced on your list, edited, and output. We are the input side of the workflow: we build the .esx, and Xactimate owns the estimate. ESXPress is an independent tool, not a substitute for any part of Xactimate itself.
What happens when a product code is not recognized?
The PDF price is kept and the line is flagged as unresolved - the total never silently changes. No code is guessed and no line disappears. You or the Xactimate user can review the flagged lines and decide what to do with them, which is exactly the kind of visibility you want when the carrier compares its PDF against your estimate.
What files do I get from the conversion?
One Xactimate .esx estimate file with line items, quantities, and unit prices straight from your scope PDF, plus optional .skx sketch files for floor plans - one per floor page, or a zip of all of them. The first sketch export builds the rooms and takes a few minutes; later exports are fast.
Where does the price in the .esx file come from?
From your own scope PDF. Every line carries the unit price the customer's PDF shows, and the export stamps no price-list identity onto the file. When a code is not recognized, the PDF price is kept and flagged rather than replaced with something from a database. The pricing you see on import is your chosen list, not an embedded one.
How reliable is the conversion?
The upload, convert, and download flow runs an automated smoke test every 30 minutes, and sketch exports go through the same pipeline as production conversions. Behind it sits a code dictionary built from 33,076 line items and 6,648 distinct product codes extracted from real insurance claim documents. The reliability claim is measured, not promotional.