Nobody budgets for the spreadsheet that grows next to the ERP. Yet walk any plant or back office running template software and you will find it: the parallel system where the work actually happens, because the official one does not match how the business runs.
That spreadsheet is not a discipline problem. It is a pricing signal. It appears at exactly the point where the template stopped describing the organisation, and someone still had to get the job done by Friday.
The workaround tax has four line items
Template software prices itself three ways: the licence you see, the implementation you expect, and the workaround culture nobody quotes. The third is the expensive one, and it is made of specific, countable things.
1. Re-keying headcount
Every place the template cannot represent a process becomes a place where a human moves data between two systems by hand. A despatch clerk copying from the ERP into an Excel sheet the transport desk maintains. A finance executive re-entering the same invoice into a reconciliation workbook. These roles are rarely labelled as data entry on any org chart, which is precisely why they never appear in the ERP business case.
2. The length of the month-end close
Close duration is the single most honest measure of whether a system of record is actually a system of record. When the close takes nine days, the extra seven are not accounting work. They are the time it takes to reconcile the official system against the shadow one, find where they disagree, and decide which to believe.
3. Decisions made on stale exports
Once the real numbers live in a workbook, reporting becomes an export cycle. The board sees Tuesday's position on Thursday. Nobody experiences this as a failure, because the number arrives and looks authoritative. The cost surfaces later, in a purchasing decision made against inventory that had already moved.
4. Key-person risk
The workbook has an author. The formulas encode pricing rules, credit policy and exception handling that exist nowhere else in writing. When that person leaves, the organisation discovers it outsourced part of its operating model to a spreadsheet nobody else can read.
How to measure the tax in a week
This does not need a consulting engagement. It needs four counts, taken honestly.
- Count the spreadsheets. Not all spreadsheets — the ones that are inputs to a decision or a payment, and that are maintained rather than generated. Each one is a place the template did not fit.
- Count the re-keying points. Every boundary where a human retypes data that already exists in a system. Multiply by frequency.
- Time the close. Then ask what the last three days were actually spent doing.
- Name the owners. For each critical workbook, who is the only person who can maintain it? That list is your concentration risk, written down for the first time.
Four numbers. They will tell you more about whether to replace the system than any vendor feature matrix, because they describe your organisation rather than the product.
What actually moves the five-year number
The comparison people expect is licence cost against build cost. That framing loses, because it compares the one number the vendor publishes against the one number the integrator quotes, and ignores everything that decides the outcome.
These are the drivers that actually move it:
| Driver | Why it moves the number |
|---|---|
| User growth curve | Per-seat licensing compounds with headcount. A custom build has near-zero marginal cost per additional user, so the two curves diverge rather than run parallel. |
| Customisation depth | Configuration is cheap. Customisation against a template is paid once to build and again at every upgrade — see below. |
| Integration count | Each system the ERP must talk to is a contract to maintain. This is usually underestimated by more than any other line. |
| Condition of the data | Duplicate masters, inconsistent units, missing history. Migration effort tracks data quality, not record count. |
| Process variance | How much the way you work differs from the template's assumption. This is the variable that decides the whole question. |
The upgrade cliff
Customisation on top of a packaged product has a property that configuration does not: it is re-paid. Every significant vendor upgrade puts the modifications back on the table, to be re-tested, re-fitted, or abandoned. Organisations discover this in year three, when the upgrade they need for a compliance change turns out to be blocked by the customisations that made the product usable in year one.
This is the mechanism behind the phrase you do not own it. It is not about source code escrow. It is about who controls the timing of your next change.
Where the crossover actually sits
The honest answer is that a single crossover year is a guess wearing a number. For organisations above a few hundred users with real process variance, the lines usually cross somewhere between years two and four — but the range is wide because the drivers above vary more between two companies in the same industry than they do between industries.
What determines your position in that range is process variance more than headcount. A thousand-user business whose operations look like the template will not cross over. A two-hundred-user business whose competitive advantage is an unusual production or credit process may cross in year two.
Which is why the useful question is not when does custom get cheaper. It is is the way we work a differentiator, or an accident of history. Those need different answers, and only one of them justifies a build.
When the template is the right answer
Criteria to apply to your own situation, not a position to hold:
- A mature product covers around ninety per cent of the requirement without customisation — configuration only.
- The process in question is not where you compete. Payroll is rarely a differentiator. Neither is general ledger.
- The organisation is still changing shape fast enough that any system built today describes a company that will not exist in eighteen months.
- There is no internal capacity to own a platform after go-live, and no appetite to buy that capacity.
Any one of those makes packaged software the better decision. Two of them make it obvious.
The sequence that de-risks the decision
The decision does not have to be made on conviction. It can be made on a document.
- Map the process as performed, not as described. The exceptions are the specification; the happy path is its cover page.
- Separate legal constraints from habits. A surprising share of what a template cannot do turns out to be something the organisation does not actually need to do.
- Price the workaround tax using the four counts above, so the comparison has a real number on the incumbent side.
- Fit-gap the template honestly, listing what would need customising rather than configuring.
- Then decide — and if the gap list is short, buy the product.
That sequence ends in a recommendation either way, and the work is not wasted if the answer is to buy: a fit-gap document is what makes a packaged implementation go well too.
The diagnostic, in one line
Count your spreadsheets. Then ask what each one is compensating for. If the answer is a handful of reports the vendor has not built yet, buy the product. If the answer is the way you price, produce, or decide credit, the template has been taxing your operations for years and the invoice simply never arrived in a form anyone could file.