A batch total is only the starting point

The first question is what sent means in the report. It may describe a generated claim, a successfully transmitted file, a clearinghouse acknowledgment, or a payer acceptance. Those events are useful, but they are not interchangeable. A file can transfer successfully while an individual claim fails later validation. A payer can receive a claim without having made a payment decision.

I would define the expected milestones with billing, interfaces, and the clearinghouse. Then I would select an outbound population by a fixed submission window and follow its claims through the available responses. Replacements and corrected submissions need their own history so that one clinical encounter is not mistaken for several independently unresolved accounts. The same reconciliation should explain the difference between a technical failure and an account that legitimately remains pending.

The evidence needs enough identifiers to match responses

My request would include outbound run and file information, claim or invoice identifiers, patient control numbers used in the exchange, payer and service area, submission timestamps, and the returned acknowledgment or status information. I would request unmatched response records and interface processing errors as well as successfully matched claims. Missing matches often reveal a control weakness that a clean operational report has excluded.

I would also obtain the current specifications agreed with the clearinghouse. ANSI 999 acknowledgments and claim-level status responses, including relevant 277 transactions, serve different purposes. I would not assume that a payer or clearinghouse supports every message type, timing option, or automated action. The design has to reflect the files the organization actually receives and how its interfaces interpret them.

Epic needs the response and the correct action

I would review the Claims Reconciliation setup with the application and interface teams. The review would cover incoming file processing, matching logic, external status mappings, and the actions that follow particular responses. An imported status is only useful when it can be connected to the right claim and translated into an appropriate next step.

For external edit management, I would establish whether corrections happen in Epic, in the clearinghouse, or in both. That division affects the completeness of claim history and the possibility of repeated errors. If Rapid Retest is in scope, I would confirm clearinghouse support and the enabled interface workflow before describing it as available. For a payer rejection, I would verify how the rejection becomes visible to an accountable team rather than waiting until it ages into a generic no-response population.

The exception list should describe the missing milestone

I would organize exceptions around evidence. A claim without any return acknowledgment needs a different investigation from a matched payer rejection, a response that cannot be matched, or a pending claim with a normal next-review date. Each exception should show the last confirmed milestone, the missing information, the owner, and the planned action.

I would avoid creating another static spreadsheet that only one analyst understands. The operational view needs a reconciliation owner, an escalation route to the clearinghouse or interface team, and a method for recording what resolved the discrepancy. Claims should not disappear from the control merely because staff resend them. The original submission and the new attempt should remain linked so the team can explain which response belongs to which version.

Testing should include the failures that are easy to miss

I would test a fully accepted file, a file with one rejected claim, an unmatched claim-level response, a duplicate status message, a corrected claim, and a late response to an older submission. I would also confirm what happens when a file load partially succeeds. Interface completion and operational completion should be checked independently.

For each case, I would verify the resulting claim history, workqueue visibility, and staff action. A corrected account should retain the useful error explanation until the appropriate milestone confirms success. The acceptance team should include someone who will own daily reconciliation, because a technically processed file may still leave an exception that no user knows how to work.

Measurement should follow the submitted cohort

I would report the proportion of the outbound claim population with each expected acknowledgment or status by an agreed interval. That denominator should be claim-level and should identify excluded submission types. The exception age begins at the relevant outbound event, not at the date the team finally notices the gap.

I would also track unmatched response volume, rejection-to-correction time, repeated submission attempts, and claims that remain unresolved after their next review date. Downstream payment timing can show a useful financial effect, but a faster acknowledgment is not automatically incremental revenue. The operating review should reconcile its ending unresolved population to the prior period plus new submissions and documented resolutions. A reliable trail lets the team distinguish a genuinely pending claim from one that never progressed as expected.