Acumatica’s Modern UI Is Becoming More Than a New Interface

The most interesting thing about Acumatica’s Modern UI may not be the interface at all. The painful part is obvious: moving away from the Classic UI means relearning screens, retesting customizations, and dealing with the normal disruption that comes with a major platform change. But Tim Rodman came away from a conversation with Alan Conroy seeing a much bigger upside. The Modern UI is creating a new layer where consultants, power users, and what Tim likes to call “duct tape developers” can build useful things around Acumatica without immediately reaching for a traditional customization project.

That distinction matters because the tools Alan has been building are not theoretical developer demos. They came from ordinary Acumatica problems: finding broken Generic Inquiries after an upgrade, making sense of a wall of trace errors, understanding what actually changed in audit history, figuring out what field sits behind a screen, and helping users notice an exception before an order goes out the door.

This kind of thing might not get an investor excited, but it sounds like actual work.

Acumatica Is Still Small in Europe, but the Footprint Is Growing

Alan Conroy has been in ERP for roughly 30 years. His first implementation was in the late 1990s, after getting the familiar assignment of being the “young tech guy” who was told, more or less, to go figure out the ERP system. Much of his career was in the office supplies industry in Ireland and the UK. More recently, he worked with ProServe, an Acumatica VAR that was later acquired by Net at Work, and he continues to do substantial work with Net at Work.

He and his colleague Sue started an Acumatica services business partly because they saw the possibility of Acumatica growing in Europe. Alan’s view is that the UK market is still early. Sage remains a major mid-market ERP presence there, with Dynamics, SAP, and others in the mix. But at an Acumatica partner event in July 2026, he saw a larger Acumatica partner footprint than at the same event in 2025, including newly onboarded firms.

The scale is still modest. Alan estimated roughly 50 people at that UK partner event, mostly partners rather than customers. He said Acumatica has some sizable VARs in the UK, while Ireland appears to be served mostly by UK-based or US-based partners. Tim compared that very loosely with an Acumatica event in Denver that had around 500 people and concluded that even reaching a fraction of the US partner footprint would represent meaningful progress from where the European ecosystem has historically been.

Tim also pushed back a little on the idea that Acumatica is fundamentally a US product being adapted for Europe. His impression has long been almost the opposite. One example is taxes. Products that originate outside the United States often handle VAT nicely and US sales tax awkwardly. Acumatica, in Tim’s experience, has historically been a little clunky with US sales tax, which to him is evidence that the architecture was never narrowly US-centric.

Alan added another piece to that explanation: MYOB. MYOB had an equity stake in Acumatica and used Acumatica as the basis for a white-labeled mid-market product in Australia. Since Australian GST has similarities to VAT, Alan thinks that relationship helped push the product toward international requirements rather than bolting them on later.

None of this means Acumatica has already “won” Europe. Alan described the market as being in its infancy. But the larger partner footprint matters because one of the emotional objections to Acumatica in the UK can be that the product feels too US-centric or that Acumatica is not committed to Europe. More local partners make that argument harder to sustain.

The Modern UI Creates a New Surface for Acumatica Tools

The conversation got more interesting when Alan explained why his browser extensions are possible in the first place. Years ago, he found a Stack Overflow article about highlighting lines in Acumatica. He liked the idea, but implementing it against the Classic UI was clunky. The code had to target tabs, initialize in multiple places, and work around HTML that was difficult to identify reliably.

The Modern UI changes that. Alan’s explanation was deliberately non-developer-ish: the browser can see more clearly what's happening behind the screen. Buttons, fields, containers, and other elements are easier to identify in the DOM, which means a browser extension can scan the page and act on what it finds.

That opens a useful middle ground between “do nothing” and “publish a customization project.” A browser extension can inspect and reorganize information without writing code into the Acumatica application itself. Alan’s extensions can read what the browser is already displaying, but they are not injecting a customization into Acumatica’s codebase.

Tim sees this as one of the reasons the Modern UI is bigger than a visual redesign. He went so far as to say that it feels more like a new ERP application and joked that it should almost be called “Acumatica 2.0.” The transition is painful partly because the change is deeper than a new coat of paint. But that same architectural shift appears to create room for browser extensions, TypeScript, AI-assisted development, and eventually computer-use agents that can navigate Acumatica more reliably.

The key point is not that every Acumatica customer should start writing browser extensions. It's that the surface area available to people outside the traditional full-time developer role is getting much larger.

A Screen Tester Born from a Broken Upgrade

