5  Adjustments, Denials, and Reversals

A patient receives care once, but the bill for that care can change several times. The provider submits a claim, corrects it, and submits it again. The payer makes a payment, recovers part of it, and issues a different payment. A diagnosis, service date, or place of service may change along the way.

By the time these records reach our warehouse, we have a history of billing activity. What we usually want for an analysis is a history of healthcare. Getting from one to the other is the work of handling adjustments, denials, and reversals, which we’ll call ADR.

In this chapter, we’ll develop a way to preserve both histories. We’ll work through common claim scenarios, investigate how related records are identified, and build views for financial and population health analysis. The central question throughout is simple: does this row describe a new service, a change to an earlier service, or a financial movement associated with it?

5.1 Two questions, two views of the data

An analyst reconciling March payments wants to know what the payer paid and recovered in March. An analyst studying January utilization wants to know which services occurred in January, using the claim information available at a particular cutoff. These questions often begin with the same records, but they require different calculations.

Financial reporting and claims development need payment activity and its timing. A January service might generate a February payment and a March recovery. Assigning everything to January would lose the payment-period history. Received dates, adjudication dates, and successive data deliveries also help explain how a reporting period developed.

That history can support reserving, including estimates of incurred but not reported claims. Reserving also requires an incurred-period view and assumptions about obligations not yet represented in the data. A payment ledger alone is not an IBNR estimate, and a reserving method may use development summaries or successive snapshots rather than every individual claim event.

Population health analysis usually needs the current adjudicated representation of care: the diagnoses, services, providers, and amounts that remain after corrections, organized by when care occurred. Keeping every superseded claim as another visit would distort utilization, clinical cohorts, risk scores, and spending by setting.

We therefore want two connected views:

  • A history view that preserves the events or versions supplied by the source, including when we received them.
  • A current adjudicated view that resolves those records as of a stated cutoff, without treating each correction as additional care.

“Current” is more precise than “final.” A claim considered complete today may change next month. And the current view should not be the only view we retain: denial management, appeals, claims development, and reproducing an earlier report all depend on information that a latest-record table can lose.

5.2 Record type is different from adjudication status

Before looking at amounts, separate what happened to a record from what the payer decided about it.

Concept What it describes
Original The initial claim or transaction in a source’s history
Adjustment A change to a previous record or its adjudication
Replacement A new state intended to supersede an earlier state
Reversal or void An event that backs out a prior transaction or claim state
Denial A payer’s adjudication outcome for a claim or line

An original claim can be denied and a corrected claim accepted. A paid claim can later be adjusted without having been denied. A reversal can be followed by a replacement, but not every adjustment requires a full reversal. Payers use these labels differently, so the table gives us concepts to investigate rather than a universal list of source codes.

One claim can contain both payable and denied lines. Interpret adjudication status at its recorded grain: a claim-level label may not describe the outcome of every service on the bill.

The sign of a payment is another distinct piece of information. A positive value can represent a payment movement or a reported balance. Zero can reflect a denial, patient cost sharing, another payer’s responsibility, capitation, or a packaged service. A negative value can represent a reversal, a recovery, or an incremental adjustment. A null amount is unknown; it is not a zero payment or a denial.

Remittance adjustment reasons also extend beyond denials. The X12 claim-adjustment reason codes include deductibles, coinsurance, and contractual adjustments. Use the source’s record type, status, reasons, and amount definitions together. No single sign test can replace them.

5.3 Five claim histories to understand

The following examples are synthetic. Amounts are in dollars, and the rows represent one claim family: an original bill and its related corrections. A family identifier is an analytical relationship, not necessarily a field the payer supplies.

For each example, distinguish the amount reported on a row from the amount represented by the current claim. Sometimes we obtain the current amount by summing movements. Sometimes we obtain it by selecting a replacement. The source contract determines which operation is valid.

5.3.1 An original claim with no subsequent changes

Suppose a claim bills $100, allows $50, and records a $25 payer payment. In this simple example, the other $25 of the allowed amount is assigned to the patient. With no subsequent changes, the original record also represents the current adjudication.

