The C&I book is where retailers win or lose real margin, and it is getting harder to defend. Your competitors are already pitching bundled renewable deals, flexible purchasing and cost recovery structured around each customer’s own risk appetite. The account you think is safe is the one they are courting. Winning new large accounts, and keeping the ones you have, increasingly means being able to say yes to propositions you have never quoted before, quickly, and at a price you can actually stand behind.

The retailers who can’t do that don’t see a noticeable loss. Instead, the losses come slowlyl: a tender that goes elsewhere, a flexible product they stop offering or a strategic customer who trusts them a little less each billing cycle.

One retailer we worked with won a competitive deal by bundling a power purchase agreement (PPA) with flexible purchasing. Sales booked it as a win. Then it reached billing, and the system couldn’t represent the PPA line item cleanly on the bill. The problem wasn’t billing. It was that the product had never been properly defined before it got there. Someone built a manual workaround outside the system. Much of the relationship afterwards was spent explaining to the customer why their bill looked the way it did. The margin sales won on the deal eroded in the cost of servicing it, and the next time that customer went to tender, the relationship was no longer the asset it should have been.

Billing is where these decisions come home. It’s the last system in the chain and the one with regulatory and financial consequences attached to its number, so it’s where a flexible product either survives or dies. The fix isn’t which systems you buy. It’s whether you planned the stack, all the way to the bill, around a market that increasingly rewards flexible purchasing and bundled products.

Why this happens

Chasing today’s problem, not tomorrow’s

Pricing needs a tool, billing needs a tool, forecasting needs a tool, and each gets bought or built to solve the problem in front of the team buying it, not the one the business will have in three years.

‘Retailers often make technology decisions to fix a problem today, rather than to build a system for the future.’ — Mark Burdus, BFY Group

The result is several systems that were each right for the team that bought them, and a stack that never quite fits together.

Disconnected teams, misaligned goals

Some of it comes down to who’s making the decision, and for how long.

‘The problem is rarely one system or one team. It is that commercial, billing, operations and technology decisions are often made in silos, while leadership moves on or changes before the full impact of those decisions is felt.’ — Mark Burdus, BFY Group

The impact is felt in a specific place: isolated pricing decisions, broken product structures or siloed definitions, all of which surface at billing. When a bill comes due, problems that escaped notice earlier have to be represented exactly in a number that the customer and regulators can see.

So the system doesn’t get redesigned. It gets patched, whether in a script by IT, a separate spreadsheet or a person explaining the bill to the customer by hand.

The cost: lost deals and leaked margin

That number is a billing number for a reason: getting a new product priced is fast, getting it to bill correctly at scale is where the months go. Each patch closes today’s gap and becomes tomorrow’s constraint. The next flexible product commercial wants to offer doesn’t get built, because building it properly means redoing the workaround from scratch.

As soon as you embark on such a route, you can expect the impacts to hit across the business: tenders lost to a competitor; flexible products withdrawn; manual billing cost and customer disputes that climb with every workaround; strategic accounts trusting you less each time and margin you can’t actually see, because it’s buried in spreadsheets rather than the system. Every transformation programme promises to fix this. Most dilute their own return by solving the calculation and leaving the billing definitions untouched.

Agree the product definition first

The default response: build it yourself, or buy one system that does everything

Consolidating tech is usually the instinct. Fewer systems, fewer handoffs and fewer places for data to break. It works well for standard contracts. For a complex C&I book, it only stays that simple if the combined system is genuinely configurable enough to handle both jobs. If it isn’t, billing sets the ceiling. It has to produce a number with regulatory and financial consequences, so when a system can’t flex both ways, it gets built around that defensible number rather than the pricing team’s need to move fast. That isn’t billing overreaching; it’s billing doing the one job it can’t compromise on. The products you can quote narrow to whatever the bill will accept: a blended rate, a published-rate or pass-through update, a take-or-pay threshold, each one only offered if the billing engine will take it. You don’t notice the trade-off until it’s built: a flexible product isn’t offered, and the deal is lost.

The other default is building it all yourself. That just moves the short-term thinking inside the business: you’re still solving today’s problem with today’s team, and now you own the maintenance too.

The right approach: one product definition, from ETRM to bill

One retailer we work with is deliberately unwinding a tightly coupled pricing-and-billing setup, splitting it into a best-of-breed stack so each system does its own job well. That’s a sound move. It only pays off if the product definition - a blended rate, a bundled PPA, a take-or-pay threshold - is the same in the CRM, the ETRM, the pricing system and the billing system. Build a flexible product in pricing and it fails at the point where billing can’t recognise the structure, because that’s the point where the customer actually sees it.

Most transformation plans skip that step. The tools get evaluated, the calculation problem gets solved and the definitions still don’t match up between systems. That’s usually where the pricing flexibility a project promised  disappears, and where its business case does too.

Plan for what the next tender will ask for

The question worth asking isn’t just what your C&I customers need today. It’s what the next one will ask for: another bundled PPA, a new cost recovery structure or a clause nobody’s quoted yet. Building for that means the product definition has to move ahead of demand, not catch up to it after a deal’s already been lost, and it has to reach all the way to the bill, not stop at the price.

The one question your RFP is probably missing

Most billing RFPs ask about uptime, integration cost and support. Few ask directly whether the billing platform can represent a new product structure without forcing a replatform down the line. That’s the question that decides whether flexible pricing actually turns into won deals, or just into another workaround.

And there’s a second answer worth planning for. If the billing engine can’t represent the structure, the calculation doesn’t have to live in billing at all. Move it upstream, into a pre-billing layer that turns a complex contract into a consistent, billing-ready number before the invoice is generated, and the billing engine keeps doing the one job it does well while the contract structure stops being the constraint. That is the difference between trimming products to fit the stack and building the stack around the products you want to sell.