Home/Research library/Operations That Don’t Scale

Guide · Reconciliation and reporting

Why Transactions Do Not Match Settlements

Yesterday's captured payments total: $1,000,000 The settlement report shows: $947,000 Is $53,000 missing? Maybe. But before opening a provider escalation, finance should answer twelve other questions. That is the central idea behind understanding why transactions do not match set

Source-imported researchEditorial verification pending

Research draft awaiting independent review. This material was adapted from an existing research library. Provider-specific promotions have been excluded automatically; facts, regulatory requirements, and conclusions must be verified before the page is indexed publicly.

Why Payment Transactions Do Not Match Settlements: 12 Causes Merchants Should Check

Yesterday's captured payments total:

$1,000,000

The settlement report shows:

$947,000

Is $53,000 missing?

Maybe.

But before opening a provider escalation, finance should answer twelve other questions.

That is the central idea behind understanding why transactions do not match settlements.

A payment settlement mismatch is not automatically evidence of missing funds, a PSP error, or failed reconciliation. A correctly processed transaction can legitimately appear different from a settlement because the two records may represent different populations, lifecycle stages, dates, currencies, or financial events.

The purpose of reconciliation is therefore not to force:

captured transactions = settlement

in every report.

It is to determine whether the difference is:

expected

explainable

a timing difference

or:

a genuine reconciliation exception.

Are you comparing the same transaction population?

Start here because every calculation that follows is useless if the populations differ.

Before comparing a transaction total with a settlement total, align:

merchant legal entity;

merchant account or MID;

PSP/acquirer;

currency;

payment method;

relevant market;

date range.

The brief makes population alignment the first branch of the Settlement Mismatch Diagnostic Tree for exactly this reason.

Suppose a merchant's internal transaction report includes:

PSP A + PSP B

but the settlement file belongs only to:

PSP A.

The totals should not match.

Likewise, combining several legal entities or settlement currencies before reconciling them can create an apparent discrepancy that exists only because unlike populations were aggregated.

This is where a useful idea from the first draft survives:

Reconcile provider relationships individually before combining them.

The deeper mechanics of consolidating providers belong in Multi-PSP Reconciliation. Here, the diagnostic rule is narrower:

Prove population equivalence before investigating amount variance.

Are you comparing the same payment lifecycle stage?

A transaction can have several monetary states.

They are not interchangeable.

For example:

Authorized amount

→ Captured amount

→ Settlement-eligible amount

→ Settled amount

→ Payout amount

→ Bank-received amount

The brief explicitly prohibits assuming:

authorized = captured

captured = settled

or:

settled = bank receipt.

If finance compares authorized transaction value against settlement value, the mismatch may simply reflect authorizations that:

expired;

were voided;

were partially captured;

were never captured.

For settlement reconciliation, the better starting population is usually the relevant captured or otherwise settlement-eligible payment activity, according to the payment method and provider model.

A payment report labelled “transactions” is therefore not enough.

Ask:

Which transaction state does this report actually represent?

Are transaction date and settlement date measuring the same period?

One of the strongest sections in Version 1 was its warning against comparing:

today's transactions

with:

today's settlement

as though they necessarily belong together.

They may not.

Payment systems can use different timestamps for:

transaction initiation;

authorization;

capture;

provider processing;

settlement;

settlement batch;

payout;

bank credit.

They may also use different time zones and cut-offs. A payment near midnight or month-end can legitimately belong to different reporting dates across systems.

Consider a hypothetical provider whose relevant settlement cut-off occurs before the merchant's reporting day ends.

A payment captured after that cut-off might appear in:

Monday's transaction activity

but:

Tuesday's settlement batch.

Nothing is necessarily missing.

The reports are using different time bases.

Are cut-offs, batching, weekends, or holidays shifting settlement?

Settlement does not always group activity according to the merchant's calendar.

Providers may batch activity according to factors such as:

cut-off time;

merchant account;

payment method;

currency;

settlement schedule;

acquiring relationship.

The consequence is important:

One calendar day of sales does not necessarily equal one settlement batch, and one settlement batch does not necessarily equal one calendar day of sales.

That distinction is part of the brief's settlement-batching discipline.

Weekends and non-business days can make the visual mismatch more obvious.

Several processing dates may later appear in one batch.

Or a transaction expected to settle after a normal lifecycle delay may still be waiting when today's report is produced.

That is a timing difference, not yet a true exception.

