Acquired: keep your software or replace it?

First, electronic invoicing: since 1 January 2025, companies based in Germany have had to be able to receive and process e-invoices in the B2B sector, and from 2028 the obligation applies to all domestic B2B turnover. In Germany the formats mainly in use for this are ZUGFeRD and XRechnung. The details are set out under e-invoicing and in the article everything about e-invoices.

Second, accounting: in Germany the tax adviser as a rule works with DATEV. If the matching export is missing, that work does not become less, it simply moves somewhere else, every month, by hand. How the handover works in projectfacts is described on the page about the DATEV interface.

Third, working time: separate requirements apply in Germany to the recording of working time, as set out under the obligation to record working time.

As long as the discussion circles around costs and habits, it is one opinion against another. As soon as it turns to requirements that have to be met, it is no longer a matter of taste. The task is then no longer to justify why the company would like to keep its system, but to demonstrate that the target system covers the requirements. That evidence should be on the table before a switch-off date is set.

Accounting records, receivables and documents go to accounting or to the tax adviser through the DATEV interface. For Austrian companies, the BMD interface does the same job. Where a different chart of accounts applies, the export is set up accordingly.

Revenue, utilisation, project status and times go to the group's reporting at the reporting date, either through the REST API or as a report, as described under Power BI and export. The run is scheduled, so nobody has to be reminded of a monthly submission.

Sign-in runs through single sign-on with the Microsoft 365 account, see Microsoft 365. Anyone who leaves the company loses access in the place where the group administers it anyway.

If the company is going to belong to a foreign parent, foreign currency and differing rules come into play. Revenue can be converted at the rate of the document date, so that head office looks at the same figures in its own currency. What can be configured here is set out under international use.

The selection and migration project itself, running both systems in parallel during the changeover, the data transfer and the training of all employees. On top of that comes whatever has to be rebuilt in the target system because it is not provided for there. In our experience, adjustments of that kind are the single largest item.

History, documents, time series and project archives can rarely be transferred in full. What is missing does not show up on changeover day but months later, at the annual accounts, during an audit, or when someone wants to trace how a project went.

Loss of productivity during the changeover phase. Lost process maturity: processes that were honed over years start again from the beginning, including the mistakes that get made along the way a second time. And the risk that exactly those key people leave who carried those processes, in a phase in which the company is actually supposed to deliver.

… the company does not run a service business of its own but is a sales or administrative unit. If its processes resemble those of the group anyway. If the target system covers the specialist area completely, including the German requirements. And if the group bears the changeover and the costs that follow it. In that case the advantage of a uniform landscape outweighs the effort.

… the company runs a project or service business of its own. If its processes are specific and demonstrably work. If the target system brings no project, time or ticket module with it and those areas would first have to be built. Or if German requirements are not covered in the target system.

The group standardises the financial level, the company keeps the operational one. That is neither an exception nor a special arrangement, but the usual split in groups of companies with differing business models.

It wants a uniform landscape in the long run, and that is a legitimate goal. The objection is not that harmonisation would be wrong, but that on the level of the figures it has already been achieved. Harmonising at the process level costs extra and delivers little where the business is of a different kind: the processes of a project services provider cannot sensibly be aligned with those of a manufacturing operation.

A fund wants to increase value and to sell in an orderly way in a few years' time. On that reading, two points argue against a change of system. First, it ties up attention and staff in exactly the phase in which the company is supposed to deliver results. Second, a company that runs its own system independently is considerably easier to carve out on resale than one that has been woven deep into the group's IT. Independence is an advantage at exit, not a blemish.

Does your system produce and receive e-invoices in ZUGFeRD and XRechnung? Does it provide a DATEV export for our tax adviser, and if not, who takes on that work in future? Does it cover German working time recording? And who carries the responsibility if a legal requirement is not met after the changeover?

Which data does the group actually need, in which format and at which reporting date? Does the target system really cover project time recording, ticket handling and project billing, or only the accounting? Who bears the migration costs and the loss of productivity, the company or the group? What happens to history, documents and running projects? And was it checked whether a connection would be enough before the replacement was decided on?