Quick answer: a merchant-settlement engine converts card activity into the net amount actually deposited into a merchant’s bank account. It begins with captured or settled sales, subtracts refunds and credits, subtracts interchange/network/processor fees and dispute-related debits, applies any reserve or holdback rules, adds or subtracts adjustments, then groups the result into funding batches. The final deposit must reconcile both to transaction-level activity and to the merchant’s bank statement.

Settlement is the arithmetic that explains why “we sold S$100,000” and “S$96,742 arrived in the bank” can both be true.

Boundary: this article explains public card-acquiring and merchant-funding mathematics. Exact fee schedules, reserve terms, funding timelines and dispute rules vary by processor, acquirer, merchant contract, card network and jurisdiction.

Why this belongs in mathematics

Merchant settlement combines aggregation, netting, timing, fee decomposition, rolling balances and reconciliation. It also highlights a recurring financial-system principle: revenue recognition, card transaction settlement and cash availability are different states.

Current Visa Acceptance reconciliation documentation separates post-transaction data into settlement, funding, fee, refund/credit and dispute records so merchants can reconstruct the amount that should arrive in their bank account. See Visa Acceptance — Reconciliation Data Specification.

1. Authorised is not settled

A card transaction commonly moves through:

authorisation → capture → settlement → funding.

An authorisation reserves spending capacity. Capture tells the acquiring stack to collect the money. Settlement moves the transaction through the payment system. Funding is when net cash reaches the merchant.

A merchant therefore should not treat authorised volume as immediately withdrawable cash.

2. Gross sales are only the starting point

Let captured sales for funding batch d be:

GrossSales_d = Σ captured sale amounts eligible for settlement.

If the merchant captured S$100,000, that is the gross transaction value entering the settlement calculation—not necessarily the bank deposit.

3. Refunds reduce future merchant cash

A refund occurs after a transaction was captured or settled and sends value back toward the cardholder.

Visa Acceptance currently distinguishes refunds/credits from pre-settlement voids: a void cancels an eligible pending transaction before settlement, while a refund follows a captured or settled transaction and creates a financial outflow. See Visa Acceptance Payment Center User Guide.

For batch d:

NetAfterRefunds = GrossSales − Refunds/Credits.

4. Fees form a stack, not one number

Merchant economics can include:

interchange;
network assessments and processing fees;
acquirer/processor markup;
gateway or service fees;
per-item fees;
cross-border or currency fees;
dispute/chargeback fees;
other contracted adjustments.

The final payout engine should therefore keep fee components typed rather than post one unexplained “merchant fee”.

For broader fee economics, see How Merchant-Acquiring Pricing Algorithms Turn Card Transactions into Fees.

5. A simple payout identity

A useful generic equation is:

NetPayout = GrossSales − Refunds − Chargebacks − Fees − ReserveHold + ReserveRelease ± Adjustments.

This is only the start. Timing determines which day’s settlement each item belongs to.

6. A worked payout example

Suppose a funding cycle contains:

gross settled sales: S$100,000;
refunds: S$2,000;
chargebacks: S$500;
interchange/network/acquirer fees: S$2,300;
rolling-reserve hold: S$1,000;
reserve release from an older cohort: S$600;
miscellaneous credit adjustment: S$100.

Then:

100,000 − 2,000 − 500 − 2,300 − 1,000 + 600 + 100 = S$94,900.

The merchant can therefore have S$100,000 of gross card sales but receive a S$94,900 funding deposit for that batch.

7. Rolling reserves are delayed merchant cash

An acquirer may retain a percentage of sales as a reserve against future chargebacks, refunds or merchant failure risk.

Let reserve rate r and eligible settled volume V:

ReserveHold = r × V.

If 10% of S$50,000 is held, S$5,000 enters the reserve ledger rather than the current merchant payout.

Later releases should be tied to the original reserve cohort and release schedule so one batch’s liquidity can be distinguished from another’s.

8. Funding delay creates a time dimension

A transaction can settle today but fund tomorrow or later depending on processor schedules, weekends, holidays, risk holds and banking cut-offs.

The system should preserve:

transaction/capture date;
settlement date;
processor funding date;
bank value date;
actual bank posting date.

These dates are not interchangeable. A business can be profitable but temporarily cash-constrained because settlement-to-funding latency grew.

9. Chargebacks can hit after the original sale funded

A dispute can debit the merchant days or weeks after the original transaction. That means today’s payout may include deductions related to old sales.

A reconciliation system must therefore preserve the link:

original transaction ↔ dispute ↔ provisional debit ↔ representment/final decision ↔ funding adjustment.

For the dispute mechanics, see How Card-Dispute Algorithms Route Chargebacks.

10. Fee timing can differ from transaction timing

Some fees are netted daily; others can be billed monthly or posted as separate debits. A merchant expecting:

