Multi-Payer SLP Invoice & Superbill Extraction to Excel

A multi-payer SLP private practice closes its books by normalizing commercial-insurance EOBs, Medicaid remittance advice, school-district contract invoices, and private-pay statements into one ledger keyed on date of service, CPT (92507 treatment, 92521-92524 evaluation, 92526 swallowing treatment, 92610-92617 swallowing and FEES), ICD-10 (F80.x, R13.1x, R47.x), payer, billed, allowed, paid, and patient responsibility. Adjustment reason codes (CARC, RARC, and payer-specific Medicaid codes) live on a separate sheet so denial patterns surface across payers over time. Multi-payer SLP invoice and superbill extraction works because the field set the bookkeeper needs is stable even though the document layouts that carry it are not: one prompt mapped to that stable schema produces the same row shape from an EOB, an RA, a district invoice, and a private-pay statement.

The four core payer shapes are instantly recognizable once they sit side by side, with TRICARE acting as an optional fifth for practices that accept it. A commercial EOB carries an itemized CPT line with billed, allowed, paid, patient-responsibility, and contractual write-off, plus CARC or RARC adjustments wherever a reduction applied. A Medicaid remittance advice uses a state-specific layout that may include payer-specific four-digit EOB codes that do not cross-walk to CARC or RARC. A school-district contract invoice usually itemizes service minutes per student against a per-minute, per-session, or flat-monthly contract rate, frequently with no CPT or ICD-10 on the line at all. A private-pay statement is a flat session line: billed equals paid, no allowed amount because there is no contracted rate, no adjustment codes.

The reader who lands here is usually one of two people: an external bookkeeper supporting an SLP private practice with a folder of mixed PDFs from four to six payers, or the practice's internal business manager wearing the bookkeeping hat at month-end. Either way, the practice-management-platform answer that dominates this problem only reconciles claims the PM tool itself filed against EOBs the PM tool itself ingested. That is fine for the practice on that PM tool with every payer integrated. It is not the situation many multi-payer SLP practices are actually in. The bookkeeper supporting a practice that uses a different PM tool, the practice with a thin PM export, or the practice handling a district contract or self-pay channel that never touched the PM tool still ends up with a folder of PDFs that has to become one analysis-ready sheet.

The SLP-Specific Field Set Worth Capturing

Before the schema, the codes. An SLP private practice's billing rotates around a compact set of CPT and ICD-10 ranges. Naming them once gives the bookkeeper a recognition list to apply against every payer document.

CPT treatment codes:

• 92507: individual speech, language, voice, communication, or auditory-processing treatment.
• 92508: group speech-language treatment for two or more individuals.

CPT evaluation codes:

• 92521: speech fluency evaluation.
• 92522: speech sound production evaluation.
• 92523: speech sound production evaluation with language comprehension and expression.
• 92524: behavioral and qualitative voice and resonance analysis.

The ASHA Medicare coding rules for speech-language pathology services identify CPT 92507 as the individual speech-language treatment code and CPT 92521-92524 as the SLP evaluation codes that replaced 92506 effective January 1, 2014. A bookkeeper opening a current EOB and seeing 92506 is looking at either a payer error or a stale superbill, not the modern evaluation code set.

When the source is an ASHA-style superbill rather than an insurer EOB, extraction should still treat the code set as ledger data: CPT, ICD-10, date of service, setting, fee, and patient responsibility. The bookkeeper is not validating the clinician's coding choice; they are turning the superbill into the same row shape the rest of the month uses.

CPT swallowing and FEES codes:

• 92526: swallowing dysfunction and oral-function-for-feeding treatment.
• 92610: clinical evaluation of swallowing function.
• 92611: motion fluoroscopic swallowing evaluation, commonly the videofluoroscopic swallow study.
• 92612-92617: the FEES and FEESST family, including endoscopic swallowing evaluation, sensory testing, interpretation, and report codes.

ICD-10 ranges. SLP claim lines pair CPT with a diagnosis from a small set of code families:

• F80.x: developmental speech and language disorders, including phonological disorder, expressive language disorder, mixed receptive-expressive language disorder, speech and language delay due to hearing loss, and developmental fluency disorder.
• R13.1x: dysphagia, including oral, oropharyngeal, pharyngeal, and pharyngoesophageal phases.
• R47.x: speech disturbances, including aphasia, dysphasia, dysarthria, slurred speech, and related conditions.

Setting markers. Place of service is a ledger field, not a footnote. The same 92507 unit is reimbursed at materially different rates across settings, and the fields that appear on the source document shift with setting:

