CYBHI Billing Reconciliation From Service Logs to Cash

CYBHI billing reconciliation is the finance-office workpaper that ties each school-linked behavioral-health service log to the submitted claim, the Carelon remittance or denial, the bank deposit, and the GL posting. Because CYBHI is a fee-for-service multi-payer fee schedule paid per claim per service line rather than an LEA Billing Option Program-style cost-settled program, reconciliation runs claim-to-cash and never resolves through an annual cost settlement. Effective January 1, 2026, claims may be submitted up to 365 days from the service date, so aged service logs and unmatched encounters become a standing exception queue rather than a one-time clean-up.

The program sits inside California's Department of Health Care Services. California's CYBHI multi-payer fee schedule workstream records that Carelon Behavioral Health was selected as the third-party administrator for California's CYBHI statewide multi-payer school-linked behavioral-health fee schedule. Carelon sits between participating LEAs, IHEs, and school-linked providers on one side and commercial and public payers on the other, which means the same Carelon remittance feed is what every participating finance office — LEA finance, IHE finance, school-linked provider billing, and the billing-vendor and county-office finance teams that submit on their behalf — is reconciling against, regardless of which payer ultimately funds the service.

The structural break with the LEA Billing Option Program matters because finance teams in this audience often have a longer BOP history. LEA BOP reconciliation runs through the Cost and Reimbursement Comparison Schedule (CRCS) at the end of the cost reporting period; the fiscal-year-end true-up is the reconciliation. CYBHI does not work that way — there is no CRCS, no period-end true-up, and no allowable-cost or settlement columns on the workpaper. Some districts and county offices run both programs in parallel, but the two should not share a workpaper structure. A reader whose actual question is about the BOP cost-settlement side should follow the dedicated workflow for school-based Medicaid cost-settlement reconciliation, which CYBHI explicitly is not. Conflating the two produces a specific failure mode: a CYBHI denial goes unworked because finance is waiting for an annual settlement to true it up. By the time the controller asks why CYBHI revenue is below forecast, the denial has aged past the 365-day submission window and the line is a write-off.

---

The Reconciliation Workpaper Field Schema

The CYBHI reimbursement tracking spreadsheet is one row per service line, not one row per claim. A single CYBHI claim can carry multiple service lines, and Carelon can deny or partially pay a single line without affecting the others on the same claim. A claim-grained workpaper hides that mechanic; a line-grained workpaper exposes it. Every column described below assumes the line-grained design.

The columns group by the artifact that supplies them.

Service-log-sourced (from the LEA's service-tracking system or the school-linked provider's clinical system):

• Student or internal identifier — the tie-back to the encounter, kept as an internal ID rather than a name.
• School site — where the service was delivered.
• Date of service — the aging anchor for everything downstream.
• Service category — for example individual therapy, group therapy, assessment, screening.
• Procedure code (CPT/HCPCS) — the billable code on the fee schedule.
• Modifier — applied where the code requires it for practitioner type, group setting, or telehealth.
• Practitioner type — for example LCSW, LMFT, LPCC, school psychologist, behavior specialist.
• Provider — the rendering provider, with a supervising provider field where supervision is required by code or by license.
• Units — the billable units for the service, with the CYBHI midpoint/half-point time rule applying to time-based codes.
• Fee schedule amount — the published CYBHI fee schedule rate at the date of service for the procedure code and modifier combination.

