Do not accept manual overrides.

The ERP went live three months ago. Every morning since, external support logs in and does the day by hand. Bank reconciliation. Supplier invoices. The things the system was bought to do.

Nobody is working on the structural fixes. And it gets harder every day, because each manual fix deletes the evidence. The transaction posts, the queue goes clean, and nobody can tell you which of yesterday’s forty exceptions were missing rules and which were one-offs.

Manual work does not just cost hours. It erases the diagnosis.

You only have a system if you use it throughout

A system you work around is not a system. It is an expensive archive with a parallel process next to it. The companies that get real results are ruthless about this: there is one way to do the work, it lives inside the systems, it is well defined, and nothing else is accepted.

That also means that when something new is needed, you pay the cost of putting it into the system, instead of handling it on the side “for now”. For now tends to last years.

What overrides look like

The ERP that is run by hand

When you go live on a new ERP, a large share of cases are exceptions, often half or more. That is normal. What matters is what you do with them. The right daily routine during hyper-care is simple:

1. What is pending? What did not clear from the bank? What is stuck in payables?
2. Diagnose each one: a missing rule, a bad mapping, or a process nobody defined before the migration.
3. Fix the rule. The same day.
4. Then handle the case by hand. Manual always comes last.

It feels slower. But run it daily with someone who writes the rule immediately and tries again, and the exceptions fall off a cliff. You move from half the cases to ninety, then ninety-five percent handled by the system, in weeks, not quarters.

The shadow spreadsheet

A logistics business in micromobility, with more than ten workshop sites and one central warehouse. The ERP was in place. Nobody trusted it, so each site ran its own spreadsheet on the side. The sheets and the system never agreed, and nobody could say what was actually on the shelves. People found out they had run out when they reached for a part that was not there, and central had nothing ready to send.

The fix was not a better system. It was two bins.

A black bin in front, a white bin behind it holding the minimum stock. When the black bin is empty, you slide the white one forward. That slide is the signal to order. If the white bin never moves in a month, the count is noted at month end, so central can read the shelf from a distance.

The point is not the bins. The point is that the capture happens as part of the physical work, so there is nothing to override and no second version of the truth. It works for anyone who holds stock and uses it themselves, like a workshop or a service operation. E-commerce warehouses are a different problem.

The ninety-percent automation

Many finance teams stop automating at around ninety percent. It seems good enough. It is not, because ninety percent still needs an owner. Someone checks it, worries about it, and carries it in their head. At a hundred percent, the task becomes a green check on a dashboard.

In most automation work the first week gets you to eighty or ninety percent. Weeks two and three remove the edge cases, usually with less effort. Most teams stop after week one. Stay for three, and the task stops existing as mental load.

The old path that still works

A new tool, three trainings, a room that loved the demo. Three weeks later nobody uses it. Not because people resist change, but because the old way still works. Nobody changes a habit while the old habit still pays. Turn off the old path, and make the new tool the only way the work moves.

The cost of doing it properly has collapsed

The usual reason for accepting overrides is cost. Changing the system for an edge case used to mean a consultant, a change request and a queue. So people handled it by hand, and the side processes grew.

That trade-off has changed. I now see teams build month-end close and reporting flows with AI in a fraction of the time it used to take. Document processing that once needed a project is automated with an AI model and a workflow tool. One planner at a logistics client built a tool over a summer that removes about a quarter of his repetitive work and flags the errors everyone knew the ERP produced. Small automations and internal tools that were never worth building are now clearly worth it.

What remains is mostly a mental barrier: the feeling that putting it into the system is a big deal. Usually it no longer is.

Build it properly, though. Code in company git, a short description of how it works, and at least one other person who can maintain it. Otherwise you have not removed a manual workaround. You have created a new key-person dependency.