Project Controlling in Scale-ups and PE Portfolios: KPIs Investors Expect

You are preparing a funding round, an acquisition or an investor update and you know your project reporting is not investor-ready. Or you are growing in a project-based business and losing visibility on project margin under rising volume. Both situations are the most common triggers for setting up project controlling from scratch. Most DACH content on startup and mid-market controlling is written for SaaS models (subscription revenue, MRR, ARR, net revenue retention) and does not fit project-based companies. Plant and machinery, cleantech EPC (solar, wind, battery storage, heat-pump installation), defence tech and dual-use, engineering services and systems integration: across all these models, margin and cash arise differently than in a subscription business. Front-loaded effort, long durations, uneven cash profiles, project risk in every margin. Anyone who maps that into classic SaaS reporting obscures economic reality and loses credibility in investor communication. This article speaks to three audiences sharing the same pain: CFOs in VC-backed scale-ups, CFOs in PE portfolio companies, and operating partners or fund managers building reporting standards across multiple portfolio companies. It covers which KPIs investors actually read in project businesses, how accounting works in DACH, and the most common mistakes in investor communication.

If you are currently in one of these situations

Four acute pain situations that typically bring founders, CFOs and PE managers to this material:

• Series A or B preparation in 8 to 16 weeks, no defensible project P&L: the most common trigger. The investor expects project margin trend, backlog with coverage ratio and cash profiles per contract type; existing reporting only delivers period view. The relevant chapters start with The four metrics and the KPI architecture that follows.
• Acquisition with chaotic project data: after closing it turns out the target cannot deliver project margin in a defensible way. The PE holding expects consolidation into the holding reporting within one to two quarters. The relevant starting point is the KPI definition question and the ERP setup, addressed in The operating partner view.
• Margin erodes under growth, root cause unclear: revenue rises, EBITDA margin slips, no one can tell whether it is a mix effect or operational deterioration. The fix requires project margin variance tracking and senior-junior mix analysis, depending on sector.
• Investor asks for backlog forecast and cash profile per contract type: standard bookkeeping does not deliver this. Defensible answers go beyond DSO and require a working capital profile per project phase, addressed in Cash conversion cycle.

Important to know: clean project controlling cannot be built from scratch in 8 to 12 weeks before a term sheet deadline. Realistic lead time is six months to reconstruct historical project data, anchor KPI definitions and adjust the ERP setup so that ongoing data is captured at the required granularity. Anyone closer to the deadline should start with a triage: which three KPIs at which depth must be credibly defensible by the DD meeting.

Why project controlling follows its own logic

Three structural differences shape project-based business models. First: revenue and cost arrive at different times. A twelve-month project produces upfront effort in month one, milestone invoices around month six, final acceptance in month twelve. Second: margin does not accrue evenly, it materialises at project completion or milestone closure. Third: risk distributes asymmetrically. A project can run on plan for six months and lose 30 percent of its margin in month seven on a technical complication.

Standard monthly reporting hides this reality. Mapping projects into period-based revenue and cost allocations does not show whether the business is healthy. Investors who have understood this ask for project P&L per order, for backlog conversion and for cash profiles by contract type. Anyone who cannot answer signals that no one in the company understands the project economics.

The four metrics investors actually read

Project margin (gross margin at project level)

The central metric. It shows whether the project business itself is profitable, independent of overhead and growth investments. Standard practice is to break this out by project category (e.g. standard vs. custom, small vs. large volumes, regional clusters). Investors want to see whether margin holds up under scale or deteriorates. Falling project margin with rising revenue is a clear warning signal, and more common than founders realise when growth is forced through lower-margin large contracts.

Cash conversion cycle in project businesses

The period from first project cost to full payment received. In typical DACH project businesses the cycle runs between 60 and 180 days, in plant construction and public-sector contracts often considerably longer. Billing 30 percent on contract, 40 percent at milestone, 30 percent at acceptance produces a different cash profile than upfront billing. Investors check whether cash conversion cycle increases under growth, because that means each new project ties up more working capital than the last. A business that scales this way can hit liquidity limits long before the project work itself becomes unprofitable.

