Roofing data taxonomy and metric ownership model for contractors

Most roofing companies don't have a data problem. They have a definition problem.

Ask three people in the same shop what "job margin" means and you'll get three different answers. The estimator thinks it's the number on the proposal. The production manager thinks it's whatever's left after the crews go home. The bookkeeper thinks it's whatever QuickBooks spits out at month-end after supplements, chargebacks, and that one warranty callback nobody logged. All three numbers are real. All three are different. And when the owner sits down to figure out which crews are actually profitable, none of them agree.

That gap — same word, different math, no owner — is what a data taxonomy fixes. Not fancier dashboards. Not another integration. Just a shared, written agreement about what each number means, who owns it, where it comes from, and what happens when two systems disagree.

This is the boring plumbing that makes everything else work. Get it right and your KPIs stop lying to you. Get it wrong and you'll spend every leadership meeting arguing about whose spreadsheet is correct instead of making actual decisions.

Why roofing data breaks in such a specific way

Roofing has a structural quirk most trades don't deal with: the same job passes through three departments that each measure it differently, on different timelines, using different systems as their source of truth.

Estimating measures a job before it exists — squares, pitch, penetrations, a labor allowance, a material takeoff. Production measures it as it happens — actual labor hours, actual bundles, tear-off surprises, weather days. Finance measures it after it's done — invoiced revenue, collected cash, supplement recovery, warranty reserve.

Each department names things in its own dialect. Estimating says "squares." Production logs "bundles installed." Finance sees "material cost of goods." Those are three views of one physical roof, but nothing in the workflow forces them to reconcile. So they drift.

A typical example: an estimator books a 32-square reroof. Production installs it, hits a rotted deck section, adds material, doesn't update the original estimate — they just do the work. Finance invoices the base contract plus a change order, but the change order gets written against a different job number because someone reopened the file. Now you've got a job that's 32 squares in one system, 34.5 in another, and split across two records in the third. Every margin calculation downstream is wrong and nobody knows it.

At one crew, a good office manager papers over this because she "just knows." At three crews, she becomes the single point of failure. At six crews, the drift compounds faster than any human can track, and you're making pricing and hiring decisions on numbers that are quietly broken.

The core idea: every metric needs four things

A defendable metric isn't just a number. It's a small contract. For each metric you actually care about, you need four things nailed down:

1. 1
   A formula — the exact math, including what's in and what's out.
2. 2
   A source of truth — the one system where the raw inputs live.
3. 3
   An owner (RACI) — who's accountable for the number being right.
4. 4
   A dispute rule — what happens when two systems produce different values.

If a metric is missing any of those, it's not a metric — it's a suggestion. And suggestions cause meetings.

This connects directly to the rules-based thinking covered here. Once your definitions are locked, you can build a rules-based metrics framework that turns roofing data into clear field decisions on top of them. But the rules only work if the underlying definitions are solid. You can't automate a decision on a number that three people define differently.

A compact metric set (resist the urge to track everything)

The mistake most shops make when they get serious about data is tracking forty metrics. Nobody owns forty metrics. Within a month the dashboard is stale and everyone's back to gut feel.

Start with a small set — twelve to fifteen numbers total — that map cleanly across the three departments. Here's a core set worth defining:

A couple things worth noticing. Every metric has exactly one accountable owner — not a committee. And the cross-stage metrics (estimate accuracy, job margin) are where the money hides, because they force two departments' numbers to actually touch.

That last row — estimate accuracy — is probably the single most valuable number most roofers never track. If your estimates consistently run 15% under on labor, you're not losing money because of bad crews. You're losing it because of bad estimating, and no amount of pressure on the field will fix it.

The RACI part: kill the "everyone owns it" problem

RACI is just four letters: who's Responsible (does the work), Accountable (owns the outcome — only one person), Consulted (has input), and Informed (needs to know the result).

The failure mode is predictable. When a number is wrong and you ask "who owns this?", you get shrugs. That's not a people problem — it's a design problem. Nobody was ever assigned.

1. 1
   Responsible

   Bookkeeper (assembles the actuals)

2. 2
   Accountable

   Controller or owner (signs off that the number is defensible)

3. 3
   Consulted

   Production manager (validates labor and material actuals), Estimator (explains variance from the bid)

4. 4
   Informed

   Sales manager, crew leads

The key rule: the accountable person is not the one doing the data entry. If your bookkeeper both enters the numbers and owns whether they're right, there's no check in the system. Separate the doing from the owning. This same discipline is what makes defendable job-level costing that produces a P&L per roofing job actually hold up — the costing only means something when someone accountable has signed off that the inputs are clean.

“

Make the accountable person someone other than the person doing the data entry.

This same discipline is what makes defendable job-level costing that produces a P&L per roofing job actually hold up — the costing only means something when someone accountable has signed off that the inputs are clean.

Data contracts: the handshake between systems

A data contract is a written agreement about what data one stage owes another, in what format, by when. It sounds bureaucratic. It's actually what stops your estimating-to-production handoff from being a game of telephone.

Think of it like a delivery ticket. When production accepts a job from estimating, they're accepting a specific set of fields — and they should be able to reject an incomplete handoff the same way a crew rejects a short material delivery.