Alan’s first example started with a very normal upgrade problem. Acumatica had deprecated and later removed a table in the Field Service area. Alan did not claim perfect recall of the exact table name during the conversation, but the practical effect was clear: Generic Inquiries that depended on it started failing.

One customer site had more than 100 Generic Inquiries. The ugly way to discover the damage was to open them one at a time and see which ones crashed. Alan wanted something faster.

So he built an Acumatica screen tester. The tool takes the base URL of an Acumatica site plus its sitemap, then opens each screen and checks a very simple thing: does it load or does it fail? At the end, it produces pass/fail results that can be exported to CSV.

That sounds almost too simple. But if an upgrade leaves five broken GIs hidden among 100 working ones, finding the five is most of the battle. A tool that quietly runs through the site lets the consultant spend time fixing failures instead of clicking through screens looking for them.

This is a recurring pattern in Alan’s work. He's not starting with, “What cool thing can JavaScript do?” He's starting with, “I am doing this repetitive thing by hand. Why?”

The Trace Copier Turns AI into a Practical Troubleshooting Harness

The next pain point was Acumatica trace errors. A failed operation can leave a consultant staring at multiple requests, exceptions, warnings, and a large wall of technical text. The old process was a lot of selecting, copying, switching tools, pasting, explaining context, and then trying to figure out what the error meant.

Alan’s Trace Copier extension collapses that workflow. On the Acumatica trace screen, it can scan the saved requests, collect the exceptions, identify things such as the screen ID and command, and copy the useful material to the clipboard.

The more interesting button is “Copy for AI.” Instead of copying raw exceptions and then separately explaining the situation to an AI model, the extension prepackages the context with a prompt. Alan demonstrated options such as asking the AI to act as a developer and suggest a fix, provide a plain-English explanation for a less technical support user, create a bug-report-style summary, or use a custom prompt with placeholders for things such as the screen ID and command.

Tim immediately called this an AI “harness.” That word captures why the feature matters. The AI model itself is not the workflow. The value comes from putting the right information in front of the model, in the right format, at the moment somebody needs it.

In the demo, the extension scanned Acumatica’s recent trace requests and found several exceptions. It automatically inserted the screen and command into the prompt. The AI response then traced the problem to a divide operation involving the wrong type of field and even pointed toward field names that could be found on the Generic Inquiry results tab.

The important part was not that AI can read an exception. People were already doing that. The improvement was removing the little pieces of friction around it: gathering the trace, finding the relevant requests, adding context, switching mental modes, and composing the same prompt again.

Alan also built a “Pick Element” capability into the extension. One use is grabbing SQL from a screen so a consultant can inspect how a complex query was built. That can be useful when reverse-engineering a GI somebody else created.

Privacy was an explicit design concern. Alan said the extensions process information locally in the browser and do not send data back to AcuGen Consulting. If a user chooses to paste the copied material into Claude, Copilot, Gemini, or another AI service, that's a separate choice made by the user in that environment. The extension’s code is also available for people who want to inspect it.

This is exactly the kind of AI usage Tim finds compelling. It's not “AI strategy.” It's one button that removes a bunch of annoying work.

The Audit Analyzer Shows Why AI Is Not Always the Important Part

Acumatica’s standard audit history has bothered Tim for years. His description was that it feels almost like an old green-screen application embedded inside a modern browser application. The data is there, but it's noisy, newest-first, and visually difficult to scan.

Alan’s Audit Analyzer attacks the presentation problem first. It reorganizes the history from oldest to newest, summarizes the significant actions, shows what values changed from and to, and lets the user filter down to specific concepts such as cost or discount.

The strongest feature is that the basic story is deterministic. Tim specifically asked whether AI was generating summaries such as “added line” or surfacing the chronological story of the transaction. Alan said no. That part comes from logic applied to Acumatica’s own data.

Tim loved that answer because the UI itself is the value. The tool does include copy-for-AI functionality, but AI is not required to make the audit history useful. A user can see the important changes, move forward through time in the natural direction, filter the noise, and drill into detail only when needed.

That makes the Audit Analyzer more of an end-user tool than a developer tool. Alan pointed out that the chronological “story” becomes especially useful on service orders and appointments where a document may accumulate a lot of activity over time. A user can understand the broad sequence first, then dig into exactly who changed a price and when.

This is a good reminder in an AI-heavy year. Sometimes the best solution is not to ask an LLM to reason over a bad interface. Sometimes the right answer is to make the interface better.

The Field Inspector Is “Inspect Element on Steroids”