Reasoning about CCC purely on the customer side misses half the picture. The cycle is the result of three levers: receivables duration to customers (Days Sales Outstanding, DSO), tied-up material and work-in-progress (Days Inventory Outstanding, DIO), and payables duration to suppliers and subcontractors (Days Payable Outstanding, DPO). In EPC, plant construction and engineering, material and subcontractor share often makes up 50 to 70 percent of project cost, which means the supplier side is the larger lever in absolute terms. In practice new suppliers often require prepayment or 14 days net, established relationships sit around 30 to 60 days net. Longer terms are negotiable in B2B and tightly constrained towards public-sector buyers. Construction subcontractors typically invoice under VOB/B (Vergabe- und Vertragsordnung für Bauleistungen, Teil B, the German construction contract regulations) with progress payments, often within 21 working days after a verified invoice, sometimes with a security retention of around 5 percent.

The critical point is the timing match between customer down payment, material procurement and subcontractor calls. If the supplier requires prepayment for material before any customer cash arrives, or the customer pays only at the first milestone with no down payment, a negative cash gap opens that can pull the project into a working capital crisis even at full margin. Defensible investor answers therefore go beyond DSO and show the working capital profile per project phase over time: down payment, material purchase, production, milestone billing, subcontractor calls, final invoice and release of security retention. Negotiation levers on the supplier side (cash discount usage, framework agreements, longer payment terms with strategic partners) belong in any CCC improvement plan, not just the customer side.

Backlog and coverage ratio

Backlog is the order book: signed contracts that are not yet fully revenue-recognised. Coverage ratio puts that backlog in relation to expected revenue in the next quarters. A coverage ratio of 0.8 for the next quarter means that 80 percent of the revenue plan is already covered by signed contracts. Investors read backlog as a leading indicator. Rising revenue with shrinking coverage ratio means growth comes from existing contracts, not new business, which is the precise trigger for asking whether the sales engine actually works.

Project P&L vs. period P&L

A statutory P&L (period view) is not enough in a project business. Investors want a project P&L on top: for each material project, a separate breakdown of revenue, direct cost, project margin and status. With a portfolio of ten to fifty active projects, this is its own reporting workstream, typically maintained in a dedicated tool (project controlling software, ERP module or structured spreadsheets). In well-run companies, management and investors know the five largest projects by name at every cut-off, with status traffic light and commercial expectation.

Sector patterns: where the KPI emphasis shifts

The four KPIs of the previous section apply across every project business. The emphasis shifts by sector, and investors expect founders and CFOs to know those shifts.

Plant and machinery

Multi-year project durations, high material and subcontractor share (typically 60 to 75 percent), down-payment-driven cash profiles, security retentions over warranty periods of two to five years. KPI emphasis: backlog with coverage ratio over 18 to 36 months, cash conversion cycle including release of security retention, project margin variance per order with breakout into material, subcontractor and own-effort share. Often underestimated: engineering change orders (contract changes during project execution) as a separate KPI line, because they can move the original project margin meaningfully. In hybrid models (plant business plus maintenance contracts) a separate view pays off: project margin in the new build, ARR characteristics in the service share. In PE reporting often additionally: EBITDA bridge before and after project risk discounts.

Cleantech EPC: solar, wind, battery storage, heat-pump installation

A common mix of B2B large projects (solar parks, wind farms, BESS plants, heat networks) and granular private or commercial work (rooftop PV, residential heat-pump installation). KPI emphasis: order mix by segment, installation cycle time per order type (from contract signature to commissioning), material share under volatile module and component prices, customer acquisition cost (CAC) in the B2C segment, subsidy and grant pipeline as a backlog component. Pipeline tracking along the typical stages (lead → site survey → quote → contract → installation → acceptance → grid connection) is decisive for forecast accuracy in residential business. PE buy-and-build in the cleantech installation market additionally requires consolidated project P&L view across multiple subsidiaries, which is operationally heavy where the ERP landscape is heterogeneous.

Defence tech and dual-use