Are you comparing gross transactions with net settlement?

This is often the simplest explanation.

Imagine:

Gross eligible payment proceeds: $1,000,000

Then the settlement includes:

$18,000 of refunds;

$12,000 of fees;

$8,000 of chargeback-related deductions;

$10,000 of reserve movement;

$5,000 of other net adjustments.

The resulting amount is:

$947,000

The missing $53,000 was never actually missing.

The merchant compared a gross activity measure with a net financial measure.

The brief distinguishes gross and net settlement explicitly and recommends constructing a settlement bridge rather than expecting gross payment activity and payout cash to equal one another.

A conceptual settlement bridge

A useful diagnostic model is:

Opening/provider balance

eligible transaction proceeds

− refunds

− applicable fees

− chargeback/dispute amounts

± adjustments

± reserve movements

± FX/conversion effects

= expected available settlement/payout amount

The exact bridge must reflect the provider's actual settlement model.

Do not turn this conceptual formula into a universal accounting rule.

Are transaction fees being deducted from settlement?

Version 1 correctly identified fees as an obvious source of net settlement difference, but its language should be slightly more precise.

Not every provider deducts every fee from every settlement in the same way.

Potential payment costs can include, depending on the arrangement:

fixed transaction charges;

percentage charges;

payment-method charges;

acquiring/provider charges;

network or interchange components where separately exposed;

cross-border charges;

FX/conversion charges;

dispute-related charges;

payout charges;

other adjustments.

The merchant first needs to establish:

Which fee?

Charged by whom?

Against which transaction or batch?

In which currency?

When?

Was it deducted from settlement or invoiced elsewhere?

The brief requires those distinctions and specifically warns against guessing fee decomposition where provider reporting does not expose it.

So if settlement is lower than transaction value, do not create one line called:

Fees: $X

unless the provider record actually supports that classification.

Did refunds occur in a different period from the original sale?

The original transaction and its refund can live in completely different reporting periods.

Suppose:

Original sale: June 15

Original settlement: June 18

Customer refund: August 4

The August settlement may be reduced by an event linked to June's sale.

If finance compares:

August sales

against:

August settlement

without separately representing the June-originated refund, August appears short.

But the financial event is explainable.

This is one of the most useful pieces of Version 1 because it explains why calendar-period comparison alone can fail.

A good record should link:

original payment

→ refund event

→ refund amount

→ provider record

→ settlement effect.

Partial and multiple refunds make this relationship even more important.

Did a chargeback or dispute affect the current settlement?

Chargebacks create a similar cross-period problem.

A customer can dispute a transaction long after the underlying sale was processed and settled.

The later financial record may contain:

disputed amount;

chargeback amount;

dispute-related fee;

reversal;

recovery;

representment-related adjustment where relevant;

final outcome.

Those events should remain linked to the original transaction even though their settlement effects occur later.

This is why:

current settlement

cannot always be explained solely by:

current-period sales.

The detailed workflow for these financial adjustments belongs in Reconciling Fees, Refunds and Chargebacks.

For mismatch diagnosis, the question is simply:

Did a later dispute event alter this settlement?

Is a reserve or holdback being mistaken for a fee?

Version 1 also makes an important distinction here.

A reserve is not automatically a processing expense.

Depending on the merchant/provider arrangement, funds may be:

temporarily withheld;

added to a rolling reserve;

released from a previous reserve;

adjusted;

offset.

That movement can reduce cash available for payout without being economically equivalent to a transaction fee.

The brief therefore requires merchants to report:

processing expense

separately from:

restricted or held funds.

If a settlement is consistently below transaction proceeds, ask:

Is this fee expense?

or:

Is this a movement into held/reserved funds?

They answer different finance questions.

Did the currency change between transaction and settlement?

A transaction can involve multiple currency states:

Presentment currency

Processing currency

Settlement currency

Payout currency

Bank-account currency

and potentially:

merchant accounting currency.

The amounts should not be compared blindly across those currencies.

Suppose a customer pays in one currency while the merchant settles in another.

A mismatch can result from:

the actual conversion rate used;

conversion timing;

rounding;

provider FX logic;

separately reported or embedded conversion charges where applicable.

The first draft said the settlement conversion would “virtually never” equal a naive transaction-time conversion.

That is unnecessarily absolute.

The stronger rule is:

Never classify a cross-currency difference as unexplained until you identify where conversion occurred, which rate was applied, and which currency each amount represents.

