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 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.

Fee-for-Service, Not Cost Settlement: Why CYBHI Reconciliation Is Its Own Workflow

Under the CYBHI fee schedule, the LEA or school-linked provider receives a straight fee-for-service rate that includes both the federal and state share, paid per claim per service line. There is no annual reconciliation between interim payments and allowable cost. The reimbursement that lands on the Carelon remittance is the final payment for that claim line, and what the finance team is reconciling is whether that final payment matches what was billed, was deposited correctly, and was posted to the right GL line.

This is the structural break with the LEA Billing Option Program (BOP), which finance teams in this audience often have a longer history with. LEA BOP historically required interim payments to be reconciled against allowable cost through the Cost and Reimbursement Comparison Schedule (CRCS) at the end of the cost reporting period; the fiscal-year-end true-up was the reconciliation, and the interim claims were just placeholders against the eventual settlement. CYBHI does not work that way. There is no CRCS for CYBHI, and there is no period-end true-up against allowable cost.

The operational consequence shows up directly in what the workpaper looks like. A CYBHI claim-to-cash reconciliation LEA workpaper does not carry cost-settlement columns — no allowable cost, no settlement adjustment, no federal share recoupment. It carries claim-to-cash columns: what was submitted, what Carelon paid, what variance exists, what was deposited, what was posted. The exceptions that age in this workpaper are unpaid, denied, partially paid, or unmatched claims. They are not under- or over-reimbursed cost-report categories.

Some districts and county offices run both programs in parallel — a CYBHI workpaper for school-linked behavioral health services billed through Carelon, and a separate Medicaid LEA BOP reconciliation for the broader school Medicaid scope including LEA BOP-eligible health and related services. 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; the rest of this article assumes claim-to-cash mechanics throughout.

Conflating the two creates real audit and resubmission errors. The most common one is a CYBHI denial that goes unworked because finance is waiting for an annual settlement to true it up — which will never come. 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 reason for separating CYBHI reconciliation cleanly from cost settlement is not theoretical; it is to keep the resubmission queue inside the window where resubmission is still possible.

---

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. Walk the schema left to right, and the workpaper reads as the audit trail of one service line through the entire claim-to-cash arc.

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

• Student or internal identifier — the load-bearing 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 load-bearing 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.

The fee schedule amount and the reimbursement amount sit as deliberately separate columns. The fee schedule amount is what the entity expected to receive at the published rate; the reimbursement amount is what Carelon actually paid on the remittance. A CYBHI fee schedule claims spreadsheet that collapses the two into a single "amount" column loses the variance — the most diagnostic signal in the workpaper, because it surfaces partial payments, modifier-driven adjustments, and unit-cap reductions that would otherwise pass as fully paid.

The schema is the same whether the LEA submits its own claims through Availity or operates through a billing vendor or county office. The artifact that supplies each column may shift — a vendor portal export rather than a direct Carelon download, a county office aggregated submitted-claims report rather than an Availity output — but the columns themselves do not. Treat the schema as the contract; treat the artifacts as the inputs that feed it.

---

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. They are not load-bearing for reconciliation, and putting them in a finance-accessible artifact materially changes who is permitted to handle the file.

The governing controls are the participating entity's own. 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. A workpaper that respects the minimum-detail principle is materially easier to share inside the finance function and across an audit; a workpaper that mirrors the clinical record creates access constraints that frequently end with finance simply not running the reconciliation at all. Build the schema thin on purpose, and let the clinical system retain the detail that does not need to leave it.

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 load-bearing column. 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.

The first reconciliation moment of the workpaper happens at this layer. For every service log line in the period, the workpaper either has a matching submitted-claims row or it does not. The "service log without submitted claim" exception category is created here and aged from this point — and from the date of service, not from the date the gap was noticed. A service log that sits unbilled is the most common preventable cause of a row aging out of the 365-day window, and surfacing it at the layer 2 match is what gives the finance team the runway to do something about it.

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 GL data is what lets the workpaper answer the questions a controller asks during a close.