Multi-year government contracts in several formats: firm fixed price (FFP) for clearly scoped deliverables, time-and-material (T&M) for open scope, cost-plus variants (CPFF, CPIF, CPAF) for R&D-heavy programmes, indefinite-delivery-indefinite-quantity (IDIQ) as a framework with task orders. In a DACH context: contracts with the Bundesamt für Ausrüstung, Informationstechnik und Nutzung (BAAINBw, the German federal armed forces procurement agency), NATO programmes, the European Defence Fund (EDF). KPI emphasis: backlog by contract phase (bid, awarded, in execution, closed) and contract type, FFP versus T&M versus cost-plus mix, earned value management (EVM) with cost performance index and schedule performance index on cost-plus and incentive contracts (often contractually mandated), compliance overhead from export control (Kriegswaffenkontrollgesetz in Germany, EU dual-use regulation), cash profiles with the agency-specific down-payment structure. Reporting requirements sit closer to classic plant business than to SaaS reporting.

Engineering services and systems integration

Personnel-intensive (personnel cost 50 to 70 percent), utilisation as the central margin lever. KPI emphasis: billable utilisation rate (industry benchmarks: 70 to 85 percent in engineering houses, 55 to 65 percent in strategy consulting), average daily rate (ADR) and effective rate (billable rate × utilisation), project margin by senior-junior mix, backlog in person-months on top of EUR. Senior-junior mix as a margin lever: junior hours with higher per-hour margin (typically 80 to 140 percent), senior hours lower margin at higher absolute contribution (typically 50 to 90 percent). Mix shifts can move project margin by 10 to 20 percentage points without changing daily rates. Bench time (non-billable utilisation) belongs in every monthly report. PE roll-up strategy is common in the market: consolidating multiple mid-market engineering houses, cross-portfolio utilisation tracking and a unified ADR definition are the central operational challenge in the first 24 months after platform acquisition.

Accounting: PoC, completed contract and IFRS 15

For longer-running projects the accounting question arises. HGB (German GAAP) follows the realisation principle under § 252 (1) no. 4 HGB: profits are only recognised once they have been earned through a sales transaction. The standard case for long-term contracts is therefore the completed-contract method, with result recognition only at project completion. True percentage-of-completion is, as a rule, not permitted under HGB, because under works contracts revenue is only recognised upon acceptance. What is possible is partial profit recognition where the contract provides for separately invoiceable part-deliveries with partial acceptance. Technically that is not PoC but revenue recognition per part-sale. Under IFRS 15 (in force since 2018, replacing IAS 11) revenue is recognised through the performance obligation model, either at a point in time or over time. Over-time recognition mirrors the effect of the former PoC logic from IAS 11. In investor conversations "PoC" and "over time" are used interchangeably. IFRS reporting typically becomes relevant for VC-backed scale-ups from Series B onwards, usually as a contractual obligation under the investor agreement rather than a statutory requirement. PE portfolio companies, depending on holding structure and exit horizon, often run parallel HGB and IFRS views, frequently from 18 to 24 months ahead of a planned sell-side exit at the latest.

Practical consequence: companies that account under HGB completed contract but report internally under PoC logic must show the bridge transparently. Investors accept that two views exist, statutory and management. They do not accept the two views appearing in different reports without explanation. The standard rule: HGB P&L as primary statement, complemented by a management view with PoC recognition, clearly labelled as "non-statutory, internal".

KPI architecture for project-driven business models

A defensible KPI structure covers four layers: order intake, project execution, profitability, working capital. Two to four KPIs per layer are enough.

A complementary project P&L view for the five to ten largest projects belongs in any serious board pack. Reporting structures for full investor reporting in Board Reporting Guide.

The operational foundation: how project costs get captured

All KPIs on the previous pages are worthless if the underlying data is not captured cleanly. The operational foundation of project controlling is that every cost and every invoice gets allocated to a project cost centre at the moment of capture, not retroactively. Anyone allocating margin to projects weeks later by intuition is building reporting on guesses, and investors typically spot it within the first hour of due diligence.