Was the captured amount different from the original transaction amount?

Another useful Version 1 point is the distinction between authorization and capture.

A payment can begin with one amount and later produce another.

For example, a hypothetical transaction could be:

Authorized: $100

Captured: $92

If finance uses the authorized amount while settlement reflects the captured amount, the $8 difference is not a settlement error.

It is a lifecycle difference.

The same principle applies to:

partial captures;

multiple captures where supported;

partial refunds;

reversals.

The brief explicitly requires partial captures and refunds to remain separate mismatch categories.

The diagnostic question is:

Which amount became settlement-eligible?

Not:

What amount first appeared in the payment system?

Is the payment method asynchronous—or did data arrive late?

Not every payment reaches final state during checkout.

Some payment methods can remain pending while the customer completes another step or while confirmation arrives later.

The brief instructs merchants to account for:

delayed confirmation;

expiry;

abandonment;

provider callback;

polling;

late success.

A pending transaction should therefore not automatically become a reconciliation exception before its expected lifecycle window has elapsed.

Late-arriving records can also include:

provider corrections;

settlement files;

refunds;

chargebacks;

reserve releases;

payout adjustments.

Payment data is not necessarily final merely because checkout has ended.

This is particularly important when reconciliation runs faster than the underlying payment method reaches final settlement state.

What about retroactive corrections and adjustments?

The first draft called out retroactive fee adjustments, and that concept is worth preserving—but as a broader adjustment category.

Providers or payment systems may produce later records that correct or adjust previously reported financial activity.

Do not automatically classify the new value as:

unexplained fee

or:

missing cash.

Look for a corresponding:

adjustment record;

correction;

reference;

settlement-line description;

provider explanation.

The key control is lineage:

Can this later adjustment be traced back to the financial event it changes?

If not, the record may deserve escalation even if the amount is small.

When does a settlement mismatch become a true exception?

Only after normal lifecycle explanations have been eliminated.

The brief defines a timing difference as something expected to reconcile after a normal lifecycle delay.

Examples include:

captured transaction not yet settled;

settlement shifted by a non-business day;

later-period refund;

later-period chargeback.

A true reconciliation exception violates the expected matching or financial logic.

Examples include:

Missing settlement record

A transaction is past its expected eligibility/timing window and no corresponding settlement record can be found.

Duplicate settlement

The same financial event appears to have been settled more than expected.

Incorrect amount

The settlement amount cannot be explained by capture, refund, fee, FX, reserve, or adjustment records.

Unexpected fee

A deduction is present but cannot be mapped to known provider terms or a documented fee event.

Wrong currency

The currency state is inconsistent with expected settlement configuration.

Unknown transaction

Settlement contains a transaction the merchant cannot associate with known payment activity.

Broken identifier mapping

The records may exist, but the merchant cannot deterministically connect them.

These deserve investigation.

Normal settlement timing should not be allowed to flood the same exception queue.

The Settlement Mismatch Diagnostic Tree

Use this sequence before escalating a discrepancy.

TRANSACTION TOTAL ≠ SETTLEMENT TOTAL

SAME POPULATION?

Entity / MID / PSP / currency /

payment method / date scope

+-- NO --> Correct population

v YES

SAME LIFECYCLE STAGE?

Authorization / capture /

settlement-eligible / settlement

+-- NO --> Align lifecycle stage

v YES

SAME TIME BASIS?

Timezone / processing date /

cut-off / batch / settlement date

+-- NO --> Classify timing difference

v YES

GROSS OR NET?

Fees / refunds / chargebacks /

reserves / adjustments

+-- EXPLAINED --> Reconcile bridge

v NOT EXPLAINED

SAME CURRENCY?

This framework follows the diagnostic sequence required by the brief.

The difference between “unmatched” and “not yet matchable”

This is a useful operational distinction.

Suppose a captured payment has an expected settlement delay.

Immediately after capture, the corresponding settlement record does not exist.

Calling it:

unmatched

can create needless manual work.

A more useful state is:

Pending expected settlement

Then, once the expected timing window expires without the required record, it can become:

Missing settlement — investigate.

The brief specifically recommends richer reconciliation states rather than reducing every record to binary matched/unmatched.

That one change can significantly improve the quality of exception queues.

Do not reconcile only by batch totals

Another useful principle from Version 1 deserves to survive:

Large-number comparison tells you that a difference exists. Transaction-level or event-level lineage tells you why.

Suppose:

Transactions: $1,000,000

Settlement: $947,000

A spreadsheet can calculate:

Variance: $53,000

But that tells the operator almost nothing.

A useful reconciliation system should instead be able to attribute the difference:

Cause

Value

Refunds

$18,000

Fees

$12,000

Chargebacks

$8,000

Reserve movement

$10,000

Adjustments

$5,000

Unexplained

The important number is not the initial variance.

It is:

unexplained variance after expected financial events have been classified.

Preserve identifiers across the payment lifecycle

Diagnosing mismatches becomes much harder when the transaction and settlement systems cannot identify the same payment.

Potential useful identifiers include:

merchant order ID;

merchant payment ID;

payment attempt ID;

PSP transaction ID;

capture ID;

refund ID;

dispute ID;

settlement ID;

settlement batch;

payout ID;

MID;

merchant entity;

currency.

No single identifier should be assumed to survive every payment lifecycle stage.

Where a deterministic provider transaction ID or settlement reference exists, use it.

Where direct identifiers do not survive, controlled mappings may require combinations of:

provider;

amount;

currency;

merchant account;

timestamp;

batch;

merchant reference.

Do not make fuzzy matching the default if stronger deterministic linkage should exist.

What should merchants measure?

The article brief specifies a small diagnostic measurement set.

Settlement mismatch value

Total value initially failing the expected transaction-to-settlement comparison.

This is not necessarily loss.

Percentage explained automatically

Possible internal definition:

Mismatch value automatically classified as known timing/financial differences

total mismatch value eligible for classification

Define the denominator.

Timing-difference value

Value that remains unmatched only because the expected lifecycle is incomplete.

True exception value

Value remaining unexplained after normal settlement logic is applied.

This is usually more important than the original mismatch total.

Root-cause distribution

What proportion of mismatch value is explained by:

timing;

fees;

refunds;

chargebacks;

reserves;

FX;

lifecycle variation;

provider adjustments;

genuine exceptions?

Exception aging

How long does a true exception remain unresolved relative to its expected lifecycle and materiality?

Recurring provider-specific categories

Are the same unexplained differences repeatedly associated with:

one PSP;

MID;

currency;

payment method;

settlement batch;

report format?

That can expose a configuration, data, or provider-reporting problem.

When should finance contact the PSP?

Not when:

transaction total ≠ settlement total.

Escalate when the merchant has first established the relevant evidence.

A strong provider escalation can say:

“Capture ID X for EUR 4,250 was settlement-eligible under our expected process before Batch Y. We have checked the related refund, dispute, fee, reserve, adjustment, and FX records and cannot identify a corresponding settlement entry. The record is now outside the expected settlement window.”

That is much more actionable than:

“Our payout is short.”

Before escalation, capture:

transaction/provider identifier;

expected amount;

currency;

capture date;

expected settlement context;

settlement batch if applicable;

relevant fees/refunds/disputes;

existing adjustment records;

mismatch classification.

The diagnostic process should remove explanations, not simply accumulate suspicion.

That supports a restrained commercial conclusion:

Useful payment reporting should make the difference between processed value and settled value explainable through identifiable transaction and financial records rather than leaving finance with one unexplained variance.

I would not carry forward the first draft's Moment Treasury statement without current first-party verification of the exact product and its reconciliation/settlement capabilities.

A mismatch can be correct

The mistake is not having a difference.

The mistake is being unable to explain it.

A $53,000 gap between captured payments and settlement might be:

fees

refunds

chargebacks

reserves

a later settlement batch

or:

a genuine missing financial record.

Those situations should not live in one bucket called:

settlement discrepancy.

The merchant should first prove:

same population

→ same lifecycle stage

→ same time basis

→ gross versus net treatment

→ same currency

→ expected lifecycle variations.

Only then does the unexplained remainder deserve to be treated as a true exception.

That is the practical answer to why transactions do not match settlements:

Do not ask why two totals are different until you have established that they were supposed to be equal in the first place.

🙂 🙂 🙂 🙂 🙂 🙂 🙂

I used the first draft as a copy and SEO asset, not as the controlling structure. The strongest material worth preserving is its plain-English treatment of gross vs. net, settlement timing, FX, refunds/chargebacks, reserves, partial captures, multi-PSP segmentation, and the principle that transaction-level explanation matters more than comparing two totals. The controlling brief sharpens that into a diagnostic article whose central point is: a mismatch can be correct; reconciliation needs to classify the difference before escalating it.

