Fee Harmonisation After a Merger: A Finance Case From Pricing to Go-Live

A case: two fee structures, one platform, and the revenue in between

Fee harmonisation after a merger looks like a pricing exercise and behaves like a revenue migration. This case follows a common situation: a group merging two entities after an acquisition, each with its own customer fee schedule and its own platform. It sets out the full sequence, from assessing both fee structures through defining the target, migrating configurations, testing calculations and managing regulatory requirements, to go-live and decommissioning, with the finance checks that belong at each step. The case is representative, not a named company. NEO Expertise supports finance teams through the finance side of integrations like this one: revenue impact, reconciliations and post-migration checks.

The Situation

A banking group has acquired a smaller institution and, a year later, merges it into its existing operating entity. The acquired institution’s customers keep their accounts, but they move to the group’s platform, and the group wants one fee schedule for everyone.

The two fee schedules overlap only partly. Some services carry a fee at one entity and none at the other. Fees with the same name are calculated differently. The acquired entity’s fees are configured in a system that will be switched off after the migration.

The programme involves business, finance, banking operations and technology teams, with dependencies between them. Finance’s questions are specific: what does the new schedule do to fee income, will every fee be calculated correctly on the new platform, and how will we know after go-live?

Step 1: Document Both Fee Structures

The assessment started with the processes at both entities and the differences between them. For each fee, the team documented:

• The fee code and description in each system
• How it is calculated: flat, percentage, tiered, capped, or waived under conditions
• When it is applied: at transaction, monthly, or at an event such as card replacement
• Waivers and exceptions, and who can grant them
• The annual fee income it produced, taken from the general ledger by fee code

The fee schedule published to customers was not enough. The real calculation rules sat in system configuration, including waivers set at account level years earlier that appeared in no document.

Step 2: Define the Harmonised Structure

With both structures documented, the business defined the target fee schedule and the target platform. Finance compared fees across entities, identified those needing alignment, and modelled the revenue effect of each decision.

Illustrative revenue impact model from this case:

Fee	Entity A	Entity B	Harmonised	Annual effect
Monthly account fee	€4.00 (60,000 accounts)	€3.00 (45,000 accounts)	€3.50	−€360k on A, +€270k on B: net −€90k
International transfer	€15	€20 (18,000 per year)	€15	−€90k on B
Card replacement	€10 (9,000 per year)	Free (7,000 per year)	€5	−€45k on A, +€35k on B: net −€10k
Net annual effect on fee income				−€190k

The net effect was small. The distribution was not: 45,000 customers at entity B faced a higher monthly fee, and every one of them would have to be told in advance. The model turned a pricing discussion into two separate decisions, one about revenue and one about customer impact.

Step 3: Migration, Configuration and Testing

Migration requirements were documented fee by fee: what moves, how it is configured on the target platform, and which account-level waivers are kept. Business rules were written down and agreed with finance, banking operations and technology, and tracked in a dependency matrix, because several fees could not be configured until others were.

Testing was where finance added most value. Test cases covered every fee type, followed by end-to-end tests on real account data. Illustrative: a parallel calculation on 2,000 sample accounts produced 37 differences between the expected and the calculated fee. Three causes explained all of them:

• Rounding applied per transaction on one platform and per statement on the other
• Account-level waiver flags that had not been migrated
• A tier boundary configured as “greater than” instead of “greater than or equal to”

Each issue was fixed and retested. Nothing went live until the parallel run showed no unexplained differences.

Programme management held these threads together. One tracker listed every fee with its status in each stage (documented, decided, configured, tested, signed off), alongside the milestones, risks, open issues and dependencies across business and technology teams. Finance reviewed it weekly with one question in mind: which fees would reach go-live without a clean test result? Two did, in the week before the planned date. The go-live moved by ten days rather than launching with calculations nobody had proven, which cost far less than correcting a wrong fee on thousands of customer statements.

