AI Changes the Economics of ERP Automation

The most interesting thing about AI automation may not be the AI part at all. It may be the way that AI changes the economics of automating all the annoying little jobs that were never worth automating before.

That idea came through clearly in Tim Rodman’s conversation with McKenzie Cash. McKenzie works for Floral Services, a relatively lean company that sells artificial plants, seasonal products, Christmas trees, and more recently candles. Like a lot of people in mid-market companies, McKenzie wears multiple hats. He's “kind of the IT guy,” but that can mean anything from dealing with printers to setting up a new vendor relationship to figuring out some ugly data problem that suddenly became his problem.

That is almost a perfect environment for AI. The person doing the work may understand the business problem very well without being an expert in Python, browser scripting, Office 365 authentication, or whatever technical rabbit hole the problem happens to lead into that day.

McKenzie’s experience is a good example of what happens when that person can suddenly borrow a programmer on demand. Not a perfect programmer. Not a replacement for understanding the work. But a tool that can take a plain-English description of a process and turn it into VBA, Python, or JavaScript quickly enough that automation starts making sense for jobs that used to be too small, too weird, or too company-specific to justify the effort.

The Best AI Use Cases May Be the Ugly Little Ones

Tim loosely thinks of the mid-market as companies doing roughly $10 million to $500 million in annual revenue. In companies like that, job descriptions tend to have softer edges than they do in giant corporations. Someone who understands the ERP system may also wind up helping with EDI, Excel, vendor portals, reporting, file manipulation, and random one-off projects that do not belong neatly to anybody else.

McKenzie likes that kind of work. Every week is different, and when somebody brings him into a project it's usually because something needs to be figured out. Sometimes the problem is mundane. Sometimes it's important and unfamiliar. Either way, somebody has to get from “we need this” to “it works.”

AI fits especially well in that gap. McKenzie originally used ChatGPT mostly as a learning tool. He could ask a basic Acumatica question in ordinary English, work through it interactively, and avoid the awkward feeling of asking a human what might be a very simple question.

That “no judgment” aspect matters more than it sounds. A user can ask the same question three ways, admit complete confusion, disappear for two days, come back to the same conversation, and keep going. There is no 15-minute billing increment and no need to bring a different consultant back up to speed.

Tim sees a natural dividing line there. An LLM can often help someone get from small-letter a to small-letter b: answer the narrow question, explain the screen, write the little script, or help troubleshoot the immediate problem. Consultants still have a role when the job is getting from big-letter A to big-letter B, where the gap includes architecture, judgment, organizational politics, change management, and all the non-logical human stuff that tends to show up in real ERP projects.

That does not mean consultants should fight the small-letter work disappearing. Tim’s view is almost the opposite. The consultants who lean into LLMs may discover their actual value faster because they can let customers handle more of the routine questions themselves and focus human time on the harder gaps.

A Two-Minute Excel Task Can Still Be Worth Automating

One of McKenzie’s first examples was almost comically small. His company had an EDI cross-reference file that needed to be uploaded to a customer portal, but the portal had a file-size limit. The downloaded file had to be split, rearranged into the acceptable format, and uploaded in multiple parts.

Manually, the job took maybe two or three minutes. That does not sound like an automation project. Traditionally, it probably would not have been one.

But there are hundreds of two-minute jobs in office work. Tim’s reaction was that the real cost is not just the two minutes. It is spending the day switching among tiny tasks that clutter the brain, interrupt more valuable work, and keep somebody buried in details.

McKenzie had AI write an Excel macro. The macro added a button that split the file into two pieces, copied the headers into each piece, and saved them in the same location with names such as Part 1 and Part 2.

Nothing about that automation is futuristic. It is ordinary VBA doing ordinary deterministic work. The important difference is that McKenzie did not have to decide whether learning enough VBA was worth saving two minutes per day. The LLM lowered the development cost far enough that the answer became obvious.

One-Time Automation Can Make Sense Too

The next example went in the opposite direction. This was not a two-minute task repeated forever. It was a miserable one-time problem.

A vendor began rejecting invoice PDFs unless the invoice number was the filename. McKenzie had a folder containing roughly 200 PDFs whose filenames were essentially random strings, and the invoices were already late.

The obvious manual solution was awful. Open a PDF, find the invoice number, rename the file, repeat a couple hundred times.

McKenzie initially thought he might have to learn enough Python to solve it. Then he realized the LLM could probably write the Python for him.

