The enterprise system is usually not the problem, and treating it as one leads to an expensive answer. It posts correctly, it closes the ledger, it holds the master data, and it does the standard part of the standard process about as well as anything on the market.
What it does not do is the part of your process that is specific to your company. The approval that has to go to a person who is not in the module's hierarchy. The exception that needs judgement before anything can be posted. The handoff between two legal entities that were separate companies eighteen months ago. The data that has to be assembled from three separate places before it is even eligible to be entered. None of that is a defect in the software. It lies outside the scope that the software was built for.
That work still has to happen, so it happens somewhere: a spreadsheet, a shared mailbox and a weekly meeting. Within a few months the spreadsheet has become the system of record for that slice of the process, and two years later it surfaces as an audit deficiency.
The Twenty Percent Has A Recognisable Shape
In finance and operations, work outside the enterprise system tends to take five forms.
- Pre-system assembly. Data is collected, matched and cleaned before it can be entered. The module accepts a clean record and has no view of where it came from.
- Approvals that do not fit the hierarchy. The real approver depends on the customer, the contract, the amount and who is available, and the module supports a tree of managers.
- Exceptions requiring judgement. A small percentage of items do not match, and each one of them needs a person to decide what happens to it. The module can flag them; it cannot hold them, assign them, or record how they were resolved.
- Cross-entity handoffs. A step starts in one entity's books and ends in another's. Two instances, two charts of accounts, and a person in the middle carrying the mapping.
- Post-system reconciliation. Something must be compared to something the module does not know about — a bank file, a partner statement, a clinical or operational system.
Name which of the five your painful process is, and you have scoped most of the work.
The enterprise system is the system of record for the ledger. Something else has become the system of record for the decision.
Why The Spreadsheet Wins Every Time
The spreadsheet does not win because anybody thinks it is good. It wins because it is available on Tuesday and the alternative is a project. Configuring or extending the enterprise system means an internal queue, an integration partner, a testing cycle and a change window. The argument that an enterprise system imposes its own logic on the company (Davenport, Harvard Business Review, 1998) explains why: these packages encode a generic model of how the work should run, and the parts of your business that do not match it are pushed to the edges. The edges are where a person with a deadline puts a spreadsheet.
The Cost Arrives Twice
The first arrival is operational and everyone feels it. The step takes three days instead of three hours because it waits for a person, and it waits for a person because there is nowhere else for it to wait. The second arrival comes later and costs more. The slice of process that lives in a spreadsheet cannot demonstrate who performed it, in what order, with which version of the input — which is the argument in why a spreadsheet stops being a control the moment someone asks for the trail. At that point it stops being an operational annoyance and becomes a disclosure question. Internal control weaknesses and information uncertainty (Beneish, Billings & Hodder, The Accounting Review, 2008) finds that disclosed weaknesses raise the market's uncertainty about the numbers themselves.
Build Around The System, Not Instead Of It
The instinct when the twenty percent hurts is to replace the eighty percent. That is the most expensive response; the replacement package has its own generic model and edges.
The alternative is a thin workflow layer that owns the steps around the enterprise system and writes back through supported interfaces. The division of responsibility is clean:
| Enterprise system | Workflow layer | |
|---|---|---|
| Owns | The ledger, master data, posting | The steps before and after posting |
| Holds | Transactions | Exceptions, approvals, mappings, evidence |
| Changes | On a release cycle | On a two-week cycle |
| Answers | What the balance is | Who decided, when, on what basis |
Three design rules keep this from becoming a second system nobody can retire. First, the enterprise system remains the system of record for anything financial; the workflow layer never holds a balance. Second, every integration goes through a supported interface, never a direct database write, so an upgrade does not silently break the process. Third, the evidence the workflow layer produces — who acted, when, on what version — is stored independently of both systems, so it survives a future migration of either system.
Where language models are useful in this layer, they belong on the reading and drafting surfaces rather than inside the execution path: extracting the fields from a supplier document, proposing a match, drafting an explanation for a variance. The decision itself stays deterministic and recorded, which is the pattern described in keeping AI on the surfaces and the execution deterministic. A suggestion that a named person accepts is auditable. A model that posts an entry directly to the ledger is not auditable.
One Workflow, Beside The System You Already Run
The useful scope here is almost always one workflow rather than a whole program. One process, from the point where the enterprise system stops to the point where it takes over again, with the exceptions held as items, the approvals recorded against real identities, and the final result written back through a supported vendor interface.
A fifteen-minute call, nothing paid, nothing signed, takes one process apart: where the enterprise system's boundary sits, what has to be built, what it costs, and whether to build it.
Where building is the answer, that work runs as a monthly engineering partnership, with the targets for each release written down before it starts and paid-for deliverables transferring to you monthly. Afterwards, $10,000 a month puts one accountable person on keeping it running as the systems on both sides of it change. The enterprise system keeps doing what it does well. The twenty percent around it stops being a spreadsheet.
References
- Davenport, T. H. Putting the Enterprise into the Enterprise System. Harvard Business Review, 1998.
- Beneish, M. D., Billings, M. B., & Hodder, L. D. Internal Control Weaknesses and Information Uncertainty. The Accounting Review, 2008.
