Finance Tech Stack by Stage: When ERP Pays Off

There is a lot of DACH content on which ERP. Almost all of it comes from ERP vendors or implementation partners. There is very little vendor-neutral content on when. From practice I see this pattern repeatedly: Series A, the board says "get off the cloud bookkeeping", someone recommends a known ERP, the contract gets signed before anyone has absorbed what a six- to twelve-month rollout means for a three-person finance team. Eighteen months and EUR 200,000 later the system runs in parts, and the actual reporting has not improved. This article covers which operational triggers justify an ERP, why business model matters more than headcount, and which components beyond the ERP often deliver the bigger leverage.

Why most startups implement ERP too early

Four recurring triggers sit behind premature ERP decisions. First: a new investor writes "Implementation of an ERP system within 12 months" into the term sheet, and no one checks whether that makes operational sense or is just boilerplate. Second: the first full-time CFO comes from a corporate background, is used to large ERP environments and reaches for the familiar tool. Third: bookkeeping runs in a cloud solution, reporting in Excel, growth creates the first friction points, and someone says an ERP would "bring it all together". Fourth: a sales rep from an ERP vendor drops a ten-page proposal in the inbox, and suddenly there is a concrete trigger for a decision no one prepared structurally.

The problem is the asymmetry between effort and maturity. An ERP rollout in a startup with thirty employees ties up five- to six-figure implementation costs depending on the system, six to eighteen months of internal bandwidth and a multi-year licence contract. If the business model still shifts after that, and it almost always does at that stage, those investments become sunk cost with lock-in. Industry analyses point to a consistent picture: around 60 to 70 percent of ERP projects exceed their initial budget, and roughly half fail to fully reach the original business case goals. The root causes lie less in the product than in premature selection, insufficient preparation and unclear ownership. The clean sequence is the inverse: stabilise the business model first, standardise the processes second, choose the tooling third.

Business model over headcount: when an ERP is actually needed

Most phase models for finance tooling rely on headcount thresholds ("from 50 employees", "from 100 employees"). That is a simplification that does not hold up in practice. A 25-person hardware startup with warehouse, BOM and manufacturing has more ERP need than an 80-person SaaS company with two contracts a month. The defensible question is: which core processes does the tooling have to map?

Headcount correlates with complexity but is not a reliable trigger. Hardware startups often need an ERP at 15 to 25 employees because BOMs and procurement logic cannot be cleanly mapped in any cloud bookkeeping. SaaS companies, in contrast, can run at 100 employees without an ERP as long as subscription billing, bookkeeping and BI are cleanly integrated. The question "which stack fits" starts with the business model, not with the headcount.

The operational symptoms that justify an ERP step

Instead of headcount or funding stage, a symptom check helps. If three or more of the following points apply, the discussion about an integrated system is functionally justified:

• Month-end close regularly takes more than fifteen working days, without that being explained by personnel changes or one-off effects.
• Multi-entity consolidation lives in a single spreadsheet that only one person understands and that becomes a bottleneck during illness or resignation.
• Multi-currency bookkeeping is maintained manually, with FX rate updates via copy-paste and no automated valuation at the balance sheet date.
• Inventory with more than 100 SKUs or multiple locations is run on Excel or pure order-management software, without integrated stock valuation.
• BOM or production planning is relevant but lives outside the bookkeeping flow, with manual transfers into the GL.
• Project P&L for more than fifteen parallel projects is maintained in spreadsheets, with retroactive cost allocation to projects. The accounting mechanics behind this — WIP build-up and release under HGB — are explained in Work in Progress in Project Businesses.
• Audit or statutory review demands controls that the current setup does not systematically support (segregation of duties, approval workflows, document trails).
• Investor reporting at group level generates manual aggregation every month that costs hours rather than minutes.

Companies with none or only one of these symptoms typically do not need an ERP. With three or more, the step should be prepared structurally. With fewer than three but already under vendor pressure, waiting twelve months and checking whether the symptoms can be solved through process standardisation or targeted best-of-breed tools is usually the better answer.

What matters in the stack besides the ERP: usually the bigger lever

An ERP is rarely the bottleneck in the finance tech stack. The following components are more often decisive for the quality of the finance function:

In the early stage (pre-seed to Series A) cash management is often the first component added after bookkeeping. Anyone operating with twelve to eighteen months of runway needs a reliable liquidity model with bank balance, fixed and variable cash outflows and realistic revenue assumptions. In most cases a well-maintained spreadsheet updated weekly is enough at the start. As complexity grows (multi-account, multi-currency, multiple entities), moving to a dedicated cash forecasting tool that pulls banking and bookkeeping data automatically pays off.

