An operation can show “paid” at checkout and still end the day with a financial discrepancy nobody can explain. The sale was approved, capture apparently occurred, and the PSP reported success, but the expected amount is missing from settlement, appears on another date, has different fees deducted, or arrives with a reference the ERP does not recognize.
This is where reconciliation stops being an administrative activity and becomes an infrastructure discipline.
Payment reconciliation compares facts recorded in different systems to verify that they represent the same financial event. In a modern operation, this normally involves at least the business system, the payment platform, the PSP or acquirer, and financial information that arrives later, such as settlement, payout, statements, or receivables files.
The objective is not merely to “balance the books.” It is to prove that commercial, transactional, and financial states remain consistent over time.
What is payment reconciliation?
Reconciliation is the systematic comparison of records that should represent the same payment or movement of funds.
If the order system says one hundred units were sold and the payment system says ninety-eight charges were captured, a difference needs explaining. If the PSP reports ninety-eight captured charges but only ninety-seven appear in the expected financial batch, there is another difference. If net proceeds do not equal the gross captured amount minus known fees, there is a third.
Each discrepancy belongs to a different layer.
Reconciliation bridges those layers and turns differences into items that can be investigated.
Are a sale, a payment, and settlement the same thing?
No.
A sale is a commercial fact. A payment is the financial process used to collect that sale. Settlement is a later stage when funds move between ecosystem participants according to the payment method's rules, timelines, fees, and arrangements.
These concepts are related, but they do not necessarily have a one-to-one relationship.
A sale may have two payment attempts. A payment may have a partial capture. One capture may create several financial movements depending on the product and provider structure. A refund may appear days after the original sale. A dispute may arise long after a payment appeared finalized.
Reconciliation exists precisely because the financial world does not fit into a Boolean field called “paid.”
Why doesn't approval finish the job?
Because authorization only indicates that a particular attempt was accepted within the authorization flow.
Even when authorization and capture happen almost together, later stages may remain. The provider may confirm asynchronous events, consolidate batches, apply fees, advance receivables, issue payouts, and record returns.
If a company considers the payment finished upon approval, it loses the ability to verify that the later financial effect occurred as expected.
The transaction system answers, “was the payment accepted?” Reconciliation answers, “did the funds and obligations associated with this payment appear correctly afterward?”
These are different questions.
What should be reconciled first?
The first link is usually between the order and the charge.
You must be able to identify which payment belongs to which sale, subscription, reservation, or invoice. Without a stable business identifier, every subsequent investigation becomes harder.
The charge must then connect to its attempts and PSP references. Events such as capture, cancellation, refunds, and chargebacks must remain associated with that same chain.
Finally, settlement or payout records must point back to this structure.
The better the correlation from charge creation onward, the less manual reconciliation is needed at the end.
What is transaction reconciliation?
Transaction reconciliation compares what your platform believes happened with what the processor or PSP records about the transactions.
It looks for differences such as a charge marked locally as pending when the PSP already considers it paid, a locally confirmed capture without external evidence, a refund recorded in one system but missing in the other, or a transaction at the PSP with no internal match.
This layer is especially important when webhooks, timeouts, and asynchronous updates are involved.
A system can lose an event without losing the transaction. Transaction reconciliation finds and corrects that difference later.
What is financial reconciliation?
Financial reconciliation compares transaction events with the expected movement of money.
It asks whether captured amounts produced the expected receipts, whether fees were applied correctly, refunds deducted, disputes recorded, receivables advances accounted for, and net proceeds matched the known breakdown.
This stage may use files, reports, balance APIs, payout movements, or accounting records supplied by the processor.
The format varies by provider. The principle does not.
Every net amount should be explainable as the sum of identifiable movements.
What is a timing difference?
Not every discrepancy is an error.
A payment may be captured today and settled on another day. A refund requested today may affect a future payout. A holiday may change the schedule. A payment method may confirm and settle at different speeds.
Reconciliation therefore needs to understand time.
Comparing only same-day totals can produce false alarms. The platform should know the expected interval between a transaction event and its financial effect.
A timing difference is acceptable when a rule explains why the movement should not yet be present.
When the expected window closes and the event is still missing, the discrepancy changes in nature.
How should fees be handled?
Fees make comparisons between gross and net amounts less straightforward.
If a R$ 100 sale produces R$ 97.50 in net proceeds, the system must explain the R$ 2.50 difference. It may include the MDR, a fixed fee, receivables advance cost, PSP fee, tax, currency conversion, or another contractual rule.
Mature reconciliation does not treat the net amount as a black box.
It breaks the movement into components.
This makes it possible to detect fee changes, incorrect settings, duplicate charges, or commercial terms that differ from expectations.
Which reconciliation does a refund belong to?
Both.
Transactionally, you must confirm whether the requested refund was processed and how much was returned.
Financially, you must verify when and how that return affected the balance, receivables, or payout.
A refund does not disappear after the API returns success. It becomes a new financial event that must be tracked.
Partial refunds make this even more important, because a charge may retain a net amount even after several returns.
What about chargebacks?
A chargeback is an excellent example of a late event.
A sale may have been approved, captured, settled, and considered complete. Weeks later, a dispute can create a new financial movement.
If reconciliation looks only at the sale's initial lifecycle, it cannot explain why a future payout decreased.
A transaction's financial life can therefore be much longer than its checkout life.
Reconciliation must accept later events without losing their connection to the original operation.
How do you reconcile a multi-PSP architecture?
Multiple PSPs increase the challenge because each provider has different identifiers, files, schedules, balance concepts, and settlement models.
An orchestration layer may normalize the transaction domain, but reconciliation should not erase real financial differences.
Ideally, create a common internal structure for movements while preserving provider-specific fields needed to explain them.
This structure may contain the transaction reference, attempt, PSP, movement type, gross amount, fee, net amount, currency, event date, expected settlement date, actual date, and external identifiers.
The platform can then compare providers without pretending they all operate identically.
Why are IDs so important?
Because reconciliation is fundamentally a matching problem.
The more stable and widely propagated the identifiers, the less reliance on heuristics.
If an internal order or charge identifier can reach the PSP as permitted metadata or a reference, it may return in reports and webhooks, making the connection easier.
When that is not possible, the platform may need external IDs, amounts, dates, and other attributes to correlate movements.
Heuristics should be the exception.
An explicit chain of IDs is far more reliable.
Is a matching amount enough to reconcile?
No.
Two different sales can have the same amount. One sale can have a partial capture. A refund can equal another charge. A batch can consolidate multiple transactions.
Amount is a useful attribute, not an identity.
Reconciliation based only on “R$ 199.90 on the same day” works until the operation grows.
An ideal match combines identifiers and time context, using the amount as an additional check.
What is a reconciliation discrepancy?
It is a difference between records that should be consistent and cannot be explained by the rules known at that moment.
A discrepancy may be a missing event, mismatched amount, unexpected fee, duplicate, unknown reference, incompatible status, or settlement outside the expected window.
A discrepancy does not necessarily mean financial loss.
It means the system cannot yet explain what happened.
The operational goal is to reduce open discrepancies and the time needed to explain them.
How should discrepancies be classified?
A simple taxonomy helps considerably.
Differences may relate to timing, reference data, transactions, finances, integrations, or commercial rules.
A timing difference tends to resolve when the settlement window closes. A reference-data difference may indicate an incorrect ID. A transaction difference may come from a lost webhook. A financial difference may represent an incorrect fee or payout.
Classifying before investigating helps route the problem to the right team.
Without classification, every discrepancy becomes a generic ticket for finance or engineering.
Three reconciliation discrepancies, from initial signal to resolution
The following three cases are entirely fictional. Amounts, fees, and conditions were chosen to illustrate investigation; they do not represent actual contracts or results. In each case, resolution must connect the symptom, sources, hypothesis, verification, adjustment, and prevention. Closing a discrepancy means explaining its movements, not editing the balance merely to make totals match.
Case 1: approved at the PSP, pending in the order. The symptom is a R$ 150 order still awaiting payment while the external dashboard shows approval. Gather the order, attempt, authorization, and capture identifiers, where a capture exists. Confirm the amount, currency, and recipient. Before correcting the order, determine whether approved means only authorized or whether the stage required by the commercial rule has been confirmed.
The hypothesis in this example is that the event arrived but was not applied to the order. Verification finds an authorization and a confirmed R$ 150 capture for the same attempt, plus the persisted, authenticated event with a processing failure. If only authorization existed, the investigation could not conclude that capture occurred. The transaction states guide helps distinguish this evidence.
The adjustment is to reapply the existing confirmation through an idempotent transition, without submitting another capture. The order moves to the commercial state permitted by confirmed capture, while settlement continues to be tracked separately. The case closes with one R$ 150 capture, one order update, and a trail explaining the earlier failure. Transaction confirmation does not finish the subsequent financial reconciliation.
To prevent recurrence, test failures between persisting the event and updating the order, as well as reprocessing and redelivery. Record the association between event, attempt, and commercial effect. Adyen's webhook handling documentation (opens in a new tab ↗), consulted on October 22, 2026, illustrates verification and duplicate-message handling. The internal design is detailed in the payment webhooks guide.
Case 2: captured does not mean settled. The initial symptom is that two captures of R$ 400 and R$ 600 total R$ 1,000, but that total does not appear in the bank account on the same day. Gather each capture's references, the batch records, the fee assumed for this example, and the bank-transfer identifier when available. Also verify the operation's own time zone, cutoff, and calendar.
The hypothesis combines a timing difference with a gross-to-net comparison. In this example, the contractual receipt window had not yet expired, and the fictional fee is 3% of R$ 1,000, or R$ 30. With no other movements, expected net proceeds are R$ 970. The initial absence of a credit does not prove a loss; nor does it establish that the capture has settled.
Later verification finds both captures in the correct batch, a total cost of R$ 30, and a R$ 970 transfer confirmed in the corresponding statement. The adjustment links this evidence, clears the expected receivable at the appropriate stage, and classifies the initial difference as one of timing and amount presentation. It neither books R$ 30 as an unexplained loss nor retroactively reduces gross sales.
The case closes because R$ 400 plus R$ 600 minus R$ 30 explains the R$ 970 received. If the credit were R$ 966, the remaining R$ 4 would remain a discrepancy until its cause was proven. To prevent false alarms, compare equivalent stages and windows, and keep gross amounts, fees, and net amounts separate. Adyen's documentation on reports and the payment lifecycle (opens in a new tab ↗) illustrates how different reports observe different stages with provider-specific semantics.
Case 3: a refund outside the original closing period. Consider another order for R$ 200, already reconciled in an earlier batch: a fictional R$ 6 fee and R$ 194 in net proceeds received. Later, a R$ 50 partial refund is confirmed. The symptom is a subsequent bank credit smaller than expected from new sales, even though the original closing was correct.
Gather the payment reference, refund-intent identity, external refund reference, its notifications, and the financial line in the later batch. The hypothesis is that the return was debited in this new period. In this scenario, new sales total R$ 1,000 with R$ 30 in fees; the same batch deducts the R$ 50 from the earlier refund. With no other adjustments, the expected credit is R$ 920.
Verification finds one effective R$ 50 refund, two deliveries of its notification, and a financial line confirming the debit. The adjustment recognizes the return once and links the later line to the same movement, without subtracting R$ 50 again because of redelivery. If there are two distinct financial references, investigate each entry's nature; do not dismiss a real debit merely because the amounts match.
The first R$ 194 credit remains in the history. The second is R$ 920. The accumulated R$ 1,114 matches R$ 1,200 in gross sales minus R$ 36 in fees and R$ 50 returned. Attributing the refund to the original order, its accumulated net contribution is R$ 144, assuming fees are not returned and no other costs apply. This does not change the statement that already confirmed R$ 194 in the first period.
The case closes by linking both periods and demonstrating a single economic refund effect. Prevention requires a stable identity, a trail between request, confirmation, and debit, and idempotent report ingestion. Adyen's Settlement details report (opens in a new tab ↗) is an example of documentation distinguishing financial movements and costs. Each provider's fields and rules must be mapped before automating matching.
In all three cases, the payment ledger must preserve the movements explaining the internal position, while reconciliation connects that record to external evidence. Turn the three sequences into reprocessing and closing tests, including when preparing payments for Black Friday. The closing criterion is a reproducible explanation of each difference and the action taken.
How do webhooks help reconciliation?
Webhooks reduce the delay between an external change and a local update.
But they do not eliminate reconciliation.
Events may be lost, duplicated, or arrive out of order. Delivery itself may fail. A parsing bug may make the application ignore a valid update.
A webhook is therefore a fast synchronization mechanism. Reconciliation is an independent verification mechanism.
The two complement each other.
Relying only on webhooks assumes no important event will ever be lost permanently.
Does polling replace reconciliation?
No.
Periodically querying the PSP may update transaction statuses, but reconciliation is broader. It checks completeness, amounts, financial movements, and consistency across sources.
Polling is a synchronization technique.
Reconciliation is a process of comparison and proof.
Even if the application checks every charge hourly, it must still verify that settlement and fees match expectations.
What is the source of truth?
It depends on the question.
For an order's commercial state, the order system may be the source. For an authorization result, the processor may be the external authority. For what your platform recorded, the internal ledger is the source. For funds actually received in a particular account, the financial statement plays another role.
Mature architectures do not try to make a single database the source of truth for every domain.
They define authority by fact.
Reconciliation verifies that these authorities remain consistent with each other.
How do you design a reconciliation routine?
The routine starts with reliable data collection.
It then normalizes enough of the format to allow comparison without discarding essential details. Next, it correlates records, applies timing rules, and calculates discrepancies.
Reconciled results can close automatically. Known differences can wait for their window. Genuine exceptions should enter an investigation queue.
The process must be idempotent so it can run again without creating duplicates.
It must also retain history, because today's explanation may change when a late event arrives tomorrow.
Should reconciliation automatically correct statuses?
In some cases, yes; in others, caution is needed.
If the local platform shows pending and a reliable PSP query shows an unambiguous final state, a rule-based correction may be reasonable.
But financial reconciliation should not indiscriminately change transaction states merely because a movement did not appear on the expected day.
Missing settlement may reflect timing, a hold, a dispute, a file error, or another condition.
Automatic corrections must respect each domain's semantics.
How do you detect orphan transactions?
An orphan transaction is an external event without a known internal match.
It may arise from persistence failures, partial processing, migrations, manual operations in the PSP dashboard, or parallel integrations outside the main architecture.
Reconciliation should have an explicit category for these cases.
Ignoring unrecognized lines is dangerous: the fact that the system does not recognize a movement does not mean it has no financial impact.
An orphan transaction warrants investigation until it is linked or classified as out of scope.
How do you detect duplicates?
Duplication may appear as two charges, two captures, two settlement lines, or two local records of the same event.
Idempotent IDs help prevent the problem at its source, but reconciliation still needs to detect it.
A common signal is more than one external movement linked to the same intent when the rule expected only one.
Another is a financial total greater than the explainable transaction total.
Detection must account for legitimately multiple operations, such as partial captures or multiple refunds, to avoid false positives.
A specific case occurs when boleto and Pix are alternatives for settling the same obligation. The boleto and Pix reconciliation guide shows how to preserve two distinct receipts, one settlement of the obligation, and resolution of the excess.
What is batch reconciliation?
Some providers organize movements into batches or payouts.
In this model, several transactions contribute to a consolidated financial total.
Reconciliation must work at two levels. First, verify each individual line. Then confirm that the sum of lines, fees, and adjustments matches the batch total.
This double check helps identify whether the problem belongs to a specific transaction or the financial aggregate.
In marketplaces, aggregate closing must also check each recipient. See how to connect allocations, fees, returns, and transfers in the payment splits, payouts, and reconciliation guide.
How should receivables advances be handled?
An advance changes the schedule and financial composition.
Funds may arrive before the original due date, with an additional cost. If the system expects only standard contractual settlement, the advance looks like a discrepancy.
Reconciliation must therefore understand financial products that change cash flow.
An advance does not change the commercial fact of the sale, but it changes the explanation of the financial movement.
This is another example of why payments and money need to be modeled in separate layers.
Are reconciliation and accounting the same thing?
No.
Reconciliation provides evidence that operational and financial events match. Accounting applies accounting rules to record those facts in the right accounts.
The two areas are closely connected but have different objectives.
Good reconciliation reduces manual entries, improves accounting information, and makes closing easier.
But it does not replace accounting classification, revenue recognition, tax rules, or the company's financial policies.
What should you measure in reconciliation?
The automatic match rate is an important metric: what percentage of movements reconcile without human intervention?
It is also useful to measure the number and financial value of open discrepancies, their average age, resolution time, incidence by PSP, discrepancy type, payment method, and problem source.
A healthy operation is not one that never finds a difference.
It is one that finds differences early, explains them quickly, and reduces recurrence.
How does reconciliation support observability?
Observability shows system behavior during execution. Reconciliation adds a later view based on effects.
A request may return 200 and still produce an unexpected financial result. A webhook may process without error but still map an amount incorrectly.
Reconciliation acts as a kind of reality check.
It asks whether later observed effects match what the system believed it had done.
How does reconciliation support Smart Routing?
Routing normally optimizes authorization and performance, but cost and financial quality also matter.
If a PSP has a good approval rate but creates more discrepancies, manual reconciliation, or operational delays, that cost should enter the analysis.
Route selection can consider not only approval and latency but also the quality of the financial lifecycle.
This requires reliable reconciliation data.
Without it, the platform sees only the first half of the story.
What is the relationship between reconciliation and a ledger?
A ledger records internal movements in a structured way. Reconciliation compares that record with external sources.
A well-designed ledger makes reconciliation much easier because it preserves history, amounts, and relationships between events.
Without a ledger, a company may rely on mutable states such as “current balance” and lose the ability to reconstruct how it reached that amount.
Reconciliation needs a trail.
A ledger provides that trail within the platform.
When does reconciliation need to be near real time?
It depends on operational risk.
For detecting a lost webhook in instant payments, a few minutes may matter. For closing a payout that happens only the next day, a daily routine may suffice.
There is no universal frequency.
The best design uses different windows for different facts.
Transactions can be reconciled frequently. Settlements can follow financial calendars. Disputes require another timeline.
How do you avoid manual spreadsheet reconciliation?
Spreadsheets are useful for individual investigations but poor permanent infrastructure.
When closing depends on downloading files, copying columns, using VLOOKUP, and adjusting formulas manually, critical knowledge remains tied to a human process.
Automation starts by documenting the rules represented by the spreadsheet.
Those rules can then become ingestion, normalization, matching, and automatic classification.
The goal is not to eliminate human analysis. It is to reserve people's time for real exceptions rather than repetitive matching.
What is the difference between conciliação and reconciliação?
In the Brazilian market, these terms are often used interchangeably for reconciliation.
Defining the scope matters most.
Some teams call comparing sales with PSP records conciliação and correcting discrepancies reconciliação. Others make no such distinction.
An architecture should not depend on informal terminology.
It must clearly specify which sources are compared, which rule defines a match, and what happens when a discrepancy exists.
How do you know whether reconciliation is mature?
A mature operation can explain any relevant amount through a chain of evidence.
If R$ 1 million was captured in a given period, it should be possible to explain how much settled, how much remains receivable, how much became fees, how much was refunded, how much entered disputes, and which discrepancies remain open.
It should also be possible to start from a financial line and find its constituent transactions.
The ability to navigate in both directions is an excellent maturity test.
Reconciliation is part of payment infrastructure
A payment platform's job does not end when it receives the PSP response.
It must track what happens afterward.
Reconciliation turns authorization, capture, refunds, fees, and settlement into a verifiable financial history.
This improves operations, support, accounting, risk control, and trust in the data.
When a company can explain why every amount came in, went out, or remains pending, the system becomes more than a collection of checkout integrations.
It operates as financial infrastructure that can be controlled.