1. 1
   Required fields

   job number, address, squares, pitch, layers to tear off, penetration count, material spec, estimated labor hours, access notes.

2. 2
   Format rules

   job number matches the master format; squares to one decimal; pitch as ratio not description.

3. 3
   Timing

   delivered at least 48 hours before scheduled start.

4. 4
   Rejection criteria

   production can bounce the handoff if any required field is blank or the measurement QA wasn't completed.

5. 5
   Change rule

   if estimating revises the job after handoff, it triggers a new version — the old numbers don't silently overwrite.

Below is a simple visualization of the estimating → production → finance handoff and versioning workflow.

That last point matters more than it looks. Silent overwrites are how you end up with a job that was 32 squares yesterday and 34 today with no record of who changed it or why.

The same discipline applies to the finance handoff. Production owes finance a clean set of actuals — final labor hours, final material counts, all change orders tied to the original job number, not a reopened duplicate. When that contract is loose, invoices get delayed and disputes multiply.

If you're wiring systems together to enforce any of this, the governance side matters as much as the plumbing — the guardrails for that are covered in operational tech governance for roofing integrations and data contracts.

A data-contract checklist you can actually use

Before you consider any stage-to-stage handoff "under contract," run it through this:

1. 1
   [ ] Every required field is named and defined (no ambiguity on what "squares" includes).
2. 2
   [ ] There's exactly one source of truth per field.
3. 3
   [ ] Format rules are written down (units, decimals, ID formats).
4. 4
   [ ] A delivery deadline is set, tied to a real trigger (schedule start, invoice run).
5. 5
   [ ] Rejection criteria exist and someone is empowered to reject.
6. 6
   [ ] Versioning rule handles revisions without silent overwrites.
7. 7
   [ ] An owner is named on both sides — sender and receiver.
8. 8
   [ ] There's a defined path when the two sides disagree (see below).

If you can't check all eight, the handoff isn't a contract yet. It's a hope.

The dispute-resolution cadence

Numbers will disagree. Two systems, three departments, human data entry — drift is guaranteed. The question isn't whether disputes happen. It's whether you have a rhythm for resolving them before they poison a decision.

1. 1
   Weekly (15 min)

   production and office reconcile any jobs where actual labor hours or material counts don't match the estimate by more than a set threshold — say 10%. Small, fast, catches drift early.

2. 2
   Monthly (45 min)

   finance, production, and estimating review estimate-accuracy and job-margin variances. This is where you find the pattern — is one crew consistently over? Is a specific roof type always underbid?

3. 3
   Quarterly

   revisit the metric definitions and data contracts themselves. Did the business change? New material line, new crew structure, new supplier? Update the taxonomy so it doesn't rot.

The threshold rule is the underrated part. You don't reconcile every job — that's exhausting and people stop doing it. You only surface jobs that breach a tolerance. Everything inside tolerance is assumed clean. That keeps the cadence light enough that people actually run it.

A real scenario: what this looks like when it clicks

A mid-sized residential reroofer running four crews couldn't figure out why good months on paper kept producing thin bank balances. Sold margins looked healthy — around 34% on proposals. Actual collected margins, when the owner finally reconstructed a few jobs by hand, were closer to 22%.

The gap wasn't theft or bad crews. It was definitional drift. Change orders were being logged against reopened duplicate job numbers, so material cost on the original job looked artificially low while the duplicate never got a proper margin calc. Supplements were tracked in a separate spreadsheet that never tied back to the job. And "sold price" in the CRM sometimes included COs, sometimes didn't — nobody had ever defined it.

They didn't buy new software first. They spent a couple weeks writing down twelve metric definitions, assigned one accountable owner to each, and set a weekly 15-minute reconciliation on jobs over the 10% variance threshold. Within roughly two months, reported and actual margins converged to within about two points of each other.

The real win wasn't the tighter number. It was that the owner could finally trust the dashboard enough to make a hiring decision on it — something he hadn't been able to do before because he always suspected the data was lying.

When this level of rigor makes sense (and when it doesn't)

When it's worth it: You're past one or two crews, you're arguing about numbers in meetings, or you can't confidently say which crews and job types actually make money. Once decisions ride on the data, the data has to be defendable.

When it's overkill: A solo operator or single-crew shop where the owner touches every job personally probably doesn't need formal data contracts and a RACI matrix. A clean job-numbering habit and one honest margin spreadsheet is enough at that size.

Who should NOT start here: If your field data is still chaos — photos scattered, timesheets unreliable, change orders written on napkins — fix the capture first. A taxonomy built on garbage inputs just gives you well-organized garbage. Get clean, consistent field data flowing before you invest in the reconciliation layer on top of it.

The bottom line

A roofing data taxonomy isn't about dashboards or reporting for their own sake. It's about making sure that when three departments look at the same job, they're actually looking at the same job. The estimator's squares, the crew's hours, and the bookkeeper's margin all have to trace back to one physical roof — with one definition, one owner, and one rule for what happens when they disagree.

The shops that get this right stop arguing about whose number is correct and start using the numbers to make real calls: which crews to grow, which job types to walk away from, which estimators need coaching. Clean definitions don't just tidy up your reporting — they turn your data into something you can actually bet the business on.