• Outpatient clinic and private practice: the standard CPT-coded EOB shape with billed, allowed, paid, and patient-responsibility breakdowns.
• Home-based early intervention: frequently billed under state Part C contracts that pay per visit or per minute, with no CPT line on the source document.
• School-based: billed as district contract minutes against a per-minute or per-session rate, again without CPT in many cases.
• SNF: subject to consolidated billing rules that affect the allowed amount and which payer is responsible.
• Acute inpatient rehab: bundled under a different prospective payment system, with SLP work usually invisible at line-item level.

The codes and settings above are capture targets, not clinical guidance. The bookkeeper records what shows up on the documents the practice receives. Selecting the correct code for a given session is the SLP's job, and ASHA's reimbursement guidance is where that decision belongs.

The Four Payer Shapes a Single Practice Sees in One Month

The same SLP session shows up four different ways. Hold one concrete event in mind: a 30-minute 92507 individual treatment delivered to a five-year-old child diagnosed F80.1, pediatric expressive language disorder, in the practice's outpatient clinic. Now follow that single event through the document shapes that land in the bookkeeper's inbox.

Commercial EOB. An itemized claim line with date of service, CPT 92507, modifier where one applies, units billed, billed amount, allowed amount, paid amount, contractual write-off, and patient responsibility broken out into deductible, coinsurance, and copay. Adjustment reason codes attach to the line wherever a reduction applies: CARC for the adjustment reason, RARC for any remark code that explains the adjustment further. The payer-specific layout varies, but the fields are consistent. Many commercial payers also issue an 835 electronic remittance advice alongside the human-readable EOB. If the practice's PM tool ingests the ERA and posts payments automatically, the bookkeeper may only need the PDF EOB for clients that lack that integration or for out-of-network claims that arrive on paper. Where the ERA is not posted, the PDF EOB is the primary source.

Medicaid remittance advice. State Medicaid programs and Medicaid managed-care organizations use state-specific RA layouts that differ meaningfully from commercial EOBs. Two hazards recur. First, many states use payer-specific four-digit EOB or edit codes that are not CARC or RARC and do not cross-walk cleanly to them. The bookkeeper records these verbatim in the reason-codes column and lets a per-state code reference handle the description lookup. Second, the same delivered 92507 session may appear with a state-defined HCPCS modifier where commercial payers would attach none, such as a modifier tied to an SLP plan of care, an education-program context, or a payer-specific program rule. The modifier matters for rate validation and for understanding which contract the line was paid under. Speech therapy Medicaid remittance advice extraction succeeds or fails on getting these state-specific fields onto the row in their original form rather than forcing them into a CARC/RARC-shaped column where they do not belong.

School-district contract invoice. Often the practice issues this invoice itself, against a service log of minutes delivered per student. The line items usually read as student initials or ID, dates of service, minutes per date, and a contract-rate-applied total: sometimes per minute, sometimes per session, sometimes a flat monthly retainer with the service log as documentation rather than the basis for the line total. CPT may not appear at all, and ICD-10 usually does not. The bookkeeper's job is to record the channel as a payer in its own right, capture the underlying minutes and the contract rate that produced the invoice total, and let the schema absorb a row where CPT and ICD-10 are blank. The invoice is the billed amount; the district's eventual remittance, frequently weeks or months later, is what populates the paid amount on that row.

Private-pay statement. Either the practice's own statement to a self-pay family or a payment record where no insurer touched the session. Structurally simple: a flat session line with billed equal to paid, no allowed amount because there is no contracted rate, no CARC or RARC, no patient-responsibility breakdown. The bookkeeper records the row at face value and flags it as a private-pay channel. The downstream value of capturing it on the same ledger is rate comparison: what the practice actually nets per 92507 unit when a self-pay family pays in full versus what the same unit nets after a commercial payer's allowed-amount haircut.

TRICARE, where present. Most SLP private practices either accept TRICARE or do not. For those that do, the TRICARE EOB layout reads as a hybrid: fee-schedule allowed amounts in the manner of a government payer, with a CPT-coded line and CARC/RARC adjustments in the manner of a commercial EOB. The bookkeeper treats it as commercial-shape with a TRICARE payer tag and lets the analytical sheets sort the channel out from there.

