How to Automate EOB Posting Without Losing Control

To automate EOB posting, start with one or two high-volume payers whose paper layout rarely changes, set a confidence threshold that sends doubtful fields to a reviewer, staff that review queue before go-live, and test on de-identified sample EOBs first. Widen to more payers only when each stage meets its exit condition.

Picking the first payers for automated EOB posting

The first payers for automated EOB posting should be the ones that send the most paper, keep the same layout from month to month, and do not already offer an electronic remittance advice (ERA). A payer that meets all three gives the most practice for the least setup, and its results are easy to judge because every EOB looks alike.

Start by listing every payer that sent a paper EOB in the last three months. For each one, note three facts.

• Volume. Count the EOB pages, not the checks. One check can cover forty pages of claims, and pages are what a reader has to process.
• Layout stability. Compare an EOB from this month with one from three months ago. If the columns, the order of fields and the location of the totals are the same, the layout is stable. A payer that redesigns its EOB every year will keep producing new kinds of misreads.
• ERA status. Check whether the payer offers ERA enrollment. If it does, enrolling is usually a better first step than automating its paper, because an ERA arrives as data that needs no reading at all.

Sort the list by volume, drop payers that offer ERA or change layout often, and take the top one or two. Those are the pilot payers. Everyone else stays on manual posting until the pilot payers are running smoothly.

Avoid starting with the hardest payer, even when its EOBs cause the most pain. A difficult first payer makes it impossible to tell whether problems come from the payer, the thresholds or the staffing. Learn on an easy one and bring the hard one in later.

Setting confidence thresholds for automated EOB posting

A confidence threshold for automated EOB posting is the score an extracted field must reach before it skips human review. Extraction software gives each field it reads, such as a paid amount or a claim number, a score for how sure it is. Fields at or above the threshold go straight through; fields below it wait for a person.

The right threshold is a trade. A high threshold sends more fields to review, which costs reviewer time but lets fewer misreads through. A low threshold sends fewer fields to review, which saves time but trusts the reader more. Start high and lower it only when the review log shows that fields just under the threshold are almost always approved without change.

Thresholds do not have to be the same for every field. A practice might hold dollar amounts, claim numbers and member IDs to a higher bar than a payer's phone number or a printed date. A misread payment amount changes a patient balance; a misread phone number changes nothing that posts.

An example of where a threshold lands

The values below are invented for the example. A fictional EOB for patient "Dana Reyes", member ID "XJ4410298", produced these field scores:

At 90, one field from this EOB goes to a person. At 97, three do. Neither is wrong; the choice depends on how many reviewers the office has and how costly a missed error would be.

Changing a threshold after go-live

Change one threshold at a time, and only with evidence from the review log. If reviewers approved nearly every allowed-amount field scored between 90 and 97 for a month without changing a digit, lowering the allowed-amount threshold is reasonable. If they corrected several, leave it where it is. Write down each change, the date and the reason, so that a later rise in posting errors can be traced to the change that caused it. When a pilot payer redesigns its EOB, raise its thresholds back to the starting level until the log shows the reader handles the new layout.

Schema Care works this way: the customer sets how sure it has to be before a field skips review, and every field below that line goes to a review queue instead of into the billing system. The threshold demo on a fictional EOB shows the queue grow and shrink as the slider moves. Thresholds and review queues in general, beyond EOB posting, are covered in the human review category.

How should the EOB review queue be staffed in the first month?

The EOB review queue in the first month should be staffed by the people who already post EOBs by hand, with one named owner, enough hours to clear the queue daily, and a second person who checks a sample of approvals. Experienced posters spot a misread fast because they know what each payer's EOB should say.

Who reviews. Pick posters who know the pilot payers. A reviewer's job is to compare a highlighted field against the original page and approve or correct it. That is quicker for someone who has keyed the same payer's EOBs for a year than for a new hire.

How many. Plan for more review work in the first month than you expect later. Thresholds start high, so more fields come to the queue, and reviewers are still learning the screen. A useful starting rule is to keep the reviewers' existing posting hours on the calendar for the pilot payers, then release time as the queue shrinks.

How fast. Set a same-day target. A field waiting in the queue is a payment that has not posted, which shows up as posting lag and unapplied cash. If the queue cannot be cleared the same day, raise staffing or narrow the pilot to fewer payers.

Who checks the checkers. Have a second person review a sample of approved fields each week. The aim is to find fields a reviewer approved that were in fact wrong, which tells you whether reviewers are rushing.

Keep a short log during the first month: fields reviewed per day, fields corrected, and the most common correction. That log is what tells you whether to lower a threshold, retrain a reviewer or drop a payer from the pilot.

Testing automated EOB posting before live patient data

Testing automated EOB posting before live patient data means running the whole process on de-identified sample EOBs first, and moving to real EOBs only after a business associate agreement (BAA) is signed with the vendor. A BAA is the written contract HIPAA requires before a vendor creates, receives, maintains or transmits protected health information for a practice.

The requirement comes from the Privacy Rule. Under 45 CFR 164.502(e) on eCFR, a covered entity may let a business associate handle protected health information only with satisfactory assurance that the business associate will safeguard it, documented in a written contract. The contract terms are listed in 45 CFR 164.504(e) on eCFR, including reporting uses not allowed by the contract and returning or destroying the information when the contract ends.

De-identified samples let a practice test before any of that applies. The safe-harbor method in 45 CFR 164.514(b) on eCFR lists identifiers that must be removed, starting with names and geographic details smaller than a state. A practical sample set is a few dozen pilot-payer EOBs with names, member IDs, addresses and claim numbers replaced by invented values, while the amounts, codes and layout stay intact.

Run the samples through extraction and review exactly as live EOBs would go, and compare the results against what a poster keys by hand from the same pages. Record every difference. Schema Care follows this order: it starts on de-identified samples and moves to live documents only after a BAA is signed.

What should automated EOB posting never post without review?

Automated EOB posting should never post a recoupment, a reversal, a payment that matches no patient, or a line whose amounts do not add up, without a person looking first. Each of these moves money in a direction that is hard to undo, and each needs context the EOB page alone does not give.

Recoupments and takebacks. A recoupment pulls back money the payer paid on an earlier claim, often one that is not on this EOB. Posting it blindly can reduce the wrong account or the wrong visit. A person should find the original claim and post the takeback against it.

Reversals. A reversal undoes an earlier payment, usually alongside a corrected claim that pays a new amount. The two must post together. If software posts one half, the patient balance is wrong until someone notices.

Unmatched patients. When the patient name, member ID and date of service on the EOB do not match an account, software must not guess. A close name match is not proof: two family members can share a subscriber ID, and payers truncate names.

Lines that do not balance. A service line should satisfy simple arithmetic: the billed amount minus every adjustment on the line, including the patient share, equals the plan payment. When a line breaks that rule, a field was misread or the payer printed something unusual. Either way a person should look.

New codes. An adjustment code the practice has never mapped should stop the line. Let a person decide how it posts, then add the rule.

Six-step rollout checklist

Step 2 and step 3 can run in parallel, since the samples are de-identified, but step 5 never starts before both are done.

When a payer's EOBs need to become 835 files for a billing system that only imports ERAs, the conversion is its own project, covered in the EOB to 835 conversion steps: scan, extract, review, build, load. To check what an ERA actually contains line by line, see how to convert an 835 file to a spreadsheet. If running a review queue in-house is not realistic, weigh payment posting outsourcing vs automation before you begin.