Alan’s third browser tool goes in the other direction and is aimed more at consultants and developers. The Field Inspector lets a user point at a button or field in Acumatica and retrieve technical information about what sits behind it.

For a selected field, the tool can surface the screen, screen ID, graph, label, DAC field, links to the DAC and source data, and browser-level information such as selectors, containers, and the element path. Tim described it as “inspect element on steroids.”

The value is mostly speed. A consultant can already use Acumatica’s Inspect Element feature, follow the data class, and work toward the source data. Alan’s tool is not inventing a new universe, but rather removing several steps from a task that technical consultants do repeatedly.

The Modern UI again makes the difference. Alan said the Field Inspector can run against the Classic UI, but it returns much less because the underlying Classic UI HTML doesn't expose as much information to the browser.

Tim thinks tools like this could broaden the definition of “developer” inside the Acumatica ecosystem. AI can now write a lot of code, while the Modern UI exposes more of the screen to browser-side logic. The line between consultant and developer is already blurry, and he expects it to get blurrier.

That does not mean the professional developer disappears. It means more people can participate in the layer between configuration and deep application development.

Small Tools Still Have a Maintenance Problem

Alan intentionally keeps the browser extensions separate rather than bundling everything into one giant Acumatica extension. Part of that is historical: each tool was built when a specific need appeared. But he also does not want a bloated plugin that slows the browser, requests too many permissions, becomes cumbersome, or turns into a maintenance monster.

Maintenance is the part of AI-assisted software development that Alan thinks people underestimate. AI has compressed the build phase dramatically. Somebody can “vibe code” a useful prototype over a weekend. But software still has to be designed, tested, secured, updated, and maintained when the underlying platform changes.

Alan explicitly does not want a plugin that works on 26R1, partially breaks on 26R2, and then limps into the next version. His intention is to maintain these tools. Keeping them small helps the user experience, but it also makes that commitment more realistic.

Tim liked the human side of that decision too. A technically elegant architecture is not automatically the right architecture if maintaining it becomes so heavy that the creator stops enjoying the project. Keeping a tool light in the browser and light in the developer’s head can be a legitimate design constraint.

There was also a practical Chrome Web Store constraint. Alan said his newer developer account was limited in how many extensions he could publish until it built more history and users. That forced him to choose which tools should get public slots first. The available extensions can also be distributed through Edge and Firefox, while Safari would require additional Apple tooling and developer costs, so he didn't see much reason to take that on for free utilities.

AI Is Making It Easier to Build Outside the ERP — Maybe Too Easy

The conversation then widened from browser extensions to software architecture. Alan sees a growing temptation to build an AI application somewhere else, connect it to Acumatica, pull data out, and create a separate experience around the ERP.

He does not deny that this can be powerful. His concern is that ERP history has already been through this cycle. Businesses once had information scattered across separate systems. ERP became valuable partly because it pulled business processes and data back together. Now AI makes it very easy to start scattering them again.

Tim recognized the pendulum immediately. He used the old phrase “there’s nothing new under the sun” to describe the swing from fragmented systems to centralized ERP and now back toward a new generation of specialized applications.

Alan’s preference is to build inside Acumatica when practical. The reason is not architectural purity. It is maintenance and security. If somebody builds a separate hosted application that talks to Acumatica, that person suddenly owns more than the business logic. They also own hosting, operations, security, integration reliability, and the ongoing care of another software stack.

That is where the easy AI demo can become misleading. AI may make the initial build shockingly fast while leaving the rest of the software development lifecycle sitting there waiting. Design, testing, deployment, monitoring, security, and maintenance did not disappear because the code was generated faster.

Tim sharpened Alan’s point even further. It's unrealistic to expect one person to be an expert in application design, ERP, infrastructure, security, and every other discipline involved. At some point that person is a generalist outside the area where they chose to specialize.

Using Acumatica’s framework lets somebody borrow expertise they do not personally possess. Acumatica handles a substantial portion of the platform, security, and application plumbing. That leaves the consultant or product builder more time to focus on applying technology to the business problem.

There are tradeoffs, of course. A separate application can do things an embedded solution cannot. But Alan is consciously choosing a lane, and Tim thinks that discipline makes sense.

Lumi Brings Conditional Formatting to Data Entry Screens

Lumi is where Alan’s ideas become a more substantial paid product. The basic problem is simple: as companies automate more activity, humans are still left looking at large amounts of information and trying to notice the few things that deserve attention.