The implication is that the same 30-minute 92507 session has produced different rows in different documents, each with a partially overlapping field set. A bookkeeper who maps each shape to its own column conventions ad hoc, capturing minutes-as-units on the district row but CPT-units-as-units on the commercial row, or stuffing a Medicaid state edit code into a column intended only for CARC values, ends up with a sheet where columns mean different things in different rows.

The Unified Ledger Schema That Absorbs All Four Shapes

A speech therapy private practice bookkeeping spreadsheet works when one main sheet absorbs every payer channel and every row means the same thing column by column, with blanks where a source document genuinely does not carry a field. The columns below are the canonical set, in order, with the rationale for each.

• Date of Service: the date the session was delivered, not the date the EOB or invoice was issued. Cross-payer analysis pivots on this.
• Payer: the named payer, such as Aetna, BCBS-IL, Illinois Medicaid, Riverside USD, or Self-Pay. Specific names, not buckets.
• Payer Channel: the type tag: commercial, Medicaid, district contract, private pay, TRICARE. This powers channel-level pivots.
• Patient or Student ID: an internal identifier the practice uses, never PHI in the ledger. The ledger is a financial record; identifiable patient data belongs in the EHR or PM tool.
• CPT: the procedure code where one is on the source. Blank for district-contract minute-only rows and for any other source that does not carry a CPT.
• CPT Modifier: captured where the source carries one. Empty otherwise; do not invent modifiers to make rows look uniform.
• Units: CPT units for coded rows, minutes for district-contract rows. Pair this with a Unit Type column, or a separate Minutes column, so the row's number is unambiguous at analysis time.
• ICD-10: the diagnosis code where the source carries it. Blank where it does not.
• Place of Service / Setting: outpatient clinic, school, home, SNF, and so on. This drives cross-setting reimbursement-rate analysis.
• Billed Amount: what the practice or EOB shows as billed.
• Allowed Amount: what the payer's contract allows. Blank for private-pay rows where there is no contracted rate.
• Paid Amount: what the payer actually paid.
• Patient Responsibility: deductible plus coinsurance plus copay, or the equivalent breakdown the source carries.
• Contractual Write-Off: billed minus allowed, where applicable.
• Reason Codes: raw codes from the source, captured verbatim. CARC, RARC, and payer-specific Medicaid four-digit codes go in this column without translation. Description and analysis happen on the denial-pattern sheet.
• Source File and Page: the filename and page number the row was extracted from. This is the verification column; without it, a disputed row is impossible to defend without opening the original PDF blind.

The case for one sheet across all channels is the analytical case. Month-end questions, total paid by payer, write-off rate by CPT, denial frequency by payer-CPT pair, payer mix as a percent of revenue, days-to-payment per channel, all want a single long table with a Payer column to filter or pivot on. Four separate sheets that have to be unioned every time create rework that compounds across months, and any one missing column on any one sheet breaks the analysis. A single sheet with meaningful blanks scales to whatever payer mix the practice picks up next.

Three shape-handling rules keep that single sheet honest. District-contract rows leave CPT and ICD-10 blank, carry minutes in the Units column with Unit Type set to "minutes", and rely on the Payer and Payer Channel columns to retain meaning. Private-pay rows leave Allowed Amount blank, set Billed equal to Paid, and leave Reason Codes empty. Medicaid RA rows put any payer-specific four-digit code into Reason Codes alongside any CARC or RARC, with one row per claim line and the cross-walk handled later. Blanks here are signal, not missing data: a blank Allowed Amount on a row tagged private pay tells the analyst that the row is at face value, not that the column failed to populate.

A small Payer Reference sheet alongside the main ledger holds, per payer, the channel type, the contract rate for district contracts or the fee schedule for commercial or Medicaid contracts where the practice has it on file, the contract term dates, and payer-specific quirks worth noting, such as state Medicaid edit-code references, district-specific minute-rounding rules, and payers that pay quarterly rather than per claim. Keeping this off the main ledger prevents transactional rows from carrying redundant rate data and lets a single rate change at contract renewal flow through to later analysis without a backfill.

Capturing CARC and RARC Codes on a Separate Denial-Pattern Sheet

The reason-codes column on the main ledger is a verbatim capture, not an analytical surface. To work with speech therapy CARC and RARC denial reason codes the way they were designed to be used, pattern detection across payers and over time, they need their own sheet.

Three code types flow into that column from the source documents, and they cross-walk separately.

