Why Contractors Keep a Spreadsheet Next to the Software

Walk into any general contractor's office that has bought construction software in the last five years and you will find a spreadsheet open next to it. Usually more than one. There is a bid worksheet the chief estimator maintains, a schedule-of-values tracker the PM uses to sanity-check the billing the system produced, and a cost-code crosswalk somebody built because the platform's cost codes do not match the accounting package's cost codes.

The usual reading is that contractors are behind the times. That is wrong, and if you are building in this space it is an expensive thing to believe. We built vision-model takeoff, estimating and AIA progress billing into BuildAEC, and every time we found a spreadsheet living beside our own product, the spreadsheet was doing something real that we had not modeled. Not something the user was too lazy to learn. Something the software structurally could not express.

There are four of those things, and they show up in roughly the same shape at every contractor we have shipped to. If your product handles all four, the shadow spreadsheet goes away on its own. If it handles three, it does not.

Job one: holding a number you are not ready to commit to

An estimate is not data. It is an argument, built over two weeks, with holes in it that the estimator knows about and is deliberately leaving open. Concrete is priced from a real quote. Sitework is a guess pending a walk. The electrical number is last job's unit cost plus twelve percent because that sub has been busy. Two line items are placeholders that exist only so the total looks sane during a Thursday review.

Software insists on committed values. A required field is a commitment. A validation rule is a commitment. A recalculating total that propagates to a proposal is a commitment. The estimator does not want to commit yet, so they work in a medium that lets a cell hold a wrong number quietly with a yellow fill and a note in column M.

The mechanism here is confidence and provenance as first-class fields on every line, not a comment thread bolted to the side. We already do this for vision-model takeoff output — each quantity line carries a confidence score that directs human review — and the same structure works for human-entered numbers. A line item should record where the number came from and how solid it is:

type EstimateLine = {
  id: string;
  costCode: string;
  quantity: number;
  unitCost: number;
  basis:
    | { kind: 'quote'; vendorId: string; quoteId: string }
    | { kind: 'historical'; sourceJobId: string; adjustmentPct: number }
    | { kind: 'takeoff'; confidence: number; pageRef: string }
    | { kind: 'placeholder'; note: string };
  locked: boolean; // frozen against recalculation
};

Once basis exists, the roll-up can report that 61 percent of the bid value is quote-backed and $340,000 of it is placeholder. That is the exact number the estimator was tracking by hand. Now it is in the system, and the review meeting runs off the software instead of the printout.

Job two: the arithmetic nobody standardized

Every contractor marks up differently, and the difference is not a preference — it is how they win work. Some carry general conditions as a percentage of direct cost. Some build GCs as a line-item schedule driven by duration. Some apply fee before contingency, some after. Some exclude sales tax on materials in one state and include it in another. Some price labor with a burden multiplier that differs by trade and by whether the job is prevailing wage.

Generic products ship one markup model and a settings page with four toggles. The contractor's actual model has fourteen decisions in it, and the moment one of them is unrepresentable, the whole calculation moves to Excel. Not the unrepresentable part. The whole thing. Nobody splits a formula chain across two systems.

This is the same failure mode we wrote about in retail software versus generic ERP: the domain has arithmetic the generic product treats as configuration, and configuration is not expressive enough. In construction the answer is a small, auditable rule layer — ordered, named calculation stages the contractor can reorder and define, with each stage's output visible as its own row on the estimate summary. Not a formula editor. An ordered pipeline of stages, each one a named function with a documented input.

The test is simple. Hand an estimator your product and their last completed bid. If they cannot reproduce the bottom line to the dollar, they will keep the spreadsheet forever, and they are right to.

Job three: the owner's format, not yours

Progress billing is where this gets expensive. A contractor bills against a schedule of values, and the SOV is not theirs. It is the owner's, or the architect's, or the lender's, and it arrives as a PDF or a spreadsheet with line descriptions that do not match any cost code the contractor uses internally.

So there are two structures that must both be true at once: the internal cost breakdown the PM manages the job against, and the external SOV the owner will approve a payment against. They have different line counts, different groupings and different granularity. The mapping between them changes when a change order lands.

