Developers: Why The Tools Tax Pros Rely On Are Ripe for Disruption (2023 Update)

Developers: Why The Tools Tax Pros Rely On Are Ripe for Disruption (2023 Update)

An overview of the ecosystem of tools tax professionals are forced to rely on, and how it contributes to the old-thymey perception of tax professionals.


The three biggest workflow headaches for tax pros:

  1. Pulling proforma lists of docs & info requests from tax software
  2. Feeding those into a portal to gather info & automate follow-ups
  3. Pulling client info directly into tax software & workpaper mgmt apps


Proforma Lists

This is the list of info used to prepare the prior year return, that's the starting point to prepare the current year return. This ought to be easy to get, right? It's virtually impossible, and a big contributor to the old-thymey perception of tax pros.


Virtually all complex US income tax reporting runs through one of four tax software programs. All four are shockingly archaic, fundamentally on-premise systems. And owned by orgs that came of age in a different era of software development.


The complexity of supporting 5k+ income tax jurisdictions in the US is a massive moat for tax software vendors. Conservative estimates say this is a $100M+ investment to build tomorrow from scratch.


So as the rest of the world progress, the infra tax pros rely on stands still.


Each system has what it calls an "organizer". A static PDF that includes some of the prior year information. This was created in the 90s as a way to collect information via mail, and remains unchanged.


Tax vendors have rolled out various digital alternatives, all are laughably bad. Solutions like sending a .exe to your client over email. Tax pros are stuck between putting an embarrassing pdf/paper organizer in front of a client, or an awful UX they'll have to run support on.


So tax pros should just build their own intake form, based on the client's proforma info, right?


Wrong.


The proforma info is inaccessible. A combination of the tax software being less than helpful, and platform lock-in disincentivizing making this accessible. Some tax vendors have an SDK they will open up for select partners, but this is a tough nut to crack. Three unfortunate workarounds some tools have adopted:


  1. Ingesting the PDF organizer and extracting prior year amounts. Unfortunately this is only partial info.
  2. Some combination of data exports from the software, reliant upon an app installed on a user's machine.
  3. An RPA bot, either on the user's machine, or on a virtual machine with access to their client database.


A Portal to Gather Info

While there are an abundance of generic portals out there, none are particularly well served for gathering tax info. Two exceptions being TaxCaddy and Soraban. And the lack of development here largely stems from the difficulty of solving the proforma problem.


Today tax pros who are willing to invest the time in building custom intake processes rely on the usual cast of characters in the web form space. But most aren't particularly suited for tax intake for a number of reasons. A client will virtually never submit 100% of their tax info gathered in one sitting. They're waiting on forms, need to confirm other details etc. So the notion of completing a webform in one sitting isn't practical here. This is largely solved by auto-saving, but eliminates 80% of web form solutions.


The other fiddly part of the process is you often need to gather a large number of amounts. For example, a list of income & expenses for a rental. If the tax pro needs 20 figures, the traditional web form UI is painful. It isn't suited for gathering large volumes of data. Imagine trying to get someone to cruise through a 100 question Typeform, one number at a time.


And while there will be a few common questions posed to all clients, 90% of these request lists are completely bespoke, by client. So the generation of the intake form itself needs to be done based on the underlying proforma list, not a boilerplate set of questions.


Integrations

It's exceedingly difficult to then pull that information directly into the tax software. This has only been semi-achieved by developers painstakingly developing RPA bots for each tax suite (across 5k+ jurisdictions).


Most tax pros have an intermediary workpaper management system. A standard way to document and store the client files, but this looks a little different for everyone. The smartest out-of-the-box solution for this, for individual taxes at the moment is SPBinder.



These factors contribute to the tax pro experience generally being awful for the client. A legacy toolset that pros desperately want to move past.


Any questions, or things you've wondered that you were too afraid to ask? Drop them in the comments and let's share some value.

Zach Mansell

Co-Founder & VP of Sales @ Truss

1 年

Hey Jason! Here at Truss we would love to show you the new document collection software we created for CPAs and capture your thoughts! https://calendly.com/gettruss/demo?month=2023-06 Gettruss.io

回复
Danny Severns

CFO, Controller, IT and Software Development Services and Solutions

1 年

Since comments are limited in size, I had to cut short my first comment. To really make this type of app evolutionary, I think it would need to include Natural Language Processing and AI. It could be designed to be really spiffy, very automated, very proactive, with minimum input from the client. I think a lot could be done to simplify integration with other apps, provided the other apps' db schemas are available. A real pet peeve of mine is the fact that so many software products keep their db tables and schemas closed and inaccessible unless you pay licenses for each of the company's user count for a report writing or data access module, and even then you may only be able to get data in or out via their import/export utilities as opposed to directly querying the db to facilitate custom reporting and integration with other apps. My point being that just how much can be done to simplify and enhance integration may be limited. Some discovery would have to be done in that area.

回复
Danny Severns

CFO, Controller, IT and Software Development Services and Solutions

1 年

Jason this is a big problem as you so masterfully described. Do you have a solution in mind or are you suggesting it is unsolvable because of the wide diversity of tax scenarios presented by tax clients? As a past CPA and also long time developer, off-hand, I could see a multi-part form corresponding to each of the return schedules, one general info applicable to all clients, and a specific form for each type of applicable schedule, A, B, E, Sch C, i.e. rental, farming & ranching, oil & gas, retail/wholesale biz, etc. I would save all that data into a common database that could be used for a number of purposes, including provided to clients as a service. Again off-hand, I don't see any practical way to access prior tax year data if the return(s) were prepared by someone else. I would think that data is in an inaccessible data silo of the tax software. But not having explored this specific problem domain, this is just speculation and supposition on my part. One can see that the annual maintenance for such an app would be very similar, although not as complex, to maintaining tax return preparation software for the changes to tax law and official forms. Probably why only legacy solutions are available.

回复
Scott Orn, CFA

Startup Accounting & Taxes at Kruze Consulting

1 年

Great post. Keep up the digging. Thank you on behalf of the community. ??

回复
Sean McLean, PMP

Founder | Fractional CIO | AI | Digital Transformation | Intelligent Automation

1 年

The APIs for most Tax systems are also problematic and the vendors don't employ redundant teams to support developer builds. They know the barrier of entry into the Tax Software game is so high that they don't have much to compete with nor move innovation at high velocity. Having modern integration points will definitely open more 3rd party apps to the party, but time will tell. Great article!

要查看或添加评论,请登录

Jason Staats的更多文章

社区洞察