All resources

Automating EOB and claims PDF processing for medical billing

How a medical billing company stopped retyping claim PDFs into spreadsheets, kept data local, and avoided two full-time hires.

A lot of medical billing work still depends on someone reading a PDF and typing what it says into another system. It’s slow and easy to get wrong, and it gets harder to staff as claim volume grows.

This post explains why PDFs are still such a problem in billing, what automating them actually involves, and how we approached it with Eagle Medical Billing.

Why billing still runs on PDFs

Payers send remittance information in two main forms. The 835 ERA is a structured X12 electronic file that software can read directly. The EOB is the human-readable paper or PDF version of the same adjudication information (OneCare Portal).

In theory, everything would come through as structured data. In practice, billing teams deal with payers that only send PDFs, practice management systems that only output PDF reports, and older systems with no export or API. Those PDFs are where retyping comes from.

What Eagle was dealing with

Eagle’s billing system produced PDF reports with no export or API. Staff were retyping claim details into a spreadsheet so they could track claims and follow up (Eagle Medical Billing case study).

The billing system treated the PDF as the final output, but Eagle’s team still needed the information inside it to do their jobs.

What we built

We built an internal platform that does five things.

  1. It batch-imports claim and EOB PDFs.
  2. It extracts claim details, charges, allowed amounts, and adjustments.
  3. It checks those details against records Eagle already has.
  4. It flags anomalies for staff to review.
  5. It gives staff a work queue with statuses and totals for failed claims.

At Eagle’s reported claim volume, the platform avoided two full-time hires. It replaced PDFs, retyping, and a spreadsheet with one system (Custom Development).

Why we kept the processing local

Claim data includes protected health information. Under HIPAA, a vendor that handles PHI for a covered entity generally becomes a business associate and needs an agreement in place (HHS). Sending claim documents to an outside AI service adds a vendor and a data flow you have to account for.

For Eagle, parsing runs inside their environment, and claim data isn’t sent to an external AI service. We added role-based access, encryption in transit and at rest, and an audit log of actions in the system.

This isn’t legal advice. Review HIPAA requirements with your compliance advisor.

Why the math runs in code

It’s tempting to hand the whole document to an AI model and trust the output. We don’t do that with numbers. Charges, allowed amounts, and adjustments are parsed and validated in code, because those values need to be exact every time. Anything that doesn’t check out goes to a person.

Our guide to automating PDF data entry covers how to test for values that look plausible but are wrong.

How this compares to off-the-shelf tools

There are good document processing products for healthcare, and some of them handle EOBs (V7 Labs). If one fits your formats, your volume, and your security requirements, it’s worth considering.

Custom makes more sense when your reports are specific to your billing system, when you need the results tied into your own tracking and follow-up, or when you want the data to stay inside your environment.

If your team is retyping claim PDFs, tell us about the process.

Put it into practice

Sources & further reading

Have a question about your own project?Let’s talk