ERP Implementation Consultant, Germany

Where German ERP implementations tend to slip

The issues I look for first are rarely technical. They come from how a German project is set up between a system house and a busy client team:

• The detailed specification is written by the partner and approved without anyone checking it against the original requirements, so gaps become contractual.
• The interface to the tax advisor is treated as a small item, then turns out to need real mapping work for accounts, tax keys and cost centers.
• Production master data, such as bills of materials and routings, is left to planners in their spare time and arrives late and incomplete.
• The procedure documentation describing how the system is used for bookkeeping is never updated, because nobody owns it.
• Training happens in the final week, and key users meet the system properly only on go-live day.

None of this is unusual, and none of it is the partner's fault alone. A client-side lead who reads the documents, chases decisions and keeps a written record changes the balance of the project. My general approach is described on the ERP implementation page; this page covers how it applies to companies in Germany.

Working alongside the system house

I do not compete with the implementation partner and I do not take over configuration. My role is to be a well-organized counterpart on your side. In practice that means reviewing the partner's detailed specification against your requirements before approval, joining design workshops to make sure process owners actually decide, and maintaining a decision log so choices made in a meeting are not reopened weeks later.

Change requests are where budgets in German projects most often move. Every new request goes into a log with the business reason, the partner's estimate and the impact on the timeline, and the managing director or a delegate approves, rejects or defers it. I check estimates for plausibility and ask for detail when a request looks like work the contract already covers.

Good system houses usually welcome this, because it means quicker decisions and fewer disputes at invoice time. Where the relationship is already strained, I start with a short review of open issues and agree priorities with both sides. If the project is seriously off track, the ERP recovery service is the better starting point.

Migrating from DATEV-linked, Sage and older Dynamics setups

Many German mid-sized companies arrive at a new ERP from a mixed landscape: an older Dynamics NAV or Sage installation for orders and stock, a separate invoicing tool, and a ledger kept by the Steuerberater in DATEV, with the company sending documents and receiving reports. Migration has to decide what moves, from where, and at which point in time.

I help you agree that plan with the partner and your advisor: which master data comes from the old ERP, whether opening balances come from the advisor's ledger, how open items are carried over, and how much history stays in the old system as a read-only archive. Retention obligations for old records do not end because the system changes, so the archive decision is taken with your advisor rather than by default.

Each trial load ends with a reconciliation your finance lead signs: balances by account, open receivables and payables, stock quantities and values by warehouse. Customer and supplier records are cleaned during the trials, not after go-live. Details of the method are on the ERP data migration service, and moving off ageing systems is covered under migration from legacy software.

Testing the advisor export, e-invoices and bookkeeping controls

German go-lives often stumble on details that only appear when real documents pass through the system. I build these into the test plan from the start:

• An export of a test period to the tax advisor, imported on their side and compared with the ERP, including tax keys and cost centers.
• Incoming structured e-invoices from real suppliers, in the formats they actually send, matched to orders and receipts.
• Outgoing invoices to public-sector or large customers who expect a structured format, checked with the receiving side where possible.
• Posting locks, reversals and period closing, confirming that posted entries cannot be changed silently.
• Document archiving, with each stored file traceable to its posting.

Whether the configuration meets GoBD expectations is for your tax advisor to confirm, and the scope of e-invoicing obligations for your company should come from them as well. My job is to collect the evidence they need and to make sure the procedure documentation is updated to describe the system as it was actually built. The UAT method is set out on my ERP testing and UAT service.

Go-live, payroll handoff, works council and hypercare

A sensible go-live point in Germany is chosen around the books, not around the partner's calendar. Switching at the start of a month or financial year keeps exports to the advisor clean; switching mid-period means two systems feed the same VAT return. I help you weigh that with your advisor and the partner.

Payroll usually stays outside the ERP, with the advisor or a payroll provider running it. The handoff still needs testing: how payroll journals arrive, which cost centers they hit and who checks them. Where a works council agreement covers the new system, management confirms it is in place before users work live, and I check that the role setup matches what was described to the council.

After the switch I run hypercare remotely: each morning a short call where key users and the partner go through what came up the day before, classification into training, data, configuration or process, and clear escalation. Hypercare ends after the first full month-end and a successful export to the advisor, not on a fixed date. My ERP go-live support page explains the checklist. For the decision that comes before all this, see ERP selection in Germany, and the Germany overview lists my other work there.