If you run a multi-platform advice firm, you probably know the feeling: it is the third week of the month, someone is cross-referencing a Transact report against a Quilter statement against a back-office fee schedule, and a number is off by forty pounds somewhere that will take two hours to find. Multiply that by twelve platforms, twelve months, and the cost in staff time alone is significant before you count the regulatory exposure from an error that slips through.
Fee reconciliation is one of the most common pain points I hear about from principals of advice firms between five and fifty advisers. It is also one of the problems where automation has the clearest, most measurable return. This article sets out what the options actually are, what level of build each requires, and what you need to have in place before any of it is worth doing.
Why fee reconciliation fails at scale
The core problem is structural, not human. Fee data lives in at least three places simultaneously: the platform (which holds the actual transaction), the back-office system (which holds your agreed fee schedule), and wherever you produce client-facing reports or invoices from. When those three sources do not talk to each other, someone has to manually bridge the gap. That someone is usually a paraplanner or an administrator who has better uses for their time.
The failure modes are predictable. Fees that should have been collected are missed because a platform did not apply the correct rate after a review. Fees that were collected are applied to the wrong client account. Platform transaction files come in different formats across providers, so any manual consolidation step introduces transcription risk. And when something does go wrong, finding it requires working backwards through multiple systems, none of which speak the same language.
This is often a data architecture problem that technology can solve, once you understand which level of solution the problem actually needs.
What level of automation does this require
Not every fee reconciliation problem needs a custom build. Most firms I speak to are operating at a level of complexity that sits squarely at Level 2 (integration), and some can solve the immediate problem entirely at Level 1 (education), by using tools they already have.
Level 1 (education) applies if your back-office system already has a reconciliation module you are not using, or if your platforms already export in a compatible format your system can import natively. Intelliflo, for example, has direct integrations with a number of investment platforms that allow account data to be pulled in without manual re-entry[1]. If you are on Intelliflo and you have not explored what its platform integrations already do, that is where I would start. The fix may be a configuration change, not a build.
Level 2 (integration) is the right level for firms where the back-office system and the platform data do not connect natively. Here, a workflow tool such as n8n, Make, or Power Automate sits in the middle: it pulls data from platform export files (usually CSV or XML), matches them against your fee schedule in the back-office or a structured spreadsheet, flags discrepancies above a defined threshold, and routes the exception report to whoever needs to review it. This is configuration work, not software engineering. A well-scoped Level 2 build typically runs from a few hundred to a couple of thousand pounds, takes days to weeks to set up, and requires human sign-off at the exception stage before any action is taken.
Level 3 (custom build) applies only if your fee model is genuinely complex across a large number of platforms with bespoke charging structures, or if you need the reconciliation output to feed directly into a regulated reporting system with full audit trail requirements. This is real engineering, and it warrants a proper scoping exercise before you commit to it.
A disciplined approach involves trying to solve at Level 1 before assuming you need Level 3. Most firms who come to me thinking they need a custom build actually need an integration they have not configured yet.
What a Level 2 reconciliation workflow actually looks like
A working fee reconciliation automation at Level 2 has five components.
First, a consistent data input. Platform exports need to land in a predictable place in a predictable format. The most reliable way to achieve this is a shared folder (SharePoint, Google Drive, or equivalent) with a standardised naming convention, into which each platform’s scheduled export drops automatically. Where platforms support scheduled FTP or SFTP export, use that. Where they do not, a scheduled manual export at a fixed point each month is still better than ad hoc.
Second, a mapping layer. Each platform will describe the same thing differently. One will call it “adviser charge”; another will call it “ongoing advice fee.” The automation needs a lookup table that translates each platform’s terminology into a single consistent field structure before any matching happens. This is the part most firms underestimate. Building the mapping layer carefully at the start saves hours of debugging later.
Third, the match logic. The workflow compares each collected fee against the agreed fee schedule for that client and that period. A match within a defined tolerance (typically one or two pounds, to account for rounding) is logged and closed. A mismatch above the threshold is flagged as an exception and routed for human review before anything else happens.
Fourth, the exception report. This is the human checkpoint. An automated workflow can identify where the numbers do not agree. It cannot decide why, and it cannot authorise a correction. The exception report should go to a named person, include enough context to investigate without logging into the platform, and require a deliberate action (approve, reject, or escalate) before the workflow proceeds. The human review step is not optional in a regulated context.
Fifth, an audit log. Every match, every exception, every human decision should be recorded with a timestamp. This is what you produce if a client raises a query or if the FCA asks how you identified and resolved a fee error.
What to have in place before you build
Automation of a broken process produces broken automation faster. Before building anything, three things need to be true.
Your fee schedules need to be the single source of truth. If different advisers have agreed different rates with the same client, and those rates live in different places, no automation will reconcile correctly. Centralise the fee schedule in your back-office system first, and make sure it is current.
Your platform access needs to support scheduled exports. Not all platforms make this straightforward. Some require a manual download. If you have platforms that will not support scheduled or automated data extraction, you will need a manual handoff step into the automated part of the workflow, and that needs to be clearly documented.
You need to know who owns each exception. An automation that flags discrepancies but routes them to a shared inbox that nobody consistently monitors is worse than the spreadsheet it replaced, because errors become invisible rather than slow. Name the person, name the review window, and put it in writing.
What to do now
If fee reconciliation is a material cost or risk in your firm, here is a sensible sequence.
First, audit your current platforms’ native integrations. Before spending anything, spend an hour with your back-office provider’s support team finding out what platform data can already be pulled in automatically. This is the Level 1 check.
Second, map the gap between what is automated and what is manual. List every step in your current reconciliation process. Mark each one as automated, semi-automated, or manual. The manual steps are where errors and time cost accumulate. This gives you an honest picture of what an integration would actually need to replace.
Third, centralise and validate your fee schedules. This is unglamorous but necessary. No reconciliation automation is reliable if the schedule it is matching against is out of date or held in multiple places.
Fourth, scope the integration before you build it. A Level 2 integration built without a clear spec will take three times as long and reconcile inaccurately. The spec should cover: which platforms, what data fields, what the match logic is, what the exception thresholds are, and who reviews exceptions.
Fifth, keep a human in the loop for every exception. The automation’s job is to find the discrepancies. The human’s job is to resolve them. The system should not move money, trigger corrections, or close exceptions without a deliberate human decision. This is not a limitation of the technology. It is the correct design for a regulated process.
A note on AI in the reconciliation workflow
AI language models are increasingly being marketed as part of financial back-office automation, and they can play a useful role in specific places, for example, in classifying ambiguous fee descriptions or drafting the exception summary that goes to the reviewing adviser. But they are not the right tool for the core matching logic. Matching a collected fee against a schedule is a deterministic task. It has a correct answer, and that answer should come from a rule, not from a model that could produce different outputs on different runs. AI-generated outputs in reconciliation workflows should be treated as a drafting aid that requires human review, not as a definitive conclusion[2]. The FCA’s operational resilience requirements, including third-party reporting obligations introduced under PS26/2, reinforce the principle that firms need to understand and be able to explain the processes underpinning their financial operations[3].
Closing
Fee reconciliation is a solved problem for firms that approach it methodically. The tools to automate it at Level 2 are widely available, not expensive, and do not require an engineering team. What they do require is clean underlying data, a clear spec, and a human checkpoint that you take seriously. Get those three things right, and the spreadsheet becomes unnecessary.
If this is an area your firm is actively working through, a discovery call with Cordrey Consulting is a sensible place to start.
This article is for informational purposes only and does not constitute regulated financial advice or a compliance opinion. Consult a qualified compliance professional for advice specific to your firm.
Sources
[1] Intelliflo, ‘Take a simpler route to leading funds with Intelliflo and WealthLink’, Intelliflo Insights, 23 May 2026. Available at: https://www.intelliflo.com/insights/thought-leadership/take-a-simpler-route-to-leading-funds-with-intelliflo-and-wealthlink
[2] Wharton (2026) ‘AI performance variability: empirical testing of task suitability’, Wharton School, University of Pennsylvania. [Case study cited for the principle that AI performance variability requires firms to test empirically which tasks are suitable for automation.]
[3] FCA, ‘PS26/2: Operational incident and third-party reporting’, Financial Conduct Authority, 2026. Available at: https://www.fca.org.uk/publications/policy-statements/ps26-2-operational-incident-third-party-reporting