Underpayment detection software for billing companies and EHR vendors

What is underpayment detection?

Underpayment detection is the check that a payer paid what it should on each line. A remit (the 835) tells you what the payer paid and why it adjusted the rest. It does not tell you whether that amount matches the rate your practice negotiated. Finding out takes a second calculation: work out the expected payment yourself, then compare it with the remit.

An underpaid claim is not a denial. The claim shows as paid, so it rarely lands in a denial queue, and nobody looks at it again unless someone checks the amount. Payer underpayments add up quietly this way, one line and a few dollars at a time, across every practice a billing company serves.

Billing companies we talk to name the same kinds of short payment again and again:

• A fee schedule paid without its annual increase.
• An add-on code dropped or paid at a lower rate.
• The patient's share applied wrong, so the payer's portion comes out short.
• A service paid through a different network than the one in the contract.
• A telehealth visit paid below the in-person rate.

Each one shows up the same way: a paid line below what it should have been. For the steps done by hand, read what to do when a payer pays less than the contract.

Contract underpayment analysis: where the expected amount comes from

Contract underpayment analysis starts with the rate. Daybook works out the expected amount for each line in one of two ways, and every flag names which one it used.

From your contract or fee schedule

Load the practice's contract or fee schedule, and Daybook reads the fee schedule into rate rows: procedure code, modifiers, revenue code, how it pays (per unit, per diem, case rate or percent of billed) and the date each rate took effect. A model proposes the rows. Fixed checks decide whether they are accepted, and anything that fails goes to a person.

Rates are kept by payer, procedure code and modifiers, with the most specific match first. Contract terms are kept as a dated history, so each claim is priced on the terms in force on its date of service. The expected amount is the contract rate times the units, capped at what was billed, minus the patient's share. A flag against a loaded rate says the line was paid below the contract.

From the remit's own rate

Before any contract is loaded, the 835 itself is evidence. When most lines on a remit were allowed at the same share of the charge, and one line with the same code was allowed at less, Daybook flags that line. This works on day one with nothing but the 835. A flag of this kind says the line was paid differently from the rest of the remit, and your biller decides whether the contract was broken.

What a flag means

Every amount is worked in whole cents. A line is flagged when it was paid at least $1 below the expected amount. Fully denied lines go to denials, not here.

Some payers pay at claim level only, and some lines have no rate on file. Daybook counts those lines and shows the count beside the result instead of guessing a rate. A clean result means every line was judged on an exact rate.

How Daybook re-adjudicates paid claims

Every night Daybook asks each payer where your claims stand, pulls the remits, checks enrollment and compares what was paid with what was expected. By morning the answers are on the claims, in the system you already use.

For underpayments, each paid line goes through five steps:

1. The remit is balanced. Every 835 is proven to the cent, provider-level adjustments included, and matched to its claims line by line.
2. The expected amount is worked out. Daybook calculates it from the contract rate on file, or from the remit's own rate.
3. The two are compared. Each paid line is re-adjudicated against that expected amount.
4. Short lines are flagged on the claim. The flag shows the expected amount, the paid amount and the gap, how the expected amount was reached and why the line was flagged. Where the payer priced the service through another network, the flag says so.
5. An appeal is drafted. The draft is ready for your team to review and send.

The rules are written as fixed code, not left to an AI model. A dispute has to hold up with the payer, and fixed rules give the same claim the same answer every time. Every payer quirk, workaround and denial reason your team has learned goes into one knowledge base, and Daybook runs it as fixed rules.

From flag to underpaid claims appeal

An underpaid claims appeal needs two things a generic letter lacks: the contract line and the remit. Daybook drafts the appeal from the flag's evidence. When a draft has numbers in it, code puts them in, not a model. Our article on what an appeal needs to cite explains why those two citations carry it.

Each flag opens as a case. Your biller makes one of three calls:

