A guide to the new claim transaction posting workflow.

Payment posting is now line-level. Instead of recording one lump sum against a claim, you allocate money to the individual service lines it was paid against, and the claim's balances, status, and reporting all follow from those allocations. Three things come with that:

You can attach the EOB, ERA, or check image to the posting as you make it.

Everything you post depends on what the claim already says, so it's worth knowing what the header is telling you.

Figure 1 — Claim overview. Patient and claim identifiers redacted.

This is the distinction most worth internalizing. Charge Balance measures against what you billed. Allowed Balance measures against what the payer agreed to allow. When a payer allows less than you billed, the difference is a contractual adjustment — not money you can chase.

In the example claim: $2,216.90 billed, $886.76 allowed, $885.00 paid. Charge Balance = $1,331.90 — mostly contractual, not collectible. Allowed Balance = $1.76 — the real outstanding amount. Work the Allowed Balance. A large Charge Balance next to a near-zero Allowed Balance means the claim is essentially resolved.

Figure 2 — Financial Summary tiles.

Figure 3 — Service Lines and Charge Breakdown.

Open the claim, go to the Transactions tab, and click Post Transaction. From a claim card in a list view, + Add Transaction does the same thing.

Figure 4 — Transactions tab. Patient and claim identifiers redacted.

Figure 5 — Posting from a claim card. Patient and provider identifiers redacted.

Figure 6 — The posting form before a type is selected.

Figure 7 — Transaction types.

Note: Write Off is available but not part of our current process. Use Adjustment instead unless you've been told otherwise.

Type (required) — Payment, Adjustment, Denial, or Write Off. Selecting a type sets sensible defaults for everything below it and clears any allocations you've already entered, so choose it first.

Amount — Not an input. It's the sum of the line allocations below, updating as you type. If it reads $0.00, you haven't allocated anything yet.

Date (required) — The date of the payment or adjudication as shown on the remittance, not today's date. Defaults to today, so change it.

Claim Number (required) — The payer's claim number from the remittance (not our internal CLM- number). It's set from the first posting on a claim and locked after that; on later postings you'll see it greyed out.

Claim Status — The X12 277 code describing the payer's response. Defaults from the type you picked: Payment → F1 (Paid), Denial → F2 (Denied), Adjustment → F3 (Revised), Write Off → F4 (No Payment). You can override it — the full code set is available, grouped by series (Acknowledgement, Pending, Finalized, Request for information, Error, Data search).

Notes — Optional. Worth using for anything the codes don't capture: check number, ERA batch, why an adjustment was made.

The status you select records what the payer said. The claim's own workflow status is recalculated from the money you post, and that calculation wins: net cash collected > $0 → Paid, or Partially Paid if any line was denied; no net cash and every service line denied → Denied. So you don't need to hand-manage the claim's status to keep it accurate. Post the money correctly and the status follows.

This is where the actual work happens.

Always enter amounts as positive numbers, on every transaction type. The transaction type determines the direction — you never type a minus sign. Payment increases paid. Adjustment / Write Off reduce the collectible balance. Denial doesn't move cash; it adjusts balances. A negative amount will be rejected.

Known issue: the on-screen helper text under Line-Level Posting for Adjustment and Write Off currently says "Enter negative amounts per line." That text is wrong and is being corrected. Enter positive amounts. (See callout 4 in Figure 10.)

The Allowed field is editable because remittances frequently correct it. Enter the allowed amount from the EOB and the claim's allowed amount updates when you post, which recalculates the Allowed Balance. When your entry differs from what's stored, the field flags the change before you post. If the payer didn't state an allowed amount, leave it alone.

Figure 8 — Payment posting, with the $0-line validation message.

To post a payment:

A paid line can't be $0. If a line is marked F1 — Paid with a $0 amount, you'll get the validation shown in Figure 8. That's the system asking you to be explicit: was it paid, or was it denied? Any line with an amount needs a Qty greater than zero.