The line-level posting matters for two practical reasons beyond audit trail. The first is revenue allocation: posting only at the deposit aggregate level loses the per-service-line trace that lets a controller answer which CYBHI service lines drove this month's revenue, at what rate, for which school site, and under which payer. The second is variance attribution: when the workpaper shows that a denied line was eventually paid on resubmission three months later, the GL posting on the resubmitted line carries forward to the period it was actually deposited in, while the original aging on the line stays anchored to the date of service. Aggregate-only posting collapses both views.

The deposit and GL layer is where finance-office discipline meets the reconciliation workpaper directly. This is the layer where standard controls — bank reconciliation against the deposit batch, GL posting review against the journal entry, fund-level reporting against the categorical fund — apply to CYBHI revenue alongside every other revenue stream the entity manages. CYBHI is not a separate financial control regime; it is a CYBHI-specific input to the same controls the finance team already runs, and the workpaper is the artifact that lets it slot in. The broader education finance team AP automation context covers the adjacent disbursement-side automation that often sits in the same finance function, and the same instinct applies in reverse on the revenue side: the more the CYBHI workpaper looks like the rest of the entity's reconciliation work, the easier it is to maintain.

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 is an audit risk and 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. The point of the categories is not to create paperwork; it is to make the queue actionable by routing each exception to the function that can close it.

Duplicate and mismatched-record exceptions form their own category, and they tend to surface only with line-grained reconciliation. The same service log appearing on two submitted claims means a billing duplication that needs one claim voided. The same claim paid twice means a Carelon-side double-pay that needs adjustment in a future remittance. Remittance lines that do not align to any submitted claim at the line level can be a payer-side resequencing of the original submission or, occasionally, a remittance for a different entity that was misrouted. Claim-grained workpapers tend to absorb these into a single status; line-grained workpapers expose them, which is one of the structural reasons the schema is built one row per service line.

The aged-exceptions queue is a standing operational artifact, not a periodic clean-up. It is reviewed at month-end alongside the close, walked through with the controller at quarter-end, and used as documentation if the participating entity is ever asked to substantiate its CYBHI revenue. Where the queue is small and steadily worked, the controller's questions are about specific lines. Where the queue is large and under-worked, the questions are about the workflow that produced the queue — and at that point the workpaper itself becomes the answer the finance team needs to be able to walk through.

---

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 for entities submitting in-house and as vendor portal downloads for those that go through a billing vendor or county office. 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. None of these arrive as the workpaper schema; each has to be translated into structured rows the workpaper can absorb.

The translation work is, in concrete terms, an artifact-to-spreadsheet job that runs every period. The finance team specifies which columns the workpaper needs from each artifact — the schema established earlier in the article — runs the artifact through extraction, and gets back a row set with the workpaper columns already populated. Period over period, every artifact, every entity. This is the loop the workpaper depends on, and the throughput of the loop is what determines whether the workpaper stays current or falls behind into a quarter-end clean-up.

Prompt-based extraction is what 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. The same prompt handles the variant remittance layouts across the program.
• 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 — some vendor portals deliver it that way — 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 without any post-processing.
• 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 — which is the exact shape the workpaper schema expects. The interaction model is a single prompt field with a file upload, so a finance team writes the prompt once for each artifact type and reuses it every period. 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 is what makes the extracted rows defensible against the workpaper's eventual audit question of where each line came from.

The privacy discipline carries through into the extraction prompt itself. The prompt is the place to enforce minimum-student-detail at the translation step, instructing the extraction to pull the internal identifier and to ignore name, diagnosis, clinical narrative, and assessment content even where the source artifact contains them. The finance workpaper then receives only what reconciliation actually requires, by construction, rather than relying on a post-processing step that would otherwise have to redact what should not have been pulled in the first place. The same instinct that keeps the workpaper schema thin keeps the extraction prompt thin, and both push in the same direction.

The reconciliation arc described across the article — service log to claim to remittance to deposit to GL, with aged exceptions as a standing queue against the 365-day window — is built and maintained period by period through this artifact-to-row translation step. The schema is the contract, the artifacts are the inputs, the extraction is the translation, and the workpaper is the running output. Where each part of the loop is repeatable, the workpaper stays current, the aged-exceptions queue stays small, and the CYBHI revenue line stays defensible at every close. Where one part of the loop is fragile, the workpaper drifts and the queue grows; the failure usually shows up first in the over-365 bucket, and by then the runway to fix it is gone.