Reconcile Insurance Payments With Bank Statements

An insurer deposit on a medical practice’s bank statement proves that cash arrived. It does not identify every claim in the payment, show why a line was adjusted, establish the contracted allowance, or prove that a payer owes more.

For US electronic payments, the useful control is EFT-to-ERA reassociation: match the electronic funds transfer to the corresponding electronic remittance advice, then reconcile the remittance to the practice-management ledger. Other countries and payers use different documents, so adapt the workflow to the local standard.

BankStatementLab can compare deposits with a payment-level accounting export, propose associations and produce an Excel, CSV or PDF control report. Use a permitted dataset without regulated patient details: one row per expected payment, with a non-patient reference, date and signed amount. Keep native ERA/835 parsing and claim review in the approved practice system.

Create a payment-level bank reconciliation

The four records have different jobs

Record	What it establishes	What it does not establish alone
Bank statement	posted deposit date and amount	claims, billed charges, adjustment reasons
EFT detail	payer, trace reference, settlement information	full claim adjudication
ERA/835 or paper remittance	claim and line payments, CARCs/RARCs, provider-level adjustments	whether the bank posted the cash correctly
Practice ledger and payer contract	billed services, patient account, expected contractual treatment	actual bank receipt

CMS explains that a Medicare ERA or paper remittance contains claim and service-line adjudication details and adjustment reasons. See Health Care Payment and Remittance Advice.

The bank is therefore a control point, not the primary claims record.

Step 1: build a deposit control list

Start with the relevant practice bank account and isolate deposits that appear to be insurer EFTs. Keep the bank’s original statement and, if available, its native CSV export.

Use a control table:

Bank posted date	Bank description	Bank amount	Payer	Trace reference	ERA found	Status
2026-05-07	HEALTH PLAN EFT	1,540.00	Example plan	004812	Yes	Matched

A description keyword is only a starting clue. Confirm payer and trace information from the EFT detail or treasury record.

If a statement exists only as a supported PDF or image, a conversion can make filtering easier. Check the extracted dates and amounts against the original before using the rows.

Step 2: reassociate the EFT and ERA

For HIPAA-standard US EFT and ERA transactions, the trace information in the payment addenda is designed to match the payment to the remittance. CMS calls this process reassociation and explains that the matching TRN segment helps connect the EFT with its ERA in its EFT and remittance operating-rule guidance.

Match:

• payer identity;
• payment or effective date;
• trace or reassociation reference;
• ERA payment amount;
• bank deposit amount;
• bank account receiving the funds.

A monthly bank PDF may show an abbreviated description without the reassociation TRN. Ask the bank’s treasury or ACH team to provide the CCD+ addenda or the required reassociation data. Do not assume a statement’s generic ACH trace number is the matching ERA reference. Use the reassociation information described in the CMS EFT and ERA guidance.

If one ERA relates to one EFT, the bank variance control is:

Bank deposit - ERA payment amount = 0

If a payer batches or splits payments differently, document the many-to-one or one-to-many relationship instead of forcing a single-row match.

Handle missing payment evidence without inventing a match

Exception	Record to obtain	Follow-up
Deposit exists, ERA missing	Payer or clearinghouse remittance	Request the ERA using payer, amount, date and reassociation reference
ERA exists, deposit missing	EFT status and destination-account detail	Confirm effective date, rejected payment or wrong account
Amount matches several ERAs	Full trace and payer identity	Leave the candidates open until evidence distinguishes them
Zero-payment remittance	Claim and adjustment detail	Review in the claims system; no bank deposit is expected merely because an ERA exists

Keep an owner, first-seen date and next action for each exception. Use the payer’s published late/missing EFT and ERA procedure rather than repeatedly importing the same remittance.

Step 3: reconcile the ERA internally

The ERA may include multiple claims and adjustments. In the US standard:

• CARCs explain why a claim or service-line amount changed;
• RARCs add detail;
• group codes assign financial responsibility;
• PLB entries describe provider-level adjustments not assigned to one claim.

CMS notes that provider-level adjustments can include prior-payment recoupments, interest, or incentive adjustments. A PLB entry is not automatically correct merely because it balances the remittance; review its code, reference, payer notice, and appeal or dispute rights.

Use an ERA worksheet:

ERA trace	Claim control	Billed	Payer paid	Patient responsibility	Contractual/other adjustment	Code	Ledger posted
004812	C-1001	900.00	700.00	50.00	150.00	See ERA	Yes

Do not infer the “expected” amount from billed charges. The payer contract, fee schedule, benefit rules, and adjudication details determine the expected treatment.

Step 4: post the payment to the practice ledger

Post the ERA at claim or service-line level according to the practice system:

1. payer payment;
2. patient responsibility where applicable;
3. contractual and other coded adjustments;
4. provider-level adjustments;
5. unresolved exceptions.

Then compare the practice’s payment batch with the ERA total and the bank deposit. An unexplained difference remains on an exception log; it is not assigned to a random patient account.

Use BankStatementLab for the deposit-to-ledger check

Once the remittance has been reviewed in your approved system, prepare an Excel or CSV export with one row per expected payment. Avoid patient names, clinical descriptions and claim details; preserve the detailed evidence in the practice system. BankStatementLab does not provide a native ERA/835 or claim-adjudication integration.

