Reading a Part A Claim: What FISS Status/Location Codes Actually Tell You

Every conversation about a stuck Medicare institutional claim starts in the same place: somebody reads the status/location code out loud. It is the most information-dense field on the claim, and it is routinely the most misread. People treat it as an error message. It is not an error message. It is the current state of a state machine, and reading it that way tells you whether to act, who to act with, and whether waiting is the correct move.

The field is four fields

The Fiscal Intermediary Shared System adjudicates institutional Medicare claims — hospitals, skilled nursing facilities, home health, hospice — covering both Part A inpatient and the institutional Part B outpatient side. Status/location, universally shortened to S/LOC, is a six-character field on those claims.

It is not one code with a prefix. It is four concatenated values, and the most common mistake is reading it as a status letter followed by five characters of location:

• Position 1 — status. What has happened to the claim.
• Position 2 — processing type. M manual, O offline, B batch.
• Positions 3–4 — driver. Which processing area holds the claim: 01 status/location, 02 control, 65 PPS/Pricer, 70 payment, 90 CWF, and so on across 01–99 plus user-defined AA–ZZ.
• Positions 5–6 — location. Where inside that driver it sits. Again 00–99 plus AA–ZZ.

So the familiar P B9997 decomposes as paid, batch, driver 99, location 97. Collapsing the middle two characters into “location” throws away the driver — which is precisely the half that tells you which function is holding the claim, and therefore who you need to talk to.

Status: what happened

The first position is a small closed set. These are the documented definitions, not paraphrases:

• S — Claim is in process.
• T — Claim has been returned to provider (RTP) for corrections.
• R — Claim has been rejected.
• D — Claim is denied.
• P — Claim is paid.
• I — Claim has been inactivated. This claim can no longer be updated.

Two of those deserve care. P is paid, not merely “processed” — though a claim can reach a P location and still be waiting on the payment floor, which is a distinction I will come back to. And S is “in process,” which in practice covers everything from a routine batch step to a claim parked in medical review for weeks. S alone tells you almost nothing. S plus a driver tells you everything.

Unprocessable is not the same as denied

The expensive mistake in this field is treating RTP, rejection, and denial as three words for the same event. They are not, and the line between them is not where most people draw it.

The line is unprocessable versus adjudicated, and it is drawn in regulation. 42 CFR 405.926 enumerates actions that are not initial determinations, and paragraph (s) covers “claim submissions on forms or formats that are incomplete, invalid, or do not meet the requirements for a Medicare claim and returned or rejected to the provider or supplier.”

Returned and rejected sit together on that list. Neither is an initial determination, so neither carries appeal rights — not because the appeal was refused, but because nothing was decided. There is no determination to appeal. The claim did not meet the requirements to be adjudicated, and the remedy is to correct it and submit again.

A denial is the other thing entirely. The claim was adjudicated on its merits and payment was refused. That is an initial determination, it is appealable, and it starts a clock. Quietly correcting and resubmitting a denial the way you would an RTP is how organizations discover, later, that they had appeal rights and let them lapse.

If your accounts-receivable workflow routes on “did it pay,” it will make this mistake at volume. It has to route on the status character.

Driver and location: where it is, and who has it

The four characters after the status are the operationally useful part, because they identify the function holding the claim. A representative set of the codes worth recognizing:

• S B0100 — system processing; the billing transaction is suspended.
• S B6001 — needs additional information from the provider. An Additional Development Request is generated from here.
• S M50MR — medical review of documentation, where a transaction lands once ADR material has come back.
• S B90xx — data is being verified against beneficiary eligibility posted at the Common Working File.
• S Mxxxx — suspended pending Medicare staff intervention.
• S MRADJ — an MSP adjustment has been received and is awaiting completion.
• T B9900 — will need provider correction once it moves to T B9997 next cycle.
• T B9997 — transactions needing provider correction appear here.
• R B75xx — rejected, suspended. R B9997 — rejected, finalized.
• D B9997 — denied claim, all services denied.
• P B9996 — posted and awaiting the payment floor.
• P B9997 — processed and paid, full or partial.
• I B9900 — inactivated from the RTP file, waiting to purge.

Read that list as a map rather than a glossary. S B6001 means the ball is in your court and a request is coming. S M50MR means a human is reading your documentation and there is nothing to send. Both show status S. Only the driver separates “send records now” from “stop calling.”

One caution: the status set is stable, the location inventory is not. Drivers and locations get added, retired and repurposed as processing logic changes, and some are user-defined. Treat any specific code as a pointer into current MAC documentation rather than something to memorize.

Why a claim moves, and why it does not

A claim runs a fairly consistent gauntlet: acceptance, consistency and coverage editing, any development or medical review, validation against the beneficiary record at CWF (driver 90), pricing (driver 65), payment (driver 70), and finalization. The S/LOC advances as each stage clears, which means watching the field over several cycles tells you far more than reading it once.

Which yields the most useful diagnostic in the system: a claim that has not moved. A transaction changing location each cycle is working, however slowly. One showing the same S/LOC for several cycles is stuck, and stuck for a reason that will not resolve on its own.

And a completely clean claim still waits. Medicare applies a statutory payment floor — a clean electronic claim cannot be paid before the fourteenth day after receipt, and a paper claim not before the twenty-ninth. FISS has a location for exactly that state: P B9996, posted and awaiting the payment floor. A claim sitting there is finished, correct, and waiting on the calendar. There is nothing to escalate. (At the far end, interest begins accruing on a clean claim still unpaid on day 31.)

Reading it like a state machine

Put together, six characters answer two questions at a glance:

• Status tells you whether to act. S means wait or supply something. T means fix your data. R means it never adjudicated. D means decide whether to appeal, on a clock.
• Type, driver and location tell you who to act with. Development, medical review, CWF, pricing, payment, or nobody at all because it is sitting out the payment floor.

None of this requires memorising tables. It requires treating the claim as an object with a lifecycle and the S/LOC as its position in that lifecycle. That framing is the difference between working claims and reading reports about claims — and it is the part that survives, because when the underlying system eventually changes, the lifecycle it encodes will not.