Skip to content

How to get Excel out of your business

Every firm that bought an ERP still runs on spreadsheets — not because users are undisciplined, but because Excel fills the exact gaps the system left open.

Operations
Published
Author
Konis Software
10 min read

Almost every company that has bought an ERP still runs part of its work on spreadsheets. That is not an admission of defeat or a sign the wrong system was chosen — it is a diagnosis. Wherever a hand-maintained spreadsheet appears, the system left a question unanswered at that exact spot. Excel is a map of those spots, and a more honest one than any satisfaction survey.

The usual reflex is to blame the user: they don't know the system well enough, they can't be bothered to enter data properly, they prefer their own way. That reflex misses. People reach for a spreadsheet precisely where the system fails to answer a real question — and when the choice is between an answer today and an answer never, the spreadsheet is the rational one. It is a symptom, not a vice.

This piece is not a call to banish Excel. Excel is a legitimate tool for what it was built for: ad-hoc analysis, a quick hypothesis, a calculation nobody will repeat. The target is narrower — the spreadsheet that has taken over the operational core, that carries a number someone files or a decision someone stands behind. The goal is not to forbid Excel, but to remove the need for it to do the system's job.

Why Excel survives

Excel does not win because it is better than the ERP. It wins because it fills three specific gaps, and each of them is a failure of the system, not of the user. As long as those gaps exist, no amount of training and no discipline policy will retire the spreadsheet — because the spreadsheet does what the system cannot.

The gap between modules

Sales knows one thing, the warehouse another, finance a third. The number that ties the three views together lives nowhere as a single value, so someone exports three reports and joins them by hand. VLOOKUP is the seam where two modules that never talk meet inside one workbook. The more an ERP is assembled from separate databases synced overnight, the longer that seam runs and the more indispensable the spreadsheet becomes.

The report that does not exist

The system holds the data but not the view. Standard reports answer yesterday's questions; the moment someone asks a slightly different one — by a dimension the menu doesn't offer, by a period cut nobody anticipated, with internal transfers excluded — there is no button, and there is Excel. Margin per salesperson per product group for the quarter, net of inter-warehouse moves, is a question a company has every month and a fixed report has never.

The quick rule nobody built in

'Discounts above 10% need the director's approval', 'supplier X is always paid at 45 days', 'these three cost centers count as one for reporting'. Small business rules that never made it into the system, so they live in someone's head and in a single cell's formula. When that person goes on leave — or leaves the company — the rule goes with them, and the spreadsheet is the only place it was ever written down. That is why you will find some subset of these workbooks in almost any company, each covering one of the three gaps:

  • Reconciling the bank statement against open items, because the system doesn't close everything on its own.
  • A manual VAT recap before the PP PDV return, when the POPDV ledger doesn't give the exact cut the accountant checks.
  • A price list with margins and discount tiers the core doesn't compute.
  • A 60-day inflow and outflow projection.
  • Sales commission worked out under rules that aren't in the system.
  • Inventory aging and slow-moving stock analysis.
  • Plan versus actual by organizational unit, stitched together from two reports.

Why this is the system's fault, not the user's

The standard response to spreadsheet sprawl is more training and more discipline. Both miss the target. A person reaches for Excel because it gives them in five minutes what the system doesn't give at all — and blaming the user for that is like blaming the thermometer for the fever. The problem is not the hand that opens the sheet; it is the void that hand reaches into.

The real cost is not the time spent in Excel. It is that the spreadsheet becomes a shadow system: a number that no longer agrees with the ledger because it was copied three days ago, a rule nobody can audit because it hides in a formula, a file with no owner and no version, a column that moves and silently breaks the whole calculation. The moment something is filed with the state or a decision is taken from that sheet, the company has acted on a basis that passes no audit.

A spreadsheet in a company is not user laziness — it is a message sent to the system: an answer is missing here. A company that counts its Excel files holds a more precise list of its ERP's shortcomings than any consultant could produce.
NG One — internal principles on scope and reporting

What actually removes the need

