If you run a multi-platform advice firm, you probably know the feeling. It’s the third week of the month, someone is checking a Transact report against a Quilter statement against a back-office fee schedule, and a number is forty pounds out somewhere that will take two hours to find. Multiply that by twelve platforms and twelve months, and the staff time alone adds up before you count the regulatory exposure from an error that gets through.

Fee reconciliation is one of the most common sources of pain in advice firms of five to fifty advisers, and one of the clearest places for automation to pay back in a way you can measure. This page sets out the options, what level of build each needs, and what has to be in place before any of it is worth doing.

Why fee reconciliation fails at scale

Fee reconciliation fails because of how the data is spread out, not because of the people doing it. Fee data lives in at least three places: the platform, which holds the actual transaction; the back-office system, which holds your agreed fee schedule; and wherever you produce client reports or invoices. When those three don’t talk to each other, someone has to bridge the gap by hand, and that’s usually a paraplanner or an administrator with better uses for their time.

The failures are predictable. A platform doesn’t apply the new rate after a review, so a fee is missed. A fee is collected but applied to the wrong client account. Each provider’s transaction file comes in a different format, so every manual step to combine them adds a chance of a copying error. When something does go wrong, finding it means working backwards through several systems that each describe things differently.

It’s a data problem, and technology can fix it once you know which level of solution it needs.

What level of automation does this require

Most fee reconciliation problems need an integration (Level 2), and some can be fixed with tools the firm already has (Level 1). Few need a custom build.

Level 1: education

Level 1 applies if your back-office system already has a reconciliation module you’re not using, or your platforms already export in a format your system can import directly. Intelliflo, for example, has direct integrations with a number of investment platforms that pull account data in without re-keying. If you’re on Intelliflo and haven’t looked at what its platform integrations already do, that’s where I’d start. The fix may be a configuration change rather than a build.

Level 2: integration

Level 2 is for firms whose back-office system and platform data don’t connect directly. A workflow tool such as n8n, Make or Power Automate sits in the middle. It pulls in each platform’s export file (usually CSV or XML), matches it against your fee schedule in the back office or a structured spreadsheet, flags discrepancies above a set threshold, and sends the exception report to whoever reviews it. This is configuration work, not software engineering. A well-scoped Level 2 build typically costs from a few hundred to a couple of thousand pounds, takes days to weeks to set up, and needs human sign-off at the exception stage before anything happens.

Level 3 (custom build) only applies if your fee model is complex across a large number of platforms with custom charging structures, or if the reconciliation needs to feed straight into a regulated reporting system with a full audit trail. That’s real engineering and deserves a proper scoping exercise before you commit.

Try to solve it at Level 1 before assuming you need Level 3. Quite often a firm that thinks it needs a custom build needs an integration it hasn’t configured yet. For the wider set of integrations an advice firm can start with, see AI for financial advisers.

What a Level 2 reconciliation workflow actually looks like

A working Level 2 fee reconciliation has five parts.

  • A consistent data input. Platform exports need to land in a predictable place in a predictable format. The most reliable way is a shared folder (SharePoint, Google Drive or similar) with a standard naming convention, where each platform’s scheduled export drops automatically. Where a platform supports scheduled FTP or SFTP export, use it. Where it doesn’t, a manual export at a fixed point each month still beats doing it whenever someone remembers.
  • A mapping layer. Each platform describes the same thing differently. One calls it “adviser charge”; another calls it “ongoing advice fee”. The automation needs a lookup table that translates each platform’s terms into one consistent field structure before any matching happens. Most firms underestimate this part, and getting it right at the start saves hours of debugging later.
  • The match logic. The workflow compares each collected fee against the agreed fee schedule for that client and period. A match within a set tolerance (typically a pound or two, to allow for rounding) is logged and closed. A mismatch above the threshold becomes an exception for human review before anything else happens.
  • The exception report. This is the human checkpoint. The workflow can find where the numbers disagree, but it can’t decide why, and it can’t authorise a correction. The report should go to a named person, include enough context to investigate without logging into the platform, and need a deliberate action (approve, reject or escalate) before the workflow carries on. In a regulated firm, this step isn’t optional.
  • An audit log. Every match, every exception and every human decision is recorded with a timestamp. That’s what you produce if a client raises a query or the FCA asks how you found and fixed a fee error.

What to have in place before you build

Three things need to be true before you build, because automating a broken process just produces the same errors faster.

  • Your fee schedules are 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’s current.
  • Your platforms support scheduled exports. Not all of them make this easy, and some need a manual download. If a platform won’t support scheduled or automated extraction, you’ll need a manual handoff into the automated part of the workflow, and that handoff needs writing down.
  • You know who owns each exception. An automation that sends discrepancies to a shared inbox nobody watches 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.

A note on AI in the reconciliation workflow

AI is useful around the edges of fee reconciliation, but it shouldn’t do the matching itself. Language models are increasingly sold as part of back-office automation, and they can help in specific places, such as classifying unclear fee descriptions or drafting the exception summary for the reviewing adviser. Matching a collected fee against a schedule has one correct answer, and that answer should come from a rule, not from a model that might produce something different on another run. Treat any AI output in the workflow as a draft that a person reviews, never as the conclusion. The FCA’s operational resilience requirements, including the third-party reporting obligations introduced under PS26/2, reinforce the principle that firms need to understand and be able to explain the processes behind their financial operations[1].

The tools for automating fee reconciliation at Level 2 are widely available, not expensive, and don’t need an engineering team. What they do need is clean data underneath, a clear spec, and a human checkpoint you take seriously.

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] 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