Accounting practice software: how customisable is it really?

When the partner of an accounting practice writes “I want practice management software with a high level of customisation”, they almost always mean something specific: being able to add their own fields, their own logic, and above all being able to get their own data out to use it elsewhere.

When a salesperson answers “of course, it is fully customisable”, they almost always mean something else: that modules can be switched on, columns moved, report layouts changed, and a workflow defined by picking from the ones the manufacturer has already built.

These are two incompatible meanings of the same word, and the distance between them is why a fair number of practices discover eighteen months after purchase that the new system does exactly what the old one did, just with a more modern screen.

This article is not about choosing between off-the-shelf software and a bespoke build: that is a different decision, and we covered it in accounting firms: custom software or off-the-shelf management tool. Here we assume the off-the-shelf product exists or is about to be bought, and answer one question only: how far can it be pushed, and how do you verify that before signing.

TL;DR

• Configurable means changing the software’s behaviour using the levers the manufacturer anticipated. Extensible means adding behaviours the manufacturer did not anticipate. Almost all Italian practice management products are highly configurable and barely extensible.
• There are four levels of customisation, and they need to be asked about separately during negotiation: configuration, own fields, internal automation, external data access. The fourth matters most and is the one nobody demos.
• The recurring pattern in the Italian market: publicly documented APIs exist mainly on satellite products (e-invoicing, archiving, digital signature, document hubs) and much less on the core practice management system. Verified against public documentation as of 15 August 2026.
• When there is no API on the core, a hierarchy of extraction strategies still exists, and they are not equivalent: scheduled export, integration via a satellite product, interface automation, direct database access. The last two have contractual and data protection implications that need looking at up front, not afterwards.
• The five questions to ask in a demo are further down this article. They cost ten minutes and change the outcome of a 30,000 euro negotiation.

The four levels of customisation

The confusion dissolves once you separate four things that arrive bundled together in a sales conversation under “yes, it can be customised”.

Level 1: configuration

Switching modules on and off, defining transaction types, setting tax rates, choosing the chart of accounts, customising a document layout, deciding who sees what.

This is what every product does, and it is also what almost no practice actually exploits: our impression, from the projects we have worked on, is that an average practice uses between 30% and 40% of the functionality it has already paid for. Before considering any customisation, it is worth asking whether the problem is simply that level 1 was never configured properly. It costs a day of training and sometimes closes the question.

Level 2: your own fields and data

Adding information the manufacturer did not anticipate: a “internal contact” field on the client record, a risk classification specific to the practice, a deadline for an obligation that does not exist in the product.

This is where products start to differ. Some offer a limited number of free-form fields, often untyped (everything is text), often not searchable and almost never exportable alongside the rest. The right question is not “can I add a field”, which is almost always yes. It is: can I search, filter, report on and export that field? If the answer is no, the field exists but does not help.

Level 3: internal automation

Making something happen automatically: if a job goes past fifteen days, email the manager. If the client has not delivered documents by the 10th, put them on a list.

This is where the gap between products is widest. Some have a configurable rules engine, some have fixed automations that cannot be modified, some have nothing and the answer is “the accountant does it when they notice”.

Level 4: external data access

Being able to read and write the system’s data from a program that is not the system. This is the level that makes a client portal possible, or a dashboard combining practice data with tax data, or an agent that tells clients where their job stands, or a flow that reconciles automatically.

It is the level that determines everything else, and the one a demo almost never shows, because it has no screen. A practice with level 4 can build anything on top, including in five years, including with a different supplier. A practice without it is tied to whatever the manufacturer decides to develop.

Where Italian products actually stop

A methodological caveat is needed here, because this is the point where most content in circulation says things that cannot be verified.

Absence of public documentation does not mean absence of an API. In Italian professional practice software, much of the technical documentation is reserved for partners and accessible after an agreement. So the only statement we can make with certainty concerns what is publicly documented, not what exists.