You do not remove Excel by banning it — a banned spreadsheet simply moves to a private laptop and becomes even less visible. You remove it by closing all three gaps at their source: the number that joined the modules becomes a field, the question with no button gets a query, and the rule that lived in someone's head becomes an object in the system.

A single core instead of joined modules

If sales, the warehouse and finance write into one model rather than three databases reconciled overnight, the number that connects them exists as a field, not a VLOOKUP. The seam disappears because it was never there: the stock level the salesperson sees and the stock value the accountant sees are two views of one record, not two reports someone joins in a third sheet. Most 'integration' spreadsheets are a consequence of architecture, not of missing goodwill.

A reporting center, not one more fixed report

The answer to 'the report doesn't exist' is not 'we'll build you another fixed report' — that just pushes the next question one step further away. The answer is a place where the user slices the same governed data themselves: by dimension, by period, with a filter and an exclusion, without an export. What matters is that the data stays live and reconciled to the ledger — a reporting center that reads from the same core cannot drift from the general ledger, because it reads the ledger rather than a copy from three days ago.

Rules that live in the system and remember their version

A quick rule belongs in the system as a first-class, versioned object: who set it, when, from which date it applies, what it replaced. Then the rule outlives the person who invented it, applies consistently to every case, and can be checked after the fact. When a discount threshold changes mid-year, a system that remembers which rule was in force then produces the correct figure for both the old and the new period — a spreadsheet with one formula does not remember it was different yesterday.

  1. 1

    Inventory the spreadsheets

    You cannot remove what you haven't seen. The first step is a list of every workbook someone maintains — with its owner, its purpose and the data it carries. Most companies are surprised by the length of the list.

  2. 2

    Classify each one

    Every sheet falls into one of four groups: a gap between modules, a report that doesn't exist, a rule that was never coded, or legitimate ad-hoc analysis. The first three belong in the system; the fourth stays in Excel, and that is fine.

  3. 3

    Return the rules to the system

    Rewrite the rules buried in formulas as versioned objects with an effective date. This is the most valuable step: a rule in the system is applied and audited, a rule in a cell works only while its author is at their desk.

  4. 4

    Build a query, not an export

    For every 'report that doesn't exist', build the cut in the reporting center over live data. The aim is that next month does not start with a fresh export into a fresh sheet.

  5. 5

    Leave ad-hoc work to Excel

    Don't force a one-off analysis into the system. If nobody depends on the sheet's result tomorrow, it is a tool, not a debt — and coding it in would solve a problem that doesn't exist.

When Excel is still legitimate

Not every spreadsheet is a symptom. Ad-hoc analysis — a hypothesis for one meeting, a quick what-if before a decision, a scenario nobody will repeat — is exactly what Excel is good at, and pushing it into the ERP would be over-engineering. The line is simple and worth saying out loud: does anyone downstream depend on the number in that sheet. If someone will take a decision or file a return from that cell tomorrow, the spreadsheet belongs in the system. If the calculation is a one-off whose result nobody remembers, Excel is the right tool and stays.

DimensionLegitimate Excel — staysSymptom — moves in
Fate of the resultNobody uses it tomorrowIt is filed, posted or decided upon
FrequencyA one-off analysis or scenarioThe same calculation every month
DependencyA personal file nobody else relies onSomeone's decision hangs on the cell
The rule insideTesting a single what-ifA business rule that applies to all
Need for a trailNone — a test is a testWho, when and under which rule

How NG One approaches it

NG One is built around a single core precisely so the three gaps never open. Sales, the warehouse and finance write into the same model, so the number that connects them exists as a field — there is no overnight sync for a VLOOKUP to bridge. The reporting center, in the Insights, automation and AI space, slices that same live data by dimension and period, with no export and no copy that drifts from the ledger. Business rules — discount thresholds, payment terms, reporting maps of cost centers — sit as versioned objects with an effective date, in the Finance and compliance space, so they survive whoever set them. Excel stays welcome where it belongs: as a tool for ad-hoc analysis, not as a company's hidden core.

The same question, against your own numbers

We run the walkthrough on your documents and your approval chain, not on demo data. Your line, your dimensions, your posting — on the screen, not in a deck.