Approved Batch, Missing Deposit: A Merchant’s Settlement Troubleshooting Checklist

A POS may show a batch as closed, a processor portal may show it as settled, and yet the merchant’s bank account may still show no deposit. A missing merchant deposit does not automatically mean funds were lost or that the processor failed. 

The difference can come from cutoff timing, weekends or holidays, netted refunds or chargebacks, reserves, funding holds, ACH processing, bank-account configuration, or simply comparing the wrong amount.

The most important rule is simple:

An approved or closed batch is not the same thing as cash being available in the bank account. Verify batch close, processor settlement, funding creation, bank transmission, and final bank posting separately.

Instead of asking only, “Where is the deposit?” ask:

“At which stage did the money stop progressing?”

That question turns a frustrating cash-flow problem into a structured POS → Processor → Funding → Bank investigation.

First: Understand What “Approved,” “Closed,” “Settled,” and “Funded” Mean

Payment terminology causes many merchant funding troubleshooting mistakes. The same word may also have slightly different operational meanings from one processor, gateway, or POS platform to another, so the provider’s own documentation should always be the final authority for status labels.

At a high level, authorization, capture, batch processing, card-network settlement, merchant funding, ACH transmission, and bank posting are separate events. 

Visa documentation, for example, distinguishes authorization from capture and describes capture as the step used to initiate clearing and settlement of an approved transaction. Mastercard likewise identifies authorization, clearing, and settlement as distinct processing functions.

That distinction matters because an approval at an earlier stage proves very little about a later stage.

Batch Closed

A batch close generally means the POS, terminal, or payment application has grouped captured transactions and submitted or finalized them for downstream processing according to that system’s workflow. It does not, by itself, prove that the processor successfully settled those transactions or transmitted merchant funding.

For example, a restaurant terminal may print a successful close report at the end of the night. The merchant should still verify that the corresponding batch appears in the processor portal with the expected transaction count and amount.

A close event should normally be documented with:

• Batch ID
• Close date and time
• Location or terminal
• Merchant ID, or MID
• Transaction count
• Gross batch amount
• Refunds and voids where shown
• Transmission or submission status

If the POS close report exists but no corresponding processor record exists, the problem is still upstream of merchant funding.

Batch Accepted or Approved

“Accepted,” “approved,” “submitted,” and similar labels can mean different things across platforms. In some environments, a successful status means that a processor endpoint received the batch; in others, it can describe an intermediate processing state.

Do not interpret “approved batch” as “deposit already sent.”

The useful question is:

What exactly has been approved?

Was it the individual transaction authorization, the batch transmission, the settlement record, or the merchant funding record?

That distinction is essential when investigating an approved batch no deposit situation. Obtain the provider’s definition of the displayed status rather than building an accounting conclusion around the label.

Settled

Settlement generally occurs farther downstream than authorization and capture. Card networks distinguish authorization from clearing and settlement, demonstrating why a transaction can be successfully approved without every later financial step having occurred.

A processor portal’s “settled” status may indicate that card transactions completed its settlement process. It does not necessarily mean that the merchant’s bank has already credited the resulting ACH deposit.

For reconciliation, record:

• Processor batch number
• Settlement ID
• Settlement date
• Gross settled amount
• Settlement status
• Associated funding record, if available

The settlement record becomes the bridge between payment processing and merchant funding.

Funded

Funding is the stage at which the acquirer or processor creates, schedules, or releases money payable to the merchant under the applicable merchant agreement.

This amount may differ from gross card sales.

Depending on the merchant’s agreement, activity such as refunds, chargebacks, reserves, fees, and other adjustments can affect the amount ultimately funded. 

Merchant agreements may also contain reserve or funding-hold provisions, so finance teams should understand their own contractual terms rather than assuming every settled dollar must become part of the next deposit.

A useful internal resource is this discussion of merchant-services contract terms, fees, chargebacks, and reserve provisions.

Bank Posted

Bank posting is the final stage relevant to the merchant’s cash balance: the destination financial institution has received and credited the transfer to the merchant account.

An ACH transfer can therefore exist downstream of the processor while remaining absent from the merchant’s visible bank ledger during part of the processing cycle.

Federal Reserve guidance distinguishes receipt of an electronic payment by a financial institution from other payment stages, reinforcing why bank-side processing should be treated separately.

Stage	What It Means	Does It Prove Money Is in Bank?
Authorization	Issuer approves or declines the payment request	No
Capture	Approved transaction is submitted for financial processing	No
Batch close	Transactions are finalized/submitted from POS or terminal	No
Processor settlement	Transactions complete the processor’s settlement stage	No
Funding created	Merchant funding record has been generated/released	No
ACH sent	Funding instruction has been transmitted into the banking path	No
Bank posted	Destination bank has credited the merchant account	Yes