Step 4: Customer Impact and Regulatory Requirements

Integration risks were assessed alongside the regulatory requirements. For payment services in the EU, the Payment Services Directive (EU) 2015/2366 requires changes to a consumer framework contract, including charges, to be proposed at least two months before they apply. For consumer payment accounts, the Payment Accounts Directive 2014/92/EU requires a fee information document and an annual statement of fees.

Those rules set the timeline. Notices to the 45,000 affected customers had to go out two months before the new fees applied, so the fee schedule had to be final, and tested, before the notices were printed. Finance also tracked the potential customer impact: complaint volumes and account closures in the weeks after the notices.

Step 5: Go-Live, Reconciliation and Decommissioning

Go-live readiness was confirmed against a checklist: configurations signed off, parallel run clean, notices sent, and customer transitions scheduled. After go-live, finance monitored fee income daily for the first month, comparing actual fee income by fee code with expected income (volume multiplied by the new tariff). Any code more than a set tolerance away from expectation was investigated the same day.

The old system was decommissioned only after the first full month of fee income had reconciled, and after the historical fee data needed for complaints, audits and statutory retention had been archived in a readable form.

The programme ended with a documented fee consolidation playbook: the approach, templates, lessons learned and future procedures, ready for the next acquisition. The wider post-deal sequence is set out in the first 100 days finance integration roadmap, and customer data checks of the kind in our post-acquisition data check are a natural first step before any migration.

Where Fee Harmonisation Goes Wrong

• Working from the published tariff. The real rules sit in the system configuration and in account-level waivers.
• Testing on sample data only. Edge cases such as capped fees, waivers and tier boundaries only appear in real account data.
• Setting the go-live date before the notice date. The two-month notice period runs backwards from go-live, not forwards from approval.
• Switching off the old system too early. Once it is gone, a fee dispute from the transition period cannot be investigated.

This sequence assumes both entities’ fees are for broadly similar services. Where the acquired entity offers products the group does not, harmonisation is the wrong frame. Those products need a separate decision to keep, reprice or withdraw them, and a withdrawal has its own customer and regulatory process.

The Fee Harmonisation Checklist

Use this as a working checklist. Each item is a check to complete, not a topic to consider.

Document both structures

• ☐ List every fee, its code and its calculation rule from system configuration
• ☐ Capture waivers and exceptions, including those set at account level
• ☐ Pull annual fee income by fee code from the general ledger

Decide the target

• ☐ Compare each fee across entities and identify those needing alignment
• ☐ Model the revenue effect of every fee decision
• ☐ Count the customers who will face an increase

Migrate and test

• ☐ Document migration requirements and configuration for each fee
• ☐ Maintain a dependency matrix between fees and teams
• ☐ Run a parallel calculation on real account data
• ☐ Investigate, fix and retest every difference before go-live

Notify, go live and close out

• ☐ Confirm the notice period for each product and work backwards from go-live
• ☐ Send customer notices before the deadline
• ☐ Reconcile fee income by code daily for the first month
• ☐ Archive legacy fee data before decommissioning the old system
• ☐ Write the fee consolidation playbook for the next deal

Frequently Asked Questions

What is fee harmonisation after a merger?

It is the process of replacing two or more customer fee structures with one, after a merger or acquisition. It covers documenting both structures, defining a target schedule, modelling the revenue effect, migrating fee configurations to one platform, testing calculations, notifying customers and decommissioning the old system.

How much notice must customers get before fees change?

For payment services to consumers in the EU, changes to charges in a framework contract must be proposed at least two months before they apply, under the Payment Services Directive. Other products and jurisdictions have their own rules, so confirm the notice period for each product before setting a go-live date.

How do you check fees are calculated correctly after migration?

Run a parallel calculation on real account data before go-live and investigate every difference. After go-live, compare actual fee income by fee code with expected income, calculated as volume multiplied by tariff, daily for the first month, and investigate any code outside tolerance.