Track acknowledgments (999 / 277CA)

Outcome

You can read the Submission tab, understand what each acknowledgment type means, identify when a claim is stuck waiting versus actually rejected, and decide whether to re-submit or fix-and-rebuild.

Prerequisites

Scope	What it lets you do
billing.claim.read	See the Submission tab
billing.claim.write	Re-submit

A claim that has reached BUILT or beyond.

The acks, end to end

Doc	Layer	Says	When
TA1	Envelope	"I read your envelope"	Seconds — only sent on errors usually.
999	Functional	"I parsed your file's transactions"	Minutes.
277CA	Claim	"I (or the payer) accepted / rejected each claim"	Hours.
835	Remittance	"Here is what we paid"	Days to weeks; covered in chapter 4.

A missing ack is a waiting state, not a rejected one. Don't act prematurely.

Reading the Submission tab

/claims/:id → Submission:

Column	Meaning
Document	837, TA1, 999, 277CA, 835.
Direction	OUTBOUND / INBOUND.
Sent / Received	UTC timestamp.
ICN / payer ref	Trading partner control number; payer claim control number.
Status	PARSED, ERRORED, ACCEPTED, REJECTED.
Inspect	Click → raw segments + structured view.

The Inspect button is your friend: it renders the X12 with loops indented and key elements decoded. Reach for the EDI manual if you need to read raw — most billers won't.

What 999 says

Element	Meaning
IK5*A	All transactions accepted.
IK5*E	Some accepted with errors.
IK5*R	All rejected at file level.
AK9*A/E/R	Same, at functional group level.
IK3 segment	Names the segment that failed.
IK4 segment	Names the element that failed.

A 999 rejection means the file didn't parse. Almost always: bad sender/receiver IDs, wrong delimiters, or a malformed envelope. Fix trading partner config and re-submit.

What 277CA says

The STC segment carries the result per claim:

STC01	Meaning
A1	Accepted by clearinghouse.
A2	Accepted by payer.
A6	Acknowledged for processing.
A7	Acknowledged but rejected.
A8	Acknowledged but unprocessable.
R*	Various reject categories.

A7 and R* are real rejections: the payer says no. The reason text that follows tells you what to fix.

Re-submit vs fix-and-rebuild

Use the Re-submit button when you're sure the cause is transient or file-level. Use Fix & rebuild (which reverses and rebuilds) for data-level rejections.

Re-submitting

1. Confirm the cause is transient. Read the 277CA's STC text; if you'd send the same bytes you'd expect a different result.

2. Click Re-submit. The platform writes a new edi_transaction row, sends, and waits for new acks. The old transaction stays for audit.

3. Watch the new ack chain.

Validation

Check	Expected
999 lands within the partner's stated SLA	Yes — minutes for most.
277CA lands within the partner's stated SLA	Yes — hours for clearinghouses, sometimes longer for direct.
Inspect renders structured view	Yes for any X12 doc.
Re-submit creates a new transaction row, not in-place	Yes.

Troubleshooting

Symptom	Cause	Fix
999 hasn't arrived in 24h	Transport stuck, partner outage	Check partner status; resend.
999 says R for the whole file	Envelope problem	EDI manual → 999 reference; usually ISA / GS mismatch.
277CA says A7 with "Member not found"	Member ID mismatch	Verify the 837's 2010BA / NM109 against the member record; refresh eligibility; rebuild.
277CA never arrives but 999 was clean	Some payers don't send 277CA	Check the partner config; if expected to be silent, watch for the 835 instead.
Submission shows ACCEPTED but 30 days later still no 835	Payer is slow or 835 dropped en route	Send a 276 status inquiry — see 6.4.

Where to next

• 3.3 — Rebill & correct when 277CA rejects.
• 3.4 — Void & replace when the original was wrong but you've already pushed.