Ask the finance team at any broker or MGA that keeps its books in a legacy PAS how month end went and you may well be there a while.

The insurance ledger is in the PAS, but the statutory accounts, VAT, payroll and audit are in Xero or Sage, so every month someone moves the numbers from one to the other and makes them agree. The bank rec, credit control and reporting all happen inside a system built for placing risk, not for closing books. And when they need a report the PAS doesn’t make, they have to raise a ticket with the vendor and wait.

That’s PAS-based IBA, and the market still calls it a proper solution. The people who run it know better. They’re good at their jobs, but they have to work in a finance module inside a placing system, and the firm pays for two ledgers.

IBA is just bookkeeping

IBA is bookkeeping with a few extra rules. Premium comes in. Some of it goes on to the insurer and some you keep as commission. Claims and returns go back the other way. You record it all and match it to the bank. And because premium you hold for clients is client money, you keep it apart from your own and run a calculation to prove that what you hold matches what you owe.

Only two parts of that belong to insurance: keeping the money apart, and the calc. Both come from CASS 5, the FCA’s client money rules. The rest is plain double-entry, the same as any business runs.

Plain double-entry is a solved problem. Xero, Sage and NetSuite do it for millions of firms, with bank feeds, matching rules, aged debt, reports that work and an audit trail your accountant already knows. For them the ledger is the whole craft, while for a PAS vendor it’s a tab at the side of the screen, and it shows.

Nobody judges a CRM on whether it runs payroll. Yet somehow a broking system gets judged on whether it keeps the books.

You’re already paying for two sets of books

Every broking firm bigger than one person already runs proper accounting software, because it has to. Statutory accounts, VAT, payroll, corporation tax, management accounts and the audit all live in Xero or Sage or NetSuite. None of them live in the PAS.

So a firm with IBA in its PAS pays for two ledgers and then makes them agree by hand. The real books sit in the GL, while a weaker copy sits in the PAS. And every month someone in finance spends days closing the gap. A ledger is meant to hold you to account. Two ledgers that disagree hold nobody to anything.

We believe that the PAS should run the broking workflows, but the ledger should keep the books.

Why your PAS keeps your books

“It’s not a proper solution if it doesn’t have IBA.” We hear it in nearly every demo and every RFP. The line serves the vendors who say it, not the firms who hear it.

Putting the books in the PAS does two things for the vendor. It makes you hard to lose, because once your money and your daily work are tied together in one system, you can’t pull out one without the other. And it sells you a second ledger you’d otherwise buy from a firm that does nothing else. That was their choice, made for their reasons.

The excuse is compliance. You need it for CASS, they say, or for the FCA. The FCA has never told anyone to run IBA inside a PAS. It wants the calc right and the money kept apart. It doesn’t mind which software does the work.

The FCA already handles client money this way in other markets. Investment firms hold it under CASS 7. Payment and e-money firms safeguard it under their own rules. Nobody there thinks the safeguarding has to live inside the system that runs the work. CASS 5 asks for a right calc and money kept apart. It says nothing about where the ledger sits.

And in those markets the system that runs the work feeds the books. It doesn’t keep them.

• Payments. Stripe, Adyen and GoCardless move the money and pass the detail to your GL. Nobody expects Stripe to file the accounts.

• Payroll. ADP and Gusto run payroll and the HMRC returns, then post journals into the accounting system.

• Investment management. Firms keep one book of record for running the portfolio and another for valuation and reporting, both fed by the same events.

“Pairing Recorder with Xero is one of the best calls we’ve made. Bank recs in Xero take a fraction of the time they took in our old PAS, and our finance team works in a tool built for finance, not a module bolted onto underwriting.”

Laura Hancock, Yutree Underwriting

Insurance broking is one of the last places that still keeps the books inside the system that runs the work. The law doesn’t ask for it. The older vendors built it that way, and the market got used to it.

What good looks like

Give each system one job. The broking platform runs the policy from quote to renewal and records every money event. Your accounting package keeps the books, does the formal accounting and runs the calc. Transactions go from the platform into the ledger. The only thing that comes back is whether each invoice has been paid. The platform keeps no books of its own and does no matching.

