Ask an energy broker's finance team how confident they are that the commission paid into the business last month matches what was actually earned, and most give a qualified answer: broadly, probably, for the accounts someone had time to check. That qualification is not a sign of a careless finance function. It is what happens when commission reconciliation is attempted against data that was never structured to make the calculation checkable in the first place. The problem is not that suppliers pay incorrectly on purpose. It is that the reconciliation has to happen at a level of detail — the individual meter point — that most brokers' own systems do not hold cleanly, against a supplier statement that rarely lines up with that level of detail either.
Why the meter point, not the contract, is the unit that matters
A single customer account can span several sites, each site can have several meter points, and each meter point — identified by its full MPAN core and top line for electricity, or its MPRN for gas — can sit on its own contract, its own contract end date and its own commission arrangement, even where the customer relationship is managed as one account. When a broker's CRM tracks commission at the customer or contract level rather than the meter point level, reconciliation against a supplier statement that reports at meter point level is structurally mismatched from the start: two records that should describe the same payment simply do not share a common key to reconcile against.
We cover the case for building the pipeline itself around meter point and contract end date, rather than deal stage, on our broker CRM development page. The same structural decision that makes a renewal pipeline usable is what makes commission reconciliation possible at all: if the CRM does not hold a clean, uniquely identified record per meter point with its own contract and its own expected commission calculation, there is nothing precise to check a supplier statement against.
Supplier statement mismatches are not always errors
The instinct when a supplier statement does not match expectations is to assume the supplier has made a mistake. Sometimes that is true. More often, the mismatch has a specific, identifiable cause that a well-designed reconciliation engine can classify rather than merely flag as "different":
- Timing differences. A contract confirmed in one month may not appear on a supplier's remittance until the following statement cycle, or later still if the supplier's own settlement process runs behind the broker's own contract confirmation date. A reconciliation engine that expects same-month matching will generate a false discrepancy for every contract sitting in this timing gap, every single month.
- Consumption estimate versus actual. Commission calculated on an estimated annual quantity at the point of sale can differ from commission calculated once actual consumption, or a revised estimate, is known, particularly for sites without half-hourly settlement where actual usage is only confirmed periodically.
- Rate or uplift versioning. If the uplift agreed with a customer changed between quote and contract confirmation — a common occurrence where a deal is renegotiated before signature — and the CRM only stores the current uplift rather than the rate that applied at the point of calculation, any later reconciliation is comparing today's rule against a historical payment it was never the basis for.
- Clawback. Early termination or cancellation triggers a clawback of previously paid commission, which appears on a later statement as a deduction against an unrelated-looking figure unless the reconciliation engine can trace it back to the original contract and the specific clawback rule that applied.
A reconciliation process that cannot distinguish between these causes treats all of them identically — as an unexplained variance for someone to chase manually — which is exactly the state most brokers' finance teams are working in today.
Settlement timing makes point-in-time reconciliation unreliable
Energy settlement is not instantaneous, and neither is the data a broker needs to check a commission calculation. Non-half-hourly consumption is often estimated and only trued up against actual meter reads later, and the settlement cycle that determines a supplier's own cost base runs weeks behind the point of sale. A reconciliation engine designed around the assumption that all the relevant facts are known and stable at the moment a contract is signed will keep re-flagging the same contracts as discrepancies as more accurate data arrives later. The correct design treats reconciliation as a process with a defined re-check cadence — an initial calculation at contract confirmation, and scheduled reconciliation passes as later data (actual consumption, corrected estimates, supplier remittance) becomes available — rather than a single pass that is expected to be final.
How to design the reconciliation engine
The pattern that holds up in practice separates the rate and commission calculation logic from the CRM's customer-facing record layer, running it as its own versioned service. Four design decisions matter most:
Store the calculation, not just the outcome
Every commission calculation should be stored with the exact inputs that produced it — the uplift rate in force at that date, the consumption estimate used, the contract term — rather than only the resulting figure. When a supplier query arrives months later asking why a specific payment was expected, the answer needs to be a lookup, not a reconstruction from whatever the CRM currently shows.
Match at meter point level, with a documented fallback
Reconciliation logic should attempt an exact match on MPAN or MPRN first, because that is the identifier both the broker and the supplier ultimately settle against, with a documented, auditable fallback — matching on customer name and site address — for the minority of statement lines that arrive without a clean meter point reference.
Classify variances instead of just flagging them
A useful reconciliation engine assigns each variance to a category — timing, estimate revision, rate versioning, clawback, or genuinely unexplained — before it reaches a person. This is what turns a queue of hundreds of unexplained figures into a short list of the ones that actually need investigation, which is usually a fraction of the total.
Run reconciliation on a schedule, not a single pass
Because settlement data arrives progressively, the engine should re-run reconciliation for a given contract at defined intervals — for example, at initial confirmation, at first supplier remittance, and again after any consumption true-up — closing out each contract's reconciliation status only once no further data is expected to change it.
This is the same architectural separation we describe for the broader commission and clawback engine on the broker CRM page linked above, and it is the piece of a broker CRM build most often underscoped, because it looks, from the outside, like a reporting feature rather than the calculation engine it actually needs to be. For the wider cost picture of building this alongside the rest of a broker platform, see our energy broker CRM cost guide, and for how the discovery process identifies which of these design decisions apply to a specific book of business, see discovery and scoping.