Two estimating ecosystems, two different databases
Xactimate and Symbility are both estimating platforms that insurers use to review repair and restoration work. They are standards of the estimating trade, which means carriers build their expectations around them. Each platform carries its own product code database and its own way of building and reviewing an estimate. A team that handles work for more than one carrier can see both names on a single week of job lists.
The point of comparing them is practical. When an estimate has to be handed back to a carrier, the platform that carrier uses decides the deliverable. That is the difference that touches a contractor day, not a question of which product is better or faster.
Neither platform is a spreadsheet. Each is built to carry line items, product codes, quantities, and pricing through a structured review. The structure is not identical between the two, and the databases behind them are not identical either. That is a fact of the estimating ecosystem, not a criticism of either platform.
For a contractor, the practical question is not which ecosystem to learn. It is what happens after the scope PDF arrives. Because the reviewing carrier owns the standard, the handoff file is the thing that has to match. Everything in this post follows from that simple fact.
The scope PDF is where every job starts
Before either platform is opened, the carrier scope PDF is the starting document. It contains the estimate the carrier wrote: line items, quantities, and the unit prices. Adjusters and restoration contractors read it to agree on the work, what gets ripped out, what gets set, what gets replaced, and at what price.
That PDF travels. A carrier may issue work in one estimating platform and ask for the corrected or supplemental work to come back in another. For work reviewed in the Xactimate ecosystem, the delivered format is a Xactimate .esx estimate file, the file that holds the line items, quantities, and unit prices the receiver reads.
This is where the two ecosystems meet the everyday workflow. The estimating platform defines what the deliverable looks like. The scope PDF defines what goes inside it.
The scope PDF is also the only version of the estimate a contractor may hold on a job. It is what gets priced on the ground, and it is what the carrier compares against when the estimate comes back. When the deliverable has to be a Xactimate .esx file, the task is to move that document into the format without changing its numbers, and without losing the flag when a line does not match a code.
Where a PDF-to-ESX converter fits
ESXPress sits at that meeting point. It reads an insurance carrier estimate PDF, the scope, and writes a Xactimate .esx estimate file containing the line items, quantities, and the unit prices. The work already done in the PDF is carried across into the format the receiver expects.
The rule that governs the conversion is simple to state: the PDF price is the source of truth. Every line carries the price from the customer own PDF. If a product code is not recognized, the PDF price is kept and the line is flagged, so the total never silently changes.
The exported file also carries no price-list or tax identity: no price-list name, no tax block, no minimums. When that .esx file is imported, the Xactimate receiver applies its own price list. A real import test in Xactimate confirmed the file opens clean, and the software asked the operator to reprice. That is the intended design: your chosen price list does the pricing.
That is the whole position of a converter in a comparison between ecosystems. It does not replace either platform, and it does not insert itself into which platform a carrier chooses. It carries work from the PDF side to the .esx side so the numbers arrive in the format the reviewing platform expects.
There is a sketch side as well. Floor plans inside a scope PDF can be exported 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 runs are faster, and sketch exports run through the same production pipeline as conversions.
What the numbers say about converted estimates
We measure our own output, because descriptions of conversion are worth about as much as the measurement behind them. Across 289 real claim files containing 7,525 line items, 2,756 line items, 36.6%, carry a product code the catalog recognizes.
The median estimate file moves 17% of its lines, and 39 files move none. That split is the honest picture of conversion: some estimates are mostly coded and repriced by the receiver, while others carry codes outside the catalog and keep their PDF price.
The reference material behind the converter is built from real claims. 33,076 line items and 6,648 distinct product codes were extracted from real insurance claim documents in the August 2026 wave, and the code dictionary is public and free: 1,480+ dedicated Xactimate code pages, each with a description, a category, and related links, plus a free code search, an ESX validator, a reprice checker, a profit calculator, a glossary, and guides.
None of this is a promise that every line converts to a catalog match. It is a description of what the conversion does and how the pipeline behaves on real files, and the pipeline is checked continuously: an automated upload-to-convert-to-download smoke test runs every 30 minutes.
The takeaway for a restoration team is that a converted estimate is a reviewed one. You know before you send which lines the receiver can reprice and which lines hold the PDF price, because the flags say so. That kind of visibility is what makes a converter a workflow tool rather than a black box.
Why reprice on import is the design, not a surprise
When a converted estimate opens in Xactimate and the receiver asks to reprice, that is not a sign the conversion failed. The exported file intentionally carries no price-list name, no tax block, and no minimums. The receiver applies its own list on import. The reprice prompt is the intended behavior.
The words matter here. The converter job is to move the estimate structure and its PDF prices, not to decide what a price should be. Where the catalog recognizes a code, the receiver list can reprice it. Where it does not, the PDF price stays and the line is flagged. Nothing about a total changes without being visible.
A real import test in Xactimate confirmed the file opens clean. For teams that want to check a file before sending it, the free ESX validator and reprice checker cover that ground without needing an import.
Every converted estimate is generated through the same pipeline as production, and an automated smoke test exercises upload, conversion, and download every 30 minutes. If a sketch or a conversion reached a customer file, it came through that checked path.
Choosing what fits your workflow
The practical comparison between the two ecosystems resolves into one question: which platform reviews the estimate? If the answer is Xactimate, the deliverable is a .esx file, and a converter that keeps PDF prices and flags unmatched codes fits between the scope PDF and the estimate.
If the reviewing carrier uses a different platform, the same scope PDF still carries the numbers. The receiving platform simply decides the file format. Either way, the document that starts the job and the prices inside it are the same.
Restoration work is about getting an estimate reviewed and paid without re-explaining the work. The ecosystems are standards because carriers use them. A converter is useful precisely because it moves existing work into the file format the receiver already expects.
If you want to look at the conversion side before deciding, the free ESX validator and reprice checker take a file and show what it contains. That is a smaller commitment than switching estimating platforms, and it answers the question with the actual numbers.