ERP selection criteria: a scorecard for European finance teams

Good ERP selection criteria work in two stages. First, a short list of knock-outs that any system must pass in Germany: EU data hosting, GoBD-compliant records, a working DATEV connection, e-invoices in and out, and HGB with SKR04. Then a weighted scorecard for the vendors that pass, scored on your own data and processes, not on a demo tenant.

Most ERP selections fail in the second stage because they never ran the first. Teams compare feature lists and demo impressions across systems that could not have passed a German tax audit. Fixing the order saves weeks, and it makes the remaining comparison honest.

---

Why do feature lists make poor ERP selection criteria?

Every vendor answers "yes" to "supports multi-entity", "has workflows" and "offers AI". The answer tells you nothing about the work your team will still do. A system can support consolidation in the sense that it holds several companies, while someone still exports trial balances to a spreadsheet to eliminate intercompany balances each month.

The better question is always a demonstration: show us, with our data, how this specific task is done, and who does what. That turns criteria into evidence. It also exposes the workarounds that make an ERP heavy over time, which we describe in ERP complexity debt.

Before scoring anything, agree internally what problem the ERP must solve. If the honest answer is "our accounting tool cannot handle entities, inventory and approvals any more", read outgrowing your accounting software first. If it is "our tax advisor needs cleaner data", the scope may be smaller than a full ERP.

Which criteria are knock-outs for a German company?

These are pass or fail. A system that fails one does not get scored.

Data hosting and GDPR. Where is the data stored, and where is it processed, including backups, support access and any AI model calls? You need a data processing agreement under Art. 28 GDPR and a list of subprocessors. If any processing happens outside the EU, ask for the legal basis in writing.

GoBD-compliant records. The German bookkeeping rules (GoBD) require bookings that cannot be changed without trace, a complete audit trail, and documents stored in their original format. Ask the vendor to show a corrected booking and its history. Ask how the system supports your process documentation (Verfahrensdokumentation).

Data access for the tax auditor. Under § 147 (6) of the German Fiscal Code (AO), the tax auditor can inspect the data in your system or ask for it in a machine-readable format. Ask to see the export. Ask how long data stays accessible: booking documents must be kept for eight years, books and annual accounts for ten.

DATEV. Your tax advisor (Steuerberater) almost certainly works in DATEV. Ask how bookings, documents and master data get there, how often, and what happens when the tax advisor makes a correction. A one-way export the advisor has to rework every month is not a working connection.

E-invoicing. Receiving structured e-invoices is mandatory in Germany since January 2025, and sending follows in 2027 and 2028 depending on turnover. The system must read and create XRechnung and ZUGFeRD, not only store them. The dates are in e-invoicing in Germany.

HGB, SKR04 and VAT. Financial statements under the German Commercial Code (HGB), the standard chart of accounts your tax advisor expects (usually SKR04 or SKR03), and preparation of the advance VAT return (UStVA). If you report under IFRS for investors, both views must come from the same bookings.

Exit. How do you get all your data out, in which format, at what cost, if you leave? A vendor that hesitates here has answered the question.

How do you score the vendors that pass?

Weight six areas. The weights below are a starting point; adjust them before the first demo, not after.

1. Process fit (25 percent). Run your three most painful processes end to end: perhaps supplier invoice to payment, order to cash, and month-end close. Score how much manual work remains, not how many screens exist.
2. One data model (15 percent). Are finance, inventory, purchasing and payroll in the same data, or connected by synchronisation? Ask what happens when a sync fails.
3. AI on your own data (15 percent). Covered in the next section.
4. Implementation (20 percent). Elapsed time to first live module, who does the work, and how many of your people for how many hours.
5. Total cost over five years (15 percent). Licences, implementation, integrations, internal time, and the cost of each additional entity or user.
6. Partner quality (10 percent). Who answers when the close stalls on day two? Ask for a reference customer of similar size in Germany and call them.

Score each area from one to five, with a written reason. A score without a reason will be argued about later.

How do you test the AI before you sign?

Every ERP vendor now claims AI. The useful distinction, explained in what is an AI-native ERP, is whether the AI works on the ledger itself or sits on top of it as a chat window.

Test it on your data. Give each shortlisted vendor three months of real bank transactions and supplier invoices and ask them to show:

• How many transactions are matched or categorised correctly without help, and how the error rate falls after corrections.
• What a suggestion looks like: is there a confidence score, and can you see why the system proposed it?
• Who approves, and whether anything is ever booked without approval.
• Where every AI action is logged, and whether the log would satisfy an auditor.

A vendor that can only demonstrate on a prepared demo tenant is asking you to buy the demo.

What should you ask about implementation and migration?

Implementation is where ERP projects lose a year. Ask for the plan in weeks, module by module, and ask what you can run in parallel with your current system before you switch. Ask who maps your chart of accounts, who loads opening balances and open items, and how your DATEV history stays accessible. The details are in ERP migration and cutover.

Be realistic about your own side. The finance lead who knows where every workaround lives is also the person closing the month. Ask the vendor how many hours per week they need from that person, in which weeks, and what happens if the close and the project collide. A plan that assumes your team has spare time is not a plan. Agree the first live module and its go-live criteria before signing.

Ask one more thing: when does the subscription start? If payment starts on signature and value starts in month nine, the risk sits with you.

How does Agent F answer these criteria?

Agent F is built with these knock-outs in mind. Data is hosted in Germany, encrypted with AES-256 and backed up daily. Bookings follow HGB and GoBD on SKR04 by default, and IFRS is supported on the same data model. Every change sits in an immutable audit trail. XRechnung e-invoices are received and sent, the UStVA is prepared from the bookings, and DATEV is a standard integration, so your tax advisor keeps working in the tools they already use. ISO 27001 certification and EU AI Act readiness are in progress. Ask about the current status, and ask the same of every vendor on your list.

On the scorecard, the difference is how we prove it. The ERP Factory configures Agent F to your company rather than a template, and the demo is built from your own data. Every AI suggestion carries a confidence score and waits for a person's approval. Implementation typically takes 4 to 10 weeks rather than the 12 to 18 months common with legacy ERP, and a free onboarding period, typically three months, runs in parallel with your current setup. The subscription starts when the system is stable.

To move forward, write down your knock-outs and weights this week, choose the three processes you will test, and prepare three months of anonymised bank and invoice data. Then ask every vendor on your list for the same test.

Learn how Agent F works, or see it on your own data at agent-f.ai/demo.