1. Cloud or on-premise?
Cloud means you work in the browser with no install. On-premise runs on your own servers,
where your firm handles the updates and backups itself. For most small and mid-sized firms
cloud is more practical: no installer, no version number to track, no licence server that
goes down after a bad update.
The choice is not a free pass. Ask whether the package runs in a plain browser without
plug-ins, and who is responsible for the updates. The wider trade-off is in the homepage
section on the EU and privacy setup.
2. Does the client data stay in the EU? (GDPR and data residency)
"In the cloud" says nothing about where the data sits. It is an architecture, not a
location promise. A tool can be fully browser-based and still route your client data
through servers outside the EU. For an accounting firm that matters: you work with tax
numbers, salary data, and company details of clients.
Ask each vendor three things: which region the hosting sits in, where any AI inference
runs, and who the sub-processors are. Record it in a data processing agreement (Article 28
GDPR). On top of the GDPR, advisors often carry a professional or contractual duty of
confidentiality. More on this on how we handle data.
3. Which tax types does the package cover?
A broad filing suite usually covers the bulk: VAT, income tax, corporate income tax,
payroll taxes, and often dividend tax, with the related reporting. Work out which types
you actually need and how often you file them.
Watch the edges. Specific requests and analyses often sit poorly in a suite, or not at
all: the 30% ruling application with its cover letter, the fiscal unity CIT request, or an
ATAD2 hybrid-mismatch analysis. That is where you add a focused tool to a suite. The three
software types sit side by side in the comparison.
4. Links to your bookkeeping and to RGS
The step that costs the most manual work is turning the general ledger into the return.
Ask whether the package reads your bookkeeping data and whether it works with the Dutch
Reference Classification System of Financial Information (RGS). RGS is the standardised chart of
accounts that translates a trial balance or annual accounts into a filing file.
Concretely: can the package import or export an RGS bridge file, and in which format?
Nextens reads a .rgs file, AFAS an
.xml file. A package that does not connect here forces you
to retype figures, with the errors that brings.
5. Automation and AI add-ons
More packages now offer AI features. The question is not whether there is AI, but what it
actually does. A model that reads a messy upload so you do not retype it is useful. A model
that decides the figures or the tax qualification itself is a risk: the output is then not
deterministic and hard to check.
So ask: does the AI set the amounts, or only read along? And where does the inference run?
For the calculations you want fixed rules that give the same result every time, not a
generative answer that can differ tomorrow.
6. Price per return or a fixed licence?
Two pricing models are common: a fixed licence (per user or per firm, often per year) or
paying per return. For the full breadth at high volume a fixed licence usually pays off.
For procedures you run only a few times a month, paying per item is often cheaper and
easier to manage.
Work it out on your real number of returns per type. A fixed licence for a procedure you
run eight times a year is rarely the cheapest choice.
7. Security and continuity
Ask about encryption of data in transit and at rest, about the backup policy, and about
how long your documents are kept. Just as important: what happens if the vendor stops? Can
you export your data, and in which format?
A tool that does not keep client data longer than needed limits your risk. At Lowkey,
uploads are processed in memory and then discarded; one billing line remains, never the
contents of the documents.