This is the easy case, but even here a repeated row needs investigation. Receiving the same claim in three monthly full-history deliveries does not create three services or three payments. We need to distinguish a new source event from another delivery of an event we already have.

5.3.2 A denied claim followed by a corrected submission

Now suppose the first submission is denied and the provider sends a corrected bill under a new identifier:

Claim ID Reported outcome Billed Allowed Payer paid
A100 Denied $100 $0 $0
A101 Accepted $75 $25 $10

For the current service, the corrected bill reports $75 billed, $25 allowed, and $10 paid. The $100 on the denied submission remains useful for understanding the original billing attempt. It does not become an additional charge for a second service.

A report of charges across submission attempts would show $175. A report of the current bill would show $75. These are different measures. Calling both “cumulative billed amount” hides the distinction; give the column a name and definition that identify what it measures.

In this example, the denied record reports zero allowed and paid amounts. That is part of the example, not a rule for every denied record. Nor does the denial establish that the patient never received care. Preserve the original outcome for denial analysis and apply the appropriate claim-status rules for each clinical or utilization measure.

5.3.3 A full reversal followed by a replacement

Here the source delivers signed movements for all three monetary fields. The second row fully backs out the first; the third introduces the corrected bill.

Event Claim ID Billed movement Allowed movement Paid movement Cumulative paid
Original A200 $100 $50 $25 $25
Reversal A201 −$100 −$50 −$25 $0
Replacement A202 $75 $25 $10 $10

Adding the movements gives $75 billed, $25 allowed, and $10 paid. Those totals agree with the replacement in this particular source model. If the original payment occurred in February and the other two movements occurred in March, February paid activity is $25 and March activity is −$15.

The current service attributes come from the replacement. If its diagnosis or place of service changed, carrying forward the original attributes would attach the right payment to the wrong description of care.

Some sources reverse only selected financial fields or supply a reversal flag with unsigned values. We must not manufacture negative billed or allowed amounts merely because paid amount is negative. The signed representation above is useful only when the source actually supports it.

5.3.4 A reversal and replacement with multiple lines

A claim with several lines has the same problem at another grain. Consider the paid amounts for two lines whose identities remain stable in this example:

Event Line 1 movement Line 2 movement Claim movement Cumulative claim paid
Original $25 $50 $75 $75
Full reversal −$25 −$50 −$75 $0
Replacement $10 $25 $35 $35

The current claim has $10 assigned to line 1 and $25 to line 2. A header-only total of $35 would not establish that allocation. Conversely, repeating the $35 header total on both lines and summing it would produce $70.

The stable line identities matter. A replacement can remove a line, add a line, split a service, or renumber the bill. Line 2 on the replacement is not automatically the same service as line 2 on the original. As discussed in Headers and Lines, a line number identifies an item within its parent record; it is not necessarily a permanent service identifier.

If a complete replacement drops line 2, selecting the newest record for each old line independently would preserve a line that no longer belongs to the claim. We must first resolve the claim version, then take the lines belonging to that version. A source that updates individual lines requires a different method.

5.3.5 A partial adjustment without a full reversal

A payer can change only the difference between an earlier amount and a revised amount. Suppose a source supplies these signed changes:

Event Billed movement Allowed movement Paid movement
Original $100 $50 $25
Incremental adjustment $20 $10 $5
Cumulative amount $120 $60 $30

The second row is a delta, not the new total. Keeping only its $5 paid amount would understate the cumulative payment of $30. A negative delta would reduce the corresponding balance; it would not necessarily cancel the service.

Now imagine a different extract that reports the original paid balance of $25 and the revised paid balance of $30. Adding those two values gives $55, which is wrong for the current claim. In that extract, the correct operation is to select the documented current state. Subtracting the two observed states reveals a $5 change, but it does not recover any intermediate transactions omitted between snapshots.

The column can be called paid_amount in either extract. Its name does not tell us whether to add it or replace it.

5.4 Establish the source contract

The most useful first step is to ask the payer or data supplier to walk through real claim histories. A file layout tells us which fields exist. Worked examples tell us how the fields behave together.