Brief interpretation

Article-owned problem: Finance sees captured transaction value and a lower settlement/payout amount and assumes funds are missing.

Evidence anchor: A settlement mismatch can be expected, explainable, incorrectly timed, or genuinely anomalous.

Editorial position: Do not escalate a discrepancy until population, lifecycle stage, timing, gross/net treatment, currency, and financial adjustments have been checked.

Common assumption challenged: “If captured transactions total X, the PSP should settle exactly X.”

Format: Progressive settlement mismatch diagnostic investigation, eliminating normal explanations before declaring a true exception.

SEO / VISUAL / EDITORIAL NOTES — NOT PART OF THE ARTICLE

What I preserved from Version 1 for SEO

The first draft already contained strong topical coverage for the search intent. I retained and sharpened:

gross vs. net;

settlement timing;

weekends/holidays;

payment-method timing;

FX;

refunds crossing reporting periods;

chargebacks crossing reporting periods;

reserves/holdbacks;

multi-PSP fragmentation;

partial captures;

later adjustments;

transaction-level reconciliation;

separate variance categories rather than one unexplained difference.

The brief explicitly says useful structure, terminology, and examples from the existing article should be preserved instead of rewriting blindly.

The main change is sequence: Version 1 listed explanations; the optimized version turns them into a narrowing diagnostic investigation.

SEO metadata

Why Transactions Do Not Match Settlements: 12 Causes

Alternative:

Why Payment Transactions and Settlements Don't Match

I recommend the first. It has:

the near-exact primary keyword;

a concrete troubleshooting promise;

list-intent appeal without turning the body into a shallow checklist.

Why Payment Transactions Do Not Match Settlements: 12 Causes Merchants Should Check

Meta description

Transactions do not match settlements for many legitimate reasons. Diagnose timing, net fees, refunds, chargebacks, reserves, FX, partial captures and true settlement exceptions.

URL slug

/why-transactions-do-not-match-settlements/

Full cluster path if desired:

/solve/operations-that-dont-scale/reconciliation-reporting/why-transactions-do-not-match-settlements/

transactions do not match settlements

Secondary keywords

payment settlement mismatch

transaction settlement mismatch

why payment settlement is lower

payment reconciliation mismatch

settlement amount does not match transactions

PSP settlement mismatch

net settlement difference

payment payout mismatch

payment settlement discrepancy

These are the assigned search targets.

Related entities

payment reconciliation

settlement reconciliation

captured amount

authorized amount

settlement eligible

settlement date

processing date

settlement batch

payout

bank receipt

net settlement

gross settlement

payment fee

refund

partial refund

chargeback

dispute

reserve

rolling reserve

holdback

FX conversion

presentment currency

settlement currency

partial capture

asynchronous payment

payment adjustment

settlement exception

PSP reconciliation

what payment reconciliation actually proves

What Is Payment Reconciliation?

transaction-to-payout matching workflow

How to Reconcile Transactions and Payouts

linking fees, refunds and disputes to original payments

Reconciling Fees, Refunds and Chargebacks

multi-currency settlement

relevant settlement/FX article

automating known timing and matching rules

Automated Payment Reconciliation

multiple providers and settlement datasets

Multi-PSP Reconciliation

Important cannibalization rule:

This article should explain why the difference exists.

The procedural “how to perform reconciliation” page should own the full matching workflow.

Measurement plan

Use the brief's seven primary metrics.

Metric

Purpose

Settlement mismatch value

Initial magnitude of the difference

Automatically explained %

How much is classified without human investigation

Timing-difference value

Value expected to resolve with lifecycle maturity

True exception value

Remaining unexplained value

Root-cause distribution

Shows what creates mismatches

Exception aging

Identifies unresolved financial risk/operational backlog

Provider-specific recurring causes

Exposes systematic data or settlement problems

I would add one supporting metric:

Mismatch explanation rate

Explained mismatch value ÷ total mature mismatch value

But do not optimize it by simply assigning every difference to a generic “adjustment” bucket.

Recommended authoritative sources

For this particular article, the most authoritative evidence is usually merchant- and provider-specific operational data, rather than generic secondary articles.

Prioritize:

Current PSP/acquirer settlement documentation.

Provider transaction export.