Submitted-claims-sourced (from the Availity submission output or the billing vendor's submitted-claims report):

• Claim number — the Carelon claim ID assigned at submission.
• Claim submitted date — when the claim was accepted into the adjudication queue.
• Claim status at submission — accepted, or rejected at intake with the intake-level reason.
• Payer or plan target — the ultimate payer the claim was routed to under the CYBHI multi-payer model.

Remittance/denial-sourced (from the Carelon remittance advice for paid lines, denial notices for denied lines, and any 835 ERA file where the entity is connected):

• Reimbursement amount — what Carelon actually paid on this service line.
• Remittance date — the date of the Carelon remittance that closed (or denied) this line.
• Payer or plan as paid — recorded separately from the submission target so payer routing changes are visible.
• Denial or adjustment reason — the CARC-equivalent code and the short text Carelon returned, captured together rather than as a single status flag.
• Allowed amount — where Carelon reports it, the contractually allowed amount that drove the paid amount.

Deposit-sourced (from the bank deposit advice or the ACH detail tied to the remittance batch):

• Deposit batch reference — the ACH or wire reference tying the bank credit to the Carelon remittance batch.
• Deposit date — the date the funds posted to the bank account.
• Deposit amount — the aggregate bank credit, which should equal the sum of paid amounts on the matched remittance batch.
• Bank account — the account that received the deposit, where finance teams operate multiple accounts.

GL-sourced (from the participating entity's accounting system after the deposit is posted):

• GL account — the revenue account used for school-linked behavioral-health revenue.
• Fund — typically a restricted or categorical fund where one is in use.
• Program — a program code identifying CYBHI specifically, where the chart of accounts supports it.
• Posting reference — the journal entry or batch ID that posted this line.
• Posting date — the date the GL entry was recorded.

Derived columns (computed from the columns above, refreshed each time the workpaper is updated):

• Days since service date — the load-bearing aging metric, given the 365-day submission window.
• Days since claim submission — a secondary aging metric for unpaid claims sitting in adjudication.
• Claim-to-cash status — submitted, paid, denied, partial, unmatched, written-off.
• Variance — fee schedule amount minus reimbursement amount; non-zero variance is the flag for partial payments and rate mismatches.
• Aging bucket — the bucket the row falls into based on days since service date.

---

Layer 1: Service Documentation, the Encounter Log, and Privacy Discipline

Every claim that ever appears on a Carelon remittance traces back to a documented encounter in a service-tracking or clinical system. If the encounter cannot be tied to a service log line, the claim cannot be defended on audit, and the corresponding row on the workpaper is an exception by definition. The service log is the originating artifact of the workpaper; everything downstream is consequence.

For the workpaper to populate cleanly, the service-log layer needs to surface a defined set of fields per service line: an internal student identifier, the school site, the date of service, the service category, the procedure code, any modifier, the practitioner type, the rendering provider (and supervising provider where supervision is required), the units, and the fee schedule amount lookup at the time of service. For time-based procedure codes, the unit count has to reflect the CYBHI midpoint/half-point time rule rather than the raw clock time spent — finance teams who source units directly from a clinician timer without applying the rule will find the units on the workpaper systematically out of step with what Carelon adjudicates.

The system that holds the service log varies. Larger participating providers run a purpose-built EHR for school-linked behavioral health that exports encounter rows directly. Some districts use a district-managed encounter system shared across special education and school-health programs. Smaller participating sites fall back to a spreadsheet-and-PDF-export workflow, where clinicians log encounters in a daily log and the billing lead consolidates them weekly. The workpaper does not care which system supplies the service log; it cares that the fields above land cleanly with one row per service line, and that the export format is repeatable period over period.

This is where the practical question of how to reconcile CYBHI claims to service logs gets answered. The workpaper should make missing-service-log exceptions visible as their own row category — a submitted claim with no traceable encounter — rather than silently discarding them. A claim that hits the remittance without a behind-it service log is the audit risk the entire reconciliation exists to surface. The workflow described in school district related-services invoice and service-log review covers the adjacent control on the related-services invoicing side, and the same review discipline applies here: every billable line should reconcile to a documented encounter before it is allowed to age toward the 365-day window.

Privacy discipline is non-negotiable at this layer. A finance reconciliation workpaper carries the minimum student-level detail needed to tie line items to deposits and the GL — typically an internal student identifier rather than a name, a service date, a service category and procedure code, and the financial fields on the line. Diagnostic detail, clinical notes, assessment content, and treatment plan information do not belong on the finance workpaper. FERPA applies at the LEA, HIPAA applies at the school-linked provider, and the entity's data-handling policy specifies who may access workpapers that carry student-level data and where those workpapers may be stored.

Layer 2: The Submitted-Claims Record

The submitted-claims record is the outbound side of the workpaper. Every service log line that becomes billable produces, at submission, a row carrying the Carelon claim number, the claim submitted date, the claim status at submission, the payer or plan the claim was routed to, and the procedure code and units as actually submitted. Capturing this layer cleanly is what gives every service log line an outbound trace before any remittance arrives — and what makes the eventual remittance match a true match rather than a date-and-code approximation.

Two submission paths are common in practice, and the workpaper has to support either. Some participating LEAs and school-linked providers handle submission in-house, with billing staff submitting through Availity directly to Carelon. Others submit through a third-party billing vendor or a county office of education that aggregates claims on behalf of the participating entity. The workpaper does not care which path is in use; what it requires is a periodic submitted-claims report that reflects the submission output, regardless of who runs the submission.

The practical operational ask, from finance to whoever runs submission, is concrete. The CYBHI fee schedule claims spreadsheet input is a periodic submitted-claims report — weekly or monthly depending on submission volume — that lists every line item submitted in the period. It needs to carry the Carelon claim number, the claim submitted date, the intake status, the procedure code and units as submitted, and a tie-back identifier that links each submitted line to the originating service log line. That tie-back is the join key. Without it, reconciliation degrades to fuzzy matching on student identifier, date of service, and procedure code, and any case where two service lines on the same date for the same student differ only by modifier becomes ambiguous.

Intake-stage rejections deserve their own status on the workpaper, distinct from adjudication denials. A claim rejected before adjudication — for missing fields, invalid identifiers, an out-of-range date of service, or a payer routing error — is a submission failure rather than a denied claim. It does not appear on a Carelon remittance because Carelon never adjudicated it. It needs to be corrected and resubmitted, and the workpaper should track the resubmission as a status change on the same line rather than treating the original submission as a permanent record. Treating intake rejections as denials misroutes them through the denial follow-up workflow and dilutes the denial queue with claims that just need a field fix.

Layer 3: Carelon Remittance, Payment Detail, and Denial Output

The Carelon remittance is the inbound mirror of the submitted-claims record. At the line level, it carries the claim number, the service line reference, the paid amount, the allowed amount where Carelon reports it, the denial or adjustment code with its short reason text, and the remittance date. Every one of those fields lands as a column on the workpaper, joined back to the submitted-claims row by claim number and service line — which is the join the line-grained schema was designed around.

The matching operation is straightforward in principle. Each remittance line should match exactly one submitted-claims row, and that submitted-claims row should already be tied to exactly one service log line from layer 1. When the chain holds — service log to claim to remittance — the workpaper row is two-thirds closed; the deposit match in the next section closes it the rest of the way. When the chain breaks, the row enters an exception status and the failure mode tells the finance team what corrective action to route. A line paid for the wrong service date, paid for unit counts the submission did not specify, or paid against a payer the claim was not routed to is not a fully reconciled line, even though it shows reimbursement.

Denial-reason discipline is what separates a workpaper that surfaces actionable denials from one that just records that denials happened. Carelon returns a CARC-equivalent code with short reason text on every denied or adjusted line. The workpaper carries both — the code and the short text — because the resubmission action depends on the reason. A coverage denial (the service was not a covered benefit on the date of service) requires a different action than a coding denial (the procedure code, modifier, or unit combination was invalid), and both differ from a duplicate-claim denial (the line had already been submitted) and from a service-date denial (the service date was outside the eligibility window). Collapsing all four into a single "denied" status hides the routing information the queue needs.

The denial follow-up workflow at finance-office grain is what closes denied lines. A denied line stays open on the workpaper until one of three things happens: it is resubmitted with corrected information and the resubmission produces a new claim number that is appended to the line, it is written off through an explicit decision with the write-off reason recorded on the line, or it ages past the 365-day submission window and is written off by default. The CYBHI denial follow-up workflow is the named operational practice that runs the queue, and the most common failure mode it exists to catch is silent denials — denials that finance receives on a remittance, never works, and discovers only when the controller asks why CYBHI revenue is below forecast at year end. The workpaper makes silence visible because every denied line carries an aging clock from the date of service.

Some of the discipline carries over from adjacent flows that finance teams already run. The school district Medicaid R&S report and 835 ERA extraction workflow covers the parallel reconciliation on the Medicaid R&S and 835 ERA side — the artifacts and codes are different, but the line-level matching logic and the denial routing instinct transfer. A finance team that already runs an R&S reconciliation has most of the operational muscle for CYBHI; what changes is the artifact set and the regulatory framing, not the workpaper structure.

Partial reimbursements are their own status on the workpaper, distinct from full payments and from denials. Carelon may pay a portion of a claim because of an allowed-amount cap below the fee schedule rate, a modifier that drives a percentage reduction, or a unit cap that limits paid units below submitted units. The workpaper records the variance between fee schedule amount and reimbursement amount for the line, and the partial-payment status flags the line for review even though Carelon considers it closed. Treating a partial as a fully paid line is the second most common preventable cause of revenue leak in CYBHI reconciliation, after silent denials, and the variance column is what surfaces it.

Layer 4: Deposit Batches and GL Posting

The deposit-to-remittance match is the second matching operation on the workpaper, and it is what closes the cash side. Carelon issues a remittance for a batch of paid lines and pays a corresponding aggregate deposit, typically by ACH to the entity's designated bank account. The workpaper carries a deposit batch reference on every paid line and ties every paid line in the remittance to that deposit. When the deposit total equals the sum of paid amounts in the matched remittance batch, the cash side of the workpaper for that batch is reconciled. When it does not, the variance enters its own exception category before any GL work happens.

Three variance categories are common at this layer, and each routes differently. A remittance batch with no corresponding deposit is usually a timing variance — the deposit is in flight and will land in the next bank day or two, and the workpaper records the expected deposit date so the row can close on receipt rather than aging silently. A deposit with no remittance trace is the more diagnostic case: a bank credit that does not tie to any open Carelon remittance batch needs investigation, because it can be a misrouted ACH, a payer adjustment outside the standard remittance flow, or in the worst case a posting against the wrong entity. Partial deposits, where the bank credit does not equal the matched remittance batch total, are most often bank fees on incoming ACH or returned items from a prior batch; both need their own GL treatment rather than being absorbed into the CYBHI revenue line.

The GL posting side carries the workpaper into the chart of accounts. Participating entities typically post school-linked behavioral-health revenue to a designated GL account, often within a restricted or categorical fund where the entity uses one for grant-coded revenue, and frequently with a program code that identifies CYBHI specifically so the revenue can be reported up at year end. The workpaper carries the GL account, the fund, the program, the posting reference, and the posting date for each line — not just the deposit-level total. Line-level posting matters for revenue allocation (which CYBHI service lines drove this month's revenue, at what rate, for which school site, under which payer) and for variance attribution (a denied line eventually paid on resubmission three months later posts to the period it was deposited in, while the aging stays anchored to the date of service). The CYBHI workpaper slots into the same finance controls as the rest of the entity's reconciliation work — bank reconciliation against the deposit batch, GL posting review against the journal entry, fund-level reporting against the categorical fund — and the broader education finance team AP automation context covers the adjacent disbursement-side automation that often sits in the same finance function.

Layer 5: Aged Exceptions, Aging Buckets, and the 365-Day Window

Every workpaper row that has not closed cleanly is an exception, and every exception ages from the date of service. A row is closed when the service log is matched to a submitted claim, the submitted claim is matched to a Carelon remittance, the remittance is matched to a bank deposit, and the deposit is posted to the GL with the program coding the entity uses for CYBHI revenue. Anything short of that — a missing match anywhere in the chain, a denial without resubmission, a partial payment without a variance review, a deposit without a posting — is open, and open rows accumulate in the aged-exceptions queue.

The 365-day claim-submission window is what makes the day-count from service date the load-bearing aging metric. Effective January 1, 2026, claims may be submitted up to 365 days from the service date, which means the runway for resubmitting a corrected denial, billing a previously unbilled service log, or correcting an intake-stage rejection is bounded — and the bound is set by service date, not by the date the gap was first noticed and not by the date of the most recent remittance. A workpaper that ages rows from any other anchor will systematically understate how close lines are to the submission deadline.

Concrete aging buckets in days from service date give the queue the structure a controller and an auditor expect:

• 0 to 30: normal in-flight. The service log may not yet be matched to a submitted claim, or the claim may still be at intake. No follow-up is required at this age unless something is structurally wrong.
• 31 to 60: still routine for adjudication, but a service log without a submitted claim at this age is becoming a real exception. The unbilled-service-log queue is what gets worked in this bucket.
• 61 to 90: claims should mostly be paid or denied at this point. A claim that is still pending at 90 days warrants a status check with Carelon, because the longer adjudication runs the more likely it is that something has stalled the claim that is not visible from the submission side.
• 91 to 180: any open exception requires action. Denials need to have been worked or written off, partial payments need to have been escalated, submission failures need to have been corrected, and missing service logs need to have been backfilled or had their claims voided. An exception that survives this bucket without action is on a path to write-off.
• 181 to 365: the resubmission runway is closing. Every open exception needs an explicit close-out plan before it crosses the 365-day threshold — resubmit, write off, or escalate. Lines that arrive in this bucket without a plan tend to be the same lines that are still here at over 365.
• Over 365: claims past the submission window cannot be resubmitted to Carelon. Rows in this bucket are write-offs by definition unless a documented exception applies. The bucket should always be small; a meaningful population here is a process failure upstream rather than an aging artifact.

The exception categories the workpaper tracks as distinct row statuses each carry their own follow-up action. A missing service log behind a submitted claim routes to a backfill review or a claim void. A submitted claim with no remittance after 90 days routes to a Carelon status check. A denial without resubmission routes to the denial follow-up workflow described in the previous section. A partial reimbursement below fee schedule rate routes to a variance review against the modifier, the unit count, and any allowed-amount adjustment Carelon has reported. A deposit without claim trace routes to a banking investigation. A GL posting without an underlying batch routes to a posting correction. Duplicate and mismatched-record exceptions — the same service log on two submitted claims, the same claim paid twice, remittance lines that do not align to any submitted claim at the line level — also form their own category and tend to surface only with line-grained reconciliation, which is one of the structural reasons the schema is built one row per service line.

---

Where Extraction Tooling Fits in the Workpaper Build

Every layer of the workpaper has a source artifact, and most of those artifacts arrive in shapes that do not match the workpaper directly. Service-log exports come out of clinical systems as CSV at larger providers and as PDF at smaller participating sites. Submitted-claims reports arrive as Availity exports or vendor portal downloads. Carelon remittances arrive as PDF advices, with 835 ERA files available where the participating entity has connected to the EDI feed. Deposit advices and bank statements arrive as PDFs from the bank. Each has to be translated into structured rows the workpaper schema can absorb, every period.

Prompt-based extraction handles the loop in practice. Each artifact gets its own prompt that names the workpaper columns the section needs and any artifact-specific rules:

• For Carelon remittance PDFs, a prompt that names the line-level fields — claim number, service line reference, paid amount, allowed amount, denial code and short text, remittance date — and instructs one row per service line produces the layer 3 input directly.
• For submitted-claims exports that already arrive as CSV, extraction is not needed; the CSV maps to the layer 2 columns by design. Where the submitted-claims report arrives as a PDF, the same prompt-driven approach pulls the layer 2 fields off the PDF.
• For service-log PDFs from smaller participating sites, a prompt that names the layer 1 fields and enforces the privacy discipline from the inside — extract internal student identifier rather than student name, leave clinical and diagnostic content behind — produces clean service-log rows that respect the minimum-detail principle.
• For deposit advices and bank statements, a prompt that pulls the deposit batch reference, deposit date, deposit amount, and bank account produces the layer 4 input for the deposit-to-remittance match.

Invoice Data Extraction is the tool we build to handle this kind of artifact-to-row translation: users extract reconciliation fields from CYBHI service-log, claim, and remittance PDFs by describing what the workpaper needs in a natural-language prompt and uploading the source artifacts, and the output lands as a structured Excel, CSV, or JSON file with one row per service line — the exact shape the workpaper schema expects. Batch processing handles up to 6,000 files per session and individual PDFs up to 5,000 pages, which covers a quarter's worth of remittances or a multi-site service-log consolidation in a single run. Every output row carries a reference back to the source file and page number, which makes the extracted rows defensible against the workpaper's eventual audit question of where each line came from.