An insurance deposit appears in the bank, yet the related claims still show unpaid in the dental software. The money has arrived, but the practice cannot confirm which patients, procedures, or adjustments belong to it. Until the team connects that deposit with the correct remittance record, the revenue remains received but not fully reconciled.
This problem develops because an Electronic Funds Transfer (EFT) and an Electronic Remittance Advice (ERA) travel through separate systems. The EFT moves money from the payer to the practice’s bank account. Meanwhile, the ERA explains how the payer processed the associated claims. It shows payments, contractual adjustments, deductibles, coinsurance, denials, and other decisions that affect each patient balance.
Therefore, finding the same payer name and payment amount is not always enough to match an EFT to its ERA. One deposit may cover several claims, include a previous overpayment recovery, or connect with more than one remittance file. A payer or payment vendor may also appear under a different name in the bank record.
Reliable EFT and ERA reconciliation requires a stronger connection. The billing team must compare the reassociation trace number, confirm the ERA’s net payment, review every claim-level adjustment, and balance the final posting against the bank deposit.
This guide explains seven daily steps for moving every insurance payment through three distinct stages:
- Received: The EFT appears in the bank account.
- Posted: The ERA details are applied to the correct patient ledgers.
- Reconciled: The bank deposit, ERA net payment, and PMS batch agree.
Following this process helps dental practices find missing ERAs, prevent duplicate payment posting, correct inaccurate patient balances, and expose insurance payments that reached the bank but never reached the patient ledger. These unposted payments can also overstate dental accounts receivable and give the practice an inaccurate picture of how much insurance revenue remains outstanding.
What Is EFT-to-ERA Reassociation?
EFT-to-ERA reassociation is the process of connecting an insurance deposit in the practice’s bank account with the electronic remittance that explains that payment. The connection matters because the money and its claim details do not arrive through the same channel.
The payer sends the Electronic Funds Transfer through the banking system. For standard healthcare EFT payments, the transaction uses the ACH CCD+ format. Meanwhile, the payer sends the Electronic Remittance Advice through a clearinghouse, payer portal, or practice management system. That remittance uses the X12 Version 5010 835 transaction.
These separate routes create a common posting gap. The bank can show that $4,850 arrived from a payment vendor, while the PMS contains an ERA from a dental payer for the same amount. Matching the records by amount may appear reasonable, but it does not prove they belong together. Another payer could send an identical amount, or one deposit could combine several remittances.
The TRN Number Creates the Reliable Connection
The adopted healthcare payment standard addresses this problem through the TRN reassociation trace number. The payer places the TRN segment in the addenda information attached to the CCD+ payment and includes the corresponding TRN segment in the associated 835 ERA. When both records contain the same trace information, the practice can connect the bank deposit with the correct remittance.
According to CMS EFT and ERA operating rules, the TRN segment in Field 3 of the CCD+ addenda record should match the TRN segment in the related ERA. This matching process is what CMS calls reassociation.
A complete match should compare these fields:
| Matching Field | What It Confirms |
| TRN reassociation trace number | The EFT and ERA belong to the same payment transaction |
| EFT and ERA net amount | The deposited amount agrees with the final remittance total |
| Effective or deposit date | The payment falls within the expected transmission period |
| Payer or payment originator | The funds came from the expected payer or vendor |
| Tax ID, provider, or location | The payment belongs to the correct dental entity |
The trace number should serve as the primary matching field when reliable CCD+ addenda data is available. The amount, date, payer, and location then validate that connection.
Reassociation Is Not the Same as Payment Posting
Reassociation answers one question: Which ERA explains this EFT deposit? Payment posting answers another: How should the money and adjustments be applied to individual patient accounts?
Suppose a $4,850 EFT matches an ERA containing twelve dental claims. The trace number confirms that the records belong together, but the payment is not fully reconciled yet. The billing team must still review each claim, allocate insurance payments, enter contractual adjustments, assign patient responsibility, identify denials, and balance the complete posting back to $4,850.
This distinction prevents a deposit from being marked complete simply because staff located an ERA with the same total. First, the team reassociates the EFT with the correct ERA. Next, it validates and posts the claim details. Finally, it confirms that the bank deposit, ERA net payment, and PMS batch agree.
Why Daily Payment Matching Matters for Dental Practices
Connecting an insurance deposit with its supporting payment record identifies where the money came from. However, that connection only becomes useful when the practice updates the related accounts without delay. Otherwise, today’s unresolved deposit joins tomorrow’s payments, new payer decisions, and changing patient balances. Within a few days, staff are no longer reviewing one clear transaction. They are rebuilding an entire sequence of financial activity.
A daily deposit audit prevents that sequence from breaking. Because the payment is reviewed close to its deposit date, the payer information remains easier to locate, the affected claims are still visible, and unusual adjustments are less difficult to trace. More importantly, completing this review gives every payment a clear direction. It either moves into posting or enters an exception workflow with a named owner.
Find Money That Never Reached the Patient Ledger
That clear direction matters because money can reach the bank without reaching the dental software. When this happens, the practice has received the funds, yet the related claims continue to appear unpaid. As those false balances remain in the aging report, unposted insurance revenue begins to distort the practice’s financial picture.
Consider a payer that deposits $7,200 on Monday. If the related payment record never imports, the bank confirms the receipt while the software continues to show several open claims. Staff may then spend time calling the payer about balances it has already paid. Meanwhile, genuinely unpaid claims receive less attention because the report no longer separates real receivables from posting gaps.
Reviewing the deposit that same day interrupts this chain. Once staff locate the supporting details and update the correct accounts, the aging report becomes more reliable. That corrected report then leads naturally to the next question: did the payer leave the right balance with each patient?
Turn Payer Decisions Into Accurate Patient Balances
Answering that question requires more than entering one total payment. The payer may divide the remaining amount between deductibles, coinsurance, copayments, contractual reductions, noncovered services, and additional insurance. Each decision changes the account differently, so the patient ledger cannot be trusted until staff apply the complete remittance correctly.
When insurance cash posting falls behind, this missing detail can move an incorrect balance toward the patient. A statement may request money that insurance already covered. In another case, a valid patient portion may remain hidden because the insurance balance still appears open. The same delay can also create an incorrect write-off, leave a credit unnoticed, or postpone a necessary refund review.
Daily processing keeps these errors from reaching the next statement cycle. Once the team records the payer’s full decision, it can separate true patient responsibility from balances that still require insurance action. That separation is essential because some unpaid amounts are not ready for patient billing at all.
Move Unresolved Claims Into the Right Follow-Up
Payment records often contain more than reimbursements. Alongside paid claims, the payer may report a denial, request additional documentation, apply a bundling rule, or assign the remaining balance to another carrier. If staff treat the file only as a deposit explanation, these decisions can remain untouched even after the paid items reach the ledger.
For instance, a crown claim may require a missing narrative, while another account may be ready for secondary submission. Delaying the review delays both actions. The first claim continues aging without its documentation, and the second cannot move forward because the primary payment information has not been recorded.
A daily workflow prevents that pause by converting each payer response into a specific task. Paid claims move to posting, documentation requests return to the responsible team, denied services enter correction, and secondary balances move to the next payer. As a result, the review does not simply record yesterday’s activity. It creates today’s follow-up priorities.
Make Collection Reports Reflect Real Revenue
Those priorities only remain accurate when the financial records agree with one another. A deposit in the bank proves that money arrived, but it does not prove that staff assigned it correctly. Similarly, an entry in the dental software proves that someone recorded a payment, but it does not confirm that the bank received the same amount.
For this reason, strong payment reconciliation controls must connect the financial side with the patient-account side before the team closes the transaction. That comparison can reveal a deposit assigned to the wrong office, a payment entered twice, money left unapplied, a recoupment omitted from the batch, or the same file imported more than once.
Finding these exceptions each day keeps the investigation close to the original transaction. Staff can still identify the payer, trace the amount, review the affected accounts, and correct the issue without reopening weeks of activity. Consequently, the owner receives a clearer picture of collections, while the billing team sees which balances still require genuine follow-up.
That level of visibility does not begin with posting. It begins by identifying every insurance deposit that entered the bank and placing it into a controlled daily review.
7 Steps to Connect Insurance Deposits With Payment Records
Step 1: Build a Complete Insurance Deposit Register
Clear financial visibility begins with the bank because it shows which funds actually entered the practice’s account. However, a bank statement alone cannot tell the billing team which claims were paid or whether the related accounts were updated. The first step, therefore, is to turn every new insurance deposit into a trackable item before anyone begins posting it.
Start each business day by reviewing all bank accounts used to receive payer funds. Next, move every new insurance deposit into one insurance deposit register, including payments that already appear familiar. Skipping a deposit because the payer usually sends it on the same day or for a similar amount creates the exact gap this process should prevent.
Record these details for each transaction:
- Deposit or effective date
- Exact amount received
- Bank transaction description
- Originating payer or payment vendor
- Bank trace or reference number
- Receiving bank account
- Tax ID or office location, when identifiable
- Employee assigned to the review
- Current status
- Date of the next required action
These fields create a working record rather than a passive list. The amount and date help staff locate the transaction, while the bank description and reference details narrow the payer search. At the same time, the location and tax ID fields prevent a multi-office practice from applying funds to the wrong entity.
Do Not Rely on the Bank Description Alone
Bank descriptions often shorten payer names or display an intermediary instead of the dental plan. For instance, a deposit connected with a familiar carrier may appear under the name of its payment vendor. If staff search only for the carrier name, they may conclude that no supporting record exists even though it has already arrived under another identifier.
For this reason, the practice should maintain a simple payer-alias reference that connects:
- The dental plan’s public name
- The name shown in the bank
- The payment vendor, when applicable
- The clearinghouse or portal used to retrieve details
- The tax ID or location receiving the funds
Each confirmed payment improves this reference. Consequently, the next deposit from the same originator becomes easier to identify without forcing staff to repeat the same investigation.
Give Every Deposit a Clear Status
Recording the transaction establishes visibility, but its status shows what must happen next. Use a short progression that reflects the actual workflow:
| Status | Meaning |
| New | Deposit entered but supporting details not yet located |
| Located | Related payment record found |
| Confirmed | Identifiers and net amount agree |
| Posted | Claim-level activity entered into the dental software |
| Balanced | Bank receipt and final software batch agree |
| Escalated | Missing or conflicting information requires follow-up |
This sequence prevents the word “complete” from hiding unfinished work. A deposit marked “Located” still needs validation, while one marked “Posted” still needs final balancing. Only the last completed status confirms that the practice has accounted for the full transaction.
Suppose the bank shows a $9,640 deposit from an unfamiliar originator. Instead of posting it to an unapplied account or waiting for someone to recognize the name, the assigned employee records the transaction as “New.” The amount, date, reference number, and originator then guide the search for its supporting details. If the file cannot be found, the item remains visible with a follow-up date rather than disappearing inside the bank statement.
By the end of Step 1, every incoming insurance payment should have an amount, an identity trail, a status, and an owner. That controlled register becomes the source for Step 2, where the team retrieves the electronic payment explanations needed to support each deposit.
Step 2: Find the Remittance Through the Route That Payer Actually Uses
The deposit register tells the team which payment needs an explanation, but it does not tell them where that explanation will appear. That path changes from one payer to another. Some carriers deliver the file directly into the dental software, while others send it through a clearinghouse, hold it inside a payer portal, or place it under a third-party payment vendor. Multi-location practices may face another variation because the same carrier can route different offices through separate enrollments.
For that reason, the search should begin with the payer’s known delivery path rather than the same portal sequence for every deposit.
A solo office working from one tax ID might receive most records through a single clearinghouse. In that setup, a missing file usually points to an import failure, inactive enrollment, or delivery delay. A DSO, however, may receive payments for several tax IDs through different systems. There, the expected file might exist but sit under another location, provider profile, or billing account.
This difference changes the investigation. The team should first ask:
Where does this payer normally send payment details for this specific tax ID and location?
That question narrows the search before staff begin opening systems at random.
Build a Payer Route Map From Real Payment History
Instead of relying on memory, create a payer route map that reflects how the practice actually receives information. Each payer entry should identify:
- The name displayed in the bank
- The dental plan connected with that originator
- The portal, clearinghouse, or vendor that receives the supporting file
- The tax ID and office attached to the enrollment
- The provider profile used when several dentists share the same location
- The person responsible for access and follow-up
- Any known delay between the deposit and file delivery
This map should not remain fixed. Payers change vendors, practices add locations, and enrollment records become outdated. Each unusual payment should therefore improve the map rather than force staff to solve the same identification problem again.
Consider a group with three dental offices. Two locations receive one carrier’s payment details through the central clearinghouse, while the third office still receives them through a legacy portal. Searching only the clearinghouse makes the third location’s deposit appear unsupported. The problem is not a missing payment record. It is a location that follows a different delivery route.
Investigate the Break at the Point Where Delivery Should Occur
Once the expected route is clear, staff can identify where the information stopped moving. If the payer portal contains the file but the dental software does not, the break likely occurred between the portal, clearinghouse, and software import. If no file appears anywhere, the issue may involve the payer’s release timing or an enrollment failure.
The investigation should follow the missing link:
| What the Team Finds | What It Suggests | Next Action |
| File appears in the clearinghouse but not the software | Import or mapping failure | Review rejection logs and software routing |
| File appears under another office | Location or tax ID enrollment mismatch | Correct the delivery profile and inspect earlier payments |
| Deposit appears under a payment vendor’s name | Originator name differs from payer name | Connect the vendor with the correct carrier in the route map |
| Several payments from one carrier lack files | Wider enrollment or transmission issue | Escalate the payer setup instead of researching deposits individually |
| One file is absent but other payments arrived normally | Isolated delivery delay | Keep the item open and monitor the permitted transmission window |
| Someone posted from a portal copy | Electronic file may still arrive later | Flag the account to prevent duplicate entry |
This decision-based review prevents staff from treating every missing record as the same problem. More importantly, it directs the correction toward the broken connection instead of merely solving one deposit.
Let the Timing Determine When Waiting Becomes Escalation
Payment details do not always arrive on the deposit date. Under the CAQH CORE reassociation rule, a health plan generally releases the corresponding electronic remittance within a window beginning no more than three business days before and ending no more than three business days after the payment’s effective-entry date.
That window explains why a file may arrive before or after the funds. Still, it should not become a reason to leave the item unowned. When the deposit arrives first, staff should record when the next search will occur and keep the transaction open under the employee responsible for that payer.
Once four business days pass after receipt of either side, CAQH CORE treats the corresponding transaction as late or missing. At that point, the review should move from monitoring to formal follow-up. The assigned employee should use the payer’s resolution process and record the case number, representative response, expected delivery date, and next contact date.
Step 3: Verify the Trace Number Before Confirming the Match
Locating the remittance narrows the search, but a similar payer name, date, or amount does not prove that it belongs to the deposit. The team must now compare the transaction identifier carried in both records.
For a standard healthcare payment, the payer includes a reassociation trace number in the bank addenda and the related remittance. When both values agree, payment trace verification creates a stronger connection than amount-based matching alone.
Review the identifiers in this order:
- Reassociation trace number
- Net payment amount
- Effective or deposit date
- Payer or payment originator
- Tax ID and receiving location
The amount and date should support the trace match, not replace it. Two deposits can share the same value, while a bulk payment may combine several claim payments under one total.
For example, suppose the bank receives two $3,250 deposits from the same payment vendor on the same day. Two remittances also show $3,250. Matching by payer, date, and amount could easily reverse them. The correct EFT trace number links each deposit to its own file and prevents payments from reaching the wrong patient accounts or office.
If the trace details are missing from the bank view, request the CCD+ addenda information from the financial institution. If the numbers conflict, keep the transaction open and contact the payer or payment vendor rather than forcing a match.
Step 3 is complete only when the trace information and supporting fields point to the same transaction. Once that connection is verified, the team can review whether the deposited amount agrees with the remittance’s true net payment.
Step 4: Compare the Deposit With the Net Remittance Amount
Once the identifiers confirm that both records belong together, the team should test whether their final amounts agree. This comparison must use the remittance’s net payment amount, not simply the total of its positive claim payments.
The difference matters because one payment file may contain:
- Payments for several patients
- Prior overpayment recoveries
- Withholds or interest
- Claim reversals
- Provider-level balance adjustments
- Funds distributed across multiple offices
Suppose the remittance shows $6,700 in current claim payments. The payer also recovers a previous $250 overpayment and applies a $30 provider-level adjustment. After both deductions, the final amount equals $6,420, which should match the bank deposit.
| Remittance Activity | Amount |
| Current claim payments | $6,700 |
| Prior overpayment recovery | −$250 |
| Provider-level adjustment | −$30 |
| Final remittance payment | $6,420 |
| Bank deposit | $6,420 |
Without reviewing those deductions, staff may report a false $280 shortage even though the payer transferred the correct net amount.
When the totals differ, do not immediately change a patient account to make the batch balance. First, check whether the payer divided one deposit across multiple remittances, combined several files into one payment, or applied an offset outside the individual claim lines. Each adjustment should remain tied to its actual payer explanation.
Step 4 is complete when the bank amount equals the full net total supported by the remittance. That financial match confirms how much arrived, while the next step determines how the payer distributed that amount across claims, adjustments, and patient balances.
Step 5: Validate Each Claim Before Moving the Remaining Balance
A balanced total confirms that the correct amount reached the bank, but it does not prove that the payer processed every claim correctly or that staff should transfer each unpaid amount to the patient. The team must now move from payment-level balancing to claim-level remittance review.
For each claim, compare:
- Patient name and account number
- Date of service
- CDT code and submitted charge
- Allowed amount
- Insurance payment
- Contractual adjustment
- Deductible, copayment, or coinsurance
- Denied or noncovered amount
- Claim Adjustment Reason Code
- Remittance Advice Remark Code
- Secondary insurance information
These details tell one connected financial story. The submitted charge shows what the practice billed, the allowed amount applies the payer contract, and the insurance payment shows what the carrier released. Any difference should then be explained by a valid adjustment, patient portion, denial, or balance assigned to another plan.
Step 6: Post the Batch and Complete a Three-Way Balance
Once every claim has a justified outcome, the team can post the payment into the dental software. However, entering the remittance does not complete the process. The batch must still agree with both the payer’s final total and the actual bank deposit.
This three-way payment reconciliation compares:
| Control Record | What Must Match |
| Bank activity | Funds the practice received |
| Payer remittance | Net amount the carrier explained |
| PMS batch | Payment and adjustments staff recorded |
Suppose the bank and remittance both show $6,420, but the software batch totals $6,390. The $30 difference proves that part of the transaction remains missing, even though the major claim payments were posted correctly. Staff should find that difference before closing the batch rather than placing it in an unapplied account simply to force a balance.
Review the posting for:
- Incorrect patient or provider selection
- Missed claim lines
- Duplicate imported payments
- Unmapped adjustment codes
- Omitted recoupments or interest
- Unapplied balances
- Wrong office or bank account
- Secondary claims that failed to generate
Automated posting deserves the same final check. Software may transfer claim data quickly, but it cannot always resolve closed accounts, location conflicts, unusual payer deductions, or duplicate files without human review.
The team should mark the transaction as “Posted” when the patient ledgers are updated. Only change its status to “Balanced” after all three control records agree to the cent.
That distinction protects the practice from closing incomplete transactions. It also ensures that every remaining mismatch enters Step 7 as a visible exception with a clear owner and resolution path.
Step 6: Post the Batch and Complete a Three-Way Balance
Once every claim has a justified outcome, the team can post the payment into the dental software. However, entering the remittance does not complete the process. The batch must still agree with both the payer’s final total and the actual bank deposit.
This three-way payment reconciliation compares:
| Control Record | What Must Match |
| Bank activity | Funds the practice received |
| Payer remittance | Net amount the carrier explained |
| PMS batch | Payment and adjustments staff recorded |
Suppose the bank and remittance both show $6,420, but the software batch totals $6,390. The $30 difference proves that part of the transaction remains missing, even though the major claim payments were posted correctly. Staff should find that difference before closing the batch rather than placing it in an unapplied account simply to force a balance.
Review the posting for:
- Incorrect patient or provider selection
- Missed claim lines
- Duplicate imported payments
- Unmapped adjustment codes
- Omitted recoupments or interest
- Unapplied balances
- Wrong office or bank account
- Secondary claims that failed to generate
Automated posting deserves the same final check. Software may transfer claim data quickly, but it cannot always resolve closed accounts, location conflicts, unusual payer deductions, or duplicate files without human review.
The team should mark the transaction as “Posted” when the patient ledgers are updated. Only change its status to “Balanced” after all three control records agree to the cent.
That distinction protects the practice from closing incomplete transactions. It also ensures that every remaining mismatch enters Step 7 as a visible exception with a clear owner and resolution path.
Step 7: Close the Match or Assign the Exception
Once the batch balances, the team can close the transaction and record the completion date. If any part remains unresolved, however, the deposit should move into an exception queue rather than disappear inside an unapplied balance or unfinished note.
Strong payment exception management gives every mismatch four elements:
- A specific reason
- A responsible employee
- A next action date
- Evidence required for closure
Use the mismatch itself to determine the next action:
| Exception | Required Action |
| Deposit received but payment details are missing | Check the known delivery route, then open a payer case after the permitted window |
| Payment details received but funds are absent | Confirm the effective date and ask the payer to trace the transfer |
| Trace numbers conflict | Verify the bank addenda and payer record before posting |
| Deposit and final total differ | Review offsets, recoupments, interest, and combined files |
| Payment belongs to another office | Transfer it through the approved location process |
| File was already posted manually | Block duplicate entry and document the earlier batch |
| Zero-dollar file appears | Route denials, reversals, or adjustments without searching for a deposit |
Zero-dollar remittances deserve particular attention because they explain claim activity without moving money. Since no bank deposit exists, staff should send each denial, reversal, or adjustment to the correct follow-up queue instead of leaving the file on an unmatched-payment report.
The transaction should remain open until the team can prove either that all three financial records agree or that the exception reached its proper resolution. Closing an item because it has aged does not resolve it. It only removes visibility.
With Step 7 complete, every payment ends in one of two controlled outcomes: fully balanced or actively assigned. That distinction keeps unposted funds, unresolved payer decisions, and inaccurate patient balances from hiding inside the revenue cycle.
Turn Every Insurance Deposit Into Account-Level Clarity
Insurance revenue is not fully accounted for simply because money appears in the bank. The practice must still identify the supporting payer record, validate the net amount, update every affected claim, and prove that the final software batch agrees with the deposit.
Completing this process daily keeps one missing file from becoming a week of unexplained transactions. More importantly, it separates genuine outstanding claims from money the practice has already received but failed to record. That clarity improves collection reports, patient balances, denial follow-up, and financial decisions.
How Virtual Dental Billing Supports the Process
Virtual Dental Billing provides structured dental EFT reconciliation services built around each practice’s payers, locations, tax IDs, and software workflow. Our team tracks incoming deposits, locates supporting payment details, verifies transaction identifiers, reviews payer adjustments, posts claim-level activity, and routes unresolved items to follow-up.
This process gives every payment a visible path from the bank to the correct patient ledger. As a result, paid claims no longer remain hidden in aging reports, while missing files, recoupments, and posting differences receive attention before they distort revenue.
Need clearer visibility into your insurance payments? Contact Virtual Dental Billing to build a reconciliation workflow that accounts for every deposit and every affected claim.
