A lot of people ask me about automation. Specifically, when do you automate something and when do you just fix it?
Honestly, I wasn’t sure I had a clean answer. But then I thought about how we actually make these decisions and I think there’s a framework buried in there. Let me walk through it using a real example.
The Invoice Problem
We have a vendor that sends us hundreds of invoices. For a long time, the AP team was entering them manually. Tedious, error-prone, inconsistent descriptions in the GL (i.e. the same product can be described as “muffler” or “chrome muffler” or “Muffler” or “MUFFLER” which made searching a minefield) and a waste of a good person’s time.
Most companies in this situation would do one of two things. They either keep entering them manually, or they buy some kind of OCR or AI system to read the PDF invoices and extract the data automatically. That second option sounds smart. It isn’t.
Here’s why. PDF extraction is not accurate. You have to train the system. It still makes mistakes. And it costs money and sometimes a lot of it. At the end of the day, no one is 100% certain it is right and the person reviewing it has to be extra careful.
We did something different. We went to the vendor directly and asked them to export a flat Excel file of our invoices instead of just emailing us PDFs. That’s it. That was the fix.
They have sophisticated systems just like we do. The data already exists in a clean, structured format on their end. We just asked them to share it. It took one conversation. It costs nothing. And it works perfectly every time.
From there, we built a simple Power Automate flow that takes that file and creates the purchase invoices directly in Business Central — matched against the PO automatically. The AP person still gets the PDF in their email, but their job is now to verify what’s already in the system, not to enter it. That’s a fundamentally different job.
Result: about 80% reduction in data entry time. Zero typos. Zero cost. A few hours of setup.
That’s low hanging fruit.
So How Do You Decide?
Working through that example, here’s what I think matters:
Go upstream, not around the problem.
The obvious solution was to build technology around the PDF. The better solution was to eliminate the PDF problem entirely by going to the source. Before you automate anything, ask yourself: where did this mess come from? Can you fix it there instead of building around it?
Most of the time, you can. And it’s almost always simpler and cheaper.
Only automate what is stable, repetitive, and rule-based.
Our invoice flow works because the input is consistent. Same vendor, same format, same fields every time. The rules don’t change.
Things that aren’t worth automating: one-off invoices; processes that change constantly; anything that requires judgment. If a human needs to think about it every time, a computer probably should not be doing it.
Fix the process before you automate it.
This one is important. You cannot automate a broken process. If you try, you just get a faster broken process.
If something isn’t working, put humans back in the loop. Figure out what’s wrong. Clean it up. Run it for a while. Then automate. In that order.
Keep humans in the loop deliberately.
We don’t auto-post the invoices. A person reviews them first. That’s intentional.
The goal isn’t to remove humans from the process, it’s to change what they’re doing. Instead of entering data, our AP person is now catching operational issues, flagging discrepancies, asking questions like “why did we buy so much of this?” That’s an AP Financial Analyst, not an AP clerk. Same person, better job.
Automation should elevate the role, not just reduce the hours.
You need to own it yourself.
Here’s the part most people don’t talk about. When the automation breaks, and at some point it will break, you need someone on the team who can fix it. Not a consultant. Not a ticket to IT. Someone who actually understands what the flow does and can get it running again the same day. Some of the people on our team join as accountants first, but end up being accountants with a tech side job. They become real wizards with the tools that are already accessible but never used. Just think how many people have access to Power Automate already, but never even try to open it.
I happen to build some of these automations myself, so that’s not an issue for me. But not every team has that. I think it should be a core skill for any CFO. If you can’t fix your own automation, you don’t really own it. Once your team gets a whiff of the automations, a few of the team members will really latch on to it. They will come up with ideas. They will bring forward new automations and some might even try it on their own and become champions of their own. Your job is to show them a path, and give them room to breathe. The one thing you need to do is to know what the processes and automations are, just in case something breaks; you will know where to look and how to fix it.
Not All Automation Has to Be Smart
At home, I run a mix of motion sensor switches and Z-wave switches controlled through Home Assistant. Friends walk in and inevitably ask: why not put Z-wave switches everywhere?
The answer is simple. I put motion sensor switches in the places where I want the light to come on when I walk in. That’s all I need them to do. Why add a Z-wave switch, set up automations in Home Assistant, configure scenes and schedules — when a $20 motion sensor switch does exactly the same job without any of that?
From the outside, the house seems equally automated either way. But some of that automation is just a dumb motion sensor doing one thing reliably. And there’s nothing wrong with that. In fact, that’s the whole point.
I bring the same logic to work. The invoice automation we built isn’t sophisticated. It’s a flat Excel file fed into Power Automate. No AI, no machine learning, no expensive software. Just a file that gets picked up and turned into purchase invoices. It looks like automation. It is automation. But it’s not complicated.
Don’t reach for the fancy switch when the motion sensor will do.
The Simple Test
Before I automate anything, I ask three questions:
- Is this high volume, consistent, and rule-based?
- Have I fixed the process first, or am I automating around a problem?
- Can someone on my team maintain this without me?
If the answer to all three is yes, it’s worth automating. If not, fix it first, or don’t automate it at all.
The best automations are the ones that are almost boring in how simple they are. Elegant, really. If it feels complicated to explain, it’s probably not ready.
This is part of an ongoing series on how I think about finance systems, automation, and building companies that run well. I’m a CFO and CA CPA who likes to tinker — and occasionally write about it.