You chose self-funding because you wanted control. The cost that gets the least attention at the sales meeting is the fragmentation between your TPA, your stop-loss carrier, and your own HR system. That fragmentation quietly erodes the savings self-funding was supposed to create.
Most conversations about Administrative Services Only (ASO) stick to the obvious topics: cash flow, state mandate exemptions, plan customization. What gets skipped is the way ASO, as it's implemented today, separates plan design, claims processing, stop-loss coverage, and member experience across different systems. That separation is a byproduct of legacy business models, and it becomes an ongoing administrative liability for employers without the technology infrastructure to manage it.
The Three Systems in an ASO Arrangement
In a fully insured plan, the carrier owns the network, claims, stop-loss risk, and member engagement, so the data flows are centralized even when the technology is dated. In an ASO arrangement, the employer owns the risk, but administration is split across three systems that don't share a data model:
- The TPA: handles claims adjudication, provider networks, and utilization management.
- The stop-loss carrier: covers catastrophic claims and needs current claims data to price risk at renewal.
- The employer's HR ecosystem: eligibility, payroll, wellness platforms, and enrollment software.
Each system runs on its own technology stack. The systems mostly exchange data through batch file transfers, ANSI 834 enrollment files and 837 claim files, which introduce latency and reconciliation errors. When a member's status changes in one system, the others learn about it later.
Where the Real Cost Lives
Start with stop-loss carrier data alignment. Stop-loss reimburses the plan for claims already paid, so the carrier's system has to agree with the TPA's system on when each large claim was incurred and when it was paid. The TPA reports claims and census data to the carrier on a monthly cycle. A TPA may code claims with different DRG groupings or bundling rules than the carrier expects. When the two records disagree, a claim the employer assumed was covered can be denied as outside the covered window, and the employer self-funds it. Specific-claim reimbursement also depends on the TPA compiling supporting documentation (bills and explanations of benefits) for the carrier to review. Every handoff is another place where the dates and codes have to match.
Incurred and Paid Dates in Stop-Loss Contracts
Most stop-loss disputes come down to two dates on a claim: when the service was incurred and when the plan paid it. The contract basis decides which combination the carrier reimburses.
A 12/12 contract covers only claims incurred and paid within the same 12-month policy period. It's the most restrictive structure. A claim incurred in month 11 but paid in month 13, after the TPA finished processing it, falls outside the window and the employer pays.
A 12/15 contract adds a paid run-out: claims incurred during the policy period are covered if they're paid within three months after it ends. Some carriers offer 12/18 with a longer tail.
A 24/12 contract, sometimes called run-in coverage, works the other way. It covers claims paid during the current policy year that were incurred in the prior 12 months. This matters most for an employer moving from fully insured to self-funded, because claims incurred under the old plan but paid after the switch would otherwise fall on the employer.
The contract basis belongs in writing next to the attachment point. The TPA should also confirm its claims data can produce both dates cleanly. When the TPA's incurred-date record and the carrier's definition disagree, the written contract basis decides who pays.
Three Places the Integrations Break
ASO makes the employer its own system integrator. Three integration points fail most often:
1. Eligibility vs. Claims Matching
An employee terminates in payroll, in Workday or ADP or another HR system. The TPA receives the updated eligibility file two days later. In between, the employee files a claim, the TPA pays it, and the employer absorbs the cost. The lag itself is the problem.
2. COBRA and FSA Crosswalks
In a fully insured plan, the carrier tracks COBRA eligibility itself. In ASO, the employer's benefits administration system has to push that data to the TPA. One mismatched field leaves a member without coverage and without a notice telling them so.
3. Wellness Incentive Failures
Your wellness platform issues a reward when a member completes a health screen. If the TPA's claims system doesn't recognize the preventive care code the wellness vendor sent over, the incentive never applies and the member pays full price for the screening. That member experience failure comes directly from the two systems not talking.
Control Requires Integration
Most employers choose ASO because they believe it gives them control over plan design, data, and cost. What they inherit is a set of unintegrated administrative systems that need constant manual reconciliation. The control is only real if you build a benefits data hub, an integration layer that normalizes claims, eligibility, stop-loss, and wellness data into one consistent record.
Few TPAs offer this natively. Many still run claims and eligibility on dated batch-processing systems, which leaves the integration work to the employer or its broker.
What to Ask Before Going ASO
If you're advising a client or making the decision yourself, set aside risk corridors and aggregate attachment points for a moment. Ask these three questions, which reveal how the administration is wired:
- What data format does your TPA use for stop-loss data transmission? If it's not a real-time API or at least a daily SFTP feed with automated validation, you're setting up a reconciliation liability.
- How do you handle eligibility file timeliness? A three-day lag between an HR system termination and the TPA update is too long. Ask whether integration runs through a modern API, for example through platforms like Rippling or Workday Benefits.
- Can your wellness platform's outcomes data flow into the TPA's medical cost analytics? If not, you have no population health trend data to plan against.
Treat ASO as a Technology Decision
ASO is a technology architecture decision as much as a financial one. Treat it that way and you avoid the administrative fragmentation that erodes the cost advantage you signed up for.
The data disconnect can be fixed, and it starts with the three questions above. Most employers running ASO never ask them.