Mandatory project field on every purchase order

The standard interface between procurement and finance runs through the procure-to-pay process: purchase requisition, approval, purchase order, goods receipt, invoice, three-way match, posting. The three-way match is the automated check that purchase order, goods receipt and invoice align on quantity, price and terms; only on a match is the invoice released for payment. Each of these steps must carry a project identifier. The most common mistake in practice: procurement orders without a project assignment because the tool does not enforce a mandatory field. The invoice runs through bookkeeping days or weeks later, no one reliably knows which project it belongs to, and it gets allocated by memory or pro-rata. From that moment on the project margin is an estimate, not a fact. The clean fix: configure the ERP or P2P tool so that no purchase requisition can be saved without a project assignment. That is a technical configuration, not a discipline question.

Mandatory project field on every single purchase is overkill, however. The pragmatic setup is a threshold logic: above a defined order value (in practice often 500 or 1,000 EUR) and for defined material groups the project field becomes mandatory; smaller purchases (office supplies, standard consumables) run on collective cost centres. Equally important is the clean treatment of non-project costs. Inventory material, workshop supplies, IT licences, cleaning or rent do not belong on project cost centres. Pushing them there contaminates project margin. Such overheads are captured on collective cost centres and, if needed, allocated to projects via allocation keys (machine hours, man hours, floor space), clearly labelled as allocation.

Hours and expense capture

In personnel-intensive project businesses like engineering, implementation or professional services, personnel cost often makes up fifty to seventy percent of project cost. Anyone not tracking hours per project lacks defensible project margin. In the early stage a best-of-breed stack still works: a human resources information system (HRIS) for employee master data, a dedicated time-tracking tool with project tagging, and a spend-management tool for expenses with a mandatory project field. Data flows into the books via API or CSV bridges.

At scale this architecture breaks down. Every tool transition becomes a source of data gaps: manual CSV exports, mapping errors between cost centres, lost or renamed project tags, expenses with no link to the time sheet, missing approvals. With twenty parallel projects and forty employees in delivery, the breaks are no longer fixable in Excel. The path leads either to an integrated ERP with native modules for hours, expenses and project allocation or to real API integrations between best-of-breed tools, not CSV ping-pong. Which step makes sense when depends on volume, project complexity and the maturity of the bookkeeping setup.

Cost centre architecture without over-granularity

A defensible project cost centre structure follows a clear hierarchy: business unit, project group or customer, individual project, optionally project phase. Roll-up has to work automatically in the ERP. The most common mistake is over-granularity: anyone setting up fifteen phase-level cost centres per project creates an administrative overhead that neither procurement nor employees on time entry sustain. Three to five layers are enough. The clean separation between project costs and overhead matters: otherwise marketing spend lands on project cost centres and project margin looks worse than it is.

Tool stack for project controlling

Four components have to be integrated for project controlling to work operationally:

• ERP project module as single source of truth: a light ERP, mid-market ERP or industry-specific solution for asset-heavy businesses. The project cost centre structure lives here, not in a spreadsheet. Integration with DATEV for tax and statutory accounts runs through established connectors.
• Procure-to-pay (P2P) layer for procurement: purchase requisition, multi-step approval, purchase order (PO) creation with mandatory project field. In light ERPs often integrated, in mid-market typically a dedicated P2P tool with an interface to the ERP and the DATEV bookkeeping system.
• Time and expense capture with project tagging: mandatory integration with the ERP, otherwise breaks emerge. Time-tracking and expense tools with defined interfaces.
• BI layer for project P&L and aggregation: a BI tool connected to the ERP data. Dashboards for active projects with status, plan-vs-actual, cost-centre drill-down.

Procurement becomes a data supplier, not just a buyer

The cultural shift behind all of this: procurement in a project-based business is no longer just responsible for getting the right material at the right price. It is part of the data chain that ultimately produces the project margin. That requires training, clear mandatory fields, automated validation and a direct communication path between procurement and finance. In practice the largest friction sits exactly here: procurement prioritises speed, finance prioritises data quality. The answer is not for one side to win, it is for the ERP system to enforce the rules so that both sides can work efficiently within them.

