Switch back to main site : Click Here
Everywhere you turn people are talking about automation and AI.
One minute you see someone saying they’re automating bank reconciliations with AI (they’re just outsourcing the work) and the next you’re seeing a 43 point list of things to automate with AI (the list is generated by AI), but whenever you try to use AI it’s hallucinating more than the pit at a Phish show.
There is a delicate balance between getting people excited about automation and AI, and lying about what you can actually do to generate hype. Accountants have some of the best bullsh*t radars out there — and automation influencers need to respect that.
The truth is, there is no silver bullet with automation, but there are meaningful opportunities out there for you to tackle.
This is the first blog in a three part series designed to teach you to weed through the noise by evaluating opportunities based on three criteria:
Suitability is simply "should I even think about this more?"
There are five key elements when considering the suitability of an automation candidate.
Your use case should fit all five criteria before you move on to measuring value and complexity.
Data should be well-organized, consistent, and in a format that's easily readable by automated systems.
This can mean different things depending on the format of the data. For a PDF, you'd want to consider the location of key information, standardization of the wording used to label key areas, and how you might "describe" to a robot where to look.
Generally speaking, PDFs are always going to be a worse input for automation compared to spreadsheets, but a scanned piece of paper is going to be even worse than a pure PDF.
Spreadsheets are an idea format to work with, but even with spreadsheets you'll want to consider column headers, cell contents (e.g. do you need to split separate data points from the same cell?), and how you can easily match data between systems. You can always add mappings and other logic to the automation you create, but automating data that is structured identically in the source and destination will be the most robust.
Example: Consider the accounts payable process. If your invoices are received in a standardized electronic format (like EDI or XML) with consistent fields for invoice number, amount, date, and vendor details, they are highly suitable for automation. On the other hand, if you're dealing with handwritten invoices or PDFs with varying layouts, automation becomes more challenging and may require additional steps like Optical Character Recognition (OCR) technology.
Processes that follow clear, consistent rules are prime candidates for automation. The more straightforward and unambiguous the rules, the easier it is to translate them into automated workflows.
Very simply, can you define the "if this, then that" logic that goes into your decision making process? Even if there are multiple branches off of the same decision tree, that will fit this criteria. You just want to avoid processes where judgement is regularly applied, or the rules are regularly changed.
Example: Consider the process of applying customer payments to outstanding invoices, a.k.a cash application or "cash app." This process typically follows a set of clear rules:
How often does something go through the process and need special treatment or deviate from the rules-based logic defined?
The frequency of exceptions in a process can significantly impact its suitability for automation. Processes with a low exception rate are generally more suitable, as they require less human intervention.
This is an area where many accountants get stuck. They'll get hung up on the fact that there is one exception to the process and use that as the reason why a process must stay manual. If your data is perfectly structured, and rules-based logic setup can handle the majority of the transactions, you may be comfortable dealing with the exceptions in a manual way.
Exception rate is worth revisiting as you think about the value and complexity of the automation use case, which will be covered in separate blogs.
Example: Let's consider the process of processing employee expense reports. In a company with clear expense policies, most reports might follow standard rules (e.g., meal expenses under $50, standard mileage rates for travel). If 95% of expense reports fall within these standard rules, this process would have a low exception rate and be suitable for automation. The 5% that fall outside these rules could be flagged for manual review.
Processes that remain relatively stable over time are more suitable for automation. Frequent changes in the process can necessitate constant updates to the automation system, reducing its efficiency and cost-effectiveness. This doesn't just mean changing the steps in the process, but can also mean changing the data structure or rules-based logic of the process. If stakeholders are constantly changing their minds about the way things are done, you need to secure commitment that they will stay as is.
Example: The monthly financial close process is typically stable. The steps involved – reconciling accounts, recording accruals, preparing financial statements – generally remain consistent month after month. This stability makes it a good candidate for automation. Conversely, a process like tax compliance might be less suitable if tax laws change frequently, requiring constant updates to the automation logic.
The stability of the underlying technology used in the process is another crucial factor. Processes that rely on stable, well-established technologies are more suitable for automation. While changing apps is a clear sign of technological instability, you should also consider changes to the existing apps, especially when using RPA.
Imagine using a bot to navigate a website for you. What happens when (name redacted) changes their layout, despite no one asking for it, and makes it much worse and clunkier. How will your robot now know where to look? Are the buttons moved? Is the click order the same?
You will want to use technology that doesn't change, or at least try to access the data from that piece of technology in ways that are less prone to changes (e.g. use an extract, transform, load ("ETF") approach via the API rather than using RPA to navigate a user interface).
Example: Consider the process of generating and sending customer invoices. If your company is billing through QuickBooks today, but is planning to shift to Stripe, you should prioritize setting up the new system first, and then automating around it. However, don’t fall into the trap of perpetually kicking the automation can down the road for a system change that might not ever happen.
Later on we’ll cover value and complexity, which will be key in considering this part of the suitability scale.
If it isn’t clearly suitable for automation, stop there.
Pursuing the wrong process is a sure fire way waste time and money trying to automate something that isn’t suitable.
However, just because something isn’t suitable today doesn’t mean it can’t become more suitable for automation. Consider tweaking the people and process before adding on technology.
Once you’ve got suitable automation ideas, it’s time to forecast their value and complexity.
Stay tuned for that.
You shouldn't. Well, you shouldn't only listen to me. Talk to lots of people.
Just whatever you do, don't fall for some trickster showing tech in a completely staged environment where they display "miraculous AI features." It's highly likely the demo is designed only to work in a demo environment and the entire engineering team is throwing up behind the scenes because they know it doesn't actually work yet (and isn't even that close).
I've seen a lot of good automation. I've also seen tons of bad automation. I started building RPA bots seven years ago for accounting processes. Some were pretty good. Then I had a boss tell me that we needed "ten bots by the end of the year for our client". That was the ask. Ten bots. What the heck does that even mean?
That was my first experience of realizing that many very smart people have almost no clue on how to scope automation projects, which is arguably just as important as understanding how to build them, because what engineer doesn't want to accept an impossible challenge, blow through timeline and budget, just to prove they can do it?
I'm rarely serious on the internet, but this is one thing I'm serious about: use these criteria to evaluate automation opportunities and you will avoid wasting time and money in the wrong places.
.jpg)