Did the Batch Actually Close?

When a payment batch deposit is missing, start at the POS rather than jumping directly to the bank. The first mandatory question is whether the transactions actually moved out of the open batch.

For additional background, this explanation of how payment batch processing moves transactions toward settlement shows why authorization, batching, and settlement should be treated as separate operational stages.

Pull the close report or POS batch history and compare the batch against the business’s expected trading activity. Verify the transaction count as well as the dollar amount; matching only the amount can hide omitted or duplicated transactions.

Record:

• Batch-close timestamp
• Batch ID
• Business date
• Terminal or location
• MID
• Number of captured transactions
• Gross captured amount
• Refund and void totals
• Close or transmission status

Also distinguish the sale date from the batch-close date. A late-night transaction, a restaurant with an operating day that crosses midnight, or a delayed manual batch close can cause those dates to differ.

Terminal Message vs. Processor Record

A terminal report is evidence from one side of the transaction path. The processor’s settlement portal is evidence from another.

A terminal may indicate that its batch-close workflow completed while the processor-side record remains pending, incomplete, or absent. Connectivity problems, application interruptions, gateway problems, or a failed downstream transmission can create situations where staff believe processing is complete when finance has not yet confirmed it.

The proper verification is:

POS Batch ID → Processor Batch Record

Compare transaction count, amount, MID, location, and dates.

If the processor cannot find the batch at all, the investigation is not yet a bank-deposit problem. Resolve the POS-to-processor transmission issue first.

Businesses that depend heavily on payment systems may also benefit from documented recovery procedures. This guide to payment-system continuity and outage planning provides useful background on payment-processing dependencies.

Automatic vs. Manual Batch Close

Some environments automatically close batches according to configured schedules; others require staff intervention. Never assume which arrangement applies.

A forgotten manual close can leave captured transactions sitting in an open batch longer than finance expects. Likewise, an automatic-close schedule can be changed, disabled, or misconfigured.

Verify:

1. Whether the location uses automatic or manual batch close.
2. The configured closing schedule.
3. Which system initiates the close.
4. Whether the expected close actually occurred.
5. Whether the processor received it.

Actual processor cutoffs should be verified with the merchant’s processor or acquirer because they are not universal.

Funding timing can also depend on when transactions are batched relative to the applicable processing cycle. This overview of batch timing and next-day merchant funding provides additional context, although merchants should always confirm the cutoff and funding schedule that applies to their own account.

Failed Automatic Close

An automatic close can be attempted without producing the intended downstream result.

Examples include:

• Connectivity loss during transmission
• Terminal or POS restart
• Gateway communication failure
• Authentication or configuration problem
• Batch remaining in a pending status

Do not repeatedly force additional closes or resubmit transactions without understanding their existing status. Duplicate submission can create a more difficult reconciliation problem.

Did the Batch Actually Settle?

Once processor receipt is established, move one step downstream and confirm settlement. This is one of the most important parts of payment settlement troubleshooting because POS status alone does not answer the funding question.

Locate the processor’s authoritative settlement report and identify the batch there.

Verify:

• Processor batch ID
• Merchant or location MID
• Settlement ID
• Settlement date
• Settled gross amount
• Transaction count
• Current settlement status
• Related funding record

If the settlement record does not exist, investigate why the submitted batch has not advanced. If it does exist, the next question becomes whether funding was created.

Batch ID vs. Settlement ID

The batch ID generally identifies a group of transactions at the POS, gateway, processor, or another processing layer. The settlement ID identifies the corresponding downstream settlement record.

They should not automatically be treated as the same identifier.

Depending on provider architecture, one POS batch could map to one processor settlement, multiple settlement records, or part of a larger settlement grouping. Likewise, funding can aggregate activity from multiple settlements.

The correct mapping is whatever the processor’s reporting system actually shows.

POS Batch ID	Processor Batch	Settlement ID	Gross Amount	Settlement Status
B-10482	PB-78142	S-55081	$8,420.00	Settled
B-10483	PB-78143	S-55082	$3,175.00	Pending
B-10484	PB-78144	S-55083	$6,910.00	Settled

These identifiers are hypothetical; merchant portals use different formats.

Processor Settlement Status

Providers may use labels such as:

• Pending
• Submitted
• Accepted
• Settled
• Funded
• Held
• Under review

Those labels are examples, not a universal status taxonomy.

Ask the processor:

“What does ‘settled’ mean in your reporting system, and what status proves that merchant funding has actually been released?”

That single question can eliminate substantial confusion.