Take one transaction. A broker binds a commercial policy with net premium of £10,000 and IPT at 12%, so £1,200, making £11,200 gross to the client. Commission is 20% of net, so £2,000. The insurer is owed £9,200: the £8,000 net premium left after commission, plus the £1,200 IPT it pays over to HMRC.

The platform records and works out the numbers. It never moves money. Cash moves in your bank, and every match happens in your ledger against the invoice the platform raised.

Everything after that matches back to the same record. The records reach your ledger through an API or as a file on a schedule, whichever suits you.

The calc then falls out of the ledger: the client money bank balance against what you still owe insurers and clients. Every line is already there, so there’s no second ledger to rebuild and no second set of numbers to check.

The real work is at the join between the two systems. Your ledger already holds your insureds as customers and your insurers as suppliers, so you map them once. After that, finance teams ask the same four questions.

The four questions finance asks

Can the customer see my commission? No. Commission is a line, and you choose which document it sits on. Put it on the insurer’s bill, not the customer’s invoice, and the invoice shows premium, IPT and fees. The commission is still in your books, the customer just doesn’t see it.

When does my income count? Every line on the insurer’s bill posts to the balance sheet, so only your commission and fees reach the P&L. The ledger’s own Profit and Loss report is your income, with no journals by hand. Count it at invoice, or date the insurer’s bill on the day the client pays in full so the commission lands that month - your accountant chooses. Either way it’s a setting, and paying the insurer never moves it.

Do I owe the insurer before my client has paid? Not on a paid basis. So the insurer’s bill shouldn’t sit in aged payables from the day you bind. The platform raises it as a draft, and the ledger keeps drafts out of aged payables. When the client’s invoice is marked paid, the platform hears about it and approves the bill. Only then does it show as due. Insurers that want paying on their own terms get their bills approved at bind.

How does an MGA send its brokers statements? Brokers pay off statements, not invoices. A ledger can’t make good ones on its own, because it doesn’t hold the policy detail and can’t roll a broker group’s branches together. The platform holds that detail. It reads which invoices are paid and sends each broker a statement of what’s still open, with the invoice number on every line, because that’s what brokers quote when they pay. Paid items drop off. A mid-month run chases the rest.

None of those answers needs a second ledger. Each is a rule about where a line lands and when, set once at the start. The matching stays in the ledger, and that matters. Two systems that each keep their own allocations will drift apart, and then nobody knows which one to believe.

Anyone who tells you the accounting has to live inside the PAS is selling you a PAS.

If you’re an MGA

For an MGA the model is the same but the numbers change. Premium held under a risk transfer agreement is the insurer’s money, not client money, so the calc covers fewer balances, usually return premium and claims money owed to policyholders. Settlement is usually per binder, in batches, against a bordereau, so the records roll up from policy to binder. Loss fund money belongs to the insurer and is tracked and reported on its own. Income covers binder commission and overrides, and profit commission only counts once you can measure it. Different numbers, then, but they still belong in the ledger.

Doesn’t two systems mean more reconciliation?

PAS vendors say two systems means more reconciliation, and for years they were right. The link between PAS and ledger was usually a summary journal with no detail behind it, plus account codes mapped by hand. Plenty of firms gave up and took the bundled module.

But that was bad plumbing, not a reason to keep everything in one box. When the platform writes each transaction into the GL as it happens, line by line, and reads back only whether it’s paid, the two have nothing to disagree about. The GL holds every line, while the platform knows what’s settled, so the month-end export and the second set of books go. The bank rec stays in the ledger, where it always worked.

The hard problems are somewhere else

Wherever the ledger sits, the hard client money problems stay hard. They were never about the box.

The hard part is cash. Premium comes in part-paid, in lumps, in different currencies, through more than one payment provider, against statements that don’t match. Then it gets split between insurers, brokers and sub-brokers down a long chain. Matching that money to the right policies and settling it cleanly is the real work. Cash in a trust account that nobody can tie to a policy is a real risk, and it’s there whether or not the ledger is bolted to the PAS.

Most of that work is routine. The client pays, the bank feed brings in the money, and the ledger matches it to the open invoice. That’s what Xero, Sage and NetSuite are built to do. It’s easier than PAS-based IBA ever made it, because the platform hands the ledger clean records with the policy reference, gross and net, the instalment plan and who’s owed what. Much of the pain in legacy matching comes from dirty data going in. Feed the ledger clean data and most payments clear themselves.

