This guest article first appeared HERE
A PAS is a transaction engine. It’s built to bind policies, calculate premium, process endorsements, and cancel coverage accurately, one policy at a time.
It is not a reporting system. It is not an analytics platform. And it was never meant to be an executive source of truth
Monday morning. You open your policy admin dashboard before the leadership meeting. Premium shows $4.2M, up 12%.
In the meeting, your CFO says she’s seeing $3.96M. Ops says $4.1M—before Friday’s cancellations.
Forty-five minutes later, you’re still arguing about which number is “real.”
The instinct is to be grumpy with your policy admin system. You’re paying six figures. It’s supposed to be the source of truth. You escalate. You push. You threaten to switch vendors.
And maybe things improve briefly before the same discrepancies come back.
If this keeps happening across teams, across systems, across vendors, it’s worth asking a harder question:
What if the system isn’t broken?
After working with dozens of MGAs, here’s the reframe that changes everything: your policy admin system isn’t failing you. You’re asking it to do a job it was never designed to do.
A PAS is a transaction engine. It’s built to bind policies, calculate premium, process endorsements, and cancel coverage accurately, one policy at a time.
It is not a reporting system. It is not an analytics platform. And it was never meant to be an executive source of truth.
The gap you’re experiencing isn’t a bug. It’s a category error. And once you see that clearly, you can stop fighting your vendor—and start designing a system that actually works.
To understand why your PAS falls short of your expectations, you have to understand what it was actually built to do.
A policy admin system is, at its heart, a transaction processing engine. Its job is to execute the individual operations that constitute insurance administration.
Binding a policy means capturing submission data, applying underwriting rules, calculating premium according to rating algorithms, generating policy documents, and creating the policy record. The system takes inputs (applicant information, coverage selections, effective dates) and produces outputs (premium amount, policy documents, database records).
Processing an endorsement means modifying coverage according to the requested change, recalculating premium for the remaining term, updating the policy record to reflect the new terms, and maintaining an audit trail of what changed and when. The system has to handle mid-term changes correctly—pro-rata premium adjustments, coverage modifications that don’t change premium, additions and deletions of covered items.
Handling a cancellation means applying the appropriate cancellation rules (flat, pro-rata, short-rate), calculating return premium, updating the policy status, and triggering any downstream processes (refund issuance, reinsurance notification, agent commission adjustment). Different cancellation types have different rules, and the system has to apply them correctly.
Every transaction is processed according to the policy’s terms and the system’s configuration. The system doesn’t make judgment calls—it executes the logic it’s been given.
For any individual policy, the PAS must be correct.
The premium calculation must be right. If the rating algorithm says this risk, with these characteristics, in this state, should be $12,847 in annual premium, the system must produce $12,847. Not $12,846. Not $12,850. Exactly $12,847.
The coverage terms must be accurate. If the policy provides $1M in liability coverage with a $5,000 deductible, the policy record must reflect exactly that. The declarations page must show it. Any system that queries the policy must see it.
The transaction history must be complete. Every change to the policy—every endorsement, every payment, every address update—must be logged with timestamps, user IDs, and before/after values. If someone asks what happened to this policy on March 15th, 2023, the system must be able to answer.
This is hard. Policies have dozens of fields. Rating algorithms have hundreds of variables. State-specific rules vary in ways that seem arbitrary until you understand the regulatory history. Edge cases are everywhere—policies that cross year boundaries, endorsements that change coverage retroactively, cancellations that are rescinded and reinstated.
It needs to handle version control of raters.
PAS systems are optimized for this complexity. Getting every policy right, every time, with full audit trail, is genuinely difficult and genuinely valuable. The vendors that do this well have earned their market position.
Beyond correctness, PAS systems are built for volume.
A midsized MGA might process hundreds of quotes per day, dozens of binds, continuous endorsements and cancellations. A large MGA might process thousands. The system has to handle this throughput reliably, without slowing down, without losing transactions, without creating backlogs that delay business.
The architecture reflects this priority. Batch processing handles high-volume operations efficiently. Queue management ensures transactions are processed in order and none are lost. Transaction logging captures everything for audit and recovery purposes. Database design optimizes for write operations, because that’s where the volume is.
This architecture is good at what it’s designed for. It’s not designed for the kinds of queries executives want to run.
The frustration with PAS systems comes from a mismatch between what executives need and what transaction systems provide.
Executives need simple answers to simple questions.
“What’s our premium this month?” This sounds like a straightforward question. There should be a number—one number—that answers it. The executive should be able to see it, trust it, quote it in meetings, put it in the board deck.
“Are we on track against plan?” This requires comparing actual to target. It assumes there’s an actual number (current premium) and a target number (budgeted premium) that can be compared. Both numbers need to use the same definition, or the comparison is meaningless.
“How’s the Smith program performing?” This requires aggregating across all policies in the Smith program—premium, losses, policy count, retention, whatever metrics matter. The aggregation needs to be consistent with how the question was asked.
Executives need numbers they can trust, quote, and act on without caveats. They need to be able to say “we’re at $4.2M” without adding “but that might change” or “depending on how you count it” or “according to one of our three systems.”
This is a reasonable need. It’s what executives at every company need. It’s just not what transaction systems provide.
The fundamental mismatch is between policy-level data and portfolio-level views.
Your PAS stores policy-level data. Policy 12847 has $14,500 in premium. Policy 12848 has $8,200. Policy 12849 has $22,100. Each individual record is correct.
Executives need portfolio-level views. What’s the total premium for all policies? What’s the average premium? What’s the premium by state, by product, by month?
Aggregation seems simple—just add up the numbers—but it requires decisions:
These decisions aren’t made in the PAS. They’re made by whoever built the report or dashboard. Different reports make different decisions, so they show different numbers. The PAS didn’t cause the discrepancy—the aggregation logic did.
When the PAS shows “premium,” what does that mean?
It might mean gross written premium—the full premium on every policy, before any adjustments. It might mean net written premium—after cancellations and endorsements. It might mean earned premium—the portion corresponding to coverage that’s already been provided. It might include policy fees, or exclude them. It might include surplus lines taxes, or not.
The definition is embedded in how the system was configured, often years ago, often by someone who’s no longer with the company. The configuration made sense at the time. It might not match what executives mean when they say “premium” today.
The executive dashboard might use one definition. The finance report uses another. The bordereaux uses a third. Everyone says “premium” and means something different.
When the dashboard shows $4.2M and finance shows $3.96M, the difference might not be an error. It might be a definition difference—one includes fees, the other doesn’t; one is net of cancellations, the other is gross. Both numbers are “correct” according to their definitions. Neither number is “wrong.” But they don’t match, and explaining why takes longer than it should.
The PAS doesn’t reconcile to anything external. It’s a closed system. It knows what it knows—the policies in its database, the transactions it’s processed—but it has no visibility into external records.
Finance has their own ledger. They book premium according to accounting rules, which differ from how the PAS calculates premium. They make adjustments for accruals, deferrals, and other accounting treatments. Their numbers are “premium” too, but calculated differently.
The carrier has their own records. They book what you’ve reported on bordereaux, adjusted according to their processing rules. Their view of your premium might lag yours by weeks, depending on how quickly they process submissions.
The reinsurer has their own view. They see what’s been reported under the treaty, with their own timing and their own adjustments.
When these don’t match—and they never match exactly—the PAS can’t explain why. The discrepancy exists in the gap between systems, not within any single system. The PAS can tell you what it has. It can’t tell you why that differs from what finance or the carrier has.
Executives want to compare periods. This month versus last month. This quarter versus same quarter last year. YTD versus plan.
These comparisons require stable snapshots. September premium should be a fixed number—the same whether you ask in October, December, or next June. Otherwise, you can’t compare it to anything.
But the PAS doesn’t naturally produce stable snapshots. It produces current state.
A report run today for “September premium” includes everything the system currently knows about September: the original policies, plus any late-processed transactions, plus any corrections that were made in October or November. It’s the most accurate view of September available right now.
But that means the report run on October 1 showed a different September number than the report run on November 15. September’s premium keeps changing, even though September is over.
This is actually correct behavior for a transaction system. You want corrections to be reflected. You want late-processed transactions to be included. You want the most accurate view possible.
But it’s terrible for executive reporting. If September’s number changes every time you look, you can’t trust any snapshot. You can’t compare to last year’s September because last year’s September has also changed. The numbers are always provisional, never final.
Your policy admin system does one thing extremely well: it answers the question “what did we sell?”
Policy issued. Premium calculated. Documents generated. Endorsement processed. Cancellation handled.
That’s what it’s built for. That’s what it’s good at.
But here’s what everyone expects it to also do: answer the question “where’s the money?”
That’s a completely different job.
The first job is policy issuance. The second job is financial ledger. They don’t require the same data model. No amount of vendor pressure will make your PAS good at both.
Here’s why.
Think about what that means.
If you’re a policy admin company: Socotra, Duck Creek, Guidewire, Instanda, whoever, you’re trying to build a platform that works for every insurance program.
But every program is different.
General liability for Carrier A has different intake questions than GL for Carrier B. Property has different fields than casualty. Workers comp has different exposure definitions than everything else.
So what happens? The PAS tries to accommodate everyone. They add fields. And more fields. And configuration options. And custom schemas.
It’s like building a house, then adding rooms every time a new tenant moves in. After a few years, you don’t have a house anymore. You have a cluster of rooms that don’t connect properly, with plumbing running through the kitchen and electrical that nobody fully understands.
That’s your PAS data model.
Here’s a pattern I see constantly.
Year one: Your schema is clean. Ten fields. Clear definitions. Everyone knows what everything means.
Year two: You add a second product. New fields get added. Some existing fields get reused in ways they weren’t designed for. The schema grows to eighteen fields.
Year three: You add a third carrier. Their bordereaux template requires different columns. More fields. Some duplicate existing fields but with slightly different names. The schema is now forty-seven fields, and at least three of them have names like “Premium_v2_FINAL_USE_THIS.”
Nobody announced the drift. It just drifted.
And now when a carrier asks you a question about your book, you can’t answer quickly—because first you have to figure out which fields actually contain the data they’re asking about, and whether those fields mean the same thing they meant two years ago.
This is the moment everything quietly breaks.
Your first product works fine. The schema makes sense. The bordereaux flows. Everyone’s on the same page.
Then you launch your second line of business.
Suddenly you’re trying to fit property data into a schema designed for GL. Or workers comp exposure definitions into fields built for liability limits. The data model wasn’t built for this. So you patch it. You add fields. You create workarounds.
By the time you launch your third product, the patches have patches. And nobody remembers what the original fields were supposed to mean.
This is the one that really breaks things at scale.
Take the word “occurrence.”
In general liability, an occurrence is an accident, including continuous or repeated exposure to the same harmful conditions. One event can span months. Multiple claims can tie back to one occurrence.
In property, an occurrence is a single event within a defined time window—usually 72 or 168 hours. Hurricane over three days? One occurrence. Same storm system a week later? New occurrence.
Same word. Same column header in your bordereaux. Completely different logic underneath.
Now multiply this across every term in insurance:
When you’re running one product with one carrier, you don’t notice this. The definitions are implicit.
When you scale to multiple products with multiple carriers, these semantic collisions explode. Your reports don’t tie because the same word means different things in different contexts, and nobody documented which definition applies where.
Here’s where it gets expensive.
You have one book of business. One set of underlying data. But every carrier wants it in a different format.
Carrier A wants 47 columns in a specific order. Carrier B wants 38 columns in a completely different order. Your reinsurer wants the data sliced a third way. Your internal reports need yet another view.
Same information. Different shapes. Every. Single. Time.
Someone on your team spends hours—sometimes days—reformatting the same data into different templates. That’s not analysis. That’s translation. And it’s a permanent tax on your operations.
Here’s the technical version of the problem.
Policy admin systems are built around the policy as the atomic unit. Policy gets created. Policy gets endorsed. Policy gets cancelled. Everything is organized by policy.
But financial reconciliation requires tracking transactions. Not policies—transactions. Every premium movement. Every commission payment. Every fee. Every tax. Every reversal.
A single policy might have dozens of transactions over its lifetime. Those transactions need to tie out—not at the policy level, but at the penny level, for each transaction, across time.
Your PAS tracks policies. Finance tracks pennies. These are different problems that require different data structures.
When you try to extract financial data from a system designed for policy tracking, you get gaps. You get timing issues. You get numbers that don’t quite tie because the system was never designed to tie them.
Here’s what actually happens in practice.
The PAS spits out data in its format. The carrier wants data in their format. Finance needs data in their format. The reinsurer needs something else entirely.
And in the middle of all of this is a person—usually someone in ops—who becomes the human integration layer.
They know that when the PAS says “LOB_CD_V2_FINAL,” it actually means the same thing the carrier is asking about when they say “line of business.”
They know that the premium in column J needs to be adjusted before it goes on the bordereaux because it includes fees that the carrier doesn’t want to see.
They know which fields are trustworthy and which ones drifted three carriers ago.
This person is the data model. All the translation, all the mapping, all the reconciliation—it lives in their head.
And when they’re out sick, or when they leave the company, nobody knows how anything works.
Audits become excavations.
A carrier asks about a variance from eighteen months ago. Your team has to dig through old bordereaux, old schema versions, old emails explaining why a field changed.
Nobody documented what changed or when. The person who made the decision might not even work there anymore.
So you excavate. Layer by layer. Trying to reconstruct what “premium” meant in Q2 2023 versus what it means now.
This isn’t analysis. It’s archaeology.
Smart, capable ops people become human middleware—spending their days translating between systems instead of doing actual operational work.
They’re not analyzing data. They’re not improving processes. They’re not building carrier relationships.
They’re reformatting spreadsheets. Explaining variances. Answering questions that should have instant answers.
That’s the hidden cost of a broken data model. Not just the errors—the opportunity cost of the people stuck cleaning up the mess.
Let me tell you what this looks like from the carrier’s perspective.
They ask a simple question: “Can you explain why your October exposure doesn’t match your premium?”
Your ops team scrambles. They pull up the PAS. They pull up the bordereaux. They pull up the internal reports. Nothing ties perfectly.
They spend three days building a reconciliation spreadsheet to explain the variance.
The carrier gets an answer eventually.
But they noticed it took three days. They noticed the explanation required a spreadsheet. They noticed that the data wasn’t immediately traceable.
They don’t say anything about it.
But their trust just dropped a little.
Do that enough times—a variance here, a delayed answer there, an explanation that requires archaeology—and suddenly your carrier relationship is different.
They’re not hostile. They’re just... more careful.
They ask more questions. They verify more things. They don’t give you the benefit of the doubt.
When you ask for expanded capacity, they hesitate. When you propose a new program, they want more documentation. When your numbers come in, they double-check.
Trust erodes before performance does. By the time you see it in the relationship, it’s been accumulating for months.
Carriers deal with dozens of MGAs. They know which ones can answer questions quickly and which ones need a week to reconcile.
They know which MGAs have clean data and which ones have “creative” explanations for why the numbers don’t quite tie.
They don’t always say it directly. But it affects how they think about you. It affects whether you get the benefit of the doubt. It affects capacity decisions.
Data credibility is relationship credibility.
Here’s the thing nobody tells you when you license a PAS:
PAS vendors are measured on transaction accuracy, system uptime, and processing speed.
They’re not measured on whether the CEO’s dashboard matches the CFO’s spreadsheet.
That’s not the problem they were hired to solve. It’s not the problem their product is designed to solve. It’s not the problem their engineers are thinking about.
Their product roadmap reflects these priorities. New features focus on transaction capabilities: better rating flexibility, faster document generation, new integration options, additional coverage types. Reporting features, when they exist, are secondary—checkboxes to satisfy RFP requirements, not core capabilities that receive major investment.
This isn’t negligence or indifference. It’s focus. The vendor is good at transaction processing because that’s what they’ve invested in. They’re not good at executive reporting because that’s not their core business.
When you pressure your vendor to fix reporting, you’re asking them to become a different kind of company. Some will try, with varying degrees of success. Most will make incremental improvements that don’t fundamentally solve the problem. The structural gap remains.
The gap is architectural. Yelling louder doesn’t change architecture.
Let’s be specific about why you get different numbers from different systems.
Aggregation decisions. Which policies are included? All policies? Only active ones? What about policies bound but not yet effective? Pending cancellations? Different reports make different choices.
Timing conventions. Is “September premium” based on policy effective date, transaction date, or processing date? If a policy effective September 15 was bound September 30 but processed October 2, does it count as September premium?
Definition drift. Does “premium” mean gross written? Net of fees? After cancellations? The definition is embedded in system configuration, set years ago by someone who’s no longer there. Different systems embedded different definitions.
Transaction vs. policy views. The PAS shows policy-level totals. Finance tracks transaction-level movements. These don’t naturally reconcile because they’re organized differently.
Each system is “correct” according to its own logic. None of them match because they’re answering slightly different questions.
Here’s what I want you to take away from this:
The problem isn’t that you chose the wrong policy admin system.
The problem is that policy admin systems are designed for one job, and you need them to do two jobs.
Yelling at your vendor won’t fix it. Switching vendors won’t fix it. The gap is structural.
What fixes it is building the layer that should sit between your PAS and everyone who needs financial data.
A layer that:
That layer is the financial ledger. Your PAS was never going to be that.
The PAS stays a transaction engine. It does what it’s good at: issuing policies, processing endorsements, calculating premium.
The ledger becomes the source of truth for the financial layer. When someone asks “where’s the money,” you have an answer that ties.
When the carrier asks about October exposure, you don’t scramble. You pull up the ledger. The answer traces back to source transactions. The reconciliation is instant because it’s already done.
When you need a bordereaux for Carrier A and a different format for Carrier B, you don’t reformat manually. The ledger outputs in whatever shape you need because the underlying data is standardized.
When someone leaves the company, the data model doesn’t leave with them. It’s documented, versioned, auditable.
The humans in ops stop being middleware. They stop spending their days translating between systems. They can actually do operational work.
Build the ledger separately. Or more simply: use software to lend a hand. Your ops team has been filling this gap with spreadsheets and heroics. They deserve better tools. That’s where truth lives.
Faroe sits between MGAs and carriers as a financial data ledger. It takes the messy, schema-drifted, semantically-collided data from your PAS and does four things:
Standardizes it—so the same fields mean the same things across products and carriers.
Normalizes it—so the data structure is consistent regardless of source.
Reconciles it—so every penny of every dollar ties out for each transaction, not just each policy.
Makes it auditable and version-controlled—so when the carrier asks a question, you can trace the answer instantly.
The MGAs who use Faroe stop arguing about whether their numbers tie—because they already know they do, to the penny, for every transaction.
Here’s the counter-argument you’ll hear from PAS vendors: “We’re not just policy admin. We do billing too. Guidewire has BillingCenter. Duck Creek has Billing. Majesco has their billing suite. We’ve got this covered.”
Fair point. Let’s look at what that actually means.
First question: Are they the same product?
Usually, no. Policy admin and billing are separate products. Separate implementations. Separate contracts. Often separate databases.
You buy PolicyCenter. Then you buy BillingCenter. Then you spend months—sometimes years—integrating them. And even after integration, you’re moving data between systems, not working from a unified model.
Second question: Do they share a data model?
This is where it gets interesting.
Ask your vendor: “If I change a field in policy admin, does it automatically flow to billing with the same definition?”
Watch the answer carefully.
In most implementations, policy admin and billing have their own schemas. Data moves between them through integrations—feeds, APIs, batch jobs. The schemas were designed for different purposes. Policy admin is organized around the policy. Billing is organized around the invoice.
Same vendor. Different data models. Integration required.
Third question: What does “billing” actually mean?
Billing administration and financial reconciliation are different things.
Billing administration is: generate an invoice, track whether it was paid, handle installments, manage collections, process refunds.
Financial reconciliation is: tie every penny of premium, commission, tax, and fee across MGA, carrier, broker, and reinsurer—at the transaction level, inception-to-date, with full audit trail.
Most billing modules are good at billing administration. They’re not designed to be the financial ledger that reconciles your entire book across all counterparties.
They answer “did the customer pay their invoice?”
They don’t answer “does our October premium tie to what we reported to the carrier, what the carrier booked, what we owe the broker, and what flows to the reinsurer—to the penny?”
The gap persists.
Even MGAs running Guidewire policy plus Guidewire billing plus Guidewire claims still build reconciliation spreadsheets. They still have ops people who “know how the data flows.” They still spend days answering carrier questions about variances.
The suite helps. It doesn’t eliminate the problem.
Because the problem isn’t whether you have policy admin and billing. The problem is whether you have a single, standardized, transaction-level financial ledger that reconciles across all parties.
That’s a different product. And it’s the one that usually doesn’t exist.
You have this problem if:
☐ The same data requires different formats for different carriers
☐ Field definitions live in one person’s head
☐ Reconciliation takes days, not minutes
☐ Carrier emails create dread, not confidence
☐ Your schema has fields named “Premium_v2_FINAL_USE_THIS”
☐ Adding a second product broke things you thought were stable
☐ Audits feel like archaeology
☐ Your ops team spends more time reformatting than analyzing
If you checked more than two of these, your humans are filling a gap that should be filled by systems.
How do you know when you’ve solved this?
Reconciliation is boring. Monthly close happens on schedule, takes a few hours, rarely surfaces surprises. The person doing it is running a process, not performing heroics.
Nobody quotes the PAS dashboard in executive meetings. Numbers come from the ledger or from finance. Everyone knows the PAS is for operations, not for strategy.
Historical numbers don’t change. September premium is the same in October as it is in December. Snapshots are stable. Board decks don’t get “corrected” after the fact.
Carrier questions are easy. When they ask about a variance, you have the answer in minutes. The explanation traces to source transactions. No spreadsheet archaeology required.
Definitions are documented and shared. When someone says “premium,” everyone knows what that means. New hires learn the definitions during onboarding.
Ops does actual ops work. Your team analyzes data, improves processes, builds carrier relationships. They don’t spend their days reformatting bordereaux.
Trust goes up. Carriers notice that your data is clean. They ask fewer verification questions. They give you the benefit of the doubt. Capacity conversations get easier.
Your policy admin system falls short. That’s normal.
It’s not a bug—it’s a design choice.
The vendors who built your PAS made a reasonable decision: optimize for policy issuance, which is what carriers and MGAs primarily need. The financial reconciliation layer was supposed to be someone else’s problem.
For most of insurance history, that someone else was humans with spreadsheets.
But spreadsheets don’t scale. Humans as middleware don’t scale. Schema drift and semantic collisions compound faster than manual processes can handle.
The answer isn’t to make your PAS better at something it’s not designed for.
The answer is to build the layer that should have existed all along: a financial data ledger that takes messy policy data and turns it into auditable, reconciled, version-controlled truth.
You know that moment in a relationship when you finally stop trying to change the other person? When you realize they’ve been this way for years, they’re going to keep being this way, and the only thing making you miserable is the expectation that they’ll magically become someone else?
That’s where you need to get with your PAS.
It’s a transaction engine. It’s good at that. It’s been good at that. Appreciate it for what it is. Stop the silent resentment about what it’s not.
Build the ledger separately. That’s where truth lives.
Here’s your first step:
Ask your ops team this question: “If you left tomorrow, what would break?”
Whatever they say, that’s your data model. And that’s the problem.
TL;DR
Three problems. One root cause. One fix.
Problem 1: The data model is broken (no canonical schema, schema drift, semantic collisions)
Problem 2: The humans are filling the gap (the ops person who IS the data model)
Problem 3: Trust erodes before performance does (carrier relationships)
Root cause: You’re asking your transaction engine to be a financial ledger.
Fix: Build the ledger separately.
This is why I built Faroe—a financial data ledger that sits between MGAs and carriers, providing inception-to-date, auditable, version-controlled data that surfaces in whatever lens your teams need. The PAS stays a transaction engine. Automate your bordereaux. The ledger becomes the source of truth. You know what you are owed, what you owe, and what you keep in real time.
If you’re an insurance operator and this resonated, I hold office hours to help teams think clearly through the inflection points that come with scaling insurance programs.