The basic merchant-services relationship between payment acceptance, processor infrastructure, and merchant accounts is also covered in this verified overview of merchant-services fundamentals.

What Settlement ID and Amount Should Be Compared With the Bank?

Do not blindly search the bank account for the POS batch’s gross sales amount.

For a settlement deposit missing investigation, finance should identify the funding record that the processor says it released. The strongest comparison usually follows this path:

Settlement ID → Funding ID → Net Funding Amount → ACH Reference → Bank Posting

The funding amount is frequently more useful for bank reconciliation because it reflects what was actually intended for the merchant’s bank account.

Funding ID

A funding ID is an identifier used within a processor’s merchant funding system. Naming conventions vary, and not every provider exposes the same identifier.

Where available, it is useful because one bank deposit may incorporate multiple settlement batches.

Suppose three batches are settled:

• Batch A: $2,000
• Batch B: $3,200
• Batch C: $1,400

If the processor creates one funding record for all three, searching the bank for $2,000, $3,200, or $1,400 may produce no match. Finance needs the actual funded total after applicable adjustments.

That makes funding ID lookup a much stronger diagnostic tool than searching by the POS batch number alone.

ACH Reference or Trace

Once the processor says that funding was transmitted by ACH, ask whether an ACH trace or other bank reference is available.

Nacha technical documentation describes the ACH trace number as a unique transaction identifier constructed within the ACH record. The exact data available to a merchant can depend on its processor and financial institution.

An ACH reference can help connect:

Processor Funding ID → ACH Entry → Receiving Bank

Provide it to the bank if the processor confirms that the ACH was sent but no matching credit is visible.

Bank Deposit Matching

Use a reconciliation table rather than relying on memory or a bank-feed search.

Funding ID	Settlement ID	Expected Amount	Funding Date	Bank Amount	Bank Date	Match?
F-90210	S-55081	$8,105.25	Mon.	$8,105.25	Tue.	Yes
F-90211	S-55083	$6,655.80	Mon.	—	—	No

The exact dates and identifiers above are illustrative.

The direct answer to “what amount should be compared with the bank?” is:

Compare the bank posting against the processor’s actual net funding record—not automatically against POS gross sales.

Gross Sales vs. Net Funding: Why the Deposit May Be Smaller

A missing payment deposit sometimes is not missing at all. The merchant is simply searching for the wrong dollar amount.

The foundational reconciliation equation is:

Gross Captured/Settled Sales
− Refunds
− Chargebacks
− Net-Deducted Fees
− Reserves or Holds
± Processor Adjustments
= Expected Merchant Funding

Include only components that apply under the merchant’s actual contract and processor configuration.

Were Fees Netted From the Deposit?

Processor pricing and billing arrangements differ. Some charges may be netted from merchant funding, while others may be billed separately or appear on a periodic statement.

Relevant charges can include transaction-related processing costs, gateway charges, account fees, or other contracted items.

Never assume:

Gross settlement − estimated processing rate = deposit.

Use the processor funding report.

It should show the adjustments that actually affected the merchant bank deposit.

Refunds and Chargebacks

Refund timing does not necessarily match original-sale timing. A refund initiated today can affect today’s funding, another funding cycle, or another accounting period depending on processor workflow.

Chargebacks can likewise create a debit or adjustment against merchant funds.

For example:

Expected gross funding: $2,500
Chargeback debit: −$1,500
Fees/other adjustment: −$300
Actual net funding: $700

Someone searching the bank for $2,500 could conclude that the entire deposit disappeared even though a $700 processor deposit posted correctly.

Reserves and Holds

A reserve is a risk-management arrangement under which funds may be retained according to a merchant agreement. A temporary funding hold or risk review is not automatically the same thing as a contractual reserve.

Similarly, a rolling reserve, account review, and individual funding hold should not be treated as interchangeable terms.

Do not assume a standard percentage or release schedule. Review the merchant agreement and obtain the processor’s explanation for the specific funding record.

Component	Amount
Gross settled sales	$10,000
Refunds	−$450
Chargebacks	−$600
Fees netted in this funding cycle	−$175
Reserve/hold	−$500
Other adjustment	+$50
Expected bank funding	$8,325

Could Cutoff Times, Weekends, or Holidays Explain the Delay?

Yes. A merchant settlement delay can be a timing difference rather than a funding failure.

But avoid statements such as “all batches before 8 p.m. fund the next day.” Processor cutoffs depend on the provider, merchant configuration, payment channel, time zone, acquiring arrangement, and sometimes account-specific terms.

The correct model is:

Batch Close Time → Processor Cutoff → Settlement Cycle → Funding Cycle → ACH Processing → Bank Posting

Close Before vs. After Cutoff

Consider a hypothetical merchant whose provider has a defined daily cutoff.

