Submitting and Tracking Claims

Overview

Once a claims-enabled invoice has generated its claims, you submit them electronically to payers and track their progress. Seniorverse submits each claim as an 837 EDI transaction through Stedi — an 837P for professional claims or an 837I for institutional claims, depending on the benefit type's claim format.

This article covers submitting claims (including the safe Dry Run preview), how batch submission behaves, reading a claim's Submissions tab, interpreting rejections and their remark codes, and the two ways to correct a claim after the fact: Resubmit and Void / Replace.

Before You Begin

• You need access to the Billing module.
• The invoice must be a claims invoice with generated claims. See "Enabling and Understanding Claims."
• Members must pass claim requirements (including eligibility, when the benefit type requires it) or the invoice will not finalize. See "Running Eligibility Checks."
• Jargon check: 837 = the outbound claim file. 277CA = the payer's acknowledgment that a claim was accepted or rejected. 835 (ERA) = the electronic remittance advice with the payment decision. CARC = Claim Adjustment Reason Code (why an amount was adjusted). RARC = Remittance Advice Remark Code (an explanatory note).

Steps

Step 1: Submit claims by sending the invoice

You do not submit claims from the Claims tab one at a time for the first pass — you send the invoice. On a finalized claims invoice, press Send Invoice. (On a draft, Send Invoice runs the whole pipeline — Prepare, Finalize, then Send.) For a claims invoice, Send queues the invoice's draft claims for submission and marks the invoice as sent; it does not email the payor.

Behind the scenes each queued claim moves to Queued, then Seniorverse submits them in batches of 5 so a large invoice submits reliably without timing out. As each claim is submitted successfully its status becomes Submitted; if a submission fails, that claim becomes Failed. The invoice Activity tab logs each batch.

Screenshot coming soon — Finalized claims invoice with the Send Invoice action in the actions menu

Step 2: Preview with Dry Run before you send

For a finalized claims invoice, the actions menu also offers Dry Run. Dry Run builds the exact 837 payloads Seniorverse would submit and writes them to the Activity log without sending anything to the payer. Use it to confirm each claim is complete and correct before a real submission. A Dry Run that reports errors on a claim tells you what to fix first.

Screenshot coming soon — Activity log showing Dry Run entries with the built 837 claim payloads

Step 3: Track a claim on the Submissions tab

Open a claim and select the Submissions tab. Each row is one submission attempt (a claim_stedi record) and shows:

• Control Number — the unique number that identifies this submission. Select it to open the submission detail, which shows the payer's claim control number, download links for the CMS-1500 and ERA PDFs (when available), and the raw request/response data.
• Status — the submission's own status: Submitted, Accepted, Rejected, Paid, or Denied.
• Submitted At — when the submission was sent.
• Actions — Void and Replace buttons appear here when the submission is eligible (see Step 6).

The claim's overall status (on the Details tab) reflects the latest submission and any remittance received.

Screenshot coming soon — Claim Submissions tab listing control number, status, submitted-at, and Void/Replace actions

Step 4: Read a rejection and its remark codes

When a payer rejects or adjusts a claim, the reason lands in the claim's Activity tab, and a failed claim also shows a Claim Failed banner on the Details tab with the reason.

• 277CA acknowledgment rejections log the payer's status category codes and status messages (for example why the file was not accepted).
• 835 (ERA) remark codes appear as an entry such as "ERA remark codes: N130 (Consult plan benefit documents…)". These are RARC notes; Seniorverse looks each code up and shows its plain-language message.
• Service-line adjustments carry the CARC reason for any amount the payer reduced or did not pay, shown as adjustment entries on the same Activity log.

Read these together to decide whether the claim needs a correction (resubmit) or a formal replacement.

Screenshot coming soon — Claim Activity tab showing a rejection with status messages and remark codes

Step 5: Resubmit a failed or rejected claim

If a claim is Failed, Error, Rejected, or Denied and has not been accepted by the payer, open the claim and use the primary Resubmit Claim button. Resubmit sends the claim again as a fresh submission and switches you to the Activity tab so you can watch the result. Use Resubmit after you have corrected whatever caused the rejection (for example a missing member ID or diagnosis on the member benefit).

Screenshot coming soon — Claim detail with the Resubmit Claim button on a failed claim

Step 6: Void or replace an accepted claim

Once a payer has accepted a claim, you no longer resubmit it — you send a formal correction. From the Submissions tab, use:

• Replace — submits a corrected claim that supersedes the original (EDI claim frequency 7). Use this to fix a claim the payer already has on file.
• Void — cancels the original claim with the payer (EDI claim frequency 8).

Both actions require the payer's claim control number, which arrives with the acknowledgment or remittance — so Void and Replace only become available after the payer has responded. Each action asks you to confirm. A Mode toggle lets you run in Dry mode (build the correction without submitting) or Apply mode (submit for real).

Screenshot coming soon — Submissions tab with the Void and Replace confirmation and the Dry/Apply mode toggle

Tips

• Resubmit vs. Replace: Resubmit is for claims that were never accepted (rejected/failed) — it is a clean retry. Replace and Void are for claims the payer already accepted — they are formal corrections tied to the payer's claim control number.
• Run a Dry Run on any invoice you are unsure about. It never contacts the payer, so it is always safe.
• The Submissions tab keeps every attempt, so you have a full audit trail of what was sent and when.
• If a claim's data blob is still loading, its Void/Replace buttons show View details instead — open the submission to let it finish loading, then the actions appear.

Troubleshooting

Related Articles

• enabling-and-understanding-claims — Enabling and Understanding Claims
• running-eligibility-checks — Running Eligibility Checks
• receiving-remittance-and-the-files-tab — Receiving Remittance and the Files Tab
• the-invoice-lifecycle — The Invoice Lifecycle
• using-the-billing-dashboard — Using the Billing Dashboard