JMT Consulting was named to Accounting Today’s 2026 Best Accounting Firms for Technology, one of 10 firms recognized nationally.
John Tiso, Vice President of Emerging Markets at JMT Consulting, joined Accounting Today’s Best Firms for Technology panel. Here is what the discussion means for a nonprofit finance team deciding what to buy next.
Firms recognized for technology do not chase new tools. They buy against a defined problem, check what they already own first, put a named owner on every system, and treat adoption as the hard part rather than an afterthought. For a nonprofit finance team, the lesson is that selection is the easy half. What determines the return is who owns the system and whether anyone actually uses it.
Every year, Accounting Today names a small group of firms to its Best Accounting Firms for Technology list, then brings a few of them together to talk about how they actually run their technology. JMT was one of the 10 firms named in 2026, alongside Sensiba and Sikich, and all three sent someone to the panel: Crystal Riggins of Sensiba, Scott Sanders of Sikich, and John Tiso of JMT, with Accounting Today editor-in-chief Dan Hood moderating.
The firms differ in size and in who they serve. What they said about technology was strikingly consistent, and most of it applies directly to a nonprofit finance office with a fraction of the budget.
Buy for the problem in front of you, and the one coming
John described JMT running two tracks at once. One is reactive, responding to a bottleneck, a pain point, or a process that has too many manual steps. The other is deliberately forward-looking.
When we look at technology, we’re not just looking at what we can use, but also what our client base can use.John Tiso, Vice President of Emerging Markets, JMT Consulting
The forward-looking track is the one most organizations skip, and it is the one with the longest payback. John pointed to JMT’s move to cloud accounting at a time when the rest of the field was still on premise, which meant committing years before clients were ready to follow.
There is a practical test attached to that. Before JMT recommends software to a client, it tries to run on the software itself.
Whenever possible, we will use software ourselves first as a candidate to evaluate it and really find out what the end user experience is like.John Tiso
For a nonprofit, the equivalent question to ask a vendor or an advisor is simple: do you run your own organization on this, and if not, why not?
Check what you already own before you buy
The panel returned repeatedly to a habit that costs nothing: looking at the existing stack before signing for anything new. Software costs are climbing, renewal increases in the double digits are now common, and vendors keep adding capability to products organizations are already paying for.
That creates a quiet form of waste. The functionality arrives, the price goes up to reflect it, and nobody uses the new feature because nobody was told it existed.
If your renewal went up because the vendor added capability, and your team is not using that capability, your cost per unit of value just went up. The fix is not a new purchase. It is finding out what the software you own can already do.
John added a timing question worth borrowing for any nonprofit business case.
We also factor in how long it will take for us to receive benefits. If it takes us three years to turn around something, can we even make that happen before we see those returns?John Tiso
Somebody has to own the system
This was the most useful thing JMT said about its own limits, and it will sound familiar to any finance team running lean.
A lot of our system maintenance and administration was almost a secondary thing that people were tasked with as a side objective to their actual role. It wasn’t until the last couple of years, when we started getting people brought in to intentionally own these increasingly complex systems, that we started to feel some relief.John Tiso
Systems administration that is nobody’s actual job is the default state in most nonprofits. It works until the software gets complicated enough that part-time attention is not enough, and by then the gap shows up as errors, stalled projects, and a system nobody quite trusts.
Naming an owner does not require hiring one. It requires deciding whose job it is, writing that into the role, and giving them the time.
Adoption is the hard part, not selection
Across all three firms, the biggest technology challenge named was not choosing tools. It was getting people to use them well after the rollout.
The default way most organizations handle this is a single training session at go-live. Everyone is in the room once, the tool is declared rolled out, and nothing is scheduled after that. John Tiso’s answer to that pattern comes from JMT’s day job of training clients on newly implemented software, turned inward on JMT’s own rollouts.
One and done fails every time.John Tiso
Three things make the difference in his experience. Identify the power users who will pick the tool up and run with it. Find a champion who sits with the team rather than above it, someone who connects to why the change is happening and can carry that to everyone else. Then keep touching it, repeatedly, long after the launch.
Finding out who is struggling takes more than an open invitation to ask questions.
Some people don’t want to openly, publicly acknowledge that they’re not grasping something. So I found that directly asking a person individually works.John Tiso
The panel also noted that most modern software reports its own usage data. Before you assume a tool is working, look at who is logging in and which features they touch. It is the cheapest adoption audit available, and it is already included in what you pay.
One number from the webinar’s live audience poll is worth sitting with: roughly a third of attending firms said they have a written technology strategy, a third have one that is not written down, and a third have none at all. Writing it down is not bureaucracy. It is what lets you say no to the next tool with a reason attached.
Why JMT went slowly on AI
The panel diverged most visibly on pace. Two of the firms described going all in on AI early. JMT took the other road, on purpose.
We’ve been really slow and methodical about AI. We intentionally did not take the “let’s just give it a shot and see what happens” approach. We felt that the risks, not only to ourselves but to our clients, were high enough to warrant that more intentional approach.John Tiso
That caution is not the same as standing still. JMT has since rolled out its fourth internally approved AI system, each one vetted before it reached a client engagement.
The reasoning behind the pace is worth stating plainly, because it is the difference between a firm serving businesses and one serving nonprofits.
Everything we do is people serving people who then turn around and serve more people, being nonprofits. If AI is not going to make that better for our clients and then their constituents, it’s just not meeting the need.John Tiso
What to take from this
Translated for a nonprofit finance office, the panel’s shared habits come down to six things.
- Write the problem down before you look at tools. If you cannot name the bottleneck, you are shopping, not solving.
- Audit what you already pay for. Ask your current vendors what shipped in the last year that you are not using.
- Put a payback window on the business case. If the benefit arrives in three years, say so out loud before you sign.
- Name an owner for every system. Not a volunteer, and not someone’s fifth priority.
- Plan the training past launch day. Role-based at rollout, then repeated. Check usage data instead of assuming.
- Write the strategy down. Even one page. It is what gives you grounds to decline the next thing.
None of this requires the budget of a 2,500-person firm. It requires deciding who owns what, and being honest about whether the last thing you bought is actually being used.
If you are weighing a system change and want a second opinion from people who work only with nonprofits, we are glad to talk it through.
Lessons from the Best Firms for Technology 2026, hosted by Accounting Today on July 9, 2026. Moderated by editor-in-chief Dan Hood, with Crystal Riggins (Sensiba), Scott Sanders (Sikich), and John Tiso (JMT Consulting).
Frequently asked questions
What do the best firms for technology do differently?
They buy against a defined business problem rather than adopting new tools for their own sake, they check what their existing software can already do before purchasing, they assign real ownership of each system rather than treating administration as a side task, and they treat adoption and training as ongoing work rather than a launch-day event.
How should a nonprofit decide whether to buy new finance software?
Start by naming the specific problem or bottleneck you are solving. Then check whether software you already pay for can address it, since vendors add capability continuously. If you still need something new, put a payback window on the business case and confirm you have the internal capacity to implement it before the next busy period.
Why does technology adoption fail after implementation?
Usually because training stopped at launch. One session is not enough for software that changes continuously. Effective adoption uses role-based training at rollout, an internal champion who works alongside the team rather than above it, repeated touchpoints afterward, and direct one-to-one check-ins, since many people will not raise a problem in a group setting.
How can we tell whether our team is actually using the software we pay for?
Look at the usage data most software already reports. It will show who is logging in and which features are being used, which tells you whether a problem is widespread or limited to a few people, and where additional training should be aimed. It costs nothing because it is included in what you already pay.
Should a nonprofit move quickly or slowly on AI?
Deliberately, and with each system vetted before it touches client or constituent data. Firms serving nonprofits carry risk on behalf of organizations that cannot absorb a data incident, which argues for approving tools one at a time rather than experimenting broadly. Moving deliberately is not the same as standing still.
