Explanation of Benefits documents contain the payment data medical practices need for posting (what was billed, paid, adjusted, and denied), but every payer formats them differently. A practice working with 15 insurance companies receives EOBs in 15 different layouts. AI-first extraction tools like Lido read EOBs contextually rather than matching coordinates, handling Blue Cross, Aetna, Cigna, Medicare, and Medicaid formats without templates, training data, or per-payer configuration. Relay, a healthcare revenue cycle company, processed 16,000 Medicaid claims across dozens of managed care organization formats in five days using a single extraction template.
If you work in medical billing, revenue cycle management, or practice administration, you already know the pain of Explanation of Benefits documents. Every insurance payer sends them. They all contain essentially the same information. No two of them look alike. Blue Cross Blue Shield formats theirs one way, Aetna another, Medicare Remittance Advices yet another. Medicaid managed care organizations each have their own variation on top of that. The data you need is always the same (what was paid, adjusted, denied, and why), but extracting it consistently across payers has historically required either manual data entry or a library of payer-specific templates that break every time a format changes.
This post covers why EOBs are so difficult to extract, what fields matter for payment posting, and how AI-based extraction handles format variation across payers without per-payer configuration.
The core problem is combinatorial. A solo medical practice might contract with 15 insurance payers. A mid-size billing company processes claims for dozens of practices, each with their own payer mix. The total number of distinct EOB formats in that billing company’s intake isn’t 15. It’s hundreds. Every payer has their own layout, field labels, and way of presenting adjustment codes and denial reasons. BCBS puts the patient responsibility in a summary table at the bottom. Aetna breaks it out per line item. Medicare RAs use a standardized but dense tabular format. Medicaid MCOs vary by state and by plan.
The volume compounds the problem. US Neurology, a multi-entity neurology practice, processes 175,000+ PDFs per year across eight entities. Many of those documents are EOBs from commercial and government payers alike. At that volume, manual data entry for payment posting is not just slow. It is a bottleneck that delays the entire revenue cycle.
Then there are backlog scenarios, which are more common than most people outside healthcare realize. A California medical lab had 3,300 EOBs backlogged from Covid-era testing. Insurance companies had disputed timely filing on the original claims, but a state bill retroactively required them to pay. The lab had a hard deadline: everything submitted to the Department of Managed Care by the end of June. That meant scanning and extracting data from 50,000 to 60,000 pages in under 90 days. Their billing software had no AI capabilities. They asked ChatGPT for recommendations. The response listed several document processing tools, but most required template setup or model training per payer. With a 90-day window and hundreds of payer formats in the backlog, there was no time for either.
Before evaluating any extraction approach, it helps to be specific about what your practice management system or billing software actually needs for payment posting. The fields are consistent across payers even when the layouts are not.
Patient name and account number. The account number is the field that ties the EOB back to a specific patient record in your system. Watch out: many practice management systems use account numbers with leading zeros (e.g., 00012345). If your extraction tool treats this as a number rather than text, it strips the zeros and the record won’t match on import. This is one of the most common extraction errors in medical billing.
Payer name and claim number. You need both to track which payer processed which claim, especially when a patient has primary and secondary insurance and you’re posting payments from both.
Service dates and procedure codes. The CPT codes and dates of service for each line item on the claim. These must match what was submitted on the original CMS 1500 form for proper reconciliation.
Billed amount, allowed amount, and paid amount per line item. The billed amount is what you submitted. The allowed amount is what the payer considers reasonable and customary. The paid amount is what they actually sent. The gaps between these three numbers tell the story of every claim.
Adjustment reason codes. This is where EOB extraction gets complicated. Adjustment codes follow the ANSI standard (CO, PR, OA prefixes), but the implications of each code are wildly different. CO-18 means the claim was already paid or is a duplicate, so you post the amount and move on. CO-29 means timely filing denial. You need to resubmit with proof of original filing date. PR-1 is deductible, PR-2 is coinsurance, PR-3 is copay. Each of these flows to a different column in your payment posting and triggers a different downstream action.
Patient responsibility. The sum of copay, coinsurance, and deductible amounts that the patient owes. This feeds your patient billing workflow.
Total paid versus total billed. The summary-level numbers you need for reconciliation against the actual check or EFT deposit.
Check or EFT number and date. The payment identifier that ties the EOB to a specific deposit in your bank account. Without this, reconciling multiple EOBs against a single bulk payment becomes manual detective work.
Template-based OCR works by defining fixed coordinates for each field on a specific document layout. You tell the tool: “The patient name is at position X,Y on the page. The paid amount is at position A,B.” This works well for documents you control, like your own invoices or internal forms. It fails on EOBs because the payer controls the format, not you.
The template approach means one template per payer per EOB format variation. A billing company with 200 payers in their mix needs 200 templates. But payers update their formats regularly (a redesigned EOB, a new field, a column reordered), and each update breaks the corresponding template. This is why template-based OCR breaks at scale. Maintaining a template library at that scale becomes its own full-time job. To understand more about why coordinate-based approaches have these structural limitations, see our post on the problem with template-based extraction.
One medical lab owner described his experience with Docparser, a template-based extraction tool: “It scanned everything really nicely, but then it created a JSON file. And that JSON file has a record of a record and within the record it has a list. So I have to parse all of them.” He was spending as much time writing code to parse the extraction output as he would have spent on manual entry. His conclusion: “I don’t want to step on a dollar to pick up a dime.”
A pharmacy operation called Swyft Scripts tried Microsoft Copilot for medical document extraction. They ran the same document through the tool multiple times and got different results each time. At over 1,000 pages per week, inconsistent extraction is worse than no extraction at all. You can’t trust the output, so you end up manually verifying everything anyway.
AI-based extraction with a tool like Lido works differently from templates. Instead of matching field coordinates, the AI reads the document contextually. This is what template-free data extraction actually looks like in practice. It understands that “Patient Responsibility” and “Amount Due from Patient” and “Member Owes” all refer to the same data point, regardless of where those labels appear on the page or what font size they’re in. You define one extraction template with your desired output columns, and that single template handles every payer format.
The results at scale are concrete. Relay, a Medicaid billing operation, processed 16,000 claims across dozens of managed care organization formats in five days using Lido. No templates, no per-payer configuration. That workload had previously taken months of manual data entry. The time savings came to over 100 hours per week returned to their team. Libertana, a home health agency in Los Angeles, processes insurance authorizations from Health Net, LA Care, CalOptima, and Anthem. Each payer’s authorization format is different, and all are handled by the same extraction workflow without payer-specific setup.
Processing speed matters when you’re dealing with EOB volumes typical of medical practices and billing companies. During their evaluation, US Neurology saw 1,000 pages processed in 1.5 to 1.75 minutes. That is not a theoretical benchmark. It’s what they observed running their own documents through the system during a live demo.
The adjustment reason codes on an EOB are not just data to capture. They are instructions that determine what happens next for each line item. CO-18 (duplicate or already paid) means you post the payment and move on. CO-29 (timely filing denial) means you gather proof of original submission and file an appeal. PR-1, PR-2, and PR-3 (deductible, coinsurance, copay) mean you send the patient a bill. Each code triggers a different workflow. Lumping them all into a single “adjustment” column makes the output useless for actual billing operations.
In Lido, you handle this with special instructions attached to your extraction template. The California lab owner described exactly this workflow: “Add up all the code 18 and put it in the paid section. Then ignore the line items where you have 18, because I’m only interested in [denials].” That instruction tells the extraction to sum all CO-18 line items into an “already paid” column, then surface only the denial codes that require follow-up action. Fully paid line items get posted automatically. Denied line items get flagged for the billing team to work.
This kind of conditional extraction logic (routing different adjustment codes to different output columns, filtering out line items that don’t need attention) is what separates a useful extraction tool from one that just dumps raw data into a spreadsheet. The special instructions apply across all payers. You don’t need a separate rule set for Blue Cross versus Medicare versus Medicaid. The AI identifies the adjustment codes regardless of how the payer formats them on the page, and your instructions determine how they’re categorized in the output.
Backlog scenarios in medical billing are more common than they should be. Covid-era claims denied and later reinstated by regulatory action. Payer disputes that took years to resolve. System migrations where documents piled up during the transition. Practice acquisitions where boxes of unprocessed EOBs came with the purchase. The challenge is always the same: thousands of documents from dozens of payers, a hard deadline, and no realistic way to get through them by hand.
The processing speed benchmarks from actual Lido users give a concrete picture of what’s possible. US Neurology saw 1,000 pages in 1.5 to 1.75 minutes during their demo. CorpBill, a billing services company, processed 300 invoices in approximately one minute. Relay cleared 16,000 Medicaid claims in five days, saving over 100 hours of manual work per week. These are not cherry-picked numbers from ideal conditions. They come from real healthcare documents with formatting inconsistencies, poor scan quality, and payer variation typical of production workloads.
For backlog processing, Lido supports batch upload. You upload the entire backlog at once, the system processes everything against your single template, and the output downloads as CSV or Excel for import into your practice management system. For operations that need an intermediate step, the workflow can go from extracted Excel to CSV to a bulk PDF generation tool and then into the billing software’s import function.
For ongoing processing after the backlog is cleared, document automation through email forwarding keeps the pipeline moving without manual uploads. You set up a dedicated email address in Lido, forward incoming EOBs to that address as they arrive, and the extracted data is ready for review and import without anyone logging into the extraction tool.
The setup process starts with your billing system’s import format, not the EOBs themselves. Define your output columns to match exactly what your practice management system expects: Patient_Name, Account_Number, Payer, Claim_Number, Service_Date, CPT_Code, Billed_Amount, Allowed_Amount, Paid_Amount, Adjustment_Code, Adjustment_Amount, Patient_Responsibility, Check_Number, Check_Date. Use your system’s exact column names so the output can be imported without reformatting.
Next, add special instructions for the fields that need specific handling. Tell the system to preserve leading zeros on account numbers by treating them as text fields, not numbers. Add the conditional logic for adjustment codes: sum CO-18 amounts into a paid column, flag CO-29 for resubmission, break out PR-1, PR-2, and PR-3 into separate patient responsibility columns if your billing system requires that granularity. Tell it to ignore fully paid line items if you only want to see actionable denials.
Upload test EOBs from your top three to five payers by volume. Include at least one Blue Cross, one Aetna or Cigna, one Medicare RA, and one Medicaid MCO if applicable. Check the output against what you’d expect from a manual review of those same documents. If a field is mapping incorrectly (say one payer labels the check number differently), add a one-line instruction to your template. Lido offers free 24-hour reprocessing, so you can refine your instructions and re-run the same test documents without additional cost.
Once your template handles the test payers correctly, expand to remaining payers. No additional templates are needed. The AI reads each new payer’s format contextually and maps it to your output columns. For ongoing processing, set up email forwarding from your billing inbox to Lido’s dedicated address so incoming EOBs are processed automatically as they arrive.
EOBs are one part of the medical billing document stack. Lido handles CMS 1500 claim forms, insurance authorizations, remittance advices, and other healthcare documents with the same single-template approach. For a broader look at how AI-based extraction differs from traditional OCR, see our guide on what OCR data extraction actually does.
Yes. AI-based extraction reads EOBs contextually rather than matching field coordinates, so a single extraction template handles every payer format. Relay, a Medicaid billing operation, processed 16,000 claims across dozens of managed care organization formats in five days using one template with no per-payer configuration. The AI identifies fields like “Patient Responsibility” or “Amount Paid” regardless of where they appear on the page or how the payer labels them.
You add special instructions to your extraction template that define how each adjustment code should be categorized. For example, you can instruct the system to sum all CO-18 (duplicate/already paid) amounts into a “paid” column, flag CO-29 (timely filing denial) line items for resubmission, and break out PR-1, PR-2, and PR-3 into separate deductible, coinsurance, and copay columns. These conditional rules apply across all payers without payer-specific configuration.
On clean digital PDFs (which most EOBs are, since payers generate them electronically), AI extraction achieves 99.5% to 100% field-level accuracy. Scanned or faxed EOBs with lower image quality typically see 95% or higher accuracy. Lido offers free reprocessing within 24 hours, so you can refine your extraction instructions and re-run documents at no additional cost until the output matches your requirements.
Yes. Lido supports batch upload for backlog processing. Based on observed processing speeds from healthcare customers, 1,000 pages process in approximately 1.5 to 1.75 minutes. A backlog of 3,300 EOBs (even at 50,000 to 60,000 total pages) can be processed in hours rather than the weeks or months that manual entry would require. The output downloads as CSV or Excel for direct import into your practice management system.
Yes, when you include a special instruction telling the system to treat account numbers as text fields rather than numeric fields. Without this instruction, an account number like 00012345 would be converted to 12345, which would fail to match in your practice management system. The text field instruction preserves the original formatting including all leading zeros.
Yes. AI-based extraction reads EOBs contextually rather than matching field coordinates, so a single extraction template handles every payer format. Relay, a Medicaid billing operation, processed 16,000 claims across dozens of managed care organization formats in five days using one template with no per-payer configuration. The AI identifies fields like “Patient Responsibility” or “Amount Paid” regardless of where they appear on the page or how the payer labels them.
You add special instructions to your extraction template that define how each adjustment code should be categorized. For example, you can instruct the system to sum all CO-18 (duplicate/already paid) amounts into a “paid” column, flag CO-29 (timely filing denial) line items for resubmission, and break out PR-1, PR-2, and PR-3 into separate deductible, coinsurance, and copay columns. These conditional rules apply across all payers without payer-specific configuration.
On clean digital PDFs (which most EOBs are, since payers generate them electronically), AI extraction achieves 99.5% to 100% field-level accuracy. Scanned or faxed EOBs with lower image quality typically see 95% or higher accuracy. Lido offers free reprocessing within 24 hours, so you can refine your extraction instructions and re-run documents at no additional cost until the output matches your requirements.
Yes. Lido supports batch upload for backlog processing. Based on observed processing speeds from healthcare customers, 1,000 pages process in approximately 1.5 to 1.75 minutes. A backlog of 3,300 EOBs (even at 50,000 to 60,000 total pages) can be processed in hours rather than the weeks or months that manual entry would require. The output downloads as CSV or Excel for direct import into your practice management system.
Yes, when you include a special instruction telling the system to treat account numbers as text fields rather than numeric fields. Without this instruction, an account number like 00012345 would be converted to 12345, which would fail to match in your practice management system. The text field instruction preserves the original formatting including all leading zeros.
%20(1).svg)