Most software picks one and forces the other into it. The spreadsheet is the crosswalk. If you only take one design decision from all of this, take this one: model the internal cost structure and the external billing structure as separate objects with an explicit, versioned mapping between them.

• Cost structure — cost codes, budget, committed cost, actual cost, forecast. Owned by the PM and the accounting integration.
• Billing structure — SOV lines, scheduled value, previously billed, this period, stored materials, retainage. Owned by the contract.
• Mapping — many-to-many, weighted, versioned, with an effective date so a change order in month seven does not rewrite month three's approved billing.
• Reconciliation — a report that proves total scheduled value equals total budget plus approved change orders, or names the variance.

That last item is the one teams skip and then regret. We learned the value of gating on reconciliation the hard way during a platform migration, where we moved over a hundred tenant databases and required a per-tenant reconciliation report before any cutover was allowed to proceed. The principle transfers directly: if two representations of the same money must agree, the system produces the proof, not a human with a calculator.

Job four: working where there is no signal, and no keyboard

Field data capture fails for physical reasons more often than software reasons. The basement has no signal. The superintendent is wearing gloves. The daily report has to be filed at 4:45pm from a truck. When entry is hard, people write on paper and someone types it in later — and the later typing job is where the parallel spreadsheet gets born, because whoever is typing wants a scratch pad.

Offline-first is not a feature you add in v3. It is a data model decision made on day one: client-generated IDs, an append-only local log of intents rather than mutated rows, deterministic conflict resolution per entity type, and a visible sync state the user can trust. We built offline-capable point of sale for Retailer OS that reconciles when the connection returns, and the hard part was never the network layer. It was deciding, per entity, what a conflict means. Two people editing the same daily log entry is a merge. Two people signing the same inspection is an error that needs a human.

For hardware a browser cannot reach — laser distance meters, rugged scanners, background location for time-on-site — we ship native shells via Capacitor rather than pretending the web platform is enough. That is a build-cost decision worth making explicitly rather than discovering after the field team stops using the app.

A short diagnostic

When we find a spreadsheet next to a system, we ask five questions in order and stop at the first yes.

1. Does it hold numbers the user is not ready to commit to? → You need confidence and provenance on the line item, plus a locking model.
2. Does it perform arithmetic your product cannot express? → You need a named, ordered, auditable calculation pipeline, not more settings.
3. Does it translate between two structures that must both be true? → You need both structures modeled, with a versioned mapping and a reconciliation report.
4. Does it exist because entry in the field is too slow or impossible? → You need offline-first data modeling and probably a native shell.
5. Is it just a report your product does not have? → Cheapest fix on this list. Ship the report.

Question five is genuinely common and genuinely easy, which is why it is worth checking last rather than first: if you lead with it you will ship reports for a year and never fix the structural problems above it.

When the spreadsheet should stay

Not every shadow spreadsheet is a defect. Some are the right tool, and building over them is waste.

A one-off analysis — should we self-perform this scope, what does this bid look like at three different fee structures — belongs in a spreadsheet. It runs once. Encoding it as a feature means maintaining a screen forever to serve a question asked twice. The signal that something deserves to be in the product is repetition plus consequence: it happens on every job, and getting it wrong costs money or delays a payment.

Small contractors are the other exception. A three-person outfit doing $2M a year with one estimator has no coordination problem to solve. The spreadsheet is fast, the estimator holds the whole model in their head, and a platform adds process cost against no benefit. The structural fixes above start paying when multiple people touch the same number and disagree about it. Below that threshold, honest advice is often to leave it alone — which is part of how we talk about scope when we scope engagements.

A shadow spreadsheet is not a training problem. It is a specification you did not write down.

The practical move, if you are building in construction or any domain with this shape, is to go collect the spreadsheets before you design the schema. Not interviews about workflow — the actual files, with the actual formulas and the actual yellow-highlighted cells. Every one of them is a requirement someone already validated in production, for free, against real jobs. We do this at the start of every build in regulated and operationally messy sectors, and it has never once failed to change the data model.

If you are staring at a stack of those files right now and trying to work out what belongs in the product, that is a conversation we are happy to have.