Settlement report/file.

Merchant agreement and applicable fee/reserve terms.

Refund/dispute files.

Payout report.

Merchant bank statement.

Payment-method documentation where asynchronous timing matters.

Approved finance/reconciliation analysis.

The brief's source hierarchy expressly prioritizes payment-system authorities, schemes, banks, official provider documentation, settlement/reporting documentation, and first-party merchant data.

Structured data

Recommended:

Article

BreadcrumbList

I would not add FAQPage solely for SEO.

The Settlement Mismatch Diagnostic Tree is the page's stronger differentiated asset.

A short visible diagnostic FAQ can still be useful without schema.

Short diagnostic FAQ

Why is my settlement lower than my transactions?

First determine whether you are comparing gross captured/settlement-eligible value with a net settlement. Then check fees, refunds, disputes, reserves, adjustments, currency conversion, and timing before treating the difference as missing funds.

Why did yesterday's payments settle today?

Transaction processing date and settlement date can differ because settlement can follow provider cut-offs, batching and method-specific lifecycle timing. The relevant provider schedule must be verified before calling the difference late.

Can refunds affect a later payout?

Yes. A refund can occur after the original transaction settled, creating a later financial adjustment. Keep the refund linked to its original payment while recording the period in which its settlement effect occurred.

Can chargebacks affect settlement?

Yes. Chargeback and dispute financial events can occur later than the original sale and can produce later settlement deductions or credits depending on the process and outcome.

Are reserves considered fees?

Not automatically. A reserve can represent temporarily held funds rather than processing expense and should be tracked separately.

When should I contact the PSP?

After confirming population, payment state, time basis, net financial adjustments, currency, and expected lifecycle timing—and when a material difference still violates the expected settlement logic.

Proposed author and reviewers

Author: Payment operations/reconciliation specialist.

Primary reviewer: reconciliation lead.

Finance reviewer: controller or payments-finance specialist.

Treasury reviewer: treasury specialist where payout/bank-receipt claims are material.

These match the expertise explicitly recommended by the brief.

Do not imply review completion until it has actually occurred.

Payment-state fact check

Before publication verify the article never implies:

authorization = capture;

capture = settlement;

settlement = payout;

payout = bank receipt;

refund = reversal;

dispute = chargeback in every context;

pending = failed;

late = missing;

transaction date = settlement date.

Settlement/payout fact check

Verify provider-specific claims for:

settlement eligibility;

settlement cut-off;

batch construction;

settlement frequency;

payout timing;

non-business-day treatment;

net/gross model;

reserve mechanics;

correction/adjustment mechanics;

payout-to-bank timing.

The brief makes these current-fact verification items and warns against relying on old provider documentation.

Fee fact check

For each fee statement verify:

fee type;

fee owner;

fee basis;

transaction/batch/invoice level;

currency;

charge timing;

whether deducted from settlement;

whether separately invoiced;

whether provider data actually exposes the component.

Do not state that interchange or network fees are directly visible unless the relevant reporting actually exposes them.

Data fact check

Before publication/implementation verify:

transaction populations are complete;

IDs are unique where assumed;

settlement batches can be linked to transaction records;

all currencies are explicit;

provider and merchant time zones are documented;

late-arriving records are supported;

corrected records are versioned appropriately;

duplicate messages are not confused with duplicate financial transactions.

The larger cluster correctly treats completeness separately from matching accuracy: a perfectly matched partial dataset can still be wrong.

Accounting boundary

The article should not prescribe:

revenue recognition;

reserve balance-sheet classification;

gross/net revenue presentation;

FX accounting;

chargeback provisions;

journal-entry policy.

It should provide traceable payment evidence so the merchant's accounting function can apply the appropriate policy.

Suggested disclaimer:

This article provides general information and does not constitute accounting, audit, legal, tax, regulatory, or financial advice. Merchants should determine appropriate accounting treatment and financial controls with qualified advisers and their internal finance/accounting teams.

The brief explicitly establishes this boundary.

Amber-flag claims

Do not publish:

“Settlement normally takes T+2.”

Provider/payment-method specific.

“Weekends always delay settlement until Monday.”

Too universal.

“All PSPs settle net.”

Incorrect as a universal statement.

“Interchange and scheme fees are always deducted before settlement.”

Depends on commercial/reporting model.

“Exchange-rate movement always causes a settlement difference.”

Only relevant where currency conversion occurs.

