What an 835 actually tells you
The X12 835 is the payer's electronic remittance advice. One transaction set is one payment: the check or EFT in BPR and TRN, a CLP loop for every claim it covers, the payer's adjustments in CAS, service lines in SVC, and provider-level adjustments in PLB outside the claims altogether. Revitics reads those segments, plus the payer name, patient and provider identifiers, dates and remark codes beside them, stores every adjustment group and reason code verbatim, and never rewrites one downstream.
| Field | What it means | What it does not tell you |
|---|---|---|
| BPR02, TRN02 | The total of this check or EFT, and its trace number. | Whether any claim on it was paid correctly. It balances even when every claim is short. |
| CLP01, CLP07 | Your claim number and the payer's claim control number. | That either matches your records; payers sometimes truncate or re-key them, and the 835 often arrives before the 837 is loaded. |
| CLP02 | Claim status: 1, 2, 3 processed as primary, secondary, tertiary; 4 denied; 22 reversal of a prior payment. | Why. A claim processed as primary can still be paid at the wrong rate. |
| CLP03, CLP04, CLP05 | Billed charge, amount paid, and the amount assigned to the patient. | Whether CLP04 is what your agreement required. Nothing in an 835 references the contract; the allowable is implied by the write-off, never stated as a rate. |
| CAS | Adjustment group (CO contractual, PR patient responsibility, OA other, PI payer initiated), a Claim Adjustment Reason Code, and an amount for each. | Whether the rate behind the adjustment is the contracted one. CO-45, "charge exceeds fee schedule or maximum allowable", says the payer applied its allowable, never what that allowable was. |
| SVC | Line-level procedure, billed charge and paid amount. | How the line was priced. Revitics takes units and modifiers from your 837 rather than from the SVC, and the rate table is nowhere in the file. |
| PLB | Provider-level adjustments: takebacks, interest, capitation, penalties. | Which claim a takeback belongs to unless the reference is populated. It is where recovered money leaves again. |
Why "paid" is not "paid correctly"
Judging a payment takes three inputs, and the 835 holds one of them. Billed comes from the 837: the claim total in CLM02 and each line's procedure, modifiers, units and charge in SV1 or SV2, plus the revenue codes and DRG on an institutional bill. Paid comes from the 835: CLP04 and the SVC lines, net of any PLB takeback that later reversed part of it. Owed comes from your contract, and neither transaction refers to it.
This is why underpayments hide so well. The payer pays something, writes the remainder off under CO-45, and the account goes to zero, which is exactly what a correctly paid account looks like. The write-off is a claim about what was owed, not proof of it. Revitics treats it that way: the contractual adjustment is justified only down to what a verified term says the payer owed, and anything beyond that is the underpayment wearing a reason code.
How to compute what was owed
Expected reimbursement is arithmetic that depends on the agreement's methodology for the service. Revitics implements four, each as a separate strategy in a deterministic engine that no language model touches:
- Fee schedule: the contracted rate for the code, multiplied by units.
- Percent of charge: the billed charge multiplied by the contracted percentage.
- Flat rate: a fixed amount for the line regardless of charge.
- Case rate: one amount for the whole claim, matched to the claim's DRG when the term is DRG-specific, taking precedence over line-by-line pricing.
Two details decide whether the result survives scrutiny. First, rounding: every amount is quantized to the cent, half up, as payers and fee schedules generally round. Banker's rounding, the default in Python's decimal arithmetic and in floating point, sends an exact half to the even neighbour, so 65% of $12.50 becomes $8.12 instead of $8.13 and a correctly paid claim looks a cent short. Second, term selection: a CPT-plus-modifier term beats a plain CPT or HCPCS term, which beats a revenue-code term, which beats a contract-wide default, and among equals the latest effective term wins so an amendment supersedes the rate it restates.
The contracted allowable is then reduced by what the payer assigned to the patient in CLP05, giving the expected payer payment. Here is the whole calculation on a synthetic claim.
| Line 1 billed, 2 units (837 SV1) | $1,750.00 |
| Line 2 billed (837 SV1) | $1,250.00 |
| Claim total (837 CLM02, 835 CLP03) | $3,000.00 |
| Line 1 verified term: fee schedule $412.50 × 2 units | $825.00 |
| Line 2 verified term: 65% of charge | $812.50 |
| Contracted allowable | $1,637.50 |
| Patient responsibility (835 CLP05, CAS PR-1) | −$150.00 |
| Expected payer payment | $1,487.50 |
| Payer actually paid (835 CLP04) | $1,212.50 |
| Written off as contractual (CAS CO-45) | $1,637.50 |
| Variance: expected less paid | $275.00 |
The 835 balances to the $3,000.00 billed and the account closes at zero. Of the write-off the contract justifies $1,362.50; the remaining $275.00 is the underpayment. Round synthetic numbers, not a customer's figures.
What separates a finding from noise
A variance is not a finding. What makes a programme credible is what it refuses to count. These are the gates Revitics applies.
- The contract term must be verified by a person. Extraction reads the uploaded agreement and proposes candidate terms, each with the excerpt, line and page it came from. A candidate prices nothing; only a term a person has reviewed and marked verified participates, and where none applies the engine returns a not-computable result — no expected payment — rather than a guess.
- The remittance must actually match the claim. A payment binds on your claim number, on the payer's claim control number, or when patient, date of service and billed charge agree on exactly one claim. Anything weaker goes to review with the reasons stated and is never force-matched.
- The variance must clear the tenant's thresholds. An underpayment is raised only when the variance is at least the tenant's minimum dollar amount (the shipped default is $25.00) and confidence is at least the tenant's minimum (default 0.70), with the calculation's share of that confidence scaled by the share of lines priced.
- Partial pricing is stated, not smoothed. When only some lines have a verified term, the expectation covers those lines, is measured against what was paid on them, and lists the unpriced lines as excluded.
- Denials stay out of the underpayment queue. A claim with status 4, or paid nothing under a CO, PI or OA adjustment, is classified from its dominant reason code and handled as a denial; CO-45 is classed contractual and eligible for reconsideration.
- No contract means no number. A paid claim with an unpaid balance and no verified term becomes a payment review carrying $0.00, meaning "nobody knows yet", not "worth nothing".
Proving it to the payer
Every finding eventually becomes a letter with a number in it, and the payer will check that number against its own remittance and its own copy of the contract. So the package is built from what the payer can verify: a request for reconsideration stating the payer's own adjustment code and amount, the contracted allowable, the expected payment after the patient's share, and the difference in dispute. Exhibits follow: A, the claim as billed, line by line; B, the payer's adjudication with its exact CAS codes, patient-responsibility adjustments kept separate because they are not contested; C, the expected-payment calculation; D, the contract term relied upon, with its excerpt; and, where they exist, acknowledgment history, prior submissions and a contested takeback. Only enclosed exhibits are named.
What is not enclosed matters as much. The raw 835 and 837 files cover other patients and the contract document is the whole agreement; neither is ever attached. Where proof such as clinical notes does not exist in the system, the package prints a stated omission addressed to the payer, because a package that is silent about a gap reads as complete.
The evidence is frozen when the letter is written and hashed with SHA-256 over a canonical serialization. Approval is blocked if the evidence has changed since, if the letter cites an unverified term, if there is no matched remittance to dispute, or if the letter's amount disagrees with the case. Nothing is sent without a person approving it, and the package the platform transmits — or hands to the person who sends it — is byte-for-byte what the reviewer approved, with its hash retained as the record. Each finding built on a matched remittance with a payment date carries a filing deadline: the remittance payment date plus the payer's reconsideration window when one is recorded, or a house default of 180 days; the deadline report states which payers have a recorded window and that every other deadline rests on the default.
Verified recovery versus projected recovery
Recovery can be attributed when a case is submitted or when the money arrives, and the two produce very different dashboards. Revitics attributes it only when it arrives. When a case is sent, the payment level on the claim at that moment, net of takebacks, is recorded as a baseline. Recovery is whatever a later 835 pays above that baseline, capped at the amount the case asked for, and allocated so two cases on one claim can never claim the same dollar. A takeback on a later remittance debits the recovery, and a reversal followed by a reissue cannot credit the same money twice, because both are inputs to one recomputation rather than separate credits.
So the dashboard keeps four numbers apart: identified, validated by a person, submitted, and verified against a remittance. Beneath them a claim's financial state is ten distinct values, each reported as unknown rather than zero when it cannot be computed. The product page describes the stages, and the architecture page covers the claim model behind them.
Doing this by hand
You do not need a platform for the first pass. Export the 835 detail from your clearinghouse or billing system, join it to the 837 lines on your claim number, add a column for the contracted rate on each fee-schedule line, and compute expected less paid less patient responsibility. For one payer and one fee schedule, that can surface systemic underpayments without any platform at all.
Where the spreadsheet stops is where the work gets expensive: rates that changed mid-year, case rates that ignore lines, payments that arrived under a different claim number, takebacks that undo a recovery you already booked, and, above all, proving to a payer what you sent and why the figure was right. Whichever way you do it, hold the four numbers apart, price only from terms someone has verified, and let the dashboard move only when a remittance does.
To see this run against your own 835 and 837 history and your contracts, under a signed agreement and with findings you can audit line by line, you can request an assessment. How the data is handled is set out on the security and trust page.