Estimating and Project Support

Xactimate Estimate Writing for roofing contractors

A scope can be right about the roof and wrong in shape. The second kind of wrong is the one that comes back.

A scope in the shape the file expects

An estimate written in Xactimate, the format most property claim files are already kept in, using the conventions its reader works in daily. Not a translation of your internal document; the document itself, built that way from the start.

Line items that each answer to something physically on the roof. A reader should be able to take any line, ask what it refers to, and be shown a measurement or a photograph rather than an explanation.

And a revision history that survives. Every version kept rather than written over, so that the question of what changed between the first scope and the current one has an answer that does not depend on somebody remembering.

Correct and unreadable is a failure state

There is a particular frustration in this work that owners recognise immediately. The scope was right. The measurements were right. Everything that was found was found. And the document came back anyway, or sat untouched, or was reconciled into something else by somebody who did not ring to ask.

The reason is rarely disagreement. It is that a document arriving in an unfamiliar shape transfers work to its reader. They must find the equivalent of each line, decide what your terms correspond to, and satisfy themselves that nothing has been double-counted. That is real effort, and it is being asked of somebody with a queue and no obligation to prefer your file over the next one. The path of least resistance is to send it back or rebuild it themselves.

What makes this genuinely awkward is that the requirement is not written down anywhere. There is no rule you can look up and comply with. It is a convention — and conventions of process are enforced far more consistently than published rules, because nobody has to defend them. A contractor looking for the regulation that says which format to use will not find one, and will keep getting documents returned.

So the discipline is to remove the translation step entirely. Write the scope where it will be read, in the units and the structure that reader uses, and spend the effort on making each line traceable instead of on explaining the document.

What estimate writing produces, and what holds each piece up A horizontal spine carries three labelled artifacts produced by estimate writing: an estimate in the expected form, lines that answer to the roof, and a revision history. Beneath each artifact a vertical line drops to a second tier naming what holds it up — respectively built to the conventions the reader already works in, every line pointing at something that is actually there, and each version kept rather than written over. Across the foot of the diagram a separate band states the judgement this function does not make, which is what any individual line is worth. The diagram shows structure only and contains no figures. What this desk produces An estimate in theexpected form Lines that answer tothe roof A revision history built to the conventionsthe reader already worksin every line pointing atsomething that is actuallythere each version kept ratherthan written over Every item above sits on the one below it. Outside this desk What any individual line is worth
Each artifact on the spine has something underneath holding it up. That is the whole design: estimate writing is not an argument, it is a set of items that can each be traced to how they were arrived at, so that a reader spends their attention on the substance and not on the layout. The band across the bottom is the part that stays outside the work.

Where a written scope is required to be legible

The format convention has no statute behind it. The underlying principle — that a scope of work has to be written down in terms somebody other than its author can check — does appear in law, in a neighbouring context, and it is worth seeing because it shows the standard is about the reader rather than about the paperwork. Taking one state as a worked example, California Business and Professions Code section 7159 “identifies the projects for which a home improvement contract is required, outlines the contract requirements, and lists the items that shall be included in the contract”, and among those items is a heading “followed by a description of the project and a description of the significant materials to be used and equipment to be installed”.

Note what that does not say. It does not specify software, or a line structure, or a pricing database. It requires a description — of the project, and of the significant materials — sufficient for the other party to know what was agreed. That is the same test a well-written estimate meets, arrived at from a different direction.

The provision binds the licence holder in that state on the contracts it covers, and reaches neither this brand nor the claims estimating conventions this page is otherwise about. It is quoted for one reason: to show that “write the scope so a stranger can check it” is not a preference of this desk. Where it is a legal requirement, it is somebody else’s legal requirement, and yours is a question for your own adviser.

On the credential: it is held, and what that means is narrow. The scope is written in the format the file is kept in, by a party trained in that format. It is a statement about how the document gets produced and about nothing else — no outcome is implied, and the department page sets out the fuller explanation rather than this page repeating it.

This describes one state’s contract-content statute to illustrate a principle. It is not legal advice, it makes no determination about your contracts, your estimates or your obligations, and requirements differ by state. Those questions belong with your own counsel.

Roofing Back Office is not affiliated with, endorsed by, or certified by any software vendor named on this site. All product names and trademarks are the property of their respective owners.

The format question the department reserved

This desk sits inside Estimating and Project Support, which owns the boundary for the whole department — where preparation stops, where negotiation begins, and what the credential does and does not mean. All of that is set out there. This page covers only the form the scope is written in.

What owners ask about the estimate itself

Our scope was right and it still came back. Why?

Frequently because it was not written in the form the file is kept in. A reader working through a queue of documents in one format receives one in another, and the burden of translation lands on them. Being correct does not remove that burden; it just means the correct document is the one waiting to be reconciled by somebody with no reason to hurry.

Is a particular estimating format legally required?

No, and that is worth saying plainly because it surprises people. No statute we are aware of prescribes what software an estimate is written in. The requirement is a convention of a process rather than a rule of law — which in practice makes it stricter, not looser, because conventions are applied by people who are not obliged to justify them.

Do you hold the Xactimate certification?

Yes. What that means is narrow: the scope is written in the format the file is kept in, by somebody trained in it. It is a statement about how the document is produced, and it implies nothing about outcomes — no level, no volume, and certainly no figure about what any file recovers. We are not affiliated with, endorsed by or authorised by the vendor, and the department page linked below sets out the wider explanation rather than repeating it here.

Can you write the scope from our photographs and measurements?

That is the normal case. What is needed is a measurement or a diagram, photographs that establish condition, and any notes on what was found. Where something is unclear we ask rather than assume, because a line item that cannot be traced back to something on the roof is the first one a reader will pull out.

What happens when the scope has to change?

The previous version is kept. Revisions on this desk are additive rather than overwriting, so it stays possible to say what changed, when and why — which is a question that gets asked far more often than anyone expects, usually months later and usually by somebody who was not there.

Do you decide what any line is worth?

No. We describe what is there and write it in the expected form. What a line is worth is set by pricing data and by the parties to the file, and arguing about it is a different activity from documenting it. Where one stops and the other begins is the department boundary, set out on the page linked below.

The contract-content statute cited here

Take the last scope that was rebuilt for you

Compare what you sent with what came back. The differences are usually structural rather than substantive, and that is fixable.