“A reserve is a processing fee.”

Incorrect conceptual treatment.

“All captured transactions should eventually settle.”

Needs lifecycle/provider qualification.

“An unmatched transaction means money is missing.”

Core thesis contradicts this.

“A payout report proves cash reached the bank.”

Payout-to-bank reconciliation is a separate stage.

“Multi-PSP totals should simply be combined before reconciliation.”

Reconcile compatible provider populations first.

“Automated reconciliation eliminates mismatches.”

Automation classifies/matches known patterns; exceptions still exist.

Not supported by the current public evidence reviewed.

“Moment Treasury explains every settlement line.”

Do not restore from Version 1 without current verification.

transaction Reporting API;

Settlement Reports;

merchant payout/reconciliation support;

Payout Report / Total Net Revenue concepts in current terms.

Before making stronger claims, internally verify:

settlement-report fields;

transaction-to-settlement identifiers;

batch identifiers;

fee detail available;

refund linkage;

chargeback linkage;

reserve reporting;

FX fields/rates;

payout report fields;

bank-reference availability;

automated reconciliation functionality;

exception reporting;

supported file/export formats;

reporting freshness;

Moment Treasury's current existence, naming, scope and settlement/reconciliation features.

Do not invent those fields or capabilities.

Cluster sameness audit

Field

Why Transactions Do Not Match Settlements

Opening

$1M captured vs $947k settlement

Primary audience

Finance / payments / treasury / reconciliation

Core failure

Difference misclassified as missing money

Primary object

Transaction-to-settlement variance

Format

Diagnostic investigation

Evidence anchor

A mismatch can be correct

Editorial position

Classify before escalating

Assumption challenged

Captured X means settlement must equal X

Primary framework

Settlement Mismatch Diagnostic Tree

Secondary asset

Settlement Bridge

Main distinction

Timing difference vs true exception

Primary metric

True unexplained exception value

SEO differentiator

Twelve concrete causes + narrowing diagnostic logic

Conclusion

Establish that totals should equal before treating difference as error

CTA direction

Run the diagnostic tree on unexplained settlement variance

That keeps this article clearly distinct from What Is Payment Reconciliation?, How to Reconcile Transactions and Payouts, Reconciling Fees, Refunds and Chargebacks, Multi-PSP Reconciliation, and Automated Payment Reconciliation.

Why Transactions Do Not Match Settlements

A finance team pulls up the day's transaction total, then checks the bank account, and the numbers don't line up. This is one of the most common sources of confusion in payment operations — and in the overwhelming majority of cases, it doesn't mean money is missing. It means the transaction report and the settlement report are answering two different questions, and reconciling them requires understanding exactly where and why they diverge.

The Core Reason: Gross Versus Net

The most basic mismatch is also the most common one. Your transaction report shows the gross amount a customer was charged. Your settlement is the net amount that actually lands in your bank account — after processing fees, interchange, and scheme fees have already been deducted. If you're comparing a gross transaction total to a net settlement amount, they will never match, and that's not an error — it's two different numbers by design. The fix here isn't investigation, it's making sure your reconciliation process is comparing gross-to-gross and net-to-net, with fees tracked as their own explicit line item rather than an unexplained gap.

Timing Differences

Settlement lag is normal and rarely aligns with your reporting periods. A transaction processed today might not settle for one, two, or several business days, depending on the payment method and provider. If your reconciliation compares "today's transactions" to "today's settlement," you will always see a mismatch, because today's settlement batch is actually paying out transactions from a few days ago, not today's.

Weekends and holidays compress and delay batches. A transaction processed on a Friday might not settle until the following Monday or Tuesday, and holiday periods can stack multiple days of transactions into a single delayed settlement batch. A reconciliation process that doesn't account for this will show apparent gaps around every weekend, every time, that aren't gaps at all — just timing.

Different payment methods settle on different schedules entirely. Cash and voucher-based methods, for instance, often don't settle until the customer has actually completed the offline payment step (paying cash at a retail location, for example), which can be days after the transaction was initially recorded as "pending" in your system. Comparing this against a same-day settlement expectation will always look wrong.

Currency Conversion

If a transaction is processed in one currency and settled in another, the amount that lands in your account depends on the exchange rate applied at settlement — which is virtually never the exact rate that would have applied at the moment the transaction occurred, since rates move continuously. This means even a transaction with zero fees and no other discrepancy can still settle for a different amount than a naive currency conversion of the original transaction total would suggest, purely because of the rate movement between transaction time and settlement time.