• CARC (Claim Adjustment Reason Code): the WPC-maintained national list. Familiar examples include CO-45 for charges beyond the contracted fee, CO-97 for a service included in another payment, PR-1 for deductible, PR-2 for coinsurance, and PR-3 for copay.
• RARC (Remittance Advice Remark Code): also WPC-maintained. RARCs supplement CARCs with explanation. N130, M86, and M97 are examples bookkeepers may see around referral, coverage, or repeat-service limitations.
• Payer-specific Medicaid four-digit codes: state-defined edit codes that look superficially like CARC values but do not share a national list. They cross-walk against per-state references, not against the WPC list.

The bookkeeper captures all three types verbatim into Reason Codes on the main ledger and lets the Denial Pattern sheet sort them out. Its columns are:

• Date of Service: copied from the main-ledger row.
• Payer: the specific payer the code came from.
• CPT: the procedure code on the affected line.
• Reason Code: the code itself, such as CO-45, N130, or a state Medicaid edit code.
• Reason Code Type: CARC, RARC, or Medicaid Payer-Specific.
• Code Description: the human-readable description, looked up once and cached on a Code Reference sub-sheet.
• Adjusted Amount: the dollar amount the code corresponds to on that line.
• Was the Claim Eventually Paid: a boolean updated as the bookkeeper closes the loop on each denial. A code on a line that ultimately paid is informational; a code on a line that never paid is the recoverable-revenue question.

One row per code per claim line. A single 92507 line that arrived with both a CO-45 contractual obligation and a separate unit-edit reduction produces two rows on this sheet, not one row with two codes mashed together.

The questions the sheet exists to answer are specific. Which payer-and-code pairs recur month over month, signaling a systemic billing or coverage problem rather than a one-off? Which CPT codes draw the highest write-off rate at which payer? Do 92507 denials cluster by ICD-10 family, for example F80.81 fluency-disorder claims denied by a payer that excludes fluency therapy from its SLP benefit? Each becomes a pivot off this sheet: Payer x Reason Code, CPT x Payer x Adjusted Amount, ICD-10 x Payer x Eventually Paid. The flat structure of one row per code is what makes those pivots clean.

The Code Reference sub-sheet is a small lookup table, code, code type, human-readable description, populated once per new code seen so analysis pivots show "CO-97 procedure included in another payment" rather than the bare code. State Medicaid four-digit codes need a per-state reference; there is no national list to cross-walk to, and the same four digits can mean different things in different state programs.

The operational point underneath the structure: a Denial Pattern sheet only earns its keep if it gets reviewed monthly. A code that has appeared on six 92507 lines from the same payer over three months is a billing-process question to escalate to the SLP or the biller, not just a data point in a spreadsheet. The structure makes the pattern visible; reviewing it makes the pattern actionable.

Folding the School-District Contract Channel into the Same Ledger

A school-district contract often sits on its own sheet because it does not look like an EOB and the bookkeeper does not want to disturb the insurance reconciliation by mixing in rows that have no CPT and no allowed amount. That instinct is administratively understandable and analytically expensive. Cross-payer questions, total revenue per delivered SLP hour, payer mix as a share of monthly billings, days-to-payment by channel, require district rows to live on the same sheet as the rest. The schema absorbs them; this section explains the mechanics.

This article is about the bookkeeper's reconciliation across all of the practice's payers. It is not about how to bill the district correctly. The reader who needs the upstream provider-billing-to-district workflow itself, invoice format, district approval cycle, contract-line documentation, should follow the dedicated school district speech therapy contract billing piece. The mechanics below assume the district invoice has already been issued and either paid, partially paid, or remitted, and the bookkeeper now needs that activity on the same sheet as the EOBs and RAs.

A district-contract row enters the main ledger with CPT and ICD-10 blank, Units carrying the service-log minutes delivered, Unit Type set to "minutes", the Payer column naming the district, the Payer Channel set to "district contract", and Billed, Allowed, and Paid driven by the contract rate applied to the minutes, or by the per-session rate applied to sessions, depending on how the contract is structured. The Reason Codes column stays empty for most district rows; districts pay against contract terms or short-pay against an exception that lands as a separate communication, not as an adjustment code on a remittance.

The unit-conversion question deserves to be handled directly. CPT 92507 is conventionally treated by many payers as a 30-minute service, with timed-code rules varying by payer policy. District contracts are commonly written in raw minutes, such as 60 minutes per week per eligible student at a per-minute rate, so a row that needs to be compared against the practice's CPT-billed work needs a conversion. Apply the conversion at analysis time, not on storage. Keep the source of truth, the district's reported minutes and contract rate, on the row, and let a derived column or separate analytical view compute comparable CPT-equivalent units when a cross-channel pivot needs them. Storing the converted value on the row instead of the source value loses the auditable link back to the contract and breaks later analysis when the contract rate changes at renewal.