1. Extract the permitted bank statements and check their rows against the originals.
2. Open My Documents → Bank reconciliation, then import the accounting/payment control export as XLSX, XLS or CSV.
3. In Review, check the date, signed amount and currency. Use Advanced configuration only when the inferred columns or optional account filter need adjustment.
4. Select the already extracted statements for the receiving account, run the preview and create the report.
5. Review proposed associations and unmatched rows. Validate individually or choose Validate all after review and confirmation; individual validations can be undone.
6. Export the full Excel, CSV or PDF report for the authorized reviewer. Source entries and practice-ledger postings are unchanged.

Matching is one-to-one, for equal signed amounts and currencies. If an ERA combines or splits payments differently, prepare a documented payment-level control outside the feature before importing. A generic bank trace must not be treated as the remittance reassociation reference without checking it.

Compare my approved payment-control export. Reading a structured export and creating the reconciliation add no credits. PDF extraction uses the applicable credits: review pricing and the privacy policy.

Worked example: a deposit smaller than claim payments

In this fictional example, an ERA contains these payer payments:

Component	Amount
Claim A payment	700.00
Claim B payment	500.00
Claim C payment	595.00
Claim payment subtotal	1,795.00
Provider-level prior-period adjustment	(255.00)
ERA payment amount	1,540.00
Bank deposit	1,540.00

The bank and ERA match: cash variance is zero. The 255.00 difference from the claim-payment subtotal is not proof that Claim A, B, or C was short-paid. It is a provider-level adjustment that must be validated against its code, reference, prior ledger history, and payer notice.

If the bank showed 1,510.00 instead, the 30.00 would be a bank-to-ERA exception. That still would not identify a specific underpaid claim.

How to investigate a possible underpayment

Use EFT, ERA and ledger reconciliation to separate a cash-receipt issue from a claim-adjudication issue. Start a deadline-sensitive underpayment or appeal review in parallel when necessary; do not let a missing bank reference cause a filing deadline to expire. For the claim in question, compare:

• submitted procedure and units;
• payer contract or applicable fee schedule;
• allowed amount;
• deductible, coinsurance, or other patient responsibility;
• CARC, RARC, and group codes;
• coordination-of-benefits information;
• prior adjustments or recoupments;
• timely filing, appeal, and reconsideration deadlines;
• the amount posted in the practice system.

Then classify the outcome: correct adjudication, posting error, missing information, contractual issue, payer error, or unresolved. A spreadsheet variance is a work item, not a legal conclusion that money is due.

Denials are not visible in the bank

A claim that produces no payment leaves no bank transaction. To identify denials or unprocessed claims, use:

• ERA and paper remittance records;
• claim-status responses;
• clearinghouse reports;
• practice-management aging and denial worklists;
• payer portals and correspondence.

Bank deposits can confirm received cash but cannot define the complete population of submitted claims.

Accounting and tax treatment is context-specific

Do not equate all deposits with taxable income or all billed charges with revenue. Treatment depends on the entity, accounting method, jurisdiction, payer arrangement, patient collections, and period cut-off.

Reconcile the cash deposit to the remittance and ledger, preserve the source documents, and let the accountant apply the correct recognition and tax rules. In the US, the IRS recordkeeping guidance emphasizes supporting documents in addition to account statements.

Protect patient and payment information

ERA, claims, billing ledgers, and related payment records can contain protected health information. For a US covered entity, HHS says the HIPAA Security Rule requires safeguards for electronic PHI, and a cloud provider that creates, receives, maintains, or transmits ePHI on the entity’s behalf may be a business associate requiring an appropriate agreement. Review HHS cloud-computing guidance.

Before using any conversion or spreadsheet service:

• determine whether the file contains PHI;
• use only vendors approved by your privacy and security team;
• confirm any required contract or business associate agreement;
• minimize the data shared;
• restrict access and maintain an audit trail;
• follow the organization’s retention and deletion policy.

A vendor’s general privacy statement is not proof that a healthcare workflow is compliant.

Monthly sign-off checklist

• Every insurer deposit has an identified payer.
• Each EFT is associated with the correct ERA or paper remittance.
• Bank amount and remittance payment total agree, or the variance is open.
• Claim and provider-level adjustments have codes and references.
• Ledger postings agree with the remittance.
• Possible underpayments are tested against contracts and adjudication details.
• Denials are reviewed from claim systems, not inferred from the bank.
• A qualified reviewer signs off exceptions.
• PHI is handled only through an approved workflow.

Frequently asked questions

Can BankStatementLab import an ERA or 835 file?

It does not provide a native ERA/835 claims parser. Keep claim processing in the approved practice system. For a permitted dataset without regulated patient information, use an Excel or CSV control export with one row per expected payment to compare with extracted bank deposits.

Does a matched insurer deposit prove claims were paid correctly?

No. A bank-to-payment match checks receipt of that payment. Claim adjudication, patient responsibility, provider-level adjustments and contractual underpayments require separate remittance and ledger review.

Can I approve and export the payment matches?

Yes. Review the proposed bank-to-payment associations, validate them individually or in bulk after confirmation, and export the complete report as Excel, CSV or PDF. BankStatementLab does not post to the practice ledger.

Should patient details be uploaded for this control?

This payment-level control can use non-patient references, dates and amounts. Keep regulated patient data in systems approved for that purpose and review your organization’s requirements before using any service. A general privacy policy does not establish healthcare compliance.

Related articles

• Convert bank statement PDFs to Excel
• How to Prepare Bank Statements for Your Accountant
• How to Reconcile Bank Statements at Month End

Create my payment-level reconciliation report using statements and control exports approved for this purpose.