A batch closed shortly before that provider-specific cutoff may enter one funding cycle, while a batch closed shortly afterward may enter the next. Both batches can eventually show successful settlement.

The lesson is not the hypothetical time—it is that close timestamp must be compared with the merchant’s actual processor cutoff.

Always distinguish:

• Sale date
• Business date
• Batch-close date and time
• Processor settlement date
• Funding date
• ACH initiation date
• Bank posting date

They are not interchangeable.

Time Zones and Business Dates

A merchant’s operating day may not align perfectly with the processor’s processing day.

Cutoffs might be interpreted based on merchant local time, terminal configuration, gateway settings, processor time zone, or another contractual setup.

Multi-location businesses are particularly vulnerable to this issue because one standard operating procedure may be applied across locations that actually have different POS configurations or cutoff relationships.

Document both timestamps and time zones whenever a batch appears late.

Weekends, Bank Holidays, and “Next-Day” Funding

Card acceptance can continue while banking and ACH schedules operate according to different processing calendars. That is why weekend or holiday activity should be reviewed before labeling a card settlement delay an incident.

Federal Reserve Financial Services publishes both its holiday calendar and a FedACH processing schedule. FedACH includes multiple processing windows, while holidays can alter when particular Federal Reserve payment services process.

This does not mean every merchant is funded directly through FedACH on the same schedule shown in those resources. The merchant’s processor, sponsoring financial institutions, and receiving bank sit between card settlement and final account posting.

Weekend Timing

A merchant can process hundreds of transactions on Saturday and Sunday while the corresponding funding path follows a different operating schedule.

Possible outcomes include:

• Processor settlement continuing while bank posting awaits another cycle
• Multiple days of sales being grouped into later funding
• Separate weekend deposits where a processor and bank support that arrangement
• A Monday posting that reflects more than one merchant business date

Therefore, do not say that weekend deposits are impossible. Determine what the merchant’s actual service supports.

Bank Holidays

Federal Reserve payment services follow published holiday schedules, so holidays can affect ACH-related processing. Federal Reserve guidance also distinguishes standard business days from banking days for certain banking purposes.

When a merchant expects funding around a holiday, document:

• Batch-close date
• Settlement date
• Processor funding date
• ACH transmission date
• Holiday
• Actual bank-posting date

That timeline often explains the apparent discrepancy.

Scenario	Batch Closed	Processor Settled	Bank Open?	Possible Impact
Normal weekday	Yes	According to provider cycle	Usually	Routine processing
Friday after provider cutoff	Yes	Possibly later cycle	Depends on following days	Funding may shift
Weekend	Yes	Provider dependent	Banking operations vary	Posting timing may differ
Bank holiday	Yes	Provider dependent	Relevant services may be closed/limited	Bank-side processing may shift

“Next-Day” vs. Bank Posting

Even when a merchant has a next-business-day funding arrangement, the phrase does not guarantee that a deposit will appear at exactly the same clock time each day.

Actual visibility can depend on:

• When the batch met the processor’s cutoff
• When funding was created
• When the ACH instruction was transmitted
• Which ACH processing window applied
• Receiving-bank operations
• Account configuration

Federal Reserve ACH resources show that multiple processing and settlement windows exist within the payment system, illustrating why “ACH sent” should not be reduced to one universal daily timestamp.

Could the Deposit Be Combined With Other Batches?

Yes. This is one of the most common reasons merchants believe a batch closed but no deposit appeared.

Do not assume:

One POS batch = one bank deposit.

Depending on the processor’s funding architecture, multiple settlements can be consolidated into one ACH credit.

For example:

Batch A + Batch B + Batch C → One Funding Deposit

If finance searches only for Batch B’s exact dollar amount, it may incorrectly mark the batch as unpaid.

The opposite can also happen:

One business day → Multiple funding deposits

That can occur when separate MIDs, payment channels, merchant entities, terminals, settlement groups, or processing arrangements are involved.

Reconciliation therefore requires identifiers, not just dollar values.

Multi-Location Merchant Funding Requires MID-Level Mapping

Multi-location reconciliation becomes much more reliable when finance follows:

Location → MID → Batch → Settlement → Funding → Bank Account

A location name alone is not sufficient.

One business may use different MIDs for stores, ecommerce channels, restaurants, franchises, or legal entities. Several locations may also fund to one concentration account, while another store funds separately.

Potential causes of apparent missing deposits include:

• Wrong MID associated with a location
• Funding sent to a different settlement account
• One account receiving deposits for several stores
• Separate ecommerce and card-present MIDs
• Recent store or MID migration
• New terminal mapped incorrectly
• Old MID remaining active during cutover

Maintain a master mapping.

