Testing EDI Responses with the Payer Simulator
When you send claims from a test account, they go to the ClaimRev Payer Simulator (the test payer) instead of a real payer. The Payer Simulator answers on demand: you ask it for the payer's 999, 277CA or 835 for claims you sent, and ClaimRev processes that response exactly as it processes a real payer's. You receive the result the way you will in production, as a 277 and an 835 in your usual delivery (SFTP pickup or the portal Downloads screen).
Nothing happens on a timer. A response is produced only when you ask for one, so a test cycle takes seconds, not days.
Before you start
ClaimRev sets this up during onboarding:
- Your test account is flagged as a test account and routed to the test payer. Claims from a production account never reach the test payer, and the test payer never answers for one.
- Your API application (or portal user) has the
payer-simulator:sendrole. - If you want 277s back, your account is set to return 277s, as in production.
Professional (837P), institutional (837I) and dental (837D) claims are all supported, and can be mixed on one test account.
Responses only ever post to the account that sent the claim. You do not need to register your test NPIs with ClaimRev, and two test accounts using the same test NPI never see each other's payments.
The flow
Everything below can be done in the portal (Test Payer in the menu, with your test account selected) or through the API.
Send each test set in one file. The Payer Simulator works one submission at a time: a submission is one file your EMR sent, and the screen lists them newest first. If you send the claims for one test run in a single file, every step acts on exactly that run, and an earlier run on the same day stays out of the way.
- Submit claims from your test account as you would in production (see Submitting a Claim). Use a subscriber ID from the scenario table to choose what the payer does.
- Follow the steps. The newest submission is picked for you. The step bar shows how many of its claims are at each step and highlights the next one; each button acts only on the claims at that step:
- Send to test payer. Sends the submission's ready claims right away instead of waiting for the next scheduled batch. When it finishes, the claims show Sent To Payer.
- Send payer 277CA. The payer's acceptance, rejection or pend for each claim. Your 277 is delivered with the payer's decision.
- Send 835. The payer's remittance, as each claim's scenario says. Your 835 is delivered.
- Send follow-up 835. For reversal, correction and split scenarios, the second 835.
- Check the Next step column. Each claim says what happens next, or why nothing does (rejected or pended by the payer, errored at ClaimRev, no payer response, or done). Pick Work on this on another submission to work on that one instead.
ClaimRev's own 277 has its own panel. ClaimRev normally sends its acknowledgement (accepted, or failed ClaimRev's edits) a few hours after it receives your file; Send ClaimRev 277 now builds it immediately, including claims that failed our edits. It is not the payer's 277CA.
Advanced lets you tick claims and send a response for just those: the payer 999 (usually everything is accepted; a claim whose scenario rejects in the 999 is errored, and the other claims in its transaction set go back to Ready To Send for the next file, exactly as with a real payer), the payer 277CA, or an 835 with a forced outcome.
Reading the claim status icons
On the Claims search screen, the two payer icons on each claim move as responses arrive:
| Payer acceptance icon | Meaning |
|---|---|
| Hourglass | Sent to the payer, or the 999 accepted the file; waiting for the payer's 277CA |
| Thumbs up | The payer accepted the claim (277CA WQ) |
| Sick face | The payer rejected the claim (277CA U, or a 999 rejection) |
| Clock | The payer pended the claim (P status) |
The file status icon becomes a plane once a 999 or 277CA shows the payer received the file.
Choosing the outcome by subscriber ID
The claim's subscriber ID (loop 2010BA, NM109) picks what the test payer does. It is matched exactly, ignoring case, hyphens, spaces and slashes, so test-deny 50 matches TESTDENY50.
| Subscriber ID | Payer 999 | Payer 277CA | First 835 | Next 835 |
|---|---|---|---|---|
TESTACCEPT | Accepted | Accepted, A2:20:PR | Paid | None |
TESTREJECTA7 | Accepted | Rejected, A7:562:85 (billing provider NPI) | None | None |
TESTPEND | Accepted | Pended, P1:20 | None | None |
TESTNORESPONSE | Accepted | None | None | None |
TESTDENY50 | Accepted | Accepted | Denied, CO-50 | None |
TESTREVERSAL | Accepted | Accepted | Paid | Reversal of that payment |
TESTCORRECTION | Accepted | Accepted | Paid | Reversal plus a corrected payment |
TESTSPLIT | Accepted | Accepted | First half of the service lines paid | The remaining lines paid |
TEST999REJECT | Rejected; the rest of its set is resent | None | None | None |
| Anything else | Accepted | Accepted | Paid | None |
"Next 835" is what you get when you send an 835 again after the claim has a test payment. When a scenario has no response for a step, nothing is sent and you are told why.
Your ClaimRev contact can add scenarios for your account (for example, a rejection with a different status code, or a claim that pends and then pays), and account administrators can manage their own on the portal's Test Payer, Scenarios tab. Use Check a subscriber ID there to see which scenario an ID resolves to before you send a claim.
What the responses contain
Payer 999. One per outbound file: AK1 names the file's group control number and each AK2 one transaction set. A rejected set carries IK3*CLM and CTX*CLM01:<your patient control number> naming the claim, then IK5*R; other sets are IK5*A. AK9 is A, P (partially accepted) or R.
Payer 277CA. Written as the payer: A1:19:PR (received) at the receiver and provider levels, and on each claim only the payer's decision: A2:20:PR with action code WQ when accepted, the scenario's rejection with action code U, or P1:20 when pended. Your 277 shows ClaimRev's own statuses followed by the payer's.
835 amounts. All amounts are calculated from your claim's own service lines:
| Outcome | CLP02 | What is paid |
|---|---|---|
| Paid | 1 | Each line allowed at 80% of charge (CO-45 for the difference). 20% of allowed is patient coinsurance (PR-2); the rest is paid. |
| Denied | 4 | Nothing. CO-50 for the full charge on every line. |
| Reversal | 22 | The previous payment, negated line for line, under the same payer claim control number (CLP07). |
| Reversal and correction | 22, then 1 | The reversal above, plus a new payment allowed at 90% of charge, under a new payer claim control number, in one 835. |
| Split | 1 | The first request pays the first half of the lines (rounded up); the next pays the rest. Each line carries its line number in REF*6R. |
CLP01 is your patient control number (CLM01). The 835's payer is SIMULATED TEST PAYER. Claims rejected on the 277CA never appear on an 835.
Service lines by claim type. Each SVC echoes the line as you billed it:
| Claim type | SVC01 | SVC04 | CLP08 / CLP09 |
|---|---|---|---|
| Professional | HC:<procedure code> | Empty | Not sent |
| Dental | AD:<CDT code> | Empty | Not sent |
| Institutional, line with a HCPCS code | HC:<HCPCS> | The revenue code | Facility type and claim frequency from your CLM05 type of bill |
| Institutional, line with only a revenue code | NU:<revenue code> | Empty | As above |
When an 835 nets below zero (a reversal, or a reversal larger than its correction), you choose how it is written, as payers differ:
| Negative balance | How it is written |
|---|---|
| Debit (default) | BPR01 I, BPR03 D, and BPR02 is the amount taken back. |
| Forward balance | A $0.00 notification (BPR*H*0.00*C*NON) with a provider-level adjustment PLB*<NPI>*<fiscal period end>*FB:<check>*<negative net> carrying the balance to later remittances. |
Either way the 835 balances: BPR02 equals the sum of CLP04 less the sum of the PLB amounts.
API
All endpoints take a bearer token (see Authentication) and act on your selected account.
| Action | Endpoint |
|---|---|
| List your submissions with how many claims are at each step | GET /api/PayerSimulator/v1/GetTestPayerBatches |
| List your claims with their status, dates, eligibility, scenario and next step | GET /api/PayerSimulator/v1/GetTestPayerClaims |
| Build ClaimRev's 277 now | POST /api/PayerSimulator/v1/SendClientAcknowledgments |
| Send your ready claims to the test payer now | POST /api/PayerSimulator/v1/SendToTestPayer |
| Get the payer 999 | POST /api/PayerSimulator/v1/SendPayer999 |
| Get the payer 277CA | POST /api/PayerSimulator/v1/SendPayer277Ca |
| Get the 835 | POST /api/PayerSimulator/v1/SendPayer835 |
| Check which scenario a subscriber ID resolves to | GET /api/PayerSimulator/v1/ResolveScenario?subscriberId={id} |
| List scenarios | GET /api/PayerSimulator/v1/ListScenarios |
List claims
GetTestPayerClaims takes optional query parameters: pageIndex, pageSize, patientLastName, patientControlNumber, statusIds (repeat it for several: 7 ready to send, 8 merged, 9 sent to payer, 10 error) and uploadBatchId (one submission). Results are newest first and include receivedDate, sentToPayerDate, lastPayerStatusDate, eraCheckDate, uploadBatchId, nextStep and nextStepLabel.
GetTestPayerBatches takes pageIndex and pageSize and returns your submissions newest first. Each has its uploadBatchId, fileName, receivedDate, claimCount, steps (each step's count and claimIds) and nextStep: the first of SendToPayer, Payer277, Payer835 and FollowUp835 with claims at it, or null when nothing is left to do. Pass a step's claimIds to the matching action.
Account actions
SendClientAcknowledgments takes no body. SendToTestPayer takes { "claimIds": [...] } to send just those claims (a submission's SendToPayer step), or an empty list for all of the account's ready test claims. Both act on your selected account. They return counts and a message, for example:
{
"eligibility": 0,
"claimsMerged": 2,
"claimsSent": 2,
"filesSent": 1,
"filesNotSent": 0,
"message": "Sent 2 claim(s) to the test payer in 1 file(s).",
"sentAt": "2026-10-20T22:00:00Z"
}
Payer responses
SendPayer999, SendPayer277Ca and SendPayer835 take ClaimRev claim ids (the claimId from GetTestPayerClaims, or the id ClaimRev returned when you submitted the claim):
{
"claimIds": ["6713f0c2a4b1e2d3c4f5a6b7", "6713f0c2a4b1e2d3c4f5a6b8"]
}
A 999 answers whole files, so it covers every claim in the files your claims went out in. A file gets no 999 if it holds a claim the test payer cannot answer for.
SendPayer835 also takes outcome and negativeBalance:
{
"claimIds": ["6713f0c2a4b1e2d3c4f5a6b7"],
"outcome": null,
"negativeBalance": 0
}
Leave outcome out (or null) to let each claim's scenario decide, or set it to force one outcome for every claim in the request:
outcome | Meaning |
|---|---|
0 | Paid |
1 | Denied |
2 | Reversal (needs an earlier test payment on the claim) |
3 | Reversal and correction (needs an earlier test payment) |
4 | Split |
negativeBalance is 0 for a debit (the default) or 1 for a forward balance; it only matters when the 835 nets below zero.
Response
The payer response endpoints return what happened to each claim:
{
"claims": [
{
"claimId": "6713f0c2a4b1e2d3c4f5a6b7",
"eligibility": 0,
"sent": true,
"message": null,
"scenario": "Scenario TESTREVERSAL"
},
{
"claimId": "6713f0c2a4b1e2d3c4f5a6b8",
"eligibility": 0,
"sent": false,
"message": "Scenario TESTREJECTA7: the payer sends no 835.",
"scenario": "Scenario TESTREJECTA7"
}
],
"payerFileIds": ["6713f1d0a4b1e2d3c4f5a6c1"]
}
A claim that cannot get a response is skipped and the others still go. eligibility says why a claim was skipped:
eligibility | Meaning |
|---|---|
0 | Eligible. If sent is false, message explains why (for example, the scenario has no 835, or a reversal has no earlier payment to reverse). |
1 | No access: the claim is not in an account your credentials can use, or the id does not exist. |
2 | The claim's account is not a test account. |
3 | The claim's payer is not the test payer. |
4 | The claim has not been sent to the payer yet. Use Send to test payer first; a payer cannot answer a file it has not received. |
When the request returns, the response has already been processed: your claim shows the payer's decision, and your 277 or 835 is in your delivery. Retrieve the 835 data as JSON with the ERA endpoints.
Things to know
- Every request sends a new response. Asking for a 277CA twice sends two, as a real payer sometimes does. Build your integration to handle that.
- One 835 per request. Claims sent together for the same account and billing provider come back on one 835 with one check. Some EHRs list that remittance once per claim; it is still one file.
- Follow-ups build on the claim's last test payment. A reversal reverses the most recent test payment on the claim, and a split pays the remaining lines only after the first half has been paid.
- "Waiting" on the Downloads screen means your 277 or 835 was built and is waiting for you to collect it, not that it is still being processed.
- Test only. The test payer only answers for claims from test accounts. When you move to production, your claims go to real payers and the responses come on the payers' schedules. Reach out to ClaimRev support to be moved over.