Targeted investments in cash management, a BI tool, FP&A and spend management deliver more operational leverage in most Series A to Series B phases than a premature ERP rollout. Prerequisite: bookkeeping is cleanly digitised, interfaces work, data is reliable. Those who reverse the sequence and start with the ERP often build the very structures they wanted to avoid: an integrated system without integrated reporting.

The DATEV question as a DACH gating criterion

In the DACH market the DATEV interface question decides whether an ERP works at all. DATEV dominates the German tax advisor market. Anyone who has a tax advisor typically also has DATEV in the data flow. Anyone introducing an ERP has to think about that connection from day one, otherwise either duplicate work emerges or a tax advisor switch becomes necessary.

An important clarification: DATEV is not an ERP, it is a dominant bookkeeping and tax platform with a complementary tool marketplace. Classic ERP systems include bookkeeping as a module and add operational processes such as procurement, inventory, production and sales around it. The right architecture is co-existence rather than replacement: the ERP becomes the operational backbone, DATEV remains the bookkeeping layer and the interface to the tax advisor. Posting data flows from the ERP into DATEV, the tax advisor continues to work in their familiar environment.

Concretely for ERP selection: a certified DATEV interface is a mandatory criterion, not a nice-to-have. ERP solutions without native integration produce either third-party connector modules with maintenance overhead and security risks, or a full tax advisor switch. Both are more expensive than the supposed price premium of a DATEV-capable ERP.

GoBD compliance as the second DACH gating criterion

Beyond the DATEV interface, there is a second binding DACH requirement for any ERP: GoBD compliance. The GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung, broadly: principles for proper electronic bookkeeping) were last updated by the German Federal Ministry of Finance in July 2025, triggered by the mandatory e-invoice requirement for B2B transactions in Germany since January 2025. They define how IT-supported bookkeeping has to look in Germany. Unlike the DATEV interface, GoBD compliance is not negotiable: violations can lead to rejection of the books or to tax estimations during a tax audit.

Six core requirements have to be met: traceability of every posting with document evidence, completeness of all transactions, accuracy of capture, timeliness of posting, order of filing and immutability of posted entries once recorded. On top of that comes a duty to maintain a Verfahrensdokumentation (process documentation describing how the bookkeeping processes are organised in the company) and an internal control system intended to prevent and document mis-postings.

Consequence for ERP selection: international systems without explicit GoBD compliance are a compliance risk in the DACH market, not just a comfort gap. Implementing a non-compliant system means accepting the risk that a tax audit objects to the data or structures. In vendor conversations the proof of GoBD compliance should be requested and contractually anchored, ideally with a commitment to adapt the system to future BMF updates. The Verfahrensdokumentation belongs in the implementation project, not in a last-minute exercise before an audit.

The phase model as a secondary anchor

Once the business model fits and the operational symptoms apply, the classic phase model serves as orientation for the tooling class. Headcount ranges are rough guides, not thresholds.

Phase 1: cloud bookkeeping (typically 1 to 30 employees)

Setup: a cloud bookkeeping solution combined with the tax advisor. Reporting in Excel or Google Sheets, complemented by a BI tool once data flows from multiple sources. Banking integration via the bookkeeping software or direct API. This phase covers the needs of nearly all DACH SaaS startups up to Series A. Hardware and project businesses tend to leave this phase earlier.

Phase 2: light ERP (typically 30 to 80 employees)

Setup: a light ERP with cloud architecture and an API-first design. These systems cover order management, basic warehouse, simple production and interfaces to bookkeeping, without the complexity of classic enterprise ERPs. They suit e-commerce, hardware startups, smaller B2B sales organisations and project businesses of moderate complexity. Bookkeeping continues in DATEV or a cloud solution alongside. Implementation typically three to six months, EUR 30,000 to 150,000.

Phase 3: mid-market ERP (typically 80 to 250 employees)

Setup: a mid-market ERP with a DATEV interface and room for adaptation. These systems cover financial accounting, fixed assets, consolidation of smaller subsidiaries, project accounting, advanced inventory and multi-currency. Implementation typically six to twelve months, costs EUR 200,000 to 800,000 plus ongoing licences. This is where the move away from cloud bookkeeping into an integrated system pays off for the first time. Prerequisites: stable processes, clear requirements, dedicated internal resources for the implementation.

Phase 4: enterprise ERP (typically 250+ employees)

Setup: an enterprise ERP from one of the major vendors. These systems are built for complex group structures, international organisations, multiple business units and regulatory-heavy industries. Implementation one to three years, costs often in the millions. In the startup context this phase is almost always driven by an acquisition, an IPO or a major strategic investor. Anyone planning an enterprise ERP without those triggers is most likely buying a tool they do not need.

What an ERP actually costs: the underestimated items

Licence costs are rarely the main issue with an ERP in the DACH market. Four cost blocks get underestimated regularly:

• Implementation and discovery: for mid-market ERPs typically two to three times the first-year licence fee (DACH rule of thumb: 1 EUR licence to 2.5 EUR implementation). With heavy customisation that ratio can grow to 1 to 5 or 1 to 10. Solution architecture and the discovery phase are often understated in initial proposals but make up 20 to 30 percent of the realistic total budget.
• Internal bandwidth: six to eighteen months of full-time finance team effort plus involvement from operations, IT and management. During that period the finance team loses twenty to thirty percent of its capacity for strategic work. None of this shows up in vendor proposals.
• Integration tax: every existing tool (banking, HRIS, BI, spend, time tracking) needs an interface to the ERP. Per integration, EUR 5,000 to 30,000 plus ongoing maintenance. Companies with five to ten tools rapidly accumulate six-figure totals here.
• Scope creep: the most common driver of budget and timeline overruns. "One additional report here, one extra workflow there" and the project grows by thirty to fifty percent against the original quote. Industry studies identify scope creep as the main reason that around two-thirds of ERP projects are classified as troubled.

On top of that come migration losses during the rollout (reporting quality typically drops for three to six months) and lock-in via the contract minimum term. A premature decision compounds for five to ten years, because data, customisations and trained users are hard to unwind once the system is in place. In realistic terms, licence fees over five to seven years account for only about 20 to 35 percent of total cost of ownership. The remainder goes to implementation, internal effort, training, customisation, integrations, hosting and maintenance. In aggregate, the seven-year TCO often runs at three to four times the initial vendor proposal.

Lock-in mechanics: what determines stack flexibility long term

An ERP decision binds the company for typically five to ten years. Over that horizon, the structural properties of the system, not the features highlighted in the sales pitch, determine stack flexibility and total cost of ownership. Four points that rarely become explicit in vendor conversations:

• Pricing follows revenue, not value: large ERP vendors often model their pricing not by delivered functionality but by expected customer revenue, with the implicit assumption that an industry of a certain size has a certain share of IT budget. Negotiations are possible but rarely fall below the vendor's "market share" of the customer's IT spend. Consequence for the stack: licence costs scale with revenue and headcount, not with utility.
• API-first as a non-negotiable criterion: an ERP without an open, documented and stable API is no longer an option. APIs are the foundation for automation, integration with the rest of the stack and AI-driven workflows. Closed systems build lock-in that becomes more expensive after three to five years than the original implementation. Compromising here also closes the door on future stack components that do not yet exist.
• Configuration vs. customisation: what gets sold as "configuration" is often customisation with its own maintenance risk. Each adaptation to standard makes future updates and migrations harder. Rule of thumb: use the standard wherever possible, customise only where the competitive advantage is documented and the maintenance risk is explicitly priced in. Modifications to core code (rather than clean API extension) are a no-go because they turn future major upgrades into multi-week projects.
• Contract minimum terms and data export: three to five years minimum term is DACH standard, automatic renewal for twelve months equally common. Without active termination, you stay locked in. At contract signature, clarify the notice period and which data export options are contractually guaranteed. Data export in an open format is not a comfort feature, it is a prerequisite for stack flexibility.

These mechanics determine how open the stack will still be in five years. ERP decisions are rarely regretted because the system does not work, but because it was chosen too early or customised too heavily.

Decision framework: three conditions for the ERP step

An ERP step is justified when three conditions hold simultaneously:

• Business model stabilised. Core processes (sales motion, revenue model, supply chain, cost structure) will not be reinvented in the next two years. Companies still in pivot mode build an ERP for a business that will not exist soon.
• Operational complexity justifies the integrated system. At least three of the symptoms above apply (multi-entity, multi-currency, BOM, project P&L, long month-end close, audit requirements, investor reporting effort). Headcount alone is not enough.
• Internal owner with capacity and functional depth. One person carries the functional ownership, has the time (at least 50 percent of working hours through the implementation phase), and understands both the business and the ERP logic. Without this owner, ERP rollouts almost always fail, regardless of vendor.

If one of these conditions is missing, the startup is too early for an ERP. The clean reaction is not to push the ERP through anyway but to build the missing condition deliberately: stabilise the business model, document the symptoms, hire or assign the owner. That takes six to eighteen months and pays off more as preparation than any premature ERP rollout.

Conclusion

The most important decision in the finance tech stack is not which ERP, but when at all. Companies that work in the early stages with a clean cloud bookkeeping setup, a defensible BI layer and structured spend management almost always have more operational leverage than a startup running an ERP rollout in parallel. The jump into an ERP justifies itself when the business model is stabilised, at least three operational symptoms apply, and an internal owner with capacity is in place. Until then: tooling follows the business, not the other way round. And in DACH, one criterion sits above the rest: ERP selection without DATEV interface logic is selection without the most important filter.