Location	MID	Batch ID	Funding ID	Destination Account	Status
Store 1	****4102	B-7821	F-9201	****3301	Posted
Store 2	****4103	B-7822	F-9202	****3301	Pending
Online	****4110	B-7831	F-9205	****7718	Posted

Use masked account references in operational worksheets.

A newly onboarded merchant should also understand how merchant accounts relate to processing infrastructure. The verified overview of merchant-services basics for business owners can provide useful background.

Could the Destination Bank Account Be the Problem?

Yes. Once the processor confirms that funding was created, the next mandatory question is whether the money was transmitted successfully to the correct destination.

Possible problems include:

• Incorrect account details
• Incorrect routing information
• Recently changed settlement account
• Closed account
• Restricted account
• Bank-side posting exception
• ACH return or rejection
• Processor still using a previous funding account

Do not assume a processor settlement issue until this part of the chain has been checked.

Bank Account Changes Need Extra Controls

A change to merchant settlement instructions is a high-risk financial operation.

After any account change, verify:

1. Who requested the change.
2. Who approved it.
3. What bank account is currently on file.
4. The effective date.
5. Whether processor confirmation was received.
6. Whether the first live deposit reached the intended account.

Do not consider the migration complete merely because a portal displays new account details.

ACH Rejection or Return

Financial institutions may return ACH entries they cannot process. Nacha materials recognize return handling and identify situations involving unusable or closed accounts, among other return conditions.

Avoid diagnosing a specific return code unless the processor or bank has actually supplied it and the code has been verified.

Ask the processor:

• Was the funding ACH created?
• Was it transmitted?
• Was it accepted downstream?
• Has any return or rejection been received?
• What ACH trace or reference is available?

Then ask the receiving bank to search using the information it supports.

Bank-Side Troubleshooting

Provide the bank with:

• Approximate transaction date
• Exact expected ACH amount
• Processor or originator/company name
• Merchant bank-account last four
• ACH trace/reference, if available

Ask whether the bank can locate a pending, posted, rejected, or returned credit.

Do not send customer card numbers. The bank does not need the customer’s PAN to trace merchant settlement funding.

Check	Verified?
Correct account on processor file	☐
Correct routing information	☐
Account open	☐
ACH credits accepted	☐
Recent bank change reviewed	☐
ACH return/reject checked	☐
Bank trace search completed	☐

Could the Processor Be Holding Funding?

A processor funding delay can occur even after transaction settlement if merchant funding is held or placed under review according to the merchant agreement and applicable risk controls.

Possible reasons can include:

• Underwriting or risk review
• Significant volume change
• Unusual transaction patterns
• Reserve arrangement
• Outstanding account-verification request
• Compliance documentation request
• Elevated dispute or chargeback exposure
• Business-model or account-information change

These possibilities do not mean any particular merchant has violated a rule. They mean finance should determine whether the funding record itself shows a hold.

Funding Hold vs. Missing Deposit

Check the processor portal or contact the processor’s funding team.

Ask whether the affected funding ID is:

• Released
• Pending
• Held
• Reserved
• Under review
• Otherwise restricted

The exact terminology will vary.

If the processor confirms a hold, request the exact information it is permitted to provide:

• Affected funding IDs
• Affected amounts
• Reason or category
• Required documentation
• Case number
• Current status
• Next procedural step

Do not attempt to structure transactions to avoid risk controls.

Reserve Deduction

A merchant reserve hold may cause a deposit to be smaller rather than completely absent.

For example, a processor funding report could show a settled amount and then a reserve adjustment before the net funding amount. Whether that is permitted and how it works depends on the merchant’s contractual arrangement.

Review the agreement rather than assuming a universal reserve percentage, term, or release period.

Could a Chargeback or Adjustment Consume the Deposit?

Yes. A chargeback adjustment, large refund, reserve debit, or other valid processor adjustment can materially reduce merchant account funding.

Consider a hypothetical funding record:

Gross settlement: $2,500
Chargeback: −$1,500
Adjustment: −$300
Net funding: $700

The merchant received only $700, but the $2,500 batch itself did not disappear.

If total debits exceed current settlement activity, some processing arrangements can produce a negative net position or other account-level handling. The merchant should verify the provider’s actual process rather than assume the same behavior across processors.

Review both daily processor funding reports and periodic merchant statements because every charge does not necessarily appear in the same report or on the same date.

Check for:

• Refund
• Chargeback
• Reserve
• Funding hold
• Debit adjustment
• Account-related fee
• Previous-cycle correction
• Other documented adjustment

Settlement Reconciliation Workflow: POS to Processor to Bank to GL

Strong payment reconciliation should happen in three stages:

1. POS to processor
2. Processor to bank
3. Bank to accounting

Bank reconciliation alone is incomplete because a bank deposit only proves that a certain amount arrived. It does not establish whether every expected POS batch was received, settled, and funded correctly.

Use this workflow:

POS Sales → POS Batch → Processor Settlement → Funding Report → Bank → GL

Three-Way Reconciliation

First, match POS batches to processor settlement records.

Confirm:

• Batch IDs
• Transaction counts
• Gross amounts
• Refunds
• Settlement status

Second, map processor settlements to funding records.

Then reconcile net funding to bank deposits.

Finally, post the reconciled activity into the appropriate accounting records.

Date	POS Batch	Processor Settlement	Funding	Bank Deposit	Difference
Day 1	$9,200	$9,200	$8,965	$8,965	$0
Day 2	$7,500	$7,500	$7,210	—	$7,210
Day 3	$5,100	$5,100	$4,980	$4,980	$0

The Day 2 exception should remain open until resolved.

Expected vs. Actual Funding

Use:

Expected Funding − Actual Bank Posting = Reconciliation Difference

Every material difference should be explained.

Avoid setting one universal dollar tolerance across businesses. Materiality should reflect the company’s accounting policy, risk profile, transaction size, and finance requirements.

Clearing Accounts

Some accounting teams use a payment-processing or merchant clearing account to distinguish sales that have been recognized from cash that has not yet reached the operating bank account.

Conceptually, this can make timing differences easier to identify because unsettled or unfunded items remain visible rather than disappearing into a generic variance.

Accounting treatment should be aligned with the organization’s accounting policies and qualified financial advisors.

Funding Aging Report

Expected funding should remain on an exception report until it posts or is otherwise resolved.

Funding ID	Expected Date	Amount	Age/Status	Owner	Next Action
F-3401	Expected cycle	$4,850	Pending	Finance	Check ACH
F-3402	Expected cycle	$2,175	Held	Controller	Processor case
F-3403	Expected cycle	$7,100	Sent/not posted	Treasury	Bank trace

Do not use an arbitrary universal number of days for escalation. Use contractual funding expectations and the processor’s documented status.

Step-by-Step Missing Merchant Deposit Troubleshooting Checklist

The most efficient investigation follows the money in order. Do not skip directly from POS sales to the bank account.

1. Verify the batch actually closed: Confirm batch ID, timestamp, transaction count, amount, MID, and location.
2. Record the batch ID: Keep the identifier exactly as displayed by the POS or terminal.
3. Confirm processor receipt: Verify that the processor has a corresponding batch record.
4. Confirm settlement ID and status: Do not rely solely on the terminal close report.
5. Locate the funding ID: Determine which funding record contains the settlement.
6. Calculate expected net funding: Start with settled activity and incorporate only verified deductions or adjustments.
7. Review refunds, fees, chargebacks, reserves, and adjustments.
8. Review cutoff, weekend, and holiday timing.
9. Verify the destination bank account: Pay special attention to recent changes.
10. Check ACH transmission and return status.
11. Obtain an ACH trace/reference when available.
12. Search the destination bank account.
13. Escalate with complete evidence.

The diagnostic decision tree is:

Batch Exists?

• No → investigate POS/batch transmission.
• Yes → Settled?
  • No → investigate settlement.
  • Yes → Funding Created?
    • No → investigate processor funding.
    • Yes → ACH Sent?
      • No → processor/funding investigation.
      • Yes → Bank Posted?
        • No → bank/ACH investigation.

This is the direct answer to a card batch funding issue: find the last confirmed successful stage and investigate the next stage.

What Evidence Should Be Sent to Processor Support?

A processor support case moves faster when the merchant supplies exact identifiers rather than saying, “Yesterday’s money never arrived.”

Prepare:

• Merchant name and location
• MID
• POS batch ID
• Processor batch ID
• Settlement ID
• Funding ID
• Settlement date
• Funding date
• Gross settlement amount
• Expected net funding
• Actual bank amount
• Expected bank account last four
• ACH trace/reference, if available
• Relevant funding/settlement reports
• Masked bank statement line or evidence of no matching posting
• Recent bank-change details, if relevant
• Prior case number and history

Evidence	Why Support Needs It
Batch ID	Identifies the source batch
Settlement ID	Identifies processor settlement
Funding ID	Locates merchant payout record
Expected amount	Defines the variance
Bank statement line	Confirms actual posting or mismatch
ACH trace	Helps follow transmitted funding
Processor report	Shows settlement and adjustments

What Not to Send Support

Funding troubleshooting ordinarily does not require sensitive customer authentication data.

Do not send:

• Full PAN
• CVV/CVC/CID
• PIN or PIN block
• Full magnetic-stripe/track data
• Card photographs
• Account credentials

PCI Security Standards Council guidance explicitly prohibits storing card verification codes after authorization and requires controls around PAN display and storage.

Mask screenshots before attaching them to ordinary support cases unless the processor’s authorized secure workflow specifically requires additional information.

Support Ticket Template

Merchant/MID:
Location:
Batch ID:
Processor Batch ID:
Settlement ID:
Funding ID:
Expected Amount:
Funding Date:
Expected Bank Date:
Bank Account Last Four:
Bank Deposit Found?:
ACH Trace/Reference:
Issue Summary:
Steps Already Checked:
Existing Case Number:

When to Contact the Processor vs. the Bank

Use the last confirmed stage to decide who owns the next investigation.

Contact the Processor First When

Contact processor or acquirer support when:

• Batch does not appear in processor reporting
• Settlement never completed
• Settlement status is unclear
• No funding ID exists
• Funding is held
• Expected net amount appears wrong
• A reserve or chargeback adjustment is unexplained
• Processor reporting says the ACH was not transmitted
• Destination account information appears incorrect

The processor is better positioned to explain the card-settlement-to-funding side.

Contact the Bank When

Bank investigation becomes more appropriate when:

• Processor confirms funding was released
• Processor confirms ACH transmission
• Destination account is correct
• Exact funded amount is known
• ACH trace/reference is available
• No corresponding bank credit can be found

Provide the bank with the trace, amount, date, and originator information.

When Both Parties May Be Needed

If the processor says the ACH completed but the bank cannot locate it, both parties may need to investigate their respective records.

A reasonable escalation path is:

Store/Finance → Processor Support → Settlement/Funding Team → Bank Treasury/ACH Team

Keep one controlled incident record rather than creating repeated unrelated support tickets.

Date	Funding ID	Issue	Support Case	Owner	Resolution
—	F-xxxx	ACH sent/no bank posting	Case ####	Finance	Open

Record every contact, case number, action, and resolution.

First-Time Funding, Bank Changes, and Processor Migrations

A missing deposit deserves extra configuration review when it occurs immediately after a major account change.

High-risk transition events include:

• New merchant account
• Processor switch
• MID change
• New bank account
• Routing-number change
• Gateway migration
• New ecommerce channel
• Location migration

During a processor cutover, reconcile both environments:

Old Processor Funding + New Processor Funding

Do not turn off reporting access to the old platform before confirming that its open batches, pending funding, refunds, and disputes have been accounted for.

Holiday or weekend timing can further complicate migration because sales, settlement, funding creation, and bank posting may fall on different dates.

For the first live funding after any bank-account change, verify:

Correct Location → Correct MID → Correct Funding ID → Correct Destination Account → Successful Bank Posting

Only then should finance consider the funding configuration operationally validated.

PCI DSS and Bank-Data Security During Settlement Troubleshooting

A settlement reconciliation investigation ordinarily needs transaction and funding identifiers—not full cardholder data.

Use:

• Batch IDs
• Settlement IDs
• Funding IDs
• Masked transaction references
• Dates
• Amounts
• MID
• Masked bank account references
• ACH trace information

Avoid exporting full PAN simply to reconcile merchant deposits.

PCI SSC guidance states that sensitive authentication data such as card verification values cannot be stored after authorization, even if encrypted. PCI DSS also imposes protections around PAN storage and display.

Bank information deserves similar operational discipline. Do not circulate full settlement-account details, online-banking credentials, or sensitive authentication information in unsecured email threads or broad-access spreadsheets.

Use the bank account’s last four digits where that is sufficient.

Restrict bank-change permissions, require MFA where supported, maintain audit logs, and independently confirm high-risk account changes.

Preventing Future Missing-Deposit Incidents

The best response to delayed merchant funding is a daily exception process that detects the problem before cash-flow planning depends on the deposit.

Every morning, finance should confirm:

• Prior batches exist
• Processor received them
• Settlement statuses are expected
• Funding IDs were created
• Expected net funding was calculated
• Bank postings appeared
• Differences were explained
• Exceptions have owners

Where supported, configure alerts for:

• Missing batch
• Failed batch close
• Settlement remaining unfunded
• Funding amount outside the company’s tolerance
• Missing expected bank posting
• Bank-account change
• Funding hold

Maintain a Location-to-MID Master File

For multi-location merchants, keep:

Location → MID → Processor → Funding Account

Add channel information if card-present, ecommerce, mobile, or other processing streams use separate merchant accounts.

Update the file whenever:

• A store opens or closes
• A MID changes
• Processor migration occurs
• Bank instructions change
• Payment channel changes