It did. He provided an example, and the generated script extracted the invoice number from the PDF and renamed the file accordingly. McKenzie ran the script locally and said it worked on the first try, saving roughly an hour of tedious typing and copy/paste work.

The script itself was disposable, and that is part of the point. Traditional automation thinking often asks how many times a process will run before development pays for itself. AI-assisted development can push that threshold all the way down to a single ugly task.

The LLM Can Write the Tool Without Becoming Part of the Tool

A very important distinction showed up in both examples. The LLM wrote code, but the LLM was not required every time the code ran.

Tim described the difference as probabilistic versus deterministic logic. Claude or ChatGPT can generate the VBA or Python probabilistically, which means the person using it still needs enough understanding to verify that the result is actually doing the right thing. But once the code exists and has been tested, the finished script can run as conventional deterministic software.

McKenzie deliberately preferred that pattern for another project involving EDI price-mismatch emails. When a customer’s purchase-order price did not match the expected price in the cross-reference data, his company could receive large volumes of email alerts. One mismatch was easy to read. Hundreds of HTML emails were not.

So he had AI help build a Python application that consolidated those messages into an actionable report. The application authenticated through the company’s Microsoft 365 environment, looked at a designated EDI folder, reviewed the relevant messages, and produced a report showing the problems that needed attention.

The privacy boundary mattered to him. McKenzie did not want to hand an LLM broad access to the company mailbox and simply ask it to keep rereading email forever. He wanted the AI to help him build the tool, then let the finished deterministic application do the recurring work.

He also made the tool usable by people who did not care about Python. The Python application was packaged as an executable and stored in a SharePoint-backed location. The executable still ran locally on the user’s computer; SharePoint was simply a convenient place to distribute it. A user could click it, authenticate, and get the report without installing Python or troubleshooting missing libraries.

That is not the fanciest architecture in the world. But that is exactly why it's interesting. The solution solved the business problem without turning a small reporting utility into an IT project.

Then Came the Truly Miserable Website

The browser automation example is where the economics get really interesting. One of Floral Services’ large customers required product information to be entered into a new vendor portal so its warehouses could order the items.

The portal was rough. Fields sometimes failed to save. Some calculated fields would not accept copy and paste. The workflow included pop-ups, nested pop-ups, tabs inside nested pages, and slow saves. Entering information too quickly could cause the previous value not to stick.

There was effectively a speed limit on data entry. On some fields, the user had to wait several seconds before moving on.

And the consequences were not trivial. The customer reserved the right to impose a $1,000 penalty for an incorrect data-entry point, although McKenzie said the customer had never actually done that. Once an item was submitted, there was also no simple undo. Correcting a mistake could require opening a ticket, deleting the item, and starting over, potentially delaying the product.

McKenzie had already done the sensible human optimization. He put the input data into an Excel spreadsheet and arranged the columns in the same sequence as the website so he could work through the portal as efficiently as possible.

Then he asked the better question: why was a human typing this at all? He already had the structured data. The browser already had the fields. The process was basically a long sequence of clicks, keystrokes, waits, and checks.

Claude Suggested Tampermonkey Instead of a Desktop Macro

McKenzie initially thought about using AutoHotkey. Tim describes AutoHotkey as basically a macro for the whole desktop instead of a macro confined to Excel or Word.

Claude suggested Tampermonkey instead. That turned out to be a better fit because the automation needed to understand the web page itself rather than merely click fixed pixel coordinates.

That difference matters on a dynamic website. AutoHotkey can work very well when a screen is static and predictable. But this portal had dynamic menus, pop-ups, conditional paths, and elements that moved around. A browser script could work with the page’s actual HTML elements and inject its own interface directly into the site.

The result was essentially a little custom application living on top of somebody else’s web application. When McKenzie navigated to the relevant URL, his Tampermonkey script loaded a control panel in the lower-right corner of the page. It could read the Excel input, remember which step it was on, and execute the next action.

The script eventually grew to roughly 57 steps. McKenzie did not sit down and design all 57 in advance. He built it incrementally.

The Automation Was Built One Annoyance at a Time

That incremental process may be the most reusable part of the story. McKenzie would reach a manual step and ask Claude, in plain English, whether that step could be automated.

A date field looked annoying because the site would not let him type the date. It forced the user to open a calendar and click a date. McKenzie asked whether the script could always select today. Claude asked for information from the browser console, McKenzie supplied it, and that problem disappeared.