Where the contract reference data lives matters. The Payer Reference sheet, already established alongside the main ledger, is the right place for the per-district contract rate, contract term dates, and unit definition: per-minute, per-session, or flat-monthly retainer. Do not store the rate on every transactional row. Pivot or look up from the reference sheet when computing expected billed amounts or running rate-against-paid checks. A single rate change at contract renewal then flows through later analysis without a backfill, and historical rows still defend their own billed amounts against the rate that applied at the time.

A related channel routinely surfaces here. When an SLP private practice delivers some of its school-based work through a non-public agency contracted to a district rather than under a direct district contract, the agency-side invoicing follows a parallel pattern with its own minute tracking and a slightly different reconciliation surface. The mechanics translate, and the dedicated treatment is at NPA monthly invoice extraction by student service minute. For the bookkeeper's purposes here, the NPA-channel rows enter the same main ledger with the agency named in the Payer column and the channel tagged appropriately.

With district rows folded in, the questions that were impossible across separate sheets become straightforward pivots. Total revenue per CPT 92507 hour delivered across all payers, after converting district minutes to comparable units. Payer mix by month, where the district appears alongside Aetna and the state Medicaid plan as a percent of monthly billings. Days-to-payment per channel, with the typical multi-week district remittance lag visible against the typical commercial EOB cycle. None of those analyses are reachable when the district sits on its own sheet, and all of them are routine month-end outputs once it does not.

Why Prompt-Driven Extraction Fits Heterogeneous Payer Formats

The schema is stable. The documents that carry it are not. That asymmetry is the engineering problem the bookkeeper is actually solving, and it determines what tooling fits.

The schema from the prior sections, date of service, payer, payer channel, CPT, modifier, units, ICD-10, place of service, billed, allowed, paid, patient responsibility, write-off, reason codes, source file and page, is what the practice needs the ledger to carry every month, regardless of payer. The documents that supply those fields drift. Aetna redesigns its EOB layout. The state Medicaid program adds a new four-digit edit-code family or shifts the position of the modifier column on its RA. The district switches from a per-session rate to a per-minute rate mid-year and reformats the invoice to match. A rigid OCR template tuned to the prior layout breaks the moment a position on the page moves; a PM tool's in-platform reconciliation does not help for documents that never entered through that PM tool.

A natural-language extraction prompt mapped to the unified schema absorbs that drift because it describes what to extract, not where on the page to find it. The prompt names the columns the ledger needs and the per-payer-shape rules already worked out: leave CPT blank when the source carries minutes only, capture state Medicaid four-digit codes verbatim alongside CARC and RARC values, set Allowed blank when the row is private pay. The same prompt produces a correctly shaped row whether the input PDF is an Aetna EOB, a Medicaid RA, a district contract invoice, or a self-pay statement. The format drift is absorbed at the description layer rather than re-encoded as new templates every time a payer changes layout.

The contrast with PM-tool reconciliation is more specific than "AI is better than software." A practice management platform reconciles the claims it filed against the EOBs it ingested. That works for the practice on that PM tool with every payer integrated and every claim posted through it. It does not help the external bookkeeper supporting a practice on a different PM tool, the practice running a thin PM export that lacks line-level detail, or the practice handling a district contract or self-pay channel that never touched the PM tool. The unified ledger is what bridges those gaps, and a prompt-driven pipeline is what populates the unified ledger across the full payer mix.

This is the job AI invoice and document extraction software is built to do. The interaction model is a prompt field and an upload area: write one prompt that names the ledger schema, attach the month's batch of mixed PDFs from every payer, and download a single Excel, CSV, or JSON file with one row per claim line in the shape the ledger expects. The same prompt works across an EOB, a Medicaid RA, a district contract invoice, and a private-pay statement, with no per-template configuration to maintain. The same interface handles volume: up to 6,000 files per batch and individual PDFs up to 5,000 pages, so a quarterly catch-up batch from a backlogged practice runs through the same prompt and workflow as a routine monthly close. Every output row carries a reference to the source file and page it was extracted from, which is the verification column the schema already specifies; a disputed allowed amount on a row from June can be traced back to the original PDF without re-opening the entire batch. Output values are typed natively in Excel, numbers as numbers and dates as dates, so pivot tables on the denial-pattern sheet and cross-payer revenue analysis work without a re-typing pass.