Strengthen Bank-Change Controls

Settlement-account changes should require:

• Restricted user permissions
• MFA
• Independent approval or confirmation
• Audit logging
• Effective-date documentation
• First-funding verification

A fraudulent or erroneous funding-account change can create a far more serious incident than a routine timing delay.

Keep Processor Reporting Access

Finance users should retain enough portal access to view settlement and funding reports while avoiding unnecessary administrator privileges.

The finance function should be able to answer:

• Did the batch settle?
• Which funding ID contains it?
• What amount was funded?
• Which adjustments changed the amount?
• Where was funding directed?
• Was transmission completed?

That information turns payment reconciliation exceptions into auditable operational events.

Common Missing Deposit Mistakes

Several mistakes repeatedly slow merchant funding troubleshooting.

Avoid:

• Assuming “batch approved” means cash reached the bank
• Checking only the POS
• Treating authorization as settlement
• Treating settlement as bank posting
• Comparing gross POS sales directly to a net deposit
• Ignoring refunds
• Ignoring chargebacks
• Ignoring reserves and holds
• Ignoring cutoff timing
• Forgetting weekend or holiday effects
• Assuming one batch always equals one deposit
• Failing to locate the funding ID
• Overlooking recent bank changes
• Calling the bank without a useful ACH reference when one is available
• Sending unnecessary cardholder data to support
• Opening repeated tickets without preserving prior case numbers
• Reconciling only at month-end
• Treating settlement date and bank-posting date as identical

The strongest operational habit is still:

Do not ask only, “Where is the deposit?” Ask, “At which stage did the money stop progressing?”

Missing Merchant Deposit Checklist

Check	Verified?
Batch closed	☐
Batch ID recorded	☐
Processor received batch	☐
Settlement ID found	☐
Settlement status confirmed	☐
Funding ID found	☐
Expected net funding calculated	☐
Fees reviewed	☐
Refunds reviewed	☐
Chargebacks reviewed	☐
Reserves/holds reviewed	☐
Other adjustments reviewed	☐
Processor cutoff checked	☐
Weekend/holiday timing checked	☐
Destination bank verified	☐
ACH transmission checked	☐
ACH trace/reference obtained where available	☐
ACH return/reject checked	☐
Bank posting searched	☐
Processor support case opened if needed	☐
Resolution reconciled to accounting records	☐

Questions to Ask the Processor, Bank, and Finance Team

A good investigation depends on precise questions.

Ask the processor:

• Did this batch actually settle?
• What is the settlement ID?
• What funding ID contains this settlement?
• What exact net amount was released?
• When was funding released?
• Did the batch fall after the merchant’s applicable cutoff?
• Were refunds, fees, chargebacks, reserves, or adjustments deducted?
• Is any amount being held?
• Which masked destination account received the funding instruction?
• Was the ACH transmitted?
• Was it returned or rejected?
• What ACH trace/reference is available?
• What does your portal’s “settled” status specifically mean?
• Does this funding record combine multiple batches?
• Which report should finance use as the authoritative processor funding report?

Ask the bank:

• Can you locate an ACH credit for this amount and approximate date?
• Can you search using the ACH trace/reference?
• Was the credit rejected or returned?
• Is the account currently able to receive ACH credits?
• Is there a posting exception?
• Could the entry appear under another processor or originator descriptor?

Finance should be able to answer:

• Which batch is expected to fund?
• What is its settlement ID?
• What is the expected net amount?
• Which MID and location own it?
• Which bank account should receive it?
• Are multiple batches aggregated?
• Were adjustments deducted?
• Who owns the exception?
• Has the final resolution been reconciled in the GL?

Frequently Asked Questions

Conclusion

An approved batch does not prove that cash is available in the merchant’s bank account. Authorization, capture, batch close, settlement, funding creation, ACH transmission, and bank posting are distinct events, and successful troubleshooting requires verifying them in order.

When investigating a missing merchant deposit, follow:

POS → Processor → Funding → Bank

Confirm the batch ID, settlement ID, funding ID, net funded amount, applicable deductions, timing, destination bank account, ACH status, and bank posting. Then escalate the case with documented evidence rather than assumptions.

Daily settlement reconciliation makes this process far easier. A merchant that routinely maps POS Sales → Batch → Settlement → Funding → Bank → GL can distinguish routine timing differences from genuine payment reconciliation exceptions quickly and maintain a clear audit trail.

Payment, banking, and accounting disclaimer: Funding schedules, cutoff times, settlement terminology, reserve arrangements, ACH processing details, return procedures, and bank-posting practices vary. 

Merchants should verify account-specific requirements with their processor or acquirer and bank and consult qualified finance or accounting professionals regarding accounting treatment.