Choosing tax software gets argued about as a features question — forms coverage, price, how the data entry screens feel after the four hundredth return. Those things matter. They are what a demo is built to show you. But whether a season runs quietly or badly is usually settled before anyone opens the program, in where the software gets installed and what the network underneath it is asked to carry. We looked at what the major vendors actually publish about this, and the requirements are more specific than most firms realise. Below are the three shapes this software comes in, the installation restrictions that get discovered in February rather than October, and the point where the choice stops being a preference and becomes a legal obligation.
The real choice is between three deployment models, not between brands
Strip the branding away and professional tax software arrives in one of three shapes. It installs on a single machine and keeps its data there. It installs across a small network, with the returns living on a server or a shared drive and each workstation reaching across to them. Or it doesn't install at all, and the practice works through a browser while the vendor runs the whole thing somewhere else. Most products are built for one of these and tolerate a second.
The reason this matters more than the feature list is that each shape hands a different job to your building.
| Deployment | What runs on your premises | What your network carries | Who holds the returns at rest |
|---|---|---|---|
| Single workstation | The application and the data | Updates and e-filing | You |
| Local network | A server or shared drive, plus every workstation | Every file read, all day, every day of the season | You |
| Vendor hosted, in a browser | Nothing but browsers | Every keystroke of every return, live | The vendor |
The middle row is the one firms underestimate. On a local network, every screen a preparer opens is a file read across your own cabling and switches, which means the network isn't a convenience sitting next to the software. It is the software's hard drive.
The vendors publish restrictions that firms find out about in February
Drake Software's published requirements ask for 8 GB of memory at minimum and 16 GB as the recommendation, on a connection of 25 Mbps or faster [Drake Software, Drake Tax System Requirements]. Those are the numbers everyone reads. Two lines further down sit the ones that cost money, because Drake states that installing to a network-attached storage device is not supported, and that using cloud storage services such as Google Drive, OneDrive or Dropbox for the data is not supported either.
Both of those are configurations a careful small firm arrives at honestly. A network-attached storage box — a small standalone drive that plugs into the network rather than into a computer — is the obvious cheap way to give four preparers a shared folder. A synced cloud folder looks like a free offsite backup, and it is genuinely useful for documents. Neither is a supported home for a live tax database. The failure shows up as file locking errors and corrupted returns, in the weeks you can least afford them.
Thomson Reuters is equally specific about UltraTax CS. A network installation should not go on the server's own C: drive — you map a drive to the server and install there instead — and a terminal server installation belongs on that terminal server's local drive. The same vendor's requirements ask for a persistent high-speed connection and advise against wireless for a networked setup.
That last one gets argued about, usually by someone whose Wi-Fi is genuinely fine. It probably is fine, for email and web pages. A dropped packet mid-write on a shared return file is a different class of event from a page that loads twice, and it is worth knowing that mesh systems in particular struggle in exactly the buildings small practices occupy. Cable the desks that carry returns. Leave the wireless for everything else.
The Safeguards Rule turns an IT preference into a legal obligation
The Federal Trade Commission's Safeguards Rule names tax preparation firms among the financial institutions it covers, which lands oddly on people who read "financial institution" and picture a bank. Among the safeguards it requires are multi-factor authentication and the encryption of customer information both in transit and at rest.
At rest is where the deployment model and the rule meet. If the returns sit on a server in your back office, encrypting them at rest is your job and nobody else's, and a workgroup that grew one machine at a time has almost certainly never been checked for it. If they sit in the vendor's system, it is the vendor's job, and yours becomes obtaining and keeping the evidence that they do it.
There is a carve-out, and it is narrower than it sounds. Firms holding customer information on fewer than 5,000 consumers are excused from four specific paragraphs of the rule — the written risk assessment, the continuous monitoring or penetration testing requirement, the written incident response plan, and the annual report to the governing body. That covers a great many practices, and it is genuinely a lighter load. It does not touch the encryption requirement, and it does not touch multi-factor authentication. Those apply to a sole practitioner with 300 clients exactly as they apply to a firm of ninety.
What this actually changes when you're comparing packages
Read the comparison tables with the deployment question in front of the feature question, because the products genuinely differ here and the difference outlives the software. A browser-based product moves the server, the backups and the encryption at rest onto the vendor, and in exchange makes your internet connection the single thing standing between your preparers and their work. A locally installed product keeps you working through an outage, and hands you the server, the patching, the encryption and the restore testing in return. There is no version of this where nobody does the work.
Neither answer is wrong. The honest way to choose is to look at which set of obligations your practice is actually equipped to carry, which is the same question we walked through for any application a business is deciding whether to move. For a firm staying local, the unglamorous part is usually the physical layer, and we spend a fair amount of each autumn putting in the cabling that a shared return file needs to survive a busy Tuesday. For a firm going hosted, it is the connection and whatever happens when it drops.
If you'd like the install checked before the season starts
The useful reframing here is small. Tax software isn't a program you buy, it is a set of obligations you agree to take on, and the vendor's documentation tells you exactly which ones before you spend anything. Reading the system requirements page properly is twenty minutes in a quiet month, and it is the cheapest work in the whole project.
If you'd like someone to look at what your current setup is actually doing, we're glad to go through it with you. That means where the data lives, what the network is carrying, and whether the configuration is one your vendor will support when you call them in March. There is time to change it now, and it is the kind of work we do for accounting and tax firms across Miami.
Sources
Drake Tax System Requirements, Drake Software. Installation considerations and System requirements for UltraTax CS, Thomson Reuters. FTC Safeguards Rule: What Your Business Needs to Know, Federal Trade Commission. 16 CFR 314.6, the exceptions section, for the scope of the fewer-than-5,000-consumers carve-out.