That said, the pattern that emerges from the public documentation of the main Italian manufacturers as of 15 August 2026 is consistent and worth knowing:

Well-documented public APIs sit on the satellite products. E-invoicing, document exchange hubs, compliant archiving, digital signature, document collection portals. TeamSystem publishes a developer portal with an API catalogue and key subscription, and the most complete and openly accessible documentation in the group is that of Fatture in Cloud, which also has published terms of use. Zucchetti publicly documents APIs on its IT services and on the Digital Hub, including an explicit section on integrating with the Digital Hub without owning a Zucchetti product.

On the core practice management system public documentation is far thinner. Bookkeeping, tax filings, practice records, billing: the part where the valuable data lives, and the part least exposed.

This is not a conspiracy, it has a mundane industrial explanation: satellite products are recent, built as services, and live off integrations with third-party software, so the API is the product. The core has twenty years or more of accumulated layers, and opening it means guaranteeing the stability of a technical contract over a codebase that changes.

The practical consequence for a practice: the question “does this product have APIs?” almost always gets a yes, and almost always that yes is about the satellite product rather than the thing you need. The question has to be asked about the specific data.

The five questions to ask in a demo

This is the part to print and take with you. Five questions, ten minutes, that no salesperson can deflect with “sure, it is customisable”, and whose answers completely change the economics of a contract.

1. “Show me right now how I extract the client list with their custom fields, in a format another program can read.” Not “can it be exported”. Watch it happen. If it needs a support ticket, or the format is a PDF, or the custom fields are not in the export, you have your answer on level 2 and level 4 in one go.

2. “Can the extraction be scheduled, or does someone have to run it by hand every time?” A manual export is usable once, for a migration. It supports no integration that has to run every day without someone remembering.

3. “Is there documented API coverage on the module I care about, and can I see the documentation before signing?” Documentation before signing is the real test. If the answer is that you see it afterwards, or only as a partner, then in substance you are buying a promise. That can be accepted, provided the contract says what happens if the promise is not kept.

4. “If I wanted to change product tomorrow, in what format do I take my history with me?” The question everyone avoids and the one that tells the truth about lock-in. It has a second useful effect: the answer describes exactly the integration path available today, because the channel you leave through is the channel you read through.

5. “What does data access cost?” On several products the API is not included in the licence: it is a separate module with its own subscription, sometimes tied to call volume. Discovering that afterwards turns a budgeted integration project into one that does not happen.

When there is no API: the hierarchy of alternatives

It happens, and it is the most common situation in practices with a long-standing product. Options exist, they are not equivalent, and they should be considered in this order.

1. Scheduled export. The system produces a readable file at fixed times into a folder, and a program reads it from there. It is the least elegant path and the most solid: it does not touch the system, violates nothing, and does not break when the manufacturer ships an update. The limits are that it is one-way and not real time. For 80% of the real use cases in a practice (a portal showing job status, a summary dashboard, an agent answering on data that changes once a day) it is more than enough.

2. Integration via the satellite product. If the data you need also passes through the e-invoicing hub or the document system, and that has a public API, you can read it there instead of in the core. It is a route many people do not consider and it often solves the problem.

3. Interface automation. A program that drives the system the way a person would, clicking and reading screens. Technically feasible, and it is worth being clear about what it involves: many licence agreements prohibit automated access to the interface, and an update that moves a button breaks the automation without warning. This is a route to consider only with the contract in hand and with the understanding that maintenance is recurring.

4. Direct database access. Technically the most powerful and the most delicate. Almost always prohibited by licence terms, and with a data protection profile that should not be underestimated: the practice’s client data is personal data the practice answers for, and opening a read channel outside the manufacturer’s intended paths is a choice that has to be documented, assessed and in many cases avoided. If you get there, you get there with the manufacturer’s written consent, not quietly.

The rule we apply: you move up the hierarchy only when the previous level has been ruled out for a demonstrated technical reason, not for convenience. Nine times out of ten you stop at the first two, and projects that start straight at the fourth are the ones that are unmaintainable within two years.

