Energy Broker Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the commission module that only records receipts happen so often?

Because it is what every accounting mindset produces, and because it is the version that can be built without reading a single confirmation.

Money arrives on a statement. A developer models a payment, matches it to a customer, posts it to a ledger and reports the total. It works, it reconciles against the bank, and it is finished quickly. What it can never do is detect absence, and absence is the whole problem. QuickBooks and Xero have the same limitation for the same reason: they record money that arrived and have no concept of money that should have.

The reason teams land here is that the alternative requires structured contract terms, and structured contract terms require someone to read confirmations and decide what the fields are. Rate, unit basis, estimated annual usage, term, upfront versus residual, guaranteed payment provisions, the split, the clawback conditions. That is unglamorous work with no visible output for a fortnight, and it competes with a quoting screen that will demo well on Friday.

The fix is to make the expected schedule the first thing built. At execution the system generates every expected payment, meter by meter and service month by service month, out to end of term. Incoming statements are normalised and matched on meter number plus service month, and three buckets fall out: matched, variance and missing. Write the acceptance test into the scope: load a statement with one meter removed and one rate reduced, and the system must produce two named exceptions without a human comparing anything. If a proposal leads with the quote engine, ask where absence gets detected, because that is where the payback is.

What goes wrong when years of contracts and meter data are migrated?

Migration in this category is consistently underestimated, and the reason is that the difficulty is not volume. It is that the same meter has been written six ways.

Meter identifiers were entered by different people over several years, sometimes with a utility prefix, sometimes without, sometimes with hyphens, sometimes padded with leading zeros that a spreadsheet stripped. Utility names appear as an abbreviation on one row and a full legal name on another. Rate classes were typed rather than selected. Then there are the structural problems: a customer with a drop and add where the same premises has two meter records, an account that changed legal entity mid term, and a contract with three amendments filed as separate rows.

If that data lands unnormalised, the expected schedule matches nothing and the system produces a wall of false exceptions on day one. The commissions person stops trusting it within a week, which is a much worse outcome than not having it, because you now have both a spreadsheet and a system.

The fix is to treat migration as its own workstream with a human review pass, not a weekend import. Normalise identifiers against the utility's own format, resolve the exceptions by hand with someone who knows the book, and do it in two passes: live contracts first so the system becomes usable, then historical commission data afterwards for dispute and trend purposes. Then prove it before cutover by taking one supplier's most recent statement and reconciling it fully in the new system against what the old workbook said. If those two do not agree, the migration is not finished.

Why do the rate matrix and statement parsers break after launch?

Because both consume files produced by other companies who owe you nothing and change formats without notice.

Rate matrices arrive daily or intraday from Constellation, NRG, Direct Energy, Shell Energy, Engie, Calpine and a list of regional suppliers, each with its own sheet layout. Statements arrive monthly as comma separated files, as documents, or as an export from a portal you have to log into. A parser written against a January layout will meet a March layout, and the dangerous failure is not a crash. It is a partial parse: a column shifts, a header changes, and the parser reads a plausible number from the wrong place. Everything downstream looks normal.

Three protections matter more than parser sophistication:

• A schema validation pass on every load, so a file that no longer matches its expected shape is rejected loudly rather than accepted quietly. A rejected file is a phone call. A silently misread file is a year of wrong numbers.
• Parse confidence monitoring with an operational alert to a named person, not a dashboard, because format drift is continuous rather than occasional.
• A quarantine queue where a failed file waits with the offending row and the rule it broke, so a business user can correct and reload without opening a ticket.

This is one of the few genuine uses for a language model in a broker platform. Extraction from statement documents survives layout drift that would break a rule based parser overnight. It has to sit behind a deterministic validation pass, because a model that guesses confidently is exactly the failure mode you are trying to eliminate.

What happens when renewal windows and clawbacks are left out?

Both get deferred as phase two features and both are direct revenue.

