A pediatric practice we work with runs a well-known EHR and a separate practice management system from another vendor, connected by an interface. In November their charges came in about nine percent below the same month a year earlier. Visits were flat. The physicians blamed payer mix; the billing manager blamed undercoding. It took us two days to find the cause, and it was one of the charge interface errors we see most often: a new nurse practitioner had been added to the EHR in October but never mapped in the interface, and every encounter she signed had been failing quietly into an error queue nobody opened. Two hundred and eleven visits, about $31,000 in charges, sitting in a folder.
That is what interface failure looks like from the outside: not a crash, not an alert, just a number a little lower than it should be. When the EHR and the billing system are separate products, and even when they are separate modules from the same vendor, every charge crosses a bridge between them, and bridges drop things. Here is how the bridge works, the errors we see most, and the daily and monthly checks that prove nothing fell through.
Glossary lines for physicians reading this. The EHR is where the note lives and where the clinician selects diagnosis and procedure codes. The practice management system (PM) is where the charge becomes a claim. The interface carries the charge from one to the other, usually as an HL7 message, a standard format for moving healthcare data between systems. A DFT message (detailed financial transaction, type DFT^P03) carries a charge; an ADT message carries patient demographics and appointments.
Key takeaways
- A charge that fails the interface does not disappear with a warning; it sits in an error queue until someone looks, and the visit is never billed.
- The most common causes are unmapped providers, locations, codes and visit types: anything new in the EHR that the interface has not been told about.
- Reconciliation has to be done by count, not by dollars, and daily: checked-in appointments versus signed encounters versus charges received, by provider.
- One named person owns the interface error queue, and the queue is empty at the end of every day.
How a charge gets from the note to the claim
The path has more steps than most people think. The patient is checked in, usually in the PM, which sends an ADT message so the visit appears on the clinician's EHR schedule. The clinician documents, selects diagnosis and procedure codes, and signs the note. Signing triggers the EHR to build a DFT message with the patient identifier, encounter date, rendering provider, service location, each CPT or HCPCS code with its units and modifiers, and the diagnosis codes with their pointers. The interface engine translates identifiers between the two systems using mapping tables and delivers the message to the PM, which creates a charge on the account and sends it on to the scrubber and the clearinghouse.
Every translation is a place to fail. The EHR knows the physician as an internal user ID; the PM knows her as a provider record with an NPI and a fee schedule. The EHR calls the second exam room at the satellite office "Room 2B"; the PM needs place of service 11 and a billing location. If a lookup fails, the message is rejected or, worse, accepted with a default value that turns into a denial later.
The interface also carries reverse traffic. Demographic and insurance changes made in the PM flow to the EHR, and in some configurations changes made in the EHR flow back. Which system is the source of truth for each field is a decision the practice should have made in writing at implementation. When it wasn't, the two systems drift: a front desk that scans a new insurance card into the EHR, because that is the screen they have open, has changed nothing for billing, and the claim goes to the old payer and denies for coverage terminated (CO-27). Our RCM audit compares the two patient tables for exactly this reason.
The charge interface errors we see most
The unmapped provider is the classic. Every new physician, NP, PA and, in some systems, every nurse who can sign a nursing visit has to exist in both systems and in the mapping table between them, and onboarding checklists that cover credentialing and EHR access usually skip that step. The failure is silent because the EHR did its job (the note is signed and the charge was sent) and the PM did its job (it rejected a message it could not understand).
The unmapped location follows the same pattern whenever a practice opens a site, adds a telehealth visit type, or renames a room. Code table drift is next: ICD-10-CM updates take effect every October 1 and CPT changes every January 1, and if one system loads the new codes and the other does not, every charge using a new code fails until someone notices. Deleted codes are worse, because some interfaces accept them and the claim then rejects at the clearinghouse.
Then there are the messages that go through and are wrong. Units default to one when the EHR field is blank, so a 10-unit injection posts as one unit. Modifiers typed in a free-text field are dropped. Diagnosis pointers are reordered, so a screening diagnosis lands first and the claim denies for medical necessity. A clinician who unsigns and re-signs a note produces two charges for one visit. And some encounters are lost before any message is built: an unsigned note never sends a charge, and a note signed without a procedure code sends nothing to bill.
| Error | What you see | Where to fix it |
|---|---|---|
| Provider not mapped | Every encounter for one clinician missing in the PM; queue shows "unknown provider" | Interface mapping table; add the step to the onboarding checklist |
| Location not mapped | All charges from one site or one telehealth visit type fail | Location mapping; confirm place of service in the PM |
| Code not in PM table | Charges with new October or January codes reject | Load the annual code update in both systems before the effective date |
| Units defaulted to 1 | Drug and supply charges underbilled; J-code payments look low | Make units a required field on the EHR charge screen |
| Modifier dropped | CO-4 and bundling denials; modifier 25 visits paid as bundled | Use the structured modifier field; test after every EHR upgrade |
| Duplicate DFT on re-sign | Two charges, one visit; CO-18 duplicate denials | Interface rule to replace rather than add on re-sign |
| Unsigned or uncoded note | Visit on the schedule, no charge, no error | EHR unsigned notes report, daily, by provider |
The daily interface check
The check has three parts and takes about twenty minutes once it is routine. Part one is the interface error queue, the list of failed messages that every interface engine and most PM systems keep. Someone opens it every morning, fixes the mapping or the data on each item and reprocesses the message, and the queue is empty by the end of the day. A queue nobody owns fills up until the number is too embarrassing to face, and then it is "cleaned up" by deleting it, which is how the pediatric practice lost its November.
Part two is the count. For the prior business day, pull the number of checked-in appointments from the schedule, the number of signed encounters from the EHR, and the number of charges received in the PM, each by rendering provider. The three numbers should be equal or the differences explained by name: two no-shows, one note still unsigned by Dr. Patel, one nurse visit with no billable service. Any unexplained gap is a missing charge. We count rather than total dollars because a day that is short three low-level visits and long one procedure looks fine by dollars and is wrong twice.
Part three is the unsigned notes report from the EHR, by provider, with the age of each note. A charge cannot cross the interface until the note is signed, so an unsigned note is a charge that has not started its journey. Most groups require signing within 24 to 48 hours; the daily list is what enforces it.
A worked example from a three-provider family practice on a Tuesday: 68 appointments checked in, 66 encounters signed, 63 charges received. The two unsigned notes belong to one physician who left early. The three-charge gap between signed and received is the real finding: two are nurse injection visits where no procedure code was entered, so the message had no charge lines and the PM discarded it, and one is a telehealth visit type added in a January EHR upgrade and not mapped to any location, a fix that would otherwise have waited until every telehealth visit that week had failed.
Monthly reconciliation and the missing encounter report
The daily count catches yesterday; the monthly reconciliation proves the month. On the third business day after month end, pull three totals for the prior month by provider and location: encounters signed in the EHR, charges posted in the PM by date of service, and claims submitted for those dates. The gap between signed and posted is your interface loss; the gap between posted and submitted is your scrubber and claim hold loss. Both should be a list of specific encounters with a reason and an owner, not a percentage.
Most PM systems have some version of a missing encounter report that compares the schedule to charges. It is only as good as the schedule: hospital rounds and nursing home visits never appear on the office schedule and so never show as missing, and for those the EHR's signed encounter list is the master.
The monthly review is also when we test the interface after any change. Every upgrade, new location, provider, visit type or code update should be followed by a handful of test charges, read in the PM line by line: provider, location, place of service, each code, units, modifiers, diagnosis order. Vendors test that the interface is up; only the practice can test that it is right. When we take on medical billing for a practice with a separate EHR, this test is the first thing we run, and it fails more often than either vendor expects.
Questions we hear
Our EHR and PM are from the same vendor. Do we still have interface errors?
Fewer, but yes. Many "integrated" products are still two applications passing messages, and the unsigned note, missing code, unit and modifier problems exist regardless.
Who should own the interface error queue?
One named person in the billing office, with a backup, and the queue count reported at the weekly billing meeting. Not IT, who can fix the mapping but cannot tell whether a charge is correct, and not "whoever notices." The same person should own the onboarding step that maps new providers and locations.
How far back can we recover charges we find in the queue?
As far back as the payer's timely filing limit allows: Medicare allows twelve months from the date of service, and commercial contracts commonly allow 90 to 180 days. A charge found after the limit is written off as unbillable, which is why the daily check matters more than the monthly one; the pediatric practice recovered most of its November because it was found in January.
What to do this week
- Open the interface error queue today and work everything with a date of service inside your shortest timely filing window first.
- Run yesterday's three-way count (checked in, signed, charges received) by provider, and keep doing it every morning.
- List every provider, location and visit type added in the last twelve months and confirm each is in the mapping table.
- Check that the January 2026 CPT and HCPCS updates are loaded in both systems and send three test charges with new codes through.
- Write down which system is the source of truth for demographics and insurance, and tell the front desk which screen to use.