Another page needed a different number of sub-items depending on the case. McKenzie described the rule, and the script was adjusted to click dynamically based on the data.

One especially strange control combined a dropdown, checkboxes, a “check all” option, and a final submit choice inside the dropdown. Claude gave McKenzie a test to run in the browser developer console so it could understand the page structure. He ran the test, fed back the result, and the script learned how to handle that too.

The automation did not require McKenzie to speak like a programmer. He was not describing static arrays, DOM selectors, or software patterns. Most of the time he was describing the workflow the way he would describe it to a colleague: this field comes next, this page behaves differently when there are multiple SKUs, this button needs to be clicked after those choices, this screen needs more time to save.

Claude translated the workflow description into code. That is a pretty big shift in who can build small internal software.

The Website Was Still Buggy, So the Automation Became Pessimistic

Automation did not magically fix the customer’s portal. If the website had a random save problem during manual entry, it could still have that problem during automated entry.

So McKenzie built around the unreliability. Different pages received different timing delays. A responsive page might need only half a second. One especially slow page eventually received a 13-second delay because moving any faster risked losing the previous entry.

The compliance page was even stranger. Floral Services sells plants, so questions about things like hazardous-material handling or temperature requirements were generally answered “no.” But the portal required clicking roughly 25 separate “no” options for every item, with no mass-update function.

That was an obvious automation target. Unfortunately, individual radio buttons still had a small chance of failing to save even when a human clicked them.

The solution was redundancy. The automated workflow eventually included a later step that returned to the compliance page and clicked the “no” answers again. Instead of pretending the source system was reliable, the automation incorporated the system’s unreliability into the process.

That is very ERP. Real automation is often less about creating an elegant happy path and more about understanding exactly where the ugly system misbehaves and designing around it.

Human Review Was Deliberately Left in the Loop

McKenzie did not automate the final submission. That was intentional.

The biggest remaining risk was not the script putting a value into the wrong field. McKenzie said it was extremely accurate at placing the data. The risk was that the source data itself might contain something inappropriate for a customer-facing field, such as an internal abbreviation.

So the automation stops before the irreversible step. McKenzie can let it work through the data entry, come back, review the completed information, and make the final submission himself.

That is a useful model for ERP automation in general. “Automated” does not have to mean “remove the human from every step.” A better design may be to automate the rote work and preserve human judgment at the point where a mistake becomes expensive or hard to reverse.

The Biggest Surprise: It Paid for Itself on the First Run

The headline result was not that the script worked. The bigger surprise was how quickly it became worth building.

McKenzie said developing the browser automation took less time than manually completing the job once. Not less time than completing it 100 times. Not a six-month payback. It saved time on the first upload, and every use after that was additional benefit.

That changes the old automation calculation. Historically, a two-hour task performed once every couple weeks might not justify a custom development project. If the automation itself can be built conversationally in less time than one manual run, the threshold gets a lot lower.

It also changes what counts as “software development.” McKenzie has no background as a Python programmer. He had some coding familiarity, but he leaned heavily on AI for these solutions. His contribution was knowing the process, recognizing the pain, testing the output, and explaining what should happen next.

That process knowledge may be the scarce resource. The person who knows exactly why the current workflow is miserable is suddenly much closer to being able to build the fix.

Why This Gets Interesting for Acumatica

The obvious next question is what happens when the same technique is aimed directly at an ERP screen. McKenzie has already done basic tests with Acumatica and believes the interface should be easier to automate than the customer portal because it's more consistent and less buggy.

The specific use case he has in mind is basically a multi-screen import scenario. Another employee has a recurring process where data must be entered on one screen, which leads to a transfer, which then requires creating something on another screen. The same information and the same sequence repeat across multiple pages.

A normal Acumatica Import Scenario is very good at certain single-screen jobs. The trouble starts when the workflow needs to cross screens. At that point, a more formal workflow or customization may be required, which brings a development environment, deployment, maintenance, and the general baggage of a customization project.

For a process one employee performs every other week, that baggage matters. McKenzie described a job that might consume two or three hours at a time but consists largely of rote clicking. That is exactly the kind of in-between problem that can be too annoying to leave alone and too small to justify a conventional software project.

A browser script could occupy that middle ground. In theory, it could navigate the normal Acumatica user interface, click the same controls a person clicks, move across screens, and preserve the logic in a lightweight script rather than a formal ERP customization.