A fully $0 payment — every line at $0 — triggers a confirmation prompt unless every service line is marked F2 — Denied. A $0 payment where everything is denied is a legitimate way to record a full denial arriving on a payment remittance. A $0 payment with lines still marked Paid is almost always a mistake.

Figure 9 — Denial posting.

To post a denial:

Reason codes are standard CARC values from a searchable list — 1 (Deductible), 2 (Coinsurance), 3 (Copay), 16 (Lacks information), 18 (Duplicate), 29 (Filing limit expired), 45 (Exceeds fee schedule), 50 (Not medically necessary), 96 (Non-covered), 197 (No precertification), and more. Use + to add multiple reason codes to one line.

Partial denials: a remittance that pays some lines and denies others can be recorded as one Payment with the denied lines set to F2 — Denied, or as a Payment plus a separate Denial. Either way the claim lands on Partially Paid.

Figure 10 — Adjustment posting.

Use an Adjustment when the collectible balance needs to change without cash moving — a contractual write-down beyond what the fee schedule captured, a correction to a prior posting, or a payer-directed reduction.

To post an adjustment:

Adjustments reduce Total paid (it's a net figure) and reduce the collectible balance. If adjustments exceed payments, Total paid can go negative — that's intentional, and surfaces recoupments.

Split divides one service line into multiple allocations — for when a single line was partly paid and partly denied. Click Split on the line. A second row appears for the same line, pre-filled with the remaining units. On a Payment, the split row defaults to F2 — Denied, since a split usually means "these units paid, those denied."

Example: 28 units billed, 20 paid and 8 denied. Row 1: Qty 20, Amount = paid amount, Status F1 — Paid. Row 2: Qty 8, Amount = denied amount, Status F2 — Denied, with group and reason.

Two rules on splits: every split row needs a Qty — splits without quantities are rejected; and quantities can't exceed billed units — splitting 28 units into 20 + 12 fails. Use Remove to drop a split row.

Figure 11 — Attachment panel on the posting form.

Attachments are optional but strongly recommended — the posting is far easier to defend later with the source document attached. Choose the file, set the type, and post as normal; the file uploads and links to the transaction.

Accepted: PDF, PNG, JPEG — up to 25 MB. Anything else is rejected immediately ("Only PDF, PNG, and JPEG files are allowed"). File contents are verified against the file type, so a renamed file won't pass. One file per posting through this form. For additional documents, attach them from the transaction list after posting.

If the upload fails but the posting succeeds, you'll be told so explicitly — "Transaction posted, but the file upload failed. Upload it from the transaction list." The transaction is saved; only the file needs retrying. Don't re-post. You can delete an attached file later if you attached the wrong one.

Remittance: UnitedHealthcare, check dated Aug 4. Line 1 (A6021, 28 units, $2,097.90 billed) allowed $839.16, paid $840.00. Line 2 (A6219, 35 units, $119.00 billed) allowed $47.60, paid $45.00, $2.60 denied as CO-45.

Result: Total paid $885.00 net. Allowed Balance drops to $1.76. Workflow status becomes Partially Paid — cash was collected and a line was denied. Claim status becomes F1.

A posted transaction can't be deleted or voided. This is deliberate — the transaction history is a financial audit trail. To correct a mistake, post an offsetting transaction: overstated a payment → post an Adjustment for the difference; posted to the wrong line → offset it, then post correctly; wrong attachment → delete the file and attach the right one, and the transaction stays. Add a Note to any correcting transaction explaining what it corrects.

Transaction types

Claim status codes you'll see most

Group codes: CO (contractual), PR (patient), OA (other), PI (payer-initiated), CR (correction/reversal)

Rules that will stop a posting

Claims you can't post against: Draft, Voided, Denied, or Closed. A claim must be filed and not terminally resolved.

Questions? Contact the billing systems team.