Request examples of an unchanged claim, a denied and resubmitted claim, a full reversal, a replacement, and a partial adjustment. Include a case with several lines and one in which a line disappears. For each, establish:

  • Identity: which fields distinguish deliveries, transactions, claim versions, and lines; which references connect related claims.
  • Meaning: whether each financial field is a movement or a replacement value, and how record types and adjudication statuses are represented.
  • Order: which sequence or timestamps establish effective ordering, including events processed on the same day.
  • Scope: whether an update replaces a whole claim or selected lines, and how deletions or voids are communicated.
  • Delivery: whether a file is a snapshot, a change feed, or a restatement of a historical window, and what its cutoff includes.

Full versus incremental delivery is separate from movement versus replacement semantics. A full file can repeat the entire transaction history. An incremental file can contain new replacement states. Appending either without understanding its contract can create duplicates or incorrect balances.

Keep the source sequence distinct from the paid date and the load timestamp. Two corrections may share a paid date. A delayed file may arrive after a newer adjudication. The first row we observe may already be an adjustment if the extract begins after the original claim. “First observed” is not the same as “original.”

5.6 Turning history into analytical tables

A useful model keeps the delivered evidence and makes its interpretation explicit. Raw staging preserves the original values, source identifiers, file identity, and receipt time. A normalized history records the verified links and source event meanings. The current view then resolves that history for a stated cutoff.

Some sources supply a final_claim_flag. Establish its meaning, grain, and cutoff before using it. In a delta stream, the last event may be flagged as current while its amount still represents only a change. Selecting that row does not turn its $5 adjustment into the $30 cumulative payment from our earlier example.

In Tuva 1.0, source-specific ADR work belongs in connector staging before publishing resolved Input Layer rows. The medical-claim Input Layer grain is (claim_id, claim_line_number, data_source); different paid dates do not make repeated versions of that key valid final inputs. Tuva Core does not supply a universal payer-specific ADR policy. The Tuva Claims ADR guide describes this boundary. Keep the financial history separately and check the contract for the Tuva version you use.

The next two SQL examples illustrate different contracts. Their staging tables and fields are teaching examples, not built-in Tuva models. They use DuckDB SQL; adapt syntax and data types for your warehouse.

5.6.1 Accumulating a verified transaction ledger

Suppose we have already established a complete opening history, eliminated repeated deliveries, linked related records, and mapped stable service-line identities. Every paid_amount in staging.medical_claim_ledger is a signed movement. source_sequence uniquely orders events within each source, claim family, and logical line.

We can then calculate a running payment balance:

select
    data_source,
    claim_family_id,
    service_line_id,
    source_sequence,
    paid_date,
    paid_amount,
    case
        when count(*) over history = count(paid_amount) over history
        then sum(paid_amount) over history
        else null
    end as cumulative_paid_amount
from staging.medical_claim_ledger
window history as (
    partition by data_source, claim_family_id, service_line_id
    order by source_sequence
    rows between unbounded preceding and current row
)
order by data_source, claim_family_id, service_line_id, source_sequence;

The explicit row frame accumulates events in the verified order. The null check prevents an unknown movement from silently becoming zero: once an unknown amount enters the history, the running balance remains unknown until the missing information is resolved. A missing predecessor can still invalidate an apparently complete sum, so the opening-history assumption must be checked outside this calculation.

This running balance does not select the current diagnosis, provider, or service category. Those attributes still need the source’s replacement rules. Nor does the ordering field establish whether an event is an original, reversal, or adjustment; the source status fields provide that meaning.

5.6.2 Selecting a complete replacement claim

For a different source, suppose each version is a complete claim state. staging.medical_claim_versions contains one record per complete version, with a claim_version_id unique within each data source, a source-defined adjudication_sequence, a receipt timestamp, and a non-null is_void flag derived from documented status rules. staging.medical_claim_lines holds the lines for each version.

To reproduce the state known before April 1, 2026, select the latest available claim version and then join its lines:

with ranked_versions as (
    select
        data_source,
        claim_family_id,
        claim_version_id,
        is_void,
        row_number() over (
            partition by data_source, claim_family_id
            order by adjudication_sequence desc
        ) as version_rank
    from staging.medical_claim_versions
    where received_at < timestamp '2026-04-01 00:00:00'
)