Mistakes we see practices make

1. Asking “is it customisable” instead of “how do I extract the data”. The first question always gets a positive answer that carries no information. The second gets a verifiable one.

2. Assessing extensibility after choosing the product. That is the moment you have no negotiating power left. The cost of data access has to be discussed while the decision is still open, because it is the only moment you can get it included.

3. Building the integration on the wrong channel out of impatience. A link built on interface automation because “the API is coming in six months” becomes permanent, and has to be maintained for years. If the API is coming in six months, waiting six months costs less.

4. Customising to preserve a habit. A good number of customisation requests are really requests to keep working the way people worked before. For each one it is worth asking whether the current process is an advantage of the practice or just its history.

5. Forgetting who maintains it. Every customisation and every integration is living code that breaks on updates and needs someone to answer for it. A practice without a stable technical contact, internal or external, should deliberately stay at levels 1 and 2, and that is a legitimate choice.

FAQ

Which practice management product is the most customisable?

There is no answer valid in the abstract, and anyone who gives you one is selling something. There is an answer valid for your case, and you get it by asking the five questions above of the two or three products on your shortlist, about the specific module you need. The criterion that separates apparently similar Italian products most sharply is the accessibility of the data from outside, more than the quantity of features, and on that the difference can be enormous.

My product has APIs. Is that enough?

It depends on three things that need checking one by one: whether the API covers the data you need or only a subset; whether it is read-only or also write; and whether it carries a cost separate from the licence. An API exposing only client records when what you need is filing status is an API that exists and does not solve anything.

What does it cost to integrate practice software with an external system?

Almost entirely on the available channel. With a documented API on the right data, a one-way integration into a portal or dashboard is a project of a few weeks. With a scheduled export it is similar, plus a few days to handle reconciliation. With interface automation the initial cost is comparable but the maintenance cost is recurring and not trivial, and has to be budgeted in years rather than months. The cost jump sits in the fragility of the channel, not in technical difficulty.

Can I add an AI agent on top of the product I already have?

Yes, and the constraint is not the AI: once again it is data access. An agent that answers questions about job status needs to read those jobs, and the whole difficulty of the project sits there. If a reliable scheduled export exists, the project is feasible without touching the system at all. We wrote up the general method in integrating an LLM with an existing ERP.

Is it better to change product or add another one alongside?

In most practices we see, alongside. The bookkeeping and filing core is where Italian products are strong and where rebuilding makes no economic sense. The parts that are almost always missing (client portal, summary views, the practice’s own automations) are also the ones easiest to build next to it. The necessary condition remains one: level 4.

If I am already reviewing the renewal, where do I start?

From an inventory of what leaves the system by hand today. Every spreadsheet someone in the practice fills in by copying from a screen is a precise description of a missing integration, and also a free estimate of its value: just count the hours.

The fourth one, the one you cannot see in a demo

In the Italian professional practice software market, the word “customisable” covers four different things, and almost everyone has the first three. The fourth, being able to reach your own data from outside, is what decides whether in three years the practice will build what it needs or wait for the manufacturer to build it.

It is also the only one you cannot see in a demo, which is why it has to be asked about explicitly, with concrete examples, while you still have negotiating power. Ten minutes of the right questions during a negotiation is worth more than any feature comparison table.

If you are evaluating a renewal or want to understand what can be built on top of what you already have, let’s talk. Half a day is enough to establish which of the four levels you actually have and which projects are possible without changing anything.

For more: the professional services page, the custom software versus off-the-shelf decision if the question is still upstream, and the AI integration into an existing ERP page for the delivery side.

Note on sources: the observations about manufacturers’ public documentation refer to what was publicly accessible on 15 August 2026 on the developer portals of TeamSystem, Fatture in Cloud and Zucchetti. Partner-only documentation cannot be verified from outside, so the absence of public documentation on a module should not be read as absence of an API: it should be read as a question to put to the manufacturer.