Fee billing remediation is one of the more predictable exercises in asset and wealth management. The pattern repeats: a review finds a population of accounts billed on terms that differ from the signed agreement, the differences run in both directions, and the investigation establishes that nobody could have detected it because the authoritative terms were never held anywhere a system could check.
The underlying problem is not arithmetic. Billing engines compute correctly from what they are given. The problem is that what they were given came from a one-time human reading of a fee appendix, and every subsequent amendment, breakpoint negotiation, household aggregation and temporary waiver arrived through a different channel, at a different time, with no reconciliation back to the document.
This datasheet sets out the fee terms worth holding as structured data on the agreement record, the reconciliation checks that catch drift, and the evidence each check should leave behind. It is deliberately mechanical, because the control value comes from doing the same comparison on a schedule rather than from doing anything clever.
The five places fee errors concentrate
Errors cluster around exceptions to the base rate. A plain percentage on a single account billed quarterly in arrears is rarely wrong. Everything that modifies that arrangement is where the population comes from.
- Breakpoint application, whether tiered or flat application applies, and whether the threshold is measured on the account, the relationship or the household.
- Aggregation and householding, which accounts are included, how membership changes are captured, and what happens when a member closes or transfers out.
- Valuation and proration, the valuation date convention, and how mid-period contributions, withdrawals and account openings are prorated.
- Waivers and promotional rates, the discount, its basis, and above all its end date, which is the field most often absent from both the document and the system.
- Amendments after signature, fee changes agreed in a letter, an email or a renegotiation that never reached the billing configuration or the contract record.
Each of these is an exception that someone negotiated for a reason. The reason is usually sound and the documentation usually thin, which is the combination that produces a remediation population three years later. The pattern is consistent enough that a review can be scoped around these five categories and will find the great majority of the differences without reading every agreement in full.
A tier table without a statement of how it applies is ambiguous, and the two readings produce materially different fees on the same balance. Billing systems have to pick one, and they pick whichever was configured first. Making application method an explicit field on the agreement record, and populating it from the document rather than from the system, resolves an error class that is otherwise invisible until a client recalculates.
The control set that keeps billing aligned
Five controls do the work. None of them require a new billing platform, and all of them depend on the fee terms existing as data somewhere other than inside a PDF.
- Capture the eight core fee fields at execution. Basis, rate table, breakpoint thresholds and application, valuation convention, frequency and timing, proration rule, aggregation membership and waiver end date, held on the agreement record
- Reconcile on every fee-affecting event. Amendments, breakpoint changes, aggregation additions and waiver grants each trigger a configuration check at the time, which is when the detail is still known
- Run a periodic full reconciliation. A scheduled comparison across the population catches what the event process missed, and the volume of findings measures how well the event process is working
- Track waiver and promotional end dates as obligations. Each discount carries an owner and an end date, so under-collection ends when it was agreed to end rather than when somebody notices
- Keep the reconciliation package as evidence. Dated comparison, differences, dispositions, approvals and reviewer sign-off, retained against the agreement so the control can be demonstrated rather than described
A five-step roadmap for getting fee terms under control
Step 1, extract fee terms from the signed population
Pull the eight core fields from the executed agreements and their amendments. Extraction tooling handles the standard cases well; the exceptions and handwritten side letters need human review, and they are also where the errors are, so budget attention accordingly.
Step 2, compare against live billing configuration
Run the first reconciliation and expect findings in both directions. Over-collections need remediation and usually client notification; under-collections need a decision on whether to correct prospectively. Record both, because the ratio tells you something about how the drift happened.
Step 3, close the event path
Identify every route by which fee terms can change, including relationship manager negotiation, retention offers, operational corrections and acquisition onboarding. Each route needs to write to the agreement record, not only to the billing system. This step is the one that stops the problem recurring.
Step 4, instrument the expiring items
Load waiver end dates, promotional rate expiries and any time-limited aggregation arrangements as obligations with owners. These are low-effort, high-return controls because nothing else in the operating model is looking for them.
Step 5, report findings and ageing, not just totals
Publish reconciliation findings by cause, by channel and by ageing. The cause breakdown tells you which template or process to fix; the ageing tells you whether detection is improving. A single count of exceptions tells you neither.
Reconcile billing to the agreement, not the memory
Aavenir holds fee schedules, breakpoints, aggregation and waiver end dates as fields and obligations, so reconciliation runs against the contract itself.
Why this is a contract problem rather than an operations problem
Operations teams are usually blamed for billing errors and are usually not the cause. They configure accurately from the information they receive. The failure is upstream: the authoritative terms were never structured, so there was nothing to configure against and nothing to check back to. That makes it a contract data problem with an operational symptom, and it explains why repeated process tightening inside billing operations produces diminishing returns. The fix has to start where the terms are agreed, which is the same reason firms running structured vendor oversight contract controls find the discipline transfers directly.
Fee field, failure mode and check
The table pairs each core field with the error it prevents and the check that confirms it. Use it to define the reconciliation script once rather than negotiating scope each cycle.
| Fee field | Typical failure | Check | Evidence |
|---|---|---|---|
| Rate table and tiers | Wrong band applied | Field to configuration comparison | Dated comparison extract |
| Breakpoint application | Flat used where tiered agreed | Explicit method field match | Field value with clause reference |
| Aggregation membership | Account missing from household | Membership list reconciliation | Approved membership roster |
| Proration rule | Mid-period flow mishandled | Recalculation on sample accounts | Sample recalculation worksheet |
| Waiver end date | Discount running past expiry | Obligation due date review | Closure record with effective date |
None of this is sophisticated, which is the point worth making to a sponsor. Billing accuracy does not need a better engine or a larger operations team; it needs the agreed terms to exist as structured data, a defined path by which every change reaches that data, and a comparison that runs on a schedule rather than on request. Firms that do both find the remediation population shrinks to the genuinely ambiguous cases, and those cases get resolved at drafting next time because the ambiguity is now visible in a field rather than buried in an appendix. Firms treating this as part of wider third-party risk contract automation usually find the same extraction work serves both purposes.
For related guidance, see DORA and ICT contracts: what Article 30 requires, A DORA guide to ICT third-party contract registers and Recordkeeping duties your vendor contracts must carry.
