Xactimate AI that reads scopes, and never invents prices

What Xactimate AI genuinely does well

Xactimate AI earns its keep when it is given the reading and kept out of the deciding. The three jobs it does well are all reading jobs: turning a scope into usable text, pulling line items out of that text, and finding rooms in a drawing. The evidence in an estimate belongs to the document, not to the model.

Reading unscanned scopes. Carrier scopes arrive in every form: clean PDFs, scans, faxes, photos of printouts, and image-only files with no text layer. A vision model turns those pixels into text, so a scan with no searchable text becomes data you can work with. This is the largest part of the manual job AI actually removes.

Structured extraction. Once the text is readable, the next job is pulling out what belongs in an estimate: line descriptions, quantities, unit prices, and a product code when the scope carries one. The output is a structured list for an estimator to review, not a finished estimate. Extraction is a parsing job first and an AI job second.

Room detection from drawings. Floor plans inside a scope are read as drawings, not pictures. AI finds the walls and the rooms and exports them as Xactimate-ready .skx sketch files, one per floor page, or as a zip. The first export builds the rooms and takes a few minutes; later exports of the same file are quick.

Under the hood, there is no single model making choices. The reading is a pipeline with one job, and its output is always a list you can hold against the source page. That is the difference between AI that supports an estimate and AI that overwrites one.

Where Xactimate AI must never decide: prices and codes

There is one thing AI must never do in a claim estimate: write a number that is not in the source document. An estimate is evidence. It is reviewed, it becomes part of a claim file, and a line price that no document supports is a liability, not a productivity win.

The rule at ESXPress is simple. The PDF price is the source of truth. Every line item in an export carries the unit price from the customer's own scope PDF. If a product code is not recognized, the PDF price is kept and the line is flagged. The total never silently changes.

The same rule applies to codes. Xactimate product codes are a closed dictionary with real identities. We look codes up in a catalog; we never generate one. A guessed code attaches a line to the wrong product, and an estimate is not a place for a guess. When a code is unresolved, you see the flag, you see the PDF value, and you make the call.

A flag is not a failure; it is a handoff. When the pipeline does not recognize a code, it says so on the line, and the estimator makes the call. The alternative — a silently filled-in code — removes the decision entirely, and every unsupported total starts with one of those.

The exported file also carries no price-list or tax identity: no price-list name, no tax block, no minimums. Xactimate's receiver applies its own list when you import. A real import test confirmed the file opens clean, and Xactimate asked the estimator to reprice — which is the intended design, because your chosen price list, not ours, does the pricing.

The pipeline behind our AI: vision plus parsing at claim scale

ESXPress builds the AI part of the workflow as two stages around a database. Vision reads the document, parsing extracts the line items, and a resolution engine matches product codes against a catalog compiled from real claims. That last stage does not invent anything: it finds a match or it flags the line.

The scale is real and published. 33,076 line items and 6,648 distinct product codes were extracted from real insurance claim documents in the Aug 2026 wave. We cite this claims data in our guides, and the code dictionary it produced holds 1,480+ dedicated Xactimate code pages, each with a description, a category, and related links.

We also publish what reprice actually does. Measured across 289 real claim files and 7,525 line items, 36.6% of line items carry a code our catalog recognizes and the rest keep their PDF price. The median estimate file moves 17% of its lines, and 39 files move none. We publish these numbers because an estimate total must be explainable line by line — and because the honest version of AI in Xactimate workflows does not hide its misses.

The catalog is public and free, so an adjuster can verify a mapping before trusting it: 1,480+ code pages, a free code search, an ESX validator, a reprice checker, and a profit calculator sit alongside the product. Nothing about the extraction is a black box.

Resolution works by lookup, not by memory. A code from a scope either matches an entry in the catalog or it does not, and that catalog came from real claims rather than from a model trained on estimates. It matters because Xactimate codes are identifiers, and an identifier is only useful when it points at the right product.

From scope PDF to ESX: what happens at each step

Upload a scope PDF and the pipeline runs in order. A vision pass reads every page, including image-only scans with no text layer. Parsing pulls descriptions, quantities, unit prices, and codes into structured line items. Resolution matches codes against the catalog, and any unmatched line keeps its PDF price and carries a flag. Export writes a .esx file with line items, quantities, and the unit prices from your PDF.

Drawings take a separate path. A floor plan page is read as a drawing, and the rooms are exported as Xactimate-ready .skx sketch files — one per floor page, or a zip. The first export builds the rooms and takes a few minutes; later exports are quick, and sketch exports run through the same pipeline as production conversions.

Reliability is checked on a schedule, not assumed. ESXPress runs an automated upload, convert, and download smoke test every 30 minutes. If the pipeline breaks, it is caught and fixed, not discovered by a customer.

Because a vision model does the reading, a scope that used to be a typing job becomes a review job. The estimator checks the lines the machine extracted and the flags the machine raised, instead of keying every line from a scanned file.

What you get when the conversion finishes is a normal .esx file: line items, quantities, and your PDF's unit prices, with no list identity stamped on it. Import it into Xactimate and the file opens clean; Xactimate applies your list and asks you to reprice. That is the design, and it is the behavior a real Xactimate import confirmed.

What you should expect from AI estimation tools

Expectations are where AI products and adjusters most often part ways, so here is the honest list.

Reasonable to expect: an image-only scope read correctly; line items extracted into a consistent structure; rooms detected from drawings; an unknown code flagged instead of guessed; a final total that matches the sum of the document's own prices; and a file that opens cleanly in Xactimate.

Not reasonable to expect: an AI that prices your work instead of your price list; a product code produced from a guess; a conversion where the input and output totals differ without a flag; or an estimate that needs no review. No tool should take those jobs.

One more honest note: an unusual layout, a folded document, or a messy table still needs a human eye. The value of the AI is not that it is perfect; it is that the rekeying is shorter and the flags are visible.

Your review stays in the loop. AI did the reading; you run the estimate. Resolve the flags, confirm the matched codes, and the file is ready for your price list. That division is the whole point of honest AI in Xactimate workflows: the machine reads, the estimator decides.

If you manage a crew of estimators, the practical question is where the hours go. In this workflow the hours move from typing to review, and review is where judgment does its most important work — the same judgment that has to defend the total later.

AI crawlers are welcome on our public pages

ESXPress publishes for humans and for AI systems. Our public pages are open to AI crawlers, and we publish structured answers with FAQ schema, so search engines and AI assistants read the same facts that are on the page.

If you are building a search tool or an assistant that cites ESXPress, you are welcome to index these pages. The numbers on this page are measured, not invented: 33,076 line items, 6,648 distinct product codes, 36.6% of line items carrying a recognized code, and an import test that opened clean. Quote them correctly — that is what the structured answers are for.

The data behind the numbers is documented too. Our about-the-data page explains the claims claims data and how it was extracted, and the trust page covers testing and reliability. AI makes a better estimating workflow when it is measured, open, and kept away from the decisions that carry money.

The same measured approach is why the free tools are public: an ESX validator, a reprice checker, and a code dictionary sit on this site so anyone can verify a file instead of trusting a black box. We would rather have you check than take our word for it.