Carrier scope PDFs: where every estimate starts
Insurance carriers send restoration scopes as PDFs. Inside the PDF are the line items, the quantities, and the unit prices that describe the job. For a contractor or an adjuster, that PDF is the starting point for the estimate that has to be priced, justified, and reported back.
ESXPress takes that PDF and produces a Xactimate .esx estimate file: line items, quantities, and the unit prices, in the format Xactimate uses. The output is the estimate file itself, not a PDF dressed up as one, and the conversion pulls the numbers straight from the scope.
The conversion does not invent anything. Every line carries the price from the customer's own PDF. If a product code in the scope is not recognized, the PDF price is kept and the line is flagged. The total never silently changes.
The scope PDF is written by the carrier, but the estimate is the document that moves through the job: it gets priced, it gets reviewed, and it becomes the basis for the report. Keeping those two separate means the conversion is a transfer of quantities, not a rewrite of prices.
Xactimate reports come from the estimate, not the PDF
The important thing about Xactimate reporting is the direction. The estimate file is the source, and the reports come from it. The summaries and totals a carrier sees are generated from the estimate's own line items, not from the PDF it was typed into. The PDF is evidence of what the carrier wrote; the estimate is the thing that gets priced.
That is why the format of the estimate matters more than it looks. If the estimate exists only as a PDF, every report, revision, and summary has to be rebuilt from the document. If the estimate is a native .esx file, the line items, the quantities, and the totals are already in the file Xactimate reads.
When you need the carrier-ready version, the Xactimate to PDF walkthrough covers getting the estimate into report form. The report pages, the summary, and the totals all come from the same file, so the numbers match the estimate.
That consistency is exactly the point for a carrier. A scope PDF lists work; a Xactimate estimate prices it, and the summary totals are part of that pricing. When the estimate is native .esx, nothing about the totals lives outside the file, so nobody has to reconcile a summary against a separate document.
What a scope PDF does not carry
A scope PDF typically lists the scope of work: categories, line items, quantities, and prices. It is made to be read. The estimate file holds the same information in a structured form: priced line items, buckets, and totals that Xactimate can sum, filter, and report on.
Our .esx exports carry that structure without a price-list identity: no price-list name, no tax block, no minimums. The receiving machine applies its own list on import, which is why a real import test in Xactimate confirmed the file opens clean and asked the operator to reprice. Nothing was lost in the conversion; the file is a real estimate.
With a native .esx, line items keep their category, their quantity, and their price in one place, and the totals are computed from those same lines. That is what makes the file usable: it is not a document about an estimate, it is the estimate.
When the estimate is native .esx, totals live in the file
With a native .esx estimate, totals and summaries live inside the estimate. Open the file and the line items, the buckets, the totals, and the summaries are there. There is no separate summary document that can drift from the line items, and no second file to keep in sync.
That matters in the middle of a job, when someone asks for the summary totals or a section breakdown. The answer is inside the estimate itself, in the same file that produced it. Revisions happen in one place, and the report reflects whatever the estimate currently holds.
The same holds as the job grows. When the scope of work changes, the estimate grows with it, and the totals and summaries follow the lines. A report generated from the estimate shows the current result, not a snapshot someone made before a revision.
The receiving machine's own price list applies on import, so the report a carrier eventually sees is priced by the list the file is opened against, not by a list baked into the file.
The report prices start as the PDF prices
Because the PDF price is the source of truth, the numbers in your estimate begin as the carrier's numbers. Measured across 289 real claim files with 7,525 line items, 2,756 line items, 36.6%, carry a code our catalog recognizes. The remaining line items keep their PDF price and stay flagged, so you can see exactly what was matched and what was not.
If a price list is applied during import, the median estimate file moves 17% of its lines, and 39 files move none. For most files, repricing touches a minority of lines; the rest keep the prices they carried with them.
Your reports only reflect what the estimate holds, so totals stay tied to the file. The conversion itself never changes a price; any repricing happens later, when a price list is applied, and it happens in Xactimate, not during conversion.
The free reprice checker shows which lines a repricing pass would move before you commit to it, and the ESX validator checks the file structure before import. Between the two, the numbers in the report are never a surprise.
Floor plans in the scope PDF can travel too
Restoration scopes often include floor plans, and those plans are part of the job too. ESXPress exports them as Xactimate-ready .skx sketch files: one per floor page, or a zip for the whole set. The first export builds the rooms and takes a few minutes; later exports are fast.
For a multi-floor job, a zip keeps the whole set together, one sketch file for each floor page, ready to open alongside the estimate. The .skx holds the geometry; the .esx holds the estimate.
Sketch exports run through the same pipeline as production files, and the full upload-to-download flow is exercised by an automated smoke test every 30 minutes. Floor plans are not a side feature set apart from the conversion; they move through the same path.
Check the estimate before it leaves your desk
A native .esx file is only useful if it is clean. The ESX validator checks the structure of an .esx before you import it, and the reprice checker shows which lines would move. The free code dictionary carries 1,480+ dedicated Xactimate code pages, each with a description, category, and related links, plus code search, a validator, and guides.
The code data is grounded in a real claims claims data: 33,076 line items and 6,648 distinct product codes were extracted from real insurance claim documents in the August 2026 wave. Every number in the code pages has a documented source, and the claims data is cited in the guides.
The validator, the reprice checker, and the dictionary are the same tools used throughout the guides, so the checks you run before import are the checks you are told about in the walkthroughs.