From weeks to days. Hundreds of invoices a minute.
A configurable billing platform for a retirement recordkeeping company, distributing payments among plan sponsors, advisors, third-party administrators and vendors. It replaced a process built on SQL queries and Excel.
The situation
The client is a retirement recordkeeping company. Money arrives from plan sponsors and has to be distributed among advisors, third-party administrators and vendors. Working out who is owed what is not simple arithmetic: discounts may apply, plans have minimum and maximum fees, and certain securities are excluded from the fee calculation altogether.
All of it ran on SQL queries and Microsoft Excel, with people in between. It worked, but it took weeks, and the staff time it consumed grew with the business.
What made it hard
The fee logic is a hierarchy, not a formula.
Discounts, minimums, maximums, security exclusions and offsets interact, so a fee depends on how they are configured together. Getting that right, and keeping it configurable without allowing a configuration to produce a nonsensical fee, is the core of the product.
- Discounts
- Plan minimums and maximums
- Security exclusions
- Offsets
The money goes to several parties, each under a different agreement.
Advisors, third-party administrators and vendors are not variations of one payee; each is paid under a different agreement. Invoice amounts also had to be adjusted automatically by offsetting against plan funds or asset sales, so the calculation reaches into balances instead of sitting beside them.
Fees move with the market.
Fee calculations depend on aggregated market values. The engine retrieves and calculates the relevant values as part of the billing process, so fees reflect the applicable valuation inputs.
Fiduciary duty means the output has to be defensible.
Every number the engine produces has to be reconstructable, so audit logs and accounting visibility were built in from the start. A fee questioned later can be traced back to the agreement and the inputs that produced it.
Operators work from financial, operational and regulatory reports, and background processing is logged, so a run can be followed after the fact.
The old rules lived in queries and spreadsheets.
The logic sat in query joins and cell formulas written by people who may no longer be at the company, and none of it was documented. Extracting the real rules, and separating the deliberate ones from the accidental ones, could not be rushed.
What was built
A configurable rule engine with a customizable fee hierarchy and market value calculation. Contractual fee arrangements are stored in the system, not just the numbers derived from them, so a fee can be reproduced a year later. Invoice and statement generation run on automated schedules, ACH payments are handled in the platform, and audit logs and accounting visibility run throughout.
A horizontally scalable multi-tenant cloud architecture, with a back-office interface designed for the people who run billing. Results integrate with the customer’s general ledger, trust and recordkeeping systems, reducing manual handoffs and supporting the broader financial workflow.
Fee structures vary by plan and by account arrangement, and each comes with its own billing periods, adjustments and reporting needs. The rules have to apply the same way every time, including at quarter-end, when billing volume can reach roughly five times that of a regular month. In 2026, March and June each ran at about that level.
.NET Core and Angular, MS SQL Server, RabbitMQ for queuing, and App Insights and Log4net for instrumentation.
The platform, January to September 2026
Figures are from the platform’s own reporting. Transaction volume covers January to September 2026. They describe the scale and scope of the work, not billing accuracy.
What changed
The client’s stated goals were to reduce the labor cost of billing, ensure fiduciary responsibility and due diligence, and build transparency about fees, service costs and portfolio detail for their own clients.
The engineering decision that mattered
Financial calculations need to be predictable, traceable, and defensible. The challenge wasn’t simply automating fee calculations; it was preserving complex business rules while making the system easier to operate, audit, and extend.