Payors and Sub-Customers

Short version: the parent customer is the payor as you report on it — Texas Medicaid, Aetna, Tricare. The sub-customer is the specific plan that actually holds the money, and it is what Qlarity maps to. The trap in between is that CentralReach shows the same payor under several different display labels, and if you build a customer for each label you end up with one payor wearing four names.

Two questions, two levels

Your practice asks two different questions about payors and they need two different answers.

The strategic question is a rollup: how much of our revenue is Texas Medicaid, how concentrated are we, what happens if that rate schedule moves. Nobody in that conversation cares which regional entity processed the claim.

The operational question is the opposite: this claim is 62 days out, who exactly do we call. That answer has to be the specific plan, because that is the entity holding the money.

QuickBooks Online gives you both through the customer hierarchy. Parent for the rollup. Sub-customer for the work.

Texas Medicaid              <- your name, readable, for reporting
    Superior HealthPlan     <- the plan that holds the money
    Amerigroup Texas
    TMHP Fee-for-Service

Florida Medicaid
    Sunshine Health
    Simply Healthcare

Aetna
    Aetna Better Health of Ohio
    Aetna Commercial

Tricare
    Humana Military (East)
    TriWest (West)

Patient Responsibility
    SMIJON
    GARLEE                  <- one sub-customer per patient

The shape holds in every state. Medi-Cal sitting over Health Net and Kaiser in California. Apple Health over Molina and Coordinated Care in Washington. AHCCCS over Mercy Care and Banner – University Family Care in Arizona. NC Medicaid over Healthy Blue and Carolina Complete. Colorado Medicaid over Colorado Access and Rocky Mountain Health Plans. The names change; the two levels do not.

The left column is yours to name. The indented rows are not — they are the payers your billing system actually adjudicates against. Every claim invoice is written to a sub-customer. Never to the parent. The parent exists to be a heading on a report.

The trap: one payer, four labels

Here is a real one, from a Colorado book we reconciled. The payer column in the CentralReach export produced four distinct strings that all pointed at the same payer:

Primary: Colorado Medicaid > No Waiver (CO Medicaid)
Primary: Colorado Medicaid > No Waiver (Primary)
Primary: Colorado Medicaid > No Waiver (Colorado Medicaid)
Primary: Colorado Medicaid > No Waiver

The parenthetical is the payer's nickname, appended to its name. It is a separate field in the record and it varies. The payer underneath is identical — same contract, same rate schedule, same remittance.

Keying on the display label rather than the payer produced 713 payment groups where there should have been 557. One hundred fifty-six of them were the same payer counted twice. On a customer list, that same error gives you four sub-customers for one plan, A/R split four ways, and an aging report where no single line tells you what that payer owes.

The rule: one sub-customer per payer, not per label variant. Before you create a customer that looks new, check whether it is an existing payer wearing a different nickname. Match on the payer, require a unique match, and never accept a client's default payer as the answer.

Then match the name exactly

Once you know which payer you are dealing with, name the sub-customer to match the payer record character for character — minus the nickname parenthetical, consistently, every time.

The sub-customer is the join key between your billing system and your general ledger. Every sync and every reconciliation depends on the two systems agreeing on the string. The moment somebody in QuickBooks tidies SUPERIOR STAR KIDS into Superior HealthPlan (STAR Kids) because it reads better, the mapping breaks and the next batch of revenue lands somewhere unexpected, or nowhere.

The place to make a name readable is the parent. The parent name is yours. Make it whatever your leadership team says out loud in a meeting, and let the ugly string live one level down where it can do its job.

If a payer name in CentralReach is genuinely wrong, fix it there first, then update the sub-customer and the mapping. Fix upstream, in one direction, always. Never fix it in the ledger and hope the two converge.

Turn off "Bill with parent"

When you create a sub-customer, QuickBooks asks how to bill it. Choose to bill the sub-customer directly.

Billing with the parent rolls the sub's invoices up so they appear and get paid under the parent. That sounds convenient and it destroys the thing you built this for. You lose per-plan aging, you lose the ability to see which specific plan is slow, and your collections queue becomes one line saying Texas Medicaid owes you $180,000 — true, and useless.

Bill the sub. Pay the sub. Age the sub. Roll up only in reports.

What you get on the reporting side

Report	Run it at	What it answers
A/R Aging Summary, collapsed	Parent	Concentration and total exposure by funding source
A/R Aging Detail, expanded	Sub	The work queue — which plan, which invoice, how old
Sales by Customer Summary	Parent	Revenue mix and payor dependency
Customer Balance Detail	Sub	Whether a plan's payments are actually clearing invoices

Same data, two altitudes, one click apart. The collapse and expand toggle on the aging report does a lot of quiet work here.

Patient responsibility gets the same treatment

Copays, coinsurance, deductibles and private pay are not a payor, but they behave like one structurally. Create a parent called Patient Responsibility — some practices call it Private Pay — with a sub-customer per patient underneath.

Use a short, deterministic naming rule so the same patient never gets two records. First few letters of the first name plus the first few of the last works well; go wider than three and three if common surnames start colliding. The rule matters more than the format, so write it down.

The point of the parent is that patient-responsibility A/R is a different collections problem than payor A/R — different aging behavior, different outreach, different write-off policy — and you want it isolated in one line rather than scattered through the report.

What not to do

• Do not make each patient a top-level customer for insurance claims. Patient-level clinical and authorization detail belongs in CentralReach. Pushing it into QuickBooks gives you a 400-row customer list, an unreadable aging report, and a HIPAA surface area you did not need. The payor owes you the money. Invoice the payor.
• Do not also track payor as a Class. Duplicate data entry, two chances to disagree. Customer already carries payor. Save Class for something Customer cannot express.
• Do not create a new sub-customer when a plan is renamed. Rename the existing one and update the mapping. Renaming preserves invoice and payment history; a new record orphans it and splits one plan's aging across two lines.
• Do not nest three levels deep. QuickBooks allows it. Your reports get worse. Two levels is the answer.

How Qlarity uses this

Qlarity maps each CentralReach payor to a QuickBooks customer, and the sub-customer is the mapping target. When claims sync, invoices are created against the sub-customer matching the payer on the billing entry, so revenue, A/R and payment application all line up at the level where money actually moves.

Set the structure up before your first sync. Retrofitting a customer hierarchy onto twelve months of posted invoices is possible, but it is a weekend nobody enjoys.