ERA inbox

Outcome

You can navigate the receivables list, understand each status, manually upload an out-of-band 835, and pick the next ERA to work.

Prerequisites

Scope	What it lets you do
billing.receivable.read	View list / detail
billing.receivable.write	Confirm and post
billing.receivable.override	Force-match low-confidence pairings

A trading partner with inbound 835 capability, or your tenant allows manual uploads.

The receivables list

/receivables shows every received 835 with status:

Status	Meaning	Move
RECEIVED	File parsed, not yet reviewed	Open and walk the tabs.
AUTO_MATCHED	All lines high-confidence matched	Confirm and post.
REVIEW_REQUIRED	Some lines need manual review	Walk Review + Unmatched.
EXCEPTIONS	Variances remain after match	Resolve before close.
POSTED	Lines applied; awaiting close	Close.
CLOSED	Fully reconciled	Read-only.

Default filters

Filter	Default
Status	RECEIVED + REVIEW_REQUIRED + EXCEPTIONS
Trading partner	All
Posted	Last 30 days
Sort	Date descending

Toggle Show closed on the toolbar to widen the list when reconciling historical activity.

What's in a receivable

Each row is one 835 transaction. Columns:

Column	Meaning
Trading partner	Whoever delivered the file.
Payer	The payer that adjudicated (BPR-NM1*PE if present).
Bulk amount	The 835's BPR02 — total payment in this transaction.
Lines	Total claim-level lines.
Status	Per the table above.
Received	When the file landed.

Click into a row → /receivables/:id opens with six tabs. The next six chapters walk each in detail.

Manual upload (out-of-band 835)

When a partner you haven't fully integrated with sends a file out-of- band, or a payer mailed a paper EOB and the bulk-pay file:

1. Click Upload ERA on the list page.

2. Drop the 835 file. The platform parses, validates against 835's minimum segment set (BPR, TRN, N1*PR/PE, CLP loops), and either:

   • Creates a new receivable at RECEIVED.
   • Returns 409 with the existing receivable's link if BPR02 + TRN02 matches an existing one (dedupe).

3. Walk the standard tab flow.

Notes on dedupe: the platform considers BPR02 + TRN02 (transaction amount + control number) the unique key. If a payer re-sends the same file, you get the dedupe error. If they correct and re-send under a new TRN, you get a new receivable; you'll need to reconcile manually.

The "alerts" feel

The header alert bell pings when a RECEIVED row arrives. Hover the bell for the trading partner + amount; click for the receivable's detail.

Validation

Check	Expected
New 835 creates a RECEIVED row	Yes.
Dedupe blocks repeat upload of the same file	Yes; 409 with link.
List filters honor URL params	Yes; you can deep-link a saved view.
Bulk-pay total = sum of lines	Should agree to the cent; chapter 4.2 walks how to spot-check.

Troubleshooting

Symptom	Cause	Fix
835 not appearing	Trading partner inbound capability disabled, or routing dropped it	Tenant Manual → Trading partners → Test connection; check the partner's inbound_835_enabled flag.
Upload rejected with parse_error	File is HIPAA-non-compliant or wrong version	Open in a text editor; confirm it's 005010X221A1. Some payers send 004010 legacy.
New receivable shows zero lines	The 835 is acknowledgment-only (no CLP loops)	Some partners send a 0-line 835 to confirm batch receipt; close as informational.
Same receivable reposts twice	The dedupe missed (rare bug)	Reverse the second post; ping support with the BPR02 + TRN02.

Where to next

• 4.2 — Auto-matched tab for the green-path flow.
• 4.4 — Unmatched & manual match when lines have no candidate.