The renewal date is not a date. It is a window driven by the contract's notice terms, the utility's switch calendar, the supplier's blackout rules and where forward pricing sits. A build that stores a renewal date field inherits the problem it was meant to solve, because that field is empty for a large slice of the book, typed by a rep who has since left. When the contract lapses the customer rolls to a variable rate, gets a bill several times higher, calls the supplier directly and signs a direct deal. Your residual dies and nothing warned you.

Clawbacks are the mirror image inside your own ledger. A customer drops in month eight, the supplier reverses an upfront payment, and you have already paid an agent their share. If the build modelled payments as rows that can be edited, the reversal has no clean path and your controller does a manual journal entry every time. Do that across sixty agents and comp questions start reaching you personally.

The fixes are structural rather than clever. Contract terms are extracted into structured fields at execution, so notice period, auto renewal clause and early termination formula produce a computed window rather than a typed date. Forward pricing is compared against each customer's contract rate to rank a daily worklist by dollars of savings available times commission at risk. And every financial movement is an event, never an edit, so a reversal is a new entry linked to what it reverses and it cascades through the split engine automatically.

Should you build custom or configure what you already own?

Under roughly four hundred live contracts with fewer than five suppliers and mostly upfront commission, do not build. PowerKiosk, Energy Broker Pro or Aggregate Energy will cover you for a subscription that is a rounding error next to a project, and the money does more good in sales capacity. We would say that before quoting.

Before commissioning anything, also check what you already pay for. Plenty of brokerages run HubSpot or Salesforce with a deal pipeline configured at implementation and never revisited, and a genuinely disciplined pipeline with required fields at close, a computed renewal task and a shared document store closes a meaningful share of the gap for the cost of a week of someone's attention. It will not fix commission reconciliation, because a customer relationship platform has no concept of expected money, but it will tell you whether your problem is really process rather than software. Equally, resist reaching for a sales compensation tool such as Spiff, CaptivateIQ or QuotaPath for the agent split problem. They model quota carrying reps on closed won revenue, not a thirty six month residual stream with reversals.

Build when the signals are concrete. A full time person exists to reconcile commission statements. You carry more than twelve suppliers. You crossed a thousand meters and renewal capture is weak. Your platform vendor cannot add a supplier you need. Or you run a channel with more than twenty agents and comp disputes reach you personally. Any two of those and the arithmetic already favours building.

How do hidden costs get into the quote?

Four items account for most of the overruns, and each is visible before kickoff if you ask.

Supplier count priced as a project rather than per supplier. Every supplier is a matrix adapter plus a statement parser plus a submission flow, and the eleventh costs roughly what the third did. Get the per supplier figure in writing.

The second market treated as configuration. Each deregulated market carries its own utility list, rate class taxonomy and switch calendar. It is not a settings change.

Historical migration priced as an import. This is the single most underestimated line in the category, and the cost is the human review pass on inconsistent meter identifiers, not the loading.

Residual complexity. Simple upfront commission is straightforward. A book mixing upfront, residual, guaranteed payment and blended structures roughly doubles the ledger work, and quotes written before anyone read a confirmation assume the simple case.

What separates a build that works from one that fails here?

Ask them to model the commission ledger on a whiteboard before you sign. Meter, service month, expected against actual, upfront and residual, clawback, agent split. If they reach for a single commissions table with an amount column, they have never done this, and the data model is the whole product. It takes an hour to test.

Ask what happens when a supplier changes a statement layout with no notice. The right answer involves per supplier adapters, a schema validation pass and an operational alert when parse confidence drops, not an assurance that it will not happen.

Ask about market coverage explicitly, including how switch timing differs between the markets you operate in and how they handle a utility with a non standard meter identifier. A developer who has not met that will meet it in week nine at your expense.

Ask how they will audit contract terms, because when a supplier disputes a rate you signed twenty six months ago the audit trail is your entire case, and signature evidence on letters of authorisation is part of it. Then get code ownership in writing before the first invoice. The parsers and the rate normalisation layer are your actual competitive asset, and a developer who wants to license those back to you is selling a platform with extra steps. At Digital Heroes the client owns the repository from the first commit.