The rest needs a person’s judgement. One payment from a sub-broker covering forty policies. A part-payment. A remittance that doesn’t match the statement. Money split three ways down a chain.

That’s the work Diesta is built for. It reads remittance and statement files in whatever shape they come, matches payments line by line to policies, handles the splits down the chain and gives everyone the same view of who’s owed what. It plugs into the systems a payment touches: the PAS, the ledger and the bank. Solve the problem once, for everyone, and brokers, MGAs and insurers all get the benefit.

Below a certain size you don’t need a tool like that. Someone clears the odd ones by hand in the ledger, against the same clean records. Either way nothing gets lost. The platform says what should happen, the bank feed shows what did, the ledger clears the easy matches and runs the calc, and a recon engine or a person clears the rest. PAS-based IBA never made any of this easier. It keeps it in the same system as the broking, which makes that system harder to leave.

Income recognition is the other hard problem, and PAS-based IBA doesn’t help there either. When commission counts is a setting, as above. The hard part is around it: deferring commission taken up front, counting profit commission and overrides only once you can measure them, and for producing brokers, working out how much of a payment is yours and how much belongs to another broker. Those are FRS 102 and IFRS 15 calls. They belong with your accountants, in proper accounting software, not in a finance tab on a policy system.

Matching the cash, keeping the books and running the broking are different jobs. Putting them in one box doesn’t make the cash match. It just makes the box harder to leave.

What you get back

Move the books out of the PAS and into a proper ledger, and you get five things back.

Cost. Accounting software is cheap because millions of firms buy it. Xero or QuickBooks costs tens of pounds a month. IBA in a PAS comes inside a system that costs thousands a month, and you pay for books twice, because you still need a real ledger for your statutory accounts.

Bank feeds. Your bank sends every transaction into the ledger each day, with no statements to download or files to upload. Each invoice from the platform carries the policy reference and the exact amount due, so the ledger suggests the match and most payments clear without anyone looking them up. Reconciliation becomes a few minutes a day, not days at month end, and the client money balance in your books is current every morning.

Credit control. Where the ledger sends the customer invoice, it can add a pay-now link, chase on a schedule you set and show aged debt at any time.

Audit and people. Your auditor sees the same ledger and audit trail they see at their other clients, and many bookkeepers and finance hires already know Xero or Sage.

Freedom to switch. PAS vendors would rather you didn’t think about this one. If your books sit in a standard ledger fed by the platform, you can change broking platforms without touching them. You point the feed at the new system and finance carries on. With IBA in the PAS, switching means moving your live ledger and client money records along with everything else. That’s frightening, so most firms never do it, and the vendors know it. Keep the two apart and you can push on price, pick the right tool for each job, and walk if you need to.

Why we built Recorder this way

We built Recorder this way on purpose. It’s an API-first System of Work. It records the policy from quote to renewal, the documents, and who did what and when. Every money event it creates goes into your accounting software: premium booked, commission earned, money in and money paid on.

For example, with Xero it’s a live link via API. When you bind, Recorder writes the invoice, any credit note and the draft insurer bill straight into Xero. You reconcile in Xero as you do today, and Xero tells Recorder within seconds what’s been paid. We’re releasing the same kind of integration for Sage shortly. Other ledgers, NetSuite and the like, take an agreed file at whatever interval suits you. Stripe handles monthly premiums, instalments and subscription billing. If you’re not ready to move your books yet, there’s a structured export into your existing PAS for downstream IBA and finance, with direct API connections where they’re available. Where a specialist reconciliation engine like Diesta or Autorek is in play, we give it the policy-level feed it needs. Transactions always go out of Recorder, and the only thing that comes back is whether they’ve been paid.

Recorder runs your broking. Your accounting software keeps your accounts, which is the job it was built for. The calc runs off the same clean data in both.

When someone says it’s not a proper solution without IBA, what they mean is that every system they’ve used kept the books in the PAS, so they assume it must. It needn’t. The older vendors built it that way because it suited them. For the firms using it, that means paying twice, and doing a reconciliation they never needed, in a system that’s hard to leave.

Let the PAS run the broking. Let the ledger keep the books.