select
    v.data_source,
    v.claim_family_id,
    v.claim_version_id,
    l.claim_line_number,
    l.paid_amount
from ranked_versions v
inner join staging.medical_claim_lines l
    on v.data_source = l.data_source
   and v.claim_version_id = l.claim_version_id
where v.version_rank = 1
  and v.is_void = false;

This requires a unique sequence within each claim family and complete version availability at the recorded receipt time. Interpret the cutoff in a documented time zone. A source with partial updates needs those updates assembled into a complete state first; the query does not perform that work.

The order of operations matters. Ranking whole claims prevents a deleted line from surviving through an older version. Ranking before excluding voids prevents an older paid claim from being resurrected after a later void. The query does not discard denied or zero-paid states merely because of their amounts. Any further exclusions depend on the analysis.

Keep the voided history even when the current service view has no row for it. A void explains the disposition of a billing record; it does not independently prove that no care occurred.

5.7 Pharmacy claims need their own rules

Pharmacy data has the same distinction between a billing history and a current record, but its transactions and identifiers differ from medical claims. NCPDP billing, reversal, and rebill requests must be interpreted alongside their responses. A submitted reversal is not necessarily an accepted reversal.

For example, the CMS pharmacy payer sheet effective July 2026 uses NCPDP D.0 billing and rebill requests, B1 and B3, and reversal requests, B2. It separately defines response statuses, including paid and duplicate-of-paid. The example shows why a transaction code and its outcome are different fields; the payer sheet’s program-specific requirements should not be generalized to other feeds.

Suppose a pharmacy submits a billing transaction with a reported $40 payer amount and 30 days supply, then successfully reverses it. If the source delivers signed paid movements, $40 and −$40 net to zero. Counting the original row as a surviving prescription would still overstate fills and days supply. If a corrected bill follows, use the documented surviving product, quantity, days supply, and payment state.

A reversal can reflect an uncollected prescription or a correction to billing; it does not have one universal clinical meaning. A paid billing record also does not prove pickup or ingestion. Do not derive medication adherence by simply counting positive financial transactions.

Retain prescription or service reference numbers, fill numbers, pharmacy identifiers, transaction identifiers, and processing order where supplied. A prescription number alone may repeat across pharmacies or fills. Follow the pharmacy source’s rules for linking reversal and rebill records, and distinguish legitimate refills or partial fills from corrected transactions. Medical claim frequency codes and medical line-number assumptions are not substitutes for that contract.

5.8 Reconcile the money and the history of care

A correct grand total is necessary, but it is not enough. We need to explain the individual histories that produce it and the categories to which those histories contribute.

For the financial view, compare payment activity with source control totals at the same grain and cutoff. On a complete, consistently defined ledger, opening balances plus movements should reconcile to closing balances. Missing predecessors, duplicate deliveries, unmatched reversals, and unknown amounts need explicit treatment.

A remittance or bank-transfer total can also include adjustments outside a specific claim. CMS’s remittance guidance describes line, claim, and provider-level adjustments. A reconciliation that ignores provider-level recoveries or other adjustments may fail even when the claim-level arithmetic is correct.

For the service view, trace the surviving claim and its lines. A replacement should not leave behind a removed diagnosis or service. A later void should not restore an earlier positive payment. Late-arriving corrections should update the appropriate service period while preserving our ability to reproduce an earlier cutoff.

Consider a bill corrected from POS 11, office, to POS 20, urgent care. Those codes describe settings; an encounter grouper also needs evidence about the service. If both claim versions survive, one visit may appear in two categories. Even if the signed payments happen to net correctly in total, spending by setting can be wrong when an obsolete category remains attached to an adjustment. CMS’s place-of-service definitions establish the distinction between the settings.

The same problem reaches further than utilization. A removed diagnosis can change a condition cohort or risk score. A corrected service date can move spending between member months. A revised rendering provider can change attribution. Those downstream results should be built from the intended adjudicated view, with the cutoff and inclusion rules carried into the analysis.

ADR is therefore part of defining the dataset. Preserve the billing history, resolve the current state using the source’s rules, and reconcile both. With that foundation in place, we can address the next question: how incurred dates, paid dates, and runout affect the completeness of a reporting period.