A provider insists they submitted the claim and you have no record of it. How do you build the submission path so that cannot happen?

Sent, accepted and adjudicating are three different facts

The dispute in the question happens because one word is doing three jobs. The provider's practice management system says "submitted", and that means a file left the building. It does not mean the clearing house parsed it, that the clearing house forwarded it, that the payer's front end accepted it, or that anything is now working the claim. Between those states there are at least three places a claim can vanish without either party noticing, and the reason it goes unnoticed is that a drop is usually silent by default rather than loud.

A claim's journey has a hop for each intermediary. The provider's system builds an X12 837 — professional, institutional or dental depending on the setting — and transmits a file, usually to a clearing house rather than directly to the payer. The clearing house validates it, splits the batch by payer, may reformat or scrub it, and forwards each portion onward. The payer's front end validates the envelope and the implementation-guide compliance of the file, then validates each claim individually against membership and provider data before it is admitted to adjudication. Only then does the claim exist as far as the payer is concerned.

So the design question is not how to make each hop reliable. It is how to make each hop tell you what it did, and how to notice when it does not.

The acknowledgement chain

The X12 transaction sets already give you the signals; the failure is almost always in whether anyone reconciles them. There are three levels, and they answer different questions.

• TA1, the interchange acknowledgement. Reports on the envelope itself, so it tells you the transmission arrived and was structurally readable. It says nothing about the claims inside.
• 999, the implementation acknowledgement. Reports whether the functional group conformed to the implementation guide. A rejected 999 typically means the whole file or a group inside it was refused for syntax or compliance reasons, and every claim in it is now nowhere.
• 277CA, the claim acknowledgement. This is the one that matters for the question, because it reports accept or reject per claim, and an accepted claim is returned with the payer's own claim control number. That number is the payer's admission that they hold the claim.

Separately and much later, the 835 remittance advice carries the payment and the explanation of each adjudicated line, and the 276/277 pair lets you ask about status for a claim you believe is in flight.

sequenceDiagram
  participant P as Provider system
  participant C as Clearing house
  participant Y as Payer
  P->>C: 837 claim file
  C-->>P: File accepted or rejected
  C->>Y: 837 forwarded
  Y-->>C: 999 file level result
  Y-->>C: 277CA per claim accept or reject
  Y-->>C: 835 remittance later

The interesting part is the gap between the two dashed responses from the payer: a file can be accepted at the 999 level while individual claims inside it are rejected at the 277CA level, so a green file-level acknowledgement is routinely mistaken for successful submission of every claim it contained.

Where claims die quietly

Three failure modes account for most of these disputes, and none of them raises an error anywhere.

The first is the acknowledgement that never arrives. Nothing is broken from the sender's point of view: the file went, the transport reported success, and the absence of a reply is not an event. Unless something is explicitly waiting for the 277CA and complaining when it is late, an unacknowledged batch looks exactly like an acknowledged one.

The second is the acknowledgement that arrives and is filed rather than matched. Plenty of implementations store inbound 999 and 277CA files dutifully and never join them back to the claims that were sent. Reconciliation is the whole control: for every claim in every outbound file, you should be able to state which acknowledgement level it has reached and how long it has been sitting there, and anything past a threshold belongs on a human's worklist.

The third is the front-end rejection that never reaches a biller. A claim rejected at the clearing house or at the payer's front end has not been adjudicated, so it produces no remittance and no denial code. It therefore does not appear in denial reporting, which is where most revenue-cycle teams look. Rejections and denials are genuinely different objects: a denial is an adjudicated decision you can appeal, and a rejection is a claim that was never accepted and must be corrected and resubmitted. A payer organisation that reports on denials and not on rejections has a blind spot precisely where this dispute lives.

Why the silence is expensive

Every payer contract carries a timely-filing limit measured from the date of service, and a claim that was never received does not stop that clock. This is what turns a data-plumbing problem into a write-off: the provider believes the claim has been with the payer for two months, discovers otherwise when the ageing report is worked, resubmits, and is denied for late filing. Appealing that denial requires proving the original submission was timely, which is exactly the evidence a system without reconciliation cannot produce.

That is also the answer to the dispute in the question. What settles it is not a screenshot of the practice system saying "submitted". It is the outbound file with its interchange control number and timestamp, the acknowledgements received against it, and — if one exists — the 277CA bearing the payer's claim control number. Where the acknowledgement chain stops is where the claim stopped, and it identifies which party's system to look in. Retaining those artefacts for at least the length of the longest filing and appeal window in your contracts is what makes the argument winnable rather than a matter of two systems asserting different things.

Build it so the reconciliation is visible before anyone telephones: a per-payer, per-day count of claims sent against claims acknowledged, with the unmatched balance ageing. That single view converts an invisible failure into a number that grows.

What this failure looks like in the wild

In February 2024, a ransomware intrusion at Change Healthcare took down clearing house services that a very large share of US claims and pharmacy transactions flowed through, and providers were unable to submit claims or receive payment for weeks. The failure was not of any one payer's system but of a shared intermediary that the whole market had quietly concentrated on. For a submission-path question this is the concentration-risk argument in concrete form: the interviewer wants you to name the dependencies outside your own estate that a claim must traverse, and say what the alternative route or the manual path is when one of them is simply not there.