The DATEV dilemma in growing project businesses

Almost every German startup begins with DATEV, not because a tooling decision was made, but because the tax advisor (Steuerberater) uses DATEV. DATEV holds a dominant position in the German tax advisor market. Anyone who has a tax advisor typically also has DATEV in the data flow. That produces a setup that works pragmatically in the early stage: DATEV Unternehmen Online for document capture, DATEV Mittelstand or Auftragswesen for invoicing, and the tax advisor handling annual statements, payroll and tax filings on the same data basis.

The break point comes once the business scales in a project-driven way. DATEV offers cost centres and cost objects and is built around classic cost accounting with business units, locations and product groups. That is exactly the problem in a project business. What is missing: project P&L logic, backlog and coverage tracking, three-way match at project cost centre level, integrated time tracking per project, earned value calculations and BI-grade data output across multi-level project hierarchies. DATEV is optimised for bookkeeping and tax, not for operational project steering. Anyone trying to map project controlling inside it builds workarounds out of side spreadsheets, manual allocations and parallel lists that collapse at the next growth jump.

The common wrong reaction: replacing DATEV entirely. That fails to solve two problems. First, the tax advisor still needs a DATEV-compatible data feed, otherwise duplication or a tax advisor switch becomes necessary. Second, the DATEV history typically carries five to ten years of data consistency that becomes painful to lose at the next due diligence.

The right answer is co-existence. The ERP becomes the operational backbone for purchase orders, goods receipts, invoices, hours, project P&L and reporting. DATEV remains the bookkeeping layer and the interface to the tax advisor. Posting data flows from the ERP into DATEV, either through the modern DATEVconnect REST API, the DATEV Buchungsdatenservice, or in the legacy case through CSV export in the EXTF format. Result: the tax advisor continues to work in their familiar DATEV environment, the company runs its project business in the ERP.

In concrete terms for the internal finance team: day-to-day work runs in the ERP. Accounts payable (AP), accounts receivable (AR), document processing, month-end close, project P&L, cashflow forecast and reporting all happen in the ERP. DATEV runs in the background as a data sink: posting data flows automatically from the ERP, and the tax advisor accesses it in their familiar DATEV environment. If bookkeeping is run internally rather than at the tax advisor, it sits in the ERP's general ledger module, not in DATEV itself. Indicator of an incomplete transition: if the internal team still captures documents in DATEV, makes manual postings there or pulls reports from DATEV, the architecture is only half done and most of the benefits stay on the table.

Best practices for the transition

• Bring the tax advisor in early, do not surprise them later. The architecture decision belongs on the agenda of tax advisor and CFO together. A good Steuerberater sees a clean ERP integration as less work for them, not more.
• Align the chart of accounts. SKR03 or SKR04 must be identical between the ERP and DATEV. Mismatches create mapping overhead on every data transfer. If the ERP defaults to a different chart, fix it on day one.
• Map the cost centre hierarchy cleanly. Projects and project phases live in the ERP with full hierarchy. For the DATEV view, they get mapped onto a flat cost centre list that is sufficient for classic bookkeeping reports. Those two views must not get blurred.
• Check the DATEV interface before ERP selection. Not every ERP has a certified DATEVconnect connector. The DATEV marketplace allows filtering. ERPs without a native interface are harder to deploy in DACH, because either the tax advisor takes on data migration or the CFO ends up building bridges.
• Verify HGB compliance of the ERP finance module. International ERPs are not automatically HGB-compliant. SKR chart of accounts, document number ranges per GoBD, process documentation and electronic retention should be settled before the contract is signed.
• Phased migration instead of big bang. First introduce the ERP with DATEV integration in parallel operation. Then progressively shift operational load (procurement, invoicing, project execution) into the ERP. DATEV remains the stable bookkeeping layer throughout. Typical migration phase: six to nine months depending on volume and data quality.
• Switch tax advisor if interface refusal persists. Tax advisors who in 2026 still refuse interface postings from the ERP and insist on manual DATEV entry are the wrong fit for a scaling project business. That is not a technical problem but a mindset problem.