Color can help. If a sales order line cannot be shipped because inventory is unavailable, Lumi can turn the row red. If margin drops below 20%, a cell can be highlighted. If cost is zero, if a price was manually changed, or if a discount looks suspicious, a rule can call attention to it immediately.

The “immediately” part matters. Alan said the highlighting happens as the field is updated rather than waiting for the document to be saved. The user gets the signal while working on the transaction, not after the mistake has already been persisted.

Tim’s comparison was conditional formatting in a Generic Inquiry. Acumatica users already understand the idea of making data visually stand out in a GI. Lumi brings a similar concept into operational data-entry screens where the user is actually doing the work.

The rule engine is designed to feel familiar rather than clever. A user can choose the Acumatica screen, select tabs such as Lines, Payments, or Shipments, decide whether the formatting applies to a cell or an entire row, choose the fields, and then define the conditions.

The conditions deliberately resemble Generic Inquiry conditions. They can use AND/OR logic and parentheses, compare a field with a literal value, or compare one field with another. Alan’s goal was not to invent a new rule language. It was to reuse patterns Acumatica users already know.

The color system is flexible but guarded. Lumi includes preset styles such as critical, warning, information, and good, with different intensity levels. Users can also choose their own foreground and background colors, bold text, or italic text. If the contrast becomes difficult to read, the product warns them.

Rules can conflict, so Lumi includes priorities and analysis. If a user expects a field to turn red but it does not, the Analyze Result feature checks whether another active rule has higher priority and explains why the expected formatting is not appearing.

Custom fields were another practical problem Alan had to solve. AcuGen can know the standard fields Acumatica ships, but it cannot know every field created by every customization project. Lumi therefore includes custom-field discovery so an administrator can find user-defined fields and add approved ones to the rule configuration.

The rules can also move between environments. Alan demonstrated exporting a rule to XML from a test tenant and importing it into another tenant, with controls around whether an existing rule can be overwritten. That avoids rebuilding the same configuration manually after testing.

Document scope lets the rule look beyond the detail line. A condition can depend on header-level information such as customer, customer class, customer price class, or document type. A rule could therefore apply only to return orders, for example, even if the formatting itself appears on a detail grid.

Alan is intentionally reluctant to turn a visual warning into a hard stop. Tim asked whether a rule might eventually prevent saving a document. Alan’s answer was basically no. There may be a perfectly valid business reason to make an exception, like when a critical order arrives at five o’clock on Friday afternoon.

His preference is to warn aggressively without taking control away from the user. Lumi is also being extended so a user can ask why something is highlighted and see which rule triggered it. Alan is exploring how selected rules might eventually participate in workflows or business events, but he doesn't want dozens of visual rules creating an unmanageable processing mess.

The roadmap also includes more targeted rule scopes. Alan discussed assigning different rules by role, branch, or specific user because the important exceptions in a retail operation may be different from the important exceptions in a wholesale operation.

He has also tried to make the product feel like it belongs inside Acumatica. Lumi includes its own wiki pages, modeled after Acumatica’s form-reference documentation, with explanations of colors, conditions, analysis, and other settings. Alan described this as part of trying to reach an ISV-grade level rather than shipping a clever customization and walking away.

The Real Opportunity Is the Layer Between Configuration and Customization

The common thread through all of these tools is not JavaScript, AI, or even the Modern UI by itself. It's the shrinking gap between standard configuration and a full customization project.

The screen tester finds failures without manually opening 100 screens. The Trace Copier packages the context an AI model needs. The Audit Analyzer makes a difficult native screen understandable without requiring AI at all. The Field Inspector helps a consultant get from a visible field to the underlying technical information faster. Lumi puts business rules in front of the user while the transaction is being entered.

They are all small examples of moving intelligence closer to the work. Sometimes that intelligence is deterministic. Sometimes it's visual. Sometimes it's an LLM. And sometimes it's just eliminating three clicks that people have been tolerating for years.

Tim’s biggest takeaway is that Acumatica’s Modern UI may make this kind of work much more common. The Classic UI gave people fewer hooks into what was happening in the browser. The Modern UI exposes more structure, while AI makes it easier for nontraditional developers to write the code that acts on that structure.

That combination could produce a lot of useful “apps inside the app.” It could also produce a lot of unmaintainable junk. The difference will probably come down to the boring things: whether the tool solves a real problem, whether the logic is understandable, whether security is taken seriously, and whether somebody is willing to maintain it after the demo works.

That's probably why Alan’s tools are such a good example. They did not start as a strategy. They started as annoyances.

And that's a pretty good place to start.