Energy Broker Software: Fixing Quote, Contract and Commission Leakage

Why broker software makes or breaks an energy broker

An energy broker is not a sales business with a CRM (Customer Relationship Management) problem. It is a data reconciliation business that happens to sell. Every dollar you earn arrives months after the work, calculated by someone else, on a statement you did not design, against a contract term you have to prove. The software is not a convenience layer. It is the only thing standing between your P&L and a supplier's accounting department.

The reality in most brokerages doing $3M to $12M in annual commission looks like this. Salesforce or HubSpot holds the customer records and deal stages. Rate matrices arrive as Excel files by email from Constellation, NRG, Direct Energy, Shell Energy, Engie, Calpine and a dozen regional suppliers, each one a different sheet layout, each one refreshed daily or intraday. Someone on the desk downloads them, pastes them into a master workbook, and builds a comparison grid for the client. Contracts get signed in DocuSign and the PDF lands in a Dropbox folder. Commission statements come in monthly, some as CSV, some as PDF, some as a portal you have to log into and export. A commissions clerk keys them into another workbook to check that what arrived matches what was promised.

The concrete scene: it is the 12th of the month, the Constellation statement has landed, and your commissions person is on the fourth hour of matching 340 meter numbers against the master workbook. Eleven accounts paid at 1.8 mils instead of the 2.2 mils on the signed confirmation. Four accounts that should have paid did not appear at all. She flags them, emails the channel manager, and waits. Three of those eleven get corrected in six weeks. The other eight quietly stay wrong for the next 36 months of the term. Nobody calculates what that costs because nobody can. We have rebuilt this exact workflow enough times to know the number: on a book of 2,000 meters, silent underpayment runs $40k to $180k a year, and it compounds because the error persists for the life of the contract.

Problem 1: rate matrices are a moving target and your quote is stale before you send it

A commercial account in ERCOT asks for 12, 24 and 36 month options across six suppliers. Your analyst pulls six matrices, filters by utility, zone, load factor band and annual usage, and builds a comparison. It takes 40 minutes. By the time the client responds the next morning, three of those prices have moved and one supplier has pulled the tier entirely. You requote. Now you have two versions of the truth in the client's inbox and a credibility problem.

Off-the-shelf CRMs cannot fix this because a rate matrix is not a product record. It is a multi-dimensional lookup keyed on utility, zone, rate class, load profile, usage band, start month, term length and green content, and it expires in hours. HubSpot's product library and Salesforce CPQ both assume a price list that changes quarterly, not a 40,000 row grid that changes at 9am and again at 2pm. Brokers who try to force it end up with the matrices back in Excel anyway.

What a custom build does: a matrix ingestion service that watches a dedicated inbox and supplier SFTP drops, parses each supplier's layout with a per-supplier adapter, normalizes it into one rate table keyed on the dimensions above, and timestamps every load. The quote engine then queries one table, not six workbooks. Add the client's actual interval data or 12 months of billing history and the engine ranks options on projected total cost, not headline rate. Every quote you send carries a matrix version stamp and an expiry, so when a client comes back two days later the system tells you the price is stale before you do. This is one place document extraction pays for itself outright: a client emails a PDF utility bill, the system pulls the account number, meter, rate class, utility and 12 month usage, and pre-fills the quote request in under a minute instead of the analyst keying it.

Problem 2: commission reconciliation is manual, so underpayment is invisible

You signed a deal at 2.5 mils upfront on 4.2M kWh annual with a 60/40 residual split. What actually pays is whatever the supplier's system says, on whatever usage actually flowed, net of whatever true-ups they applied. If the supplier drops a meter, misapplies the rate, or fails to flow the account after a drop-and-add, you find out only if a human catches it.

QuickBooks and Xero cannot solve this. They record money that arrived. They have no concept of expected commission, so they cannot detect the absence of money. Generic CRMs have the same gap: the deal closes and the record goes quiet. Neither one models a payment stream that runs 36 months and can silently degrade in month 14.

What a custom build does: at contract execution, the system generates a full expected payment schedule from the confirmation terms, meter by meter, month by month, out to the end of term. When a statement lands, a parser normalizes it into a common ledger and matches every line to an expected line on meter number plus service month. Three buckets fall out: matched, variance, and missing. Variance over a threshold you set, say $50 or 5%, opens a dispute record with the confirmation PDF, the expected calculation and the statement line already attached, so your channel manager sends a case, not an email that says "this looks wrong." Missing meters get chased automatically. The parsers are the work here: each supplier statement format needs its own adapter, and they change without notice. This is one of the few places where an LLM extraction layer beats hand-written parsers, because it survives layout drift on PDF statements that would break a regex rule set overnight. Keep a deterministic validation pass behind it so nothing enters the ledger unchecked.

Problem 3: renewals arrive without warning and you lose the account to the incumbent

A 36 month contract signed in March 2024 expires March 2027. Your CRM has a close date and a renewal date field somebody typed in. Nobody typed it in for 40% of your book because the field is optional and the rep who closed it left. When the contract lapses, the customer rolls to the supplier's variable rate, gets a bill three times higher, calls the supplier directly, and signs a direct deal. Your residual dies and you never saw it coming.

Off-the-shelf tools fail here because the renewal date is not one date. It is a window driven by the contract's notice terms, the utility's switch calendar, the supplier's blackout rules and where the forward curve sits. A HubSpot workflow can fire a task 90 days out. It cannot tell you that this specific ERCOT account should be repriced now because 24 month strips just dropped 8% and the customer's notice window opens in three weeks.

