Structured scope intake
Scope XML in. Import-ready Xactimate ESX out.
XML to ESX conversion takes a scope file that another system already structured and turns it into an import-ready Xactimate estimate, with no reading and no retyping in between. ESXPress accepts Xactimate's own export, a carrier export such as a third-party administrator's estimates file, and the line-item table inside any other estimating system's XML. Because the file already carries its line items as fields, the line arrives as data instead of being read off a page: the code is taken from the file where it states one, and resolved from the description where it does not. A unit price carried by a carrier or administrator export, by another estimating system's XML, or by a ScopeJSON payload is used as-is and recorded as coming from the payload. A Xactimate export carries no price that this path reads, so those lines are priced from the grounding catalogue and the row records that source. A line that cannot be grounded is flagged for review, never guessed.
Five conversions a month are free, no card. The paste tool above runs in your browser.
Four shapes, one pipeline
The difference between a clean conversion and a bad one is whether the file is read or only translated. Every shape below lands on the same line items, the same code grounding and the same import guard.
Read field by field
Xactimate's own export
The native interchange file. Claim and project fields, every line item with its category, selector, activity, quantity and unit, and the note text under each line all carry through exactly as written.
Translated, then grounded
A carrier or administrator export
Third-party administrators and carriers ship their own estimate XML with their own vocabulary. The translator maps that vocabulary onto the same ground the rest of the pipeline uses, so the lines are priced and guarded exactly like any other scope.
Structural reader
Another estimating system's XML
An estimating platform that is not Xactimate still knows its own scope. The structural reader finds the repeated line-item table by field shape, instead of demanding a schema it has never seen.
Documented input
ScopeJSON, if you build your own
A plain JSON shape with a one-to-one XML mirror, documented field by field at esxpress.org/xml-schema for teams that would rather send a clean payload than reverse-engineer a dialect.
What is exact, what is flagged, what is never invented
The three things that decide whether an estimate holds up are the code, the quantity and the price. Here is the rule for each one on this path.
A price in a carrier or system export is the price
When a carrier export, another system's XML, or a ScopeJSON payload carries a unit price, that price is used and the row records that it came from the payload. A Xactimate export is the one exception: it carries no price this path reads, so those lines are priced from the grounding catalogue and the row records that instead.
A missing price is named, not blurred
When the file carries no unit price, the line is priced from the grounding catalogue and the row records that source instead. You can see which lines came from where.
A code we cannot ground is flagged
Resolution runs in a fixed order, exact phrase first, then the curated phrase map, then a single unambiguous catalogue match. Where the answer stays ambiguous the line keeps its flag and waits for your pick. A wrong code is a wrong price, so we never take that trade.
A missing quantity is named or refused, never guessed
A Xactimate export, a recognised carrier export, or a ScopeJSON payload with a line missing its quantity is refused, and the missing field is named on that line. Any other structured file goes to the structural reader, which reads the missing quantity as one and names that line in the report.
The dashboard leg adds the 93-rule completeness audit, opened from the review page, which reports lines a scope is missing with the citation behind each one. The public API leg runs the import guard. Thousands of catalogue codes are the grounding set behind the resolution step.
Three steps
Send the file
Upload it in the dashboard next to the PDF control, or POST it to the API. Nothing is retyped and there is no OCR step on this path.
The shape is detected and the lines are grounded
The file is matched to a known shape, its line items are mapped onto your Xactimate vocabulary and priced, and every line records which source its code and its price came from.
Download the ESX, with the flags attached
You get the import-ready ESX plus the list of lines that need your eyes: ungrounded codes, any quantity the structural reader had to read as one, and anything the file left out.
Questions
What exactly counts as scope XML here?
Any structured scope file that carries line items: Xactimate's own export, a carrier or third-party administrator export, another estimating platform's export, or a ScopeJSON payload. A file with no line items in it, such as a sign-on letter or an energy rating file, is refused with the reason named instead of being turned into an empty estimate.
Is any reading involved?
No. On the XML path the values come out of the file as data. There is no page image, no optical character recognition and no column guessing, which is why a quantity or a code cannot be misread the way a printed page can.
What happens to a line whose code cannot be resolved?
It stays unresolved and is flagged for review. It is never given a guessed code. You can accept the suggestion or pick the right one on the review screen, and the price follows the code you choose.
Does the file's own unit price survive?
For a carrier or administrator export, another estimating system's XML, and a ScopeJSON payload, yes: the price is used as-is and recorded as coming from the payload. A Xactimate export carries no price this path reads, so those lines are priced from the grounding catalogue and the source is recorded on the row either way.
Does XML count as more than one conversion?
No. One scope is one conversion whether it arrives as PDF or as XML, and a scope above a thousand line items is never split or truncated.
Can our software send files automatically?
Yes. The public API accepts one structured payload per request with a key. It answers with a preview by default; add the build flag and the reply is a job you poll for the file, or add the sync flag to wait for it in the same response. Bulk runs today go through the dashboard's multi-file upload rather than the structured endpoint.
Do we have to switch tools?
No. The output is a normal Xactimate ESX file built for your own licensed copy of Xactimate. Nothing here replaces your estimating software.
What about a carrier whose format we have not seen?
Send a sample. The structural reader handles any file that carries a line-item table. A shape we have never seen becomes a named translator once we have proven it on a real file, and until then the refusal names the reason rather than producing a wrong estimate.
Send one file and look at the report
One scope is one conversion, whether it arrives as XML or as PDF. Where a company runs its own system, ask about the API and batch path.