What project controlling in reporting is not

Three confusions that come up regularly:

• Project controlling is not project management. Project management runs the operational delivery: schedules, resources, stakeholders. Project controlling runs the economic performance: margin, cashflow, risk, forecast accuracy. The two functions work together but do not replace each other.
• Project controlling is not bookkeeping. Bookkeeping records the past under statutory rules. Project controlling steers active and future projects with management lens. Anyone who derives project margin only from the books has a delayed and often wrong picture.
• Project controlling is not a SaaS translation. Forcing project revenue into MRR or ARR neither improves investor communication nor internal understanding. Project businesses have their own KPIs and deserve their own language.

The most common mistake: selling project revenue as ARR

ARR lines show up regularly in pitch decks of DACH scale-ups and in reporting packages of PE portfolio companies whose business model is fundamentally project-based. The logic is understandable: VCs understand ARR, the pitch sounds more familiar, valuation multiples for ARR are higher. In a PE context, an ARR story additionally helps with multiple arbitrage between buy- and sell-side. The problem: ARR assumes revenue recurs without new sales effort. Project businesses almost never satisfy that definition.

Experienced investors recognise ARR construction in project-based models immediately and read it as a credibility issue. The clean alternative: project backlog, planned order intake, recurring revenue components (maintenance, service, SaaS components in hybrid models) shown separately. Where part of the business is genuinely recurring (e.g. maintenance contracts following a plant sale), that part can be reported as ARR, clearly demarcated from project revenue. This differentiation reads as honest in the pitch and leads to better valuation conversations, not worse.

The operating partner view: reporting across the portfolio

Operating partners and fund managers at DACH PE houses face a specific pain in project businesses. They oversee five to fifteen portfolio companies, often with different ERPs, different charts of accounts and different KPI definitions. Comparability across the portfolio is wishful thinking, not reality. Four levers address the problem at the root:

• KPI definition standard: what counts as project margin, how backlog is measured, how coverage ratio is calculated, anchored in a reporting package that all portfolio companies receive at onboarding. Without that standard, every quarterly consolidation is an apples-to-oranges comparison.
• Buy-and-build integration: roll-up strategies (solar aggregator, HVAC platform, engineering holding) bring their own ERP structures with every acquisition. Consolidated project P&L per deal is six to twelve months of work. Pragmatic path: a standardisation roadmap with a target ERP and unified cost centre hierarchy, not every add-on stand-alone.
• Value creation plan tracking at project level: monthly reporting that breaks project margin down by initiative (pricing, supplier consolidation, utilisation, fixed-cost dilution), not only an EBITDA bridge against plan. Without that view, it is impossible to tell whether VCP initiatives are working or whether margin improvement is just a mix effect.
• Pre-exit cleanup as a day-one VCP initiative: sell-side quality of earnings requires three to five years of historical project data. Retroactive reconstruction 18 months before exit costs six figures in advisory and triggers discount discussions with buyers.

When an operating partner needs short-term external capacity at a portfolio company (typical triggers: new acquisition with unclear project margin history, reporting gap to the PE holding, sell-side DD preparation, 100-day plan after closing), the profile question is fractional CFO versus interim CFO. Setup options in Fractional CFO vs. Interim CFO.

Conclusion

Project controlling in project-based businesses is not an additional reporting discipline alongside bookkeeping, it is the working foundation on which project economics become visible in the first place. Three building blocks make the difference: data captured at the point of origin through a tool stack that does not break under scale; an architecture with the ERP as operational backbone and DATEV as interface to the tax advisor; and KPIs that fit project reality rather than the SaaS template. What changes from audience to audience is reporting frequency and depth, not the underlying data. VC investors read quarterly, PE investors monthly, operating partners across the portfolio. Build the foundation right and all three are served. For capital-intensive project businesses that also need to build project finance structures, bankability and a capital stack alongside operational controlling, a dedicated guide is available in Infrastructure Financing for Capital-Intensive Scale-ups.