A/R by Payer Analysis

A single aging column mixes every payer the practice bills, every reason a claim is open, and insurance balances with patient balances. Splitting it by payer is worth doing because the causes of an open balance are overwhelmingly payer-specific: an enrollment problem, a configuration error, an attachment requirement, a contract term. One number across all payers cannot point at any of them.

But the split creates a comparison, and a comparison invites a ranking, and the ranking is where the analysis usually goes wrong. The next section is about that, and it is the part worth reading before building the report rather than after.

Two payers with different days in A/R may be behaving identically. What differs is what flows through them.

• Service mix. If one payer's population brings more of the work that requires authorization, documentation or an attachment, its claims will take longer for reasons that are about the services rather than about the payer.
• Benefit design. Plans that leave more with the patient convert insurance balances into patient responsibility faster, and patient balances age on a completely different curve. A payer can look fast because its members pay slowly somewhere else on the report.
• Secondary coverage. A population with high secondary or coordination of benefits involvement carries a second adjudication inside the same balance. That is two payers' time recorded against one.
• Volume and composition. A small payer's average moves on a handful of claims. A single stuck high-value account can make a payer look systematically slow when nothing systematic is happening.
• The practice's own share. Charges billed late age before anyone sends them. Where billing lag differs by payer — because one requires an attachment the practice assembles by hand — part of that payer's aging belongs to the practice.

1. 01

   Split insurance from patient first

   Before any payer cut. These are different receivables with different collection mechanics, and mixing them makes the payer whose plans carry the most patient share look like the payer with the worst follow-up. A/R aging buckets covers why one column hides this.
2. 02

   Hold the population constant

   Each payer against its own prior periods. This is the comparison that survives the confound, and it is also the one that detects the thing worth detecting: a change in behavior, which is what a configuration update or a policy change looks like from the outside.
3. 03

   Move from time to reasons

   The distribution of adjustment reason codes and group codes across a payer's remittances is behavior rather than circumstance. A payer whose reason mix shifts has changed something, and the reason names what.
4. 04

   Separate the never-adjudicated from the adjudicated-and-unpaid

   A claim the payer has no record of and a claim that finalized to a balance nobody posted are different failures that look identical in an aging column. The 276/277 claim status transaction is how that distinction is made at scale rather than by calling.
5. 05

   Set thresholds from the payer's own finalization pattern

   Where that payer's claims have usually finalized, derived from the practice's own history — not from a round number and not from anybody's published benchmark. A threshold that means something for one payer means nothing for another.

Every by-payer analysis has a hole in it: the payer whose remittances arrive as paper, as a portal download, or in a proprietary layout that will not reconcile with the rest. That payer quietly drops out of the report, which means the analysis is weakest exactly where it is least able to say so.

The practical consequence is worth stating plainly: comparable remittance data is something a practice may require rather than something it has to be granted. Where a payer's data is the obstacle to analyzing that payer, the obstacle has a remedy, and the remittance advice arriving in the standard form is what makes every other section of this page mechanizable rather than manual.

The reason this analysis repays the effort is that its findings are rarely fixable by following up harder. A pattern that holds across a payer's whole population is structural, and structural problems have owners elsewhere.

• A configuration difference. The payer is applying a rule the practice has not accounted for. Every affected claim shares one cause, so the fix is one change rather than a queue.
• An enrollment or credentialing gap. Claims for one location or one provider are behaving differently under one payer. This is almost never a follow-up problem and is frequently invisible until the data is cut this way.
• A contract term doing its job. The payment is what the agreement says, and the surprise is the practice's. That is a renegotiation input rather than a denial, and recording it while it is fresh is what makes it available at renewal.
• A practice-side lag wearing a payer's name. Charges for that payer are billed later, or its attachments are assembled by hand. The report says payer; the cause is internal.
• A vendor boundary. Where follow-up is outsourced, a payer-level pattern may be a scope question rather than a payer question — see outsourced A/R vendor oversight.