• Dispute. The biller sends the reconsideration from the payer's portal, and the case waits on the payer until its follow-up date.
• Upheld. The payer answered and stands by what it paid. The biller can send it again or accept it.
• Accept. The payment stays as paid. A flag can also be marked not worth chasing, with the reason.

Daybook sends nothing to the payer on its own, and a decision on a flag never changes the claim's status. When the answer needs a phone call, Daybook calls the payer, waits on hold, works the phone tree and asks what your biller would ask. The reference number and the answer land on the claim.

What your team still decides

Agents do the payer work, and your team keeps every billing decision. Your billers make every call on appeals, write-offs and posting.

Nothing is offshored, so there is none of the data-handling, quality or compliance exposure of large offshore teams. Daybook takes over the portal checks, hold time and status follow-up, and any change to your headcount is your call.

Who it is for

Medical billing companies. You bill for many practices, each with its own payer contracts. Daybook checks every paid line against that client's rates and puts the result on the claim in your PM system. Daybook does not run a billing company and will not compete with the RCM companies it works with. It can also run inside your own tools, so your clients never need to know which infrastructure is behind it.

EHR and practice management vendors. If your EHR bundles RCM, Daybook is the infrastructure behind it. Every answer is written back onto the claim inside the EHR, under your name. Daybook ships its work as pull requests against your own repositories, the screens follow your workflow, and your engineers own the code afterwards.

How it connects to your systems

Nobody switches software. Daybook connects to the PM systems, EHRs and clearinghouses your clients use. Where a system has no API, it builds a browser automation and wraps it as an integration. Remits come from the 835s, and payments post through the path your system already has. For how each remit is checked before anything else, read how to balance and match every remit.

A forward-deployed engineer can handle onboarding, starting from the contracts, fee schedules, rules and scripts you already have. If you run several PM systems at once, see how a billing company works across several practice management systems.

Daybook is HIPAA compliant and signs a BAA with each customer before any PHI is processed. Data is hosted in the United States, and each customer has a separate database.

How other tools handle underpayments

The tools below each handle a short payment differently. How we compared:

• We read each vendor's public pages in October 2026, and an analyst profile where noted.
• We recorded what each one says it does when a payer pays short, and who it sells to.
• A price is shown only where the vendor publishes one. Otherwise it says "Not public".

Best for, option by option:

• Daybook: a medical billing company or EHR vendor that wants every paid line checked against its rates, with the appeal drafted and the decision left to its billers.
• SuperDial: a team that wants payer calls made and payment details brought back, and does the contract math itself. Its claim status calls return the paid amount, allowed amount and check or EFT number.
• Zentist: a DSO with at least five locations that needs dental EOBs and ERAs collected, parsed and posted.
• eAssist: a dental office that wants to hand billing to people entirely. Its published fees start at $1,400 per month per location under $40,000 in monthly insurance collections, then 3.50% of collections from $40,000 to $100,000.
• Lassie: an independent practice that wants EOBs posted and insurance payments reconciled, with underpayments flagged for staff review.

How pricing works

Daybook uses usage-based pricing. There are no subscriptions and no seats, and customers pay only for what Daybook processes. After the BAA, Daybook starts on one practice, or one payer and one system, with milestones agreed up front. It expands to your other practices once they are met. Our article on how usage-based pricing works for claims automation explains the model.

Is this right for you?

Daybook is a good fit if:

• You bill for practices with negotiated payer contracts, and nobody checks paid amounts against them line by line.
• You want each flag to show the expected amount and the math, so a biller can trust it and a payer can follow it.
• You want appeals drafted but sent by your own people.
• You are an EHR or PM vendor whose customers ask for RCM inside your product.

Another option may fit better if:

• You run a dental group and mainly need EOBs collected and posted. Zentist and Lassie are built for that; see Zentist alternatives.
• You want people to do all of a dental office's billing. A service such as eAssist does that.
• You mainly need payer phone calls answered and recorded. See SuperDial alternatives.

For the rest of the claim work, see claim status automation for billing companies, revenue cycle agents for EHR vendors and the best AI medical billing software for billing companies.