But this part is still a hypothesis, not a finished success story. McKenzie had tested that the basic technique works in Acumatica, but the full multi-screen use case had not been completed yet. Tim was enthusiastic about the potential, but the conversation stopped short of claiming that Tampermonkey should replace Import Scenarios or Acumatica workflows generally.

That uncertainty is worth preserving. The interesting conclusion is not “throw away the supported ERP tools.” It is that AI-assisted browser scripting may add another option for narrow, repetitive, UI-driven processes that fall awkwardly between manual work and full customization.

Security Still Has to Be Part of the Conversation

Browser extensions and generated scripts deserve some caution. McKenzie made several changes specifically because he did not want the automation to reach farther than necessary.

The original script pulled a software library at runtime. He did not like that from a security standpoint, so he downloaded the dependency and pointed the script to a local copy instead.

He also scoped the script to the specific website where it was needed. The script was configured to run only at the relevant URL rather than receiving broad permission across unrelated sites.

He disabled automatic updating for the extension as well. His reasoning was pragmatic: once the setup worked, he did not want an update breaking the script unexpectedly.

None of that makes browser automation automatically safe. It does show the right kind of thinking. Generated code, extensions, authentication, permissions, dependencies, and company data all create real boundaries that somebody still has to understand and own.

AI May Change Consulting by Moving the Boundary of “Easy”

The same pattern has implications for ERP consultants. McKenzie does not expect consultants to disappear, and Tim does not either.

What may disappear is some of the work around the edges. A customer who once called a consultant to ask how to perform a small Acumatica task may now ask an LLM first. A user who once lived with a two-minute annoyance may have AI write the macro. A company that once assembled an EDI exception report manually may build a little internal utility instead.

That leaves consultants with proportionally harder problems. And that may be fine.

Tim’s view is that consultants who embrace AI can bring more knowledge to the table, not less. McKenzie pointed out that a consulting firm could eventually use AI to make better use of its own ticket history: recognize that another customer had a similar problem, surface the prior resolution, and reduce the amount of tribal knowledge lost when employees leave.

The sensitive-data question is not solved by saying that out loud. Tim explicitly acknowledged that he did not know exactly how a consulting firm should implement that kind of cross-client intelligence while respecting confidentiality and security. But the potential is obvious enough to be worth exploring carefully.

The New Skill Is Explaining Work Clearly

There is a larger pattern underneath all of McKenzie’s examples. He is becoming an interface between the LLM and the real business.

That role looks a little like the early days of Google. Tim remembers a period when some people in an office were simply better at searching the web, so coworkers would bring questions to the person who knew how to get useful answers out of Google. Eventually web search became normal behavior for almost everybody.

AI may be in a similar phase. People at McKenzie’s company now come to him and ask whether Claude can help with a problem because he has developed an instinct for what the tool can and cannot do.

That instinct is probably more valuable than memorizing prompts. McKenzie’s parting advice was to start by asking AI questions whose answers are already known. That gives the user a cheap way to calibrate the tool, notice where it's strong, notice where it confidently goes wrong, and develop a feel for when a new problem is a good candidate.

Once that calibration happens, the world starts looking different. A weird PDF renaming job stops being “an hour of copy and paste.” A recurring Excel cleanup stops being “just two minutes.” A terrible vendor portal stops being “the way the customer makes us do it.”

Instead, the question becomes much simpler: does a person really need to keep doing this the hard way?

The Practical Bottom Line

The strongest lesson from McKenzie’s experience is not that everyone needs to become a programmer. It's almost the opposite.

People who understand the business process can now reach much farther into programming than they could before. They can describe what they are doing, let an LLM help translate that workflow into code, test the result, and gradually remove the parts of the job that are pure repetition.

The safest and most useful pattern may often be surprisingly boring. Let AI help write the tool. Let deterministic code run the repetitive process. Limit permissions. Keep dependencies understandable. And leave a human in the loop where judgment or irreversible consequences still matter.

Most importantly, the automation does not need to be grand. It can be a button in Excel. It can be a Python executable that produces one report. It can be a browser script that clicks 25 “no” buttons so a person does not have to.

That is where this gets interesting for Mid-Market ERP. There are a lot of small, ugly, highly specific processes that nobody would ever put on a software-development roadmap.

AI is making some of them cheap enough to fix anyway.