daily sales − daily fees = bank deposit

can be wrong if the acquirer bills part of the fee stack later.

The settlement engine should therefore classify each fee by recognition and funding treatment.

11. Funding files should reconstruct the deposit

Visa Acceptance’s current reconciliation specification includes separate Reconciliation, Funding Detail, Deposit Summary, Fee Detail and Dispute Detail records. A related current support procedure expresses the practical reconciliation as:

Gross Sales − Refunds/Credits − Interchange & Assessment Fees − Processing Fees = Expected Net Amount

with the expected net amount reconciled to deposit detail and the merchant’s bank statement, subject to chargebacks, fee reversals and other adjustments.

See Visa Acceptance — merchant funding reconciliation procedure.

12. Settlement reconciliation is a three-level problem

Transaction level: did each captured sale/refund/dispute have the correct outcome?
Batch level: do the included transactions and fees sum to the funding amount?
Bank level: did that funding amount actually arrive on the merchant statement?

A merchant can pass one level and fail another. For example, processor records can sum correctly while the bank deposit is missing.

13. Multi-currency settlement needs separate ledgers

If sales occur in EUR but the merchant is funded in SGD, the payout engine may also need an FX conversion layer.

Useful fields include:

transaction currency;
settlement currency;
gross transaction amount;
conversion rate;
FX fee/spread where applicable;
settlement-currency payout.

Currency conversion should be explained separately from acquiring fees so the merchant can identify whether a variance came from FX or card economics.

14. Negative settlement is possible

If a quiet sales day is followed by large refunds and chargebacks, the settlement equation can become negative.

Example:

sales: S$5,000;
refunds: S$4,000;
chargebacks: S$2,000;
fees: S$300.

Net = −S$1,300.

The processor/acquirer may offset the debit against future funding, draw from reserve, debit the merchant account, or use another contractual method. Negative net settlement is therefore a legitimate state the engine must represent explicitly.

15. Creative-work lens: a restaurant till versus the bank bag

A restaurant can ring S$10,000 of sales during the day, issue S$300 of refunds, pay platform fees, hold money for a disputed bill and deposit a smaller amount at night. Merchant settlement is the card-system version of reconciling the till with the bank bag.

16. The merchant-settlement pipeline

Collect captured/settled sales by merchant and currency.
Subtract linked refunds and credits.
Apply chargebacks/dispute debits and reversals.
Calculate interchange, network, processor and service fees.
Apply reserve holds and releases.
Apply other credits/debits and contractual adjustments.
Convert settlement currency where applicable.
Group transactions into funding batch.
Calculate expected net payout.
Generate funding/deposit detail.
Compare expected payout with actual bank deposit.
Age and repair settlement breaks.

17. Failure modes

Authorisation=funding assumption. Pending card activity is treated as cash.
Gross-sales accounting. Refunds, fees and disputes are ignored.
Reserve invisibility. Held merchant cash is not separately tracked.
Timing collapse. Capture, settlement and bank-posting dates are treated as one date.
Old-dispute confusion. Current payout variance cannot be traced to a prior transaction.
Fee-stack collapse. One opaque deduction prevents cost diagnosis.
Negative-settlement denial. Engine assumes payouts cannot fall below zero.
Bank-level blind spot. Processor report is accepted even when bank deposit never arrives.

18. Diagnostics and falsifiers

Can every deposit be reconstructed from transaction and fee detail?
What percentage of gross sales becomes funded cash by merchant segment?
How much cash is currently held in reserve?
Which settlement batches age beyond expected funding time?
How much of payout variance comes from refunds, disputes, fees or FX?
Can every chargeback debit be linked to an original transaction?
Do processor funding records equal the bank statement amount to the minor unit?
How often does settlement become negative and how is it funded?

Suppose someone claims, “Sales were S$100,000, so the processor owes us S$100,000 today.” A falsifier is a settlement batch containing refunds, chargebacks, fees, reserve holds and funding delays. Gross sales and current payable cash are different state variables.

Research anchors

The deeper lesson

Merchant settlement is the mathematics of turning activity into cash. Gross sales create the starting claim. Refunds and disputes reverse part of it. Fees price the payment service. Reserves shift some cash into the future. Funding schedules decide when the merchant can actually use the money. A strong settlement engine therefore never asks only, “How much did the merchant sell?” It asks, “Which transactions became final, which obligations offset them, what amount should be funded now, and can that amount be reconstructed exactly from the deposit back to the underlying events?”

Educational note: This article explains public acquiring and settlement concepts. It is not merchant-services, accounting or legal advice.

Small Group Tutorials

How Merchant-Settlement Algorithms Calculate Payouts: Gross Sales, Refunds, Chargebacks, Fees, Rolling Reserves, Funding Delays and Reconciliation