The re-keying tax: when the same number gets typed four times

Nobody budgets for the handoff

Ask an owner where their process is slow and they'll name a step: estimating, invoicing, onboarding. Watch the work for a day and you'll usually find something different. The steps are fine. It's the seams that leak.

A number gets established once — a square footage, a unit price, a scope line — and then it gets re-entered. Into the proposal. Into the contract. Into the billing system. Into the spreadsheet somebody keeps because they don't trust the billing system. Each hop is a few minutes and one chance to introduce a typo, and none of it appears on any budget line, because it isn't a step anybody planned. It's the connective tissue between steps that were each designed on their own.

What it actually costs

The time is the least of it. Re-keying costs three things, roughly in ascending order of damage.

• Hours. Real, but usually modest — a few minutes per hop, several hops per job. Annoying rather than fatal.
• Errors. Transposed digits, a stale price from an older revision, a scope line that got edited in one document and not the other. These surface late, in front of a customer, when they're most expensive to fix.
• Trust. This is the real bill. Once two systems disagree, people stop believing either one. They keep private spreadsheets. They call to confirm figures that are already written down. The organisation quietly grows a second, informal record-keeping layer, and every decision now takes an extra phone call.

That third cost compounds, and it never shows up as a line item. It shows up as an operation that feels heavier than its headcount should require.

What we saw in a contractor's paperwork

On one build, the chain ran estimate → proposal → progress billing, and the same job figures were being re-entered at each boundary. The estimator produced the numbers, someone rebuilt them into a client-facing proposal, and someone else rebuilt them again into a formal AIA-format invoice — a document with unforgiving formatting rules, where a mismatch against the signed contract means a rejected pay application and a delayed payment.

The fix wasn't a faster typist or a better template. It was making the estimate the single origin of the figures and letting every downstream document derive from it, so a change made once propagates instead of being re-applied. The result was a chain from bid to billing with no re-keying at any boundary — and, notably, no change at all to how the estimator prefers to work.

Three signs you're paying it

• Somebody maintains a shadow spreadsheet. Not out of stubbornness — because it's the only place the numbers are reliably current. A shadow record is a symptom, not a discipline problem.
• A change late in a job means editing several documents. If a scope revision requires visiting three places, you don't have one process; you have three that happen to agree most of the time.
• People verify by conversation. When "let me just confirm that figure with you" is routine, the written record has already lost its authority.

Why "just integrate it" usually isn't the answer

The obvious move is to connect the tools you already have, and sometimes that works. Often it doesn't, for a plain reason: off-the-shelf systems each carry their own idea of what a job is, and those ideas don't line up. Forcing them to sync means bending your operation to fit whichever vendor's data model is least flexible — and you'll feel that compromise every day, long after the integration project is forgotten.

The alternative isn't ripping anything out. It's deciding where each number originates, then building the thin connective layer that carries it forward in the shape your business actually uses. That's usually a much smaller build than people expect, because you're not replacing the steps. You're just refusing to type the same thing twice.

And keep a person on the output. Derived documents should be reviewed before they go anywhere that matters — the point is to remove the retyping, not the judgement.

The compounding part

Fix one seam and the effect isn't local. The proposal goes out the same day because nobody's rebuilding it. The invoice matches the contract because it was derived from it, so it doesn't come back rejected. Cash arrives sooner. The shadow spreadsheet gets abandoned because the real record is finally trustworthy again.

That's the flywheel argument in miniature. You didn't make any single step faster. You stopped losing momentum between them — and the whole wheel spins easier for it.