How to Build a PCF Software Business Case When You Already Calculate PCFs in Excel

Why now: On 18 February 2027, batteries become the first product group for which a Digital Product Passport is mandatory in the EU, and the Commission's indicative timeline lines up iron and steel, textiles, tyres and aluminium behind them under the Ecodesign for Sustainable Products Regulation (EU) 2024/1781. For a growing list of product groups, product-level data is becoming a regulated requirement.

Your team already produces product carbon footprints (PCFs). Some are even certified. They live in a set of well-built spreadsheets maintained by one or two people who know every formula. Then procurement asks the obvious question: why pay for a platform when the work is already getting done?

It is a fair question, and it is the most common one we hear from sustainability teams that already run PCFs in spreadsheets. The honest answer is that sometimes you should not buy. This guide gives you the cost buckets, a worksheet you can fill in, the signals that tell you Excel has reached its limit, and a way to present the result to your CFO.

What does a PCF really cost when you calculate it in Excel?

More than the analyst's time. The real cost per PCF is the total annual cost of your in-house model divided by the number of PCFs you actually deliver, and most of that cost sits outside the spreadsheet.

CO2 AI has published its own estimate for the chemicals industry: around €1,075 per SKU to compute a footprint manually, versus €53 per SKU with its AI computation tool. Treat that as a vendor reference point, not a benchmark: the article says the figures come from "our calculation with customers" and does not publish the hours, salaries or product counts behind them. That is exactly why you should calculate your own number.

Seven cost buckets make up the in-house model:

• Analyst time per PCF: hours to model the bill of materials, allocate site energy, match emission factors, document and review. Teams usually undercount review loops and rework after customer questions.
• Data collection: hours spent by procurement, production and finance pulling BOMs, volumes and utilities. Teams usually undercount the time of people outside the sustainability team.
• Emission factor databases: licences for secondary data. Teams usually undercount multi-user or multi-database licences as scope grows.
• Verification or critical review: third-party review fees and internal preparation hours. Teams usually undercount preparation time, not just the invoice.
• Updates: recalculation when factors, recipes, suppliers or methods change. Teams usually undercount every new database or standard version.
• Key-person risk: the cost of a gap if the person who owns the model leaves. Teams usually undercount hiring and onboarding time.
• Request handling: hours spent reformatting results into each customer's template or portal. Teams usually undercount requests answered late, or not at all.

For reference points on the hidden buckets, CO2 AI's Build vs Buy analysis estimates emission factor database access at $20K to $80K per year and first-time assurance preparation at 200 to 400 hours, and reports that teams who migrated from in-house builds spent 15% to 25% of their carbon accounting capacity on methodology maintenance. Those are estimates for corporate Scope 3 programmes, so use them to prompt questions, then replace them with your own invoices and timesheets.

When is Excel enough for product carbon footprints?

When volume is low and stable. If you footprint a handful of products, receive few customer requests a year, and your recipes and suppliers rarely change, a well-documented spreadsheet model plus an occasional external review is a rational choice.

Excel is usually enough when all of these are true:

• You need a small number of PCFs per year and the list is not growing.
• Customers accept your format, and nobody asks for structured data exchange.
• Recipes, sites and key suppliers change rarely, so recalculation is occasional.
• At least two people can run and explain the model.
• Your verifier is comfortable with the spreadsheet as evidence.

If you tick every box, keep the spreadsheet, document it well, and revisit the decision next year. The goal is not to buy software. The goal is a defensible cost per PCF.

When does a spreadsheet PCF model break?

When the number of products, requests or audit questions grows faster than your headcount. Spreadsheets scale linearly with people; demand for product data does not.

Watch for five breaking points:

1. Hundreds of SKUs. Representative products stop being acceptable once customers ask about the exact grade they buy.
2. Recurring customer requests. Every request becomes a small project, and the queue starts to set your priorities.
3. Structured data exchange. Customers start asking for PCFs aligned with the PACT methodology and technical specifications, which support the digital exchange of PCF data. PACT Version 3 was released on 30 April 2025.
4. Audit trail. Under PACT V3, verification shifts from the calculation model to the PCF Program, meaning the processes a company uses to produce and manage its PCFs, from 2030. A process that lives in one person's files is hard to verify.
5. Regulated product data. As Digital Product Passports roll out product group by product group, more of your customers will need product-level data on a fixed schedule.

How do you calculate cost per PCF and ROI for a PCF platform?

Divide your total annual in-house cost by the PCFs you deliver, then compare it with the platform's annual cost divided by the PCFs you expect to deliver with it. Add the value of hours freed and revenue protected.

Use this worksheet. Fill in your own numbers from timesheets, invoices and your CRM, not from estimates found online.

• A. Analyst hours per year on PCFs: hours per PCF x PCFs delivered + update and request hours.
• B. Loaded hourly cost: annual salary + employer costs + overhead, divided by productive hours.
• C. People cost: A x B, plus hours from procurement, production and finance x their loaded cost.
• D. Licences and review fees: EF databases + verification or critical review + consultants.
• E. Total annual in-house cost: C + D.
• F. PCFs delivered per year: count of PCFs actually sent to customers or used internally.
• G. In-house cost per PCF: E / F.
• H. Platform annual cost: vendor quote + implementation + remaining internal hours x B.
• I. PCFs expected per year with the platform: based on SKU list and request pipeline.
• J. Platform cost per PCF: H / I.
• K. Hours freed: (A minus remaining hours) x B.
• L. Revenue at risk: revenue from accounts with unanswered or late PCF requests x your estimate of the share at risk.

Two rules make this worksheet credible with finance. First, compare cost per PCF at the same volume: a platform rarely wins on today's ten PCFs, but it can win on next year's several hundred. Second, count hours freed as savings only if they go somewhere useful, such as reduction projects or more requests answered.

On pricing models: ask vendors how cost changes as volume grows, whether pricing is per PCF, per SKU, per site or per platform, and what happens if you exceed a cap. Choose the structure that matches your volume curve, and model it in line H for the next two to three years.

How do you present a PCF software business case to a CFO?

Lead with cost per PCF and revenue at risk, not with features. Finance approves a change in unit economics and a reduction in risk; it rarely approves a tool.

A one-page structure that works:

• The question: "We deliver X PCFs a year at Y per PCF. Customers are asking for Z. Can we meet that demand at today's cost?"
• Options: stay in Excel, hire another analyst, outsource to consultants, or adopt a platform. Show each with cost per PCF at next year's volume.
• Risk: key-person dependency, verification readiness, and named customer requests you cannot answer on time.
• Upside: hours redeployed, faster responses in tenders, and product-level data for decarbonization decisions.
• Decision and review point: a 12-month check on PCFs delivered and cost per PCF.

Notice that "hire another analyst" sits on that list. When the comparison is framed as cost per PCF against a full-time role, you make the trade-off explicit instead of leaving it implied.

What should you expect from PCF software beyond automation?

Scale, traceability and exchange. Automation reduces hours, but the business case usually rests on what Excel cannot do at all.

CO2 AI, an AI-powered carbon management platform used by enterprises such as Volvo Group, Klöckner & Co and Accor, approaches this through its product carbon footprint module. The platform matches bill of materials data to emission factors across global databases, states support for PACT, TfS, PEF, ISO 14067, ISO 14044 and the GHG Protocol, keeps an audit trail on every data point and methodology, and lets you share footprints with customers through API-based integrations.

In practice: Reckitt previously matched activity data to emission factors through manual categorization. With CO2 AI, it moved from 333 representative products to precise emissions data for each of its 25,000 products in just under four months, improving the accuracy of its emissions footprint by 75 times. For your business case, the lesson is coverage: product-level data changed what the team could see and act on.

Before you sign, test the trade-offs: data portability, how methodology updates are handled, and whether your experts stay in control. A platform makes skilled PCF practitioners faster; it does not replace their judgement.