Somewhere in the first three meetings about artificial intelligence, a firm gets told that the data has to be centralised first. Everything into one repository. One schema, one warehouse, one source of truth. Then, once that is done, the useful work can begin.

It is a reasonable sounding sequence, and it is usually the most expensive way to start.

What the pitch is actually proposing

Two arrangements that answer the same question, and differ in what has to exist first.
Two arrangements that answer the same question, and differ in what has to exist first.

Consolidation means copying. The engagement files, the practice management records, the document store, the accounting platform, the shared drive that nobody will admit is still load-bearing. Each one gets read, reshaped into a common form, and written somewhere new.

That copy has three properties worth thinking about before anyone signs.

It costs money in proportion to how messy the sources are, which is to say a lot. The reshaping work is where the budget goes, and the mess is only fully visible once the work is underway.

It goes stale immediately. A copy is accurate at the moment it is made. Keeping it accurate means building and maintaining synchronisation for every source, forever. That is a running cost that arrives after the project is declared finished.

It doubles what you have to protect. The client data now lives in the original system and in the new one. Both need access controls, both need monitoring, both appear on the subprocessor list you hand a client during a security review. Permissions are the hard part: the original systems already know who may see what, and the copy has to be taught all of it again, correctly, or it becomes a way for people to read things they could not open directly.

The goal that actually gets asked for

Notice what the firm wanted. Somebody wanted to ask a question and get an answer that accounts for everything the firm knows. "What did we agree with this client about their inventory method last year?" "Has anyone here handled a multi-state filing for a business like this?" "Where did the prior year workpapers for this engagement end up?"

That is a request for one place to ask. It gets read as a request for one place to store, and those are different problems with very different price tags.

One place to ask can be built over systems that stay exactly where they are. The question arrives, the system works out which sources could answer it, retrieves the relevant material from each, and assembles a response that cites where every part came from. Nothing was copied. The original systems remain the only copy, keep their own permissions, and continue to be maintained by whoever maintains them now.

Why this is cheaper in a way that compounds

The consolidation approach front-loads all of the cost and defers all of the value. Months of work happen before anyone asks a single question, and the first question is often the one that reveals a source was reshaped wrongly.

Reaching systems where they are inverts that. One source can be connected, tested against real questions, and judged before the second one is touched. If the third source turns out to add nothing, it never gets connected, and the money that would have gone into reshaping it is still in the account.

There is a quieter benefit. When the answer cites its source, a reviewer can open the original and check. An answer assembled from a warehouse cites a row in the warehouse, and verifying it means trusting that the copy was made faithfully.

When centralising is the right answer

There are real cases, and a firm should recognise them rather than reject the idea on principle.

When the source system is being retired. Data from a platform you are leaving has to go somewhere, and that somewhere is a consolidation project whatever else you call it.

When the questions are analytical rather than specific. Reporting across every engagement for trends, margins, utilisation or realisation genuinely wants the numbers in one shape. That is a reporting warehouse, it is a well understood thing to build, and it is a much narrower project than centralising everything.

When a source cannot be reached at all. Some systems have no interface worth the name. If the only way in is an export, the export is the answer.

The distinction is that each of these starts from a specific question that centralising answers. The pitch to centralise first starts from the assumption that all questions need it.

What to ask when you hear the pitch

Three questions, and they are fair to ask of anyone, including us.

Which specific questions does the firm want answered? If nobody can name three, the project has no way to tell success from completion.

For each one, which systems hold the answer, and can they be reached where they sit? Most modern practice systems can. A vendor who has not checked is proposing a shape before understanding the problem.

What is the smallest version of this that would prove the approach? If the answer involves a year and a warehouse before anything is demonstrable, that is worth knowing before the budget is committed rather than after.

A firm that asks those three questions will sometimes still decide to centralise, and it will be doing it for a reason it can explain to its partners. That is a different position from being told it is the necessary first step.