Hansen Technologies Alternatives: Keep the Billing Engine, Change Vendors, or Build Your Own

Why teams start looking for a Hansen alternative

Rarely because bills are wrong. Usually because the business has changed shape and the platform has not kept up with the pace at which it needs to change. A retailer wants to launch a time of use product with a novel structure, a communications provider wants to bundle connectivity with a partner service, and the estimate that comes back is a change request with a delivery slot rather than a configuration task. When that repeats for a year, the commercial team starts believing the platform is the reason they cannot compete on product.

The second reason is roadmap uncertainty. Hansen's portfolio has grown substantially through acquisition, which is a normal and often sensible way to build a company, but it means the product line you are on has its own history, its own architecture and its own modernisation timeline. Customers on different lines get different answers about where investment is going. If your line is not the one attracting the current investment, that is a legitimate strategic concern and worth raising directly at renewal rather than inferring from silence.

The third is cost shape. Billing platforms in this class are quoted, usually tied to account or subscriber volume, with implementation and change delivered as services. Growth reprices the platform, and every product idea carries a services cost, so the run rate never quite settles at a number finance can plan around.

What Hansen genuinely does well

The billing engine is the product, and billing engines are underrated by everybody except the people who have tried to write one. Rating consumption accurately, applying tariffs that changed mid period, prorating a mid cycle plan change, handling tax by jurisdiction, running arrears and collections, producing an invoice that survives a regulator's inspection and a customer's lawyer, and doing it for every account on a fixed calendar without fail: that is a genuinely hard problem with no partial credit.

Domain depth is the second strength. Hansen has served energy, water, communications and pay television for a long time, which means the regulated market complexity that surprises newcomers is already encoded in the product. It also serves organisations that the largest global vendors treat as too small to bother with, which matters if you are a mid sized retailer or operator with genuinely complex billing and a modest customer count. And the company has been around long enough that continuity is not a gamble, which is not a trivial consideration when picking who calculates your revenue.

Where it actually strains

• Configuration ceilings on product design. Tariffs that fit the model are configuration. Tariffs that do not are development, and commercial teams cannot easily tell in advance which category a new idea falls into.
• Change delivered as services. When most substantial change arrives through the vendor's professional services, your product velocity is bounded by their delivery capacity and your budget cycle rather than by your own team.
• Upgrade gravity. Heavily customised deployments make version upgrades into their own projects, which encourages deferral, which makes the eventual upgrade larger. The pattern is familiar in every long lived enterprise product.
• Reporting rigidity. Standard reports cover finance and operations. The cross cutting analysis, margin by product by cohort by channel over time, usually ends up in a warehouse you built anyway, which raises the question of what else belongs outside the platform.
• Portfolio breadth. A vendor serving several verticals across several acquired product lines allocates engineering attention across all of them. Your regulatory change competes with someone else's in a different market.
• Data portability. Rated usage, tariff history and invoice detail live in a model built for the platform. Extracting them in a form another system can consume is a project, and its size is the honest measure of your switching cost.

Your realistic options

• Stay and renegotiate scope. Take the last two years of change requests to the renewal conversation and ask which of them should have been configuration. That question, asked with evidence, changes commercial discussions more than a competitive bid does.
• Switch vendors. In utilities the comparisons are Gentrack, Oracle's customer care and billing products, SAP for utility billing, Itineris and Kraken Technologies, plus a set of newer retail platforms. In communications the field includes Amdocs, CSG Systems, Netcracker, Optiva and Comarch. A swap is a full reimplementation, so treat it as a programme, not a migration.
• Keep the engine, own the surface. Leave rating, invoicing and collections where they are, and build self service, agent tooling, product configuration workflows and analytics against extracted data. Most of what frustrates the business lives in that surface, not in the engine.
• Rebuild for a specific book. New brands, a wholesale line, a small retail entrant or an MVNO can run a purpose built billing stack without inheriting decades of legacy tariff structure. This is the only situation where building the core is a reasonable bet.

When a custom build pays back

Start from what breaks if it is wrong. Self service portals, agent consoles, product catalogue workflows, partner reporting and margin analytics can all be fixed the next morning if they are wrong. A misrated invoice sent to a hundred thousand customers cannot. Build the first category with enthusiasm and treat the second with suspicion.

That first category is bigger than most operators realise. Customers judge you on the bill presentation, the payment experience and whether the portal shows what they expect, none of which requires touching rating logic. Staff judge you on how many systems they need to answer one question. Finance judges you on whether margin by product is available without a spreadsheet. All of that can be built on top of an extract, in months, at a fixed cost, without any risk to a bill run.

Building the core is defensible in exactly one scenario: a book of business with simple, modern tariffs and no legacy, where you can define the rules from scratch and prove them against a small population before scale. A new brand, a wholesale or partner billing line, an internet of things connectivity business. In that shape, a purpose built platform with clean product modelling is achievable and gives you the product velocity the incumbent could not. Extend it later if it earns the right, and never migrate the legacy book onto it just to consolidate.

Migration reality

A billing migration is judged on one number: how many invoices differed and by how much. Everything in the plan should serve that comparison.

Start with archaeology. Every tariff ever offered, including the ones closed to new customers but still active for someone, every discount granted as a retention gesture, every contractual exception negotiated with a large account. This is normally undocumented and lives in configuration and in the memory of two long serving employees. Extract it before you design anything.

Then plan a dual run. Both systems rate the same usage for at least two full billing cycles, and you reconcile line by line, not in aggregate. Aggregate totals can match while thousands of individual customers are wrong in offsetting directions. Migrate in waves by segment or cycle, never the whole base at once, and keep a rollback defined per wave.

Carry the operational state that people forget: payment mandates and direct debit authorisations, arrears positions and payment arrangements, dunning stage, credit balances, open disputes, tax settings, and in regulated markets the industry data flows and message history that let you prove what you sent and when. Keep a read only archive of historical invoices for the full statutory retention period, because customers and regulators will ask about periods your new system never processed.

Cost bands

Billing platform pricing in this class is quoted rather than published, generally scaled to account or subscriber volume, with implementation and ongoing change billed as professional services and a multi year term attached. A vendor swap is a reimplementation programme, not a migration project, and should be budgeted accordingly. On the custom side, using what Digital Heroes typically delivers as the frame: a customer and staff facing layer over an existing billing engine, covering self service, bill presentation, agent tooling and margin analytics, runs roughly $80k to $200k over 12 to 20 weeks. A purpose built billing platform for a smaller retailer, new brand, wholesale line or MVNO, with product modelling, rating, invoicing, payments and collections, runs roughly $250k to $550k. Those are build costs you own rather than a fee that reprices as your customer base grows.

The honest recommendation

If your bills are accurate and your cycle completes on time, keep the engine. That is not timidity, it is an accurate reading of where the risk sits. Push hard at renewal on the two things that actually hurt, which are the cost of change and the clarity of your product line's roadmap, and get both in writing. Build the surface: self service, agent tooling, product workflows and analytics, where speed is worth money and mistakes are cheap. Consider a full custom platform only for a clean book with no legacy, and switch vendors only when the relationship is genuinely broken, understanding that you are buying a reimplementation and a fresh set of the same structural constraints under a different logo.