Refunds and Chargebacks Land in a Different Period Than the Original Sale

A refund issued today reduces a settlement today or in an upcoming batch — but the original transaction it's refunding may have settled weeks or months ago, in a completely different reporting period. Comparing this month's settlement to this month's gross sales without separately accounting for refunds tied to prior-period transactions will show a mismatch that has nothing to do with an error and everything to do with refund timing crossing a reporting boundary. Chargebacks behave similarly — a chargeback reverses funds from a transaction that may have settled long before the dispute was ever filed.

Reserves and Holdbacks

Some processing arrangements include a rolling or fixed reserve — a portion of each settlement withheld temporarily as a risk buffer, released later according to the reserve's terms. If a reserve is in place and not accounted for explicitly in your reconciliation model, a consistent percentage of every settlement will appear to be "missing," when it's actually just being held and will be released on a defined schedule.

Multi-PSP and Multi-Acquirer Fragmentation

Merchants running transactions across more than one PSP or acquiring relationship — common as volume grows — often receive separate settlement batches from each, on different schedules, with different fee structures and different reporting formats. Reconciling this by comparing one combined transaction report against a single settlement figure doesn't work; each provider relationship needs to be reconciled against its own settlement batches individually before the totals can be meaningfully combined.

Partial Captures and Authorization Adjustments

An authorization and the actual captured amount aren't always identical — some transaction flows authorize one amount and later capture a different (often lower) amount based on final order details. If your transaction report is tracking authorized amounts while settlement reflects captured amounts, the two will diverge in a way that looks like an error but is actually just two different stages of the same transaction lifecycle.

Retroactive Fee Adjustments

Card networks and acquirers occasionally issue retroactive adjustments — a fee correction, a reclassification, or a scheme-level adjustment applied after the fact to transactions that already settled. These show up as unexplained small discrepancies in a later settlement period tied to transactions from an earlier one, and without visibility into adjustment-specific reporting, they're easy to mistake for reconciliation errors rather than legitimate corrections.

How to Actually Reconcile This Properly

Reconcile at the transaction level, not the batch total level. Comparing one big number to another big number tells you that something doesn't match, but not why. Matching individual transactions to the specific settlement batch and fee breakdown they belong to is what actually surfaces the real cause of any gap.

Build your reconciliation window around actual settlement timing, not calendar reporting periods. A same-day comparison will show a "gap" every single day if your provider settles on a T+2 basis. The comparison needs to be structured around when a transaction is expected to settle, not simply grouped by the calendar date it occurred.

Track fees, FX, refunds, chargebacks, and reserves as separate line items, not a single unexplained variance. A reconciliation process that produces one combined "difference" number is much harder to trust or debug than one that shows exactly how much of the gap is fees, how much is FX, how much is a prior-period refund, and how much (if anything) is genuinely unexplained.

Reconcile each PSP or acquiring relationship separately before combining totals. Especially relevant for merchants running multiple providers — combine after reconciling each individually, not before.

What This Costs You If It's Not Done Well

Beyond the basic annoyance, poor reconciliation has real downstream costs: inaccurate financial reporting that finance and leadership are making decisions on, missed fee errors or overcharges that go undetected because no one is checking transaction-level detail against what was actually billed, a slower month-end close as the team manually chases down "unexplained" gaps that are actually just timing or FX, and — in the worst case — reduced ability to catch actual fraud or processing errors, because the noise from normal, explainable mismatches drowns out the signal from a genuine problem.

A Starting Checklist

Confirm whether your reconciliation is comparing gross to gross and net to net, not gross to net

Map your actual settlement timing (T+1, T+2, or longer) and build your comparison window around that, not the calendar date of the transaction

Separately track FX-driven variance for any transactions settled in a different currency than they were charged in

Confirm refunds and chargebacks are matched back to their original transaction's period, not just netted against the current period's totals

Confirm whether a reserve or holdback is in place, and whether it's factored into your expected settlement amount

If running multiple PSPs or acquirers, confirm each is reconciled individually before combining totals

Check whether any adjustments (fee corrections, retroactive reclassifications) appear in a dedicated report, or whether they're only visible as unexplained line-item variance

Need help narrowing down payment options?

Answer a few questions about your business and compare the capabilities that matter to you.

Explore matching options ↗