It’s just a rounding error

Famous last words on a massive monthly invoice. How a rounding problem in an energy company’s spot-price invoicing turned out to be an architectural one.

· Business

Famous last words on a massive monthly invoice.

A few years ago we were called in by an energy company to rescue the invoicing for their largest industrial customers. These customers had monthly bills of between $1m and $2m.

The invoicing system for this was a desktop database. Sitting off to the side of the core systems, quietly running the most commercially sensitive invoices in the company.

The wrinkle: these large customers were on spot pricing. The wholesale price moved every half hour, settled across 48 trading periods a day. It was the settlement of thousands of micro-transactions across transmission networks, lines companies, and the retailer, each with their own charge codes, each priced at the moment the electricity actually moved.

The presenting problem was rounding. Numbers that should have reconciled were drifting by amounts small enough to look like nothing on a single line item, but large enough to matter when you multiplied them across a huge number of half-hourly settlements.

The deeper issue was architectural. The original system had been built for traditional billing then modified, patch by patch, into something it was never designed to be.

Real-time financial systems break the assumptions baked into traditional architecture.

Data model, reconciliation model, audit model, dispute model. They all need rebuilding from the bottom up. And they need to live somewhere accountable.

Do you have business critical systems running off to the side of your core systems? If so, happy to talk it through.

Graphic: It’s just a rounding error. Famous last words on a massive monthly invoice. A cracked invoice screen showing a total of $1,988,765.42 breaks through a wall, with an old desktop computer in the rubble labelled legacy architecture and shadow IT.