The same heterogeneity argument holds in adjacent therapy verticals. An ABA practice reconciling 97153, 97155, and 97156 line items across the same commercial, Medicaid, and private-pay mix faces the same per-payer-format-drift problem against a different CPT set; the mechanics translate, and the ABA therapy invoice extraction to Excel treatment carries the modality-specific schema. The single-prompt-against-stable-schema pattern is what makes the workflow portable across vertical CPT sets without rebuilding the pipeline every time.

The engineering point underneath the workflow is simple: one prompt that names the unified schema is one thing to maintain. Per-template OCR is a maintenance liability that scales with payer count and with every layout change a payer makes. Per-PM-tool integration is a maintenance liability that scales with the number of PM tools the bookkeeper supports across clients. Neither liability disappears with practice growth; both grow with it.

Using the Unified Ledger to Spot Underpayments and Close the Month

Once the ledger and the denial-pattern sheet are populated, monthly close is a small set of queries run against them. SLP invoice reconciliation in Excel is straightforward when the schema has done its work; the analytical moves below are pivot tables and filtered ranges, not bespoke reports.

The underpayment query. Filter the ledger to commercial and Medicaid rows where Paid Amount is less than Allowed Amount minus Patient Responsibility, group by Payer and CPT, and surface the lines where the payer underpaid against its own contracted allowed amount. The distinction worth holding here is between the contractual write-off and the recoverable underpayment. The gap between Billed and Allowed is the contractual write-off, the payer's negotiated discount, and is generally not recoverable. The gap between Allowed and Paid plus Patient Responsibility is the recoverable underpayment, and it is what the bookkeeper escalates to the biller for resubmission or appeal. A practice that has been treating the write-off as the problem has been working the wrong number; a practice that has not been checking the second gap has been leaving recoverable revenue on the table.

The denial-pattern review. Pivot the Denial Pattern sheet by Payer x Reason Code over the trailing three months. The threshold for action is roughly this: a code that appears on more than three claim lines for one payer, or on more than five percent of that payer's claim lines, is a pattern. Some codes are correct adjustments and warrant no escalation: PR-1 deductible, PR-2 coinsurance, and PR-3 copay are patient-responsibility allocations, not denials. The review is about codes that signal a billing or coverage problem: a CO-97 cluster suggesting the payer is bundling 92507 against another procedure, an N130 cluster pointing at a referral or authorization gap, a state Medicaid four-digit code that has appeared every month for a quarter and has never been investigated. Each pattern becomes a billing-process question to escalate to the SLP or the practice's biller, with the specific payer-code-CPT combination as the start of the conversation.

The district-minute reconciliation. With district rows in the main ledger and the practice's CPT-coded rows alongside, reconcile that the SLP's logged 92507 minutes for district students agree with the minutes the district was invoiced for. Discrepancies tend to land in two shapes. Minutes invoiced without a clinician log entry: the invoice claims service was delivered but the clinical documentation does not back it. This is a documentation-or-billing escalation back to the SLP, and it is the kind of issue that turns into an audit problem if the district reviews its records. Logged sessions that did not make it onto the invoice: the SLP delivered and documented service that was never billed. This is recoverable revenue waiting to be invoiced on next month's cycle. Both should be logged with the student-or-IEP identifier and the date so the next month's review can confirm closure.

The cross-payer revenue view. With every payer channel on one sheet, the practice owner's questions become routine pivots. Total paid per delivered 92507 unit across all payers, after converting district minutes to comparable units. Payer mix by month: what share of revenue came from commercial, Medicaid, district, and private pay this period and how that has shifted quarter over quarter. Days-to-payment per channel: how quickly each payer pays from date of service to payment received, which becomes the cash-flow input the practice owner uses to plan against. None of these are bookkeeping diagnostics; they are operational outputs the practice runs on.

The principles underneath these queries are not unique to SLP work. The pattern of three-way matching, what was billed, what was allowed under contract, what was actually paid, is the general reconciliation problem treated more broadly in the invoice reconciliation process and three-way matching treatment. The SLP context specializes the pattern with CPT/ICD-10 fields, payer-specific reason codes, and the district-minute channel, but the underlying logic is the same.

The monthly close is finished when the ledger reconciles to deposits, the denial-pattern sheet has been reviewed and escalations logged, the district-minute reconciliation has matched the service log to the invoice, and the cross-payer revenue view has been delivered to the practice owner. Every later month's close runs the same pipeline against the next batch of mixed PDFs and the same schema.