What a custom build does: contract terms are extracted at execution into structured fields, notice period, auto-renewal clause, early termination fee formula, so the renewal window is computed, not typed. The system watches forward pricing against the customer's existing rate and surfaces a ranked worklist every morning: which accounts to call today, why, and what the pitch is. The forecasting is honest arithmetic, not magic. Take current forwards, the customer's usage shape and their contract rate, and rank by dollars of savings available times commission at risk. On a 2,000 meter book that turns a renewal desk of four people into a renewal desk of two, and the two are calling the right accounts.

Problem 4: agent and sub-broker splits nobody can audit

If you run a channel, you pay 1099 agents, sub-brokers and referral partners on some fraction of what you collect. The splits differ by agent, by supplier, sometimes by deal. Someone maintains this in a workbook. When an agent asks why their October check was $2,100 lower than expected, the answer takes two hours to assemble and the agent does not believe it.

Commission plan tools like Spiff, CaptivateIQ or QuotaPath model quota-carrying reps on closed-won revenue. They are built for a sales comp cycle, not a 36 month residual stream with clawbacks when a customer drops in month 8 and the supplier reverses the upfront. Payroll systems will not touch it because these are 1099 payouts against variable third-party remittance.

What a custom build does: split rules live as data, not spreadsheet formulas. Every dollar that lands on the ledger cascades through the split engine and produces a per-agent statement line traceable back to the meter, the service month and the supplier statement it came from. Agents get a portal showing what paid, what is expected, and what is in dispute. Clawbacks are modeled explicitly with the reversal event attached. The support cost of channel comp questions drops close to zero, which is worth more than it sounds when you have 60 agents.

Problem 5: supplier onboarding and contract paperwork is a per-deal tax

Every supplier wants their own LOA format, their own confirmation template, their own credit package, their own submission portal. A single deal can mean an LOA in DocuSign, a usage pull from the utility portal, a credit app, and then rekeying the whole thing into the supplier's broker portal. Twenty minutes to an hour per deal, per supplier, done by someone who should be selling.

No CRM fixes this because the work is not in your system. It is in seven other people's systems. Zapier or Make will not bridge it either: most supplier broker portals have no API worth the name, and the ones that do gate it behind volume tiers.

What a custom build does: one intake captures the customer and meter data once. The system generates each supplier's LOA and confirmation from templates populated with that data, pushes to e-signature, and files the executed document against the contract record with the terms extracted into fields. Where a supplier offers EDI or an API, you integrate it. Where they do not, you accept that and build a clean submission packet plus a checklist rather than pretending. Be realistic in scope: assume half your suppliers will never give you an API, and design the system so a human submits in four minutes instead of forty.

What this costs and what drives the number

Digital Heroes has delivered over 2,000 projects, and energy broker platforms land in a consistent band. A focused first release, meaning matrix ingestion for four to six suppliers, a quote engine with comparison output, contract records with extracted terms, and a commission ledger with variance detection, typically runs $60k to $130k and ships in 12 to 16 weeks. A full platform with multi-supplier EDI, agent portals and split engines, renewal forecasting, client-facing dashboards and reporting runs $150k to $400k phased across 6 to 12 months.

What pushes you toward the top of the band in this category, specifically. Supplier count: every supplier is a matrix adapter plus a statement parser plus a submission flow, and the eleventh supplier costs about the same as the third. Market count: ERCOT, PJM, NYISO, ISO-NE and the deregulated gas markets each carry their own utility list, rate class taxonomy and switch calendar, and adding a second market is not a config change. Historical data migration: importing eight years of contracts from a workbook where the meter numbers have inconsistent formatting is usually four to six weeks on its own and it is the single most underestimated line item we see. Residual modeling depth: simple upfront commission is easy, and a book with mixed upfront, residual, guaranteed-payment and blended structures roughly doubles the ledger work. If someone quotes you $30k for this, they have not seen a supplier statement.

Build versus buy, and where the line actually sits

Buy is genuinely right in two situations. First, if you are under roughly 400 live contracts with fewer than five suppliers, a platform like PowerKiosk, Energy Broker Pro or Aggregate Energy will cover you, and their monthly fee is cheaper than any build by an order of magnitude. Take the constraint and get on with selling. Second, if your commission structure is straightforward upfront and you are not running a channel, most of the value of a custom build evaporates. The reconciliation problem is real but small enough for one person and a workbook.

The signals that it is time to build are concrete, not philosophical. You have a full-time person whose job is reconciling commission statements. You are paying more than 12 suppliers. You crossed 1,000 meters and your renewal capture rate is under 60%. Your platform vendor cannot add a supplier you need and their roadmap answer is "next year." You are running a channel with more than 20 agents and comp disputes reach you personally. Any two of those and the arithmetic is already in favor of building.

The position: most brokers build too late, not too early. They wait until the workbook breaks, which happens at the exact moment they are scaling fastest and can least afford a 16 week project. The right time is when you can see the second of those signals coming, not when you are living in the third.

How to choose a developer for energy broker software

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

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

Ask about market coverage explicitly. A developer who does not know that a Texas switch has different timing rules than a Pennsylvania switch, or who has never handled a utility with a non-standard meter identifier, will discover this in week 9 of your build at your expense.

Ask about the customer data you will hold. Meter numbers, account numbers and usage history are regulated in several states, LOAs carry signature evidence you may need to produce in a supplier dispute, and if you touch California accounts you have CCPA obligations. Ask how they handle audit logging on contract terms specifically, because when a supplier disputes a rate you signed 26 months ago, the audit trail is your case.

And get code ownership in writing before the first invoice. In this category the parsers and the rate normalization layer are your actual moat. A developer who wants to license those back to you is selling you a platform with extra steps.