Ecommerce payment reconciliation ties three things together: the orders your store recorded, the settlements your payment gateway reports, and the payouts that reach your bank. In a healthy month none of the three will agree on a raw total, and every difference should be explainable by a named cause.
​

The complexity comes from volume and fragmentation rather than difficulty. A store running one gateway and one marketplace already has two funding paths with different schedules, different fee models, and different refund mechanics, and each additional channel multiplies the reconciliations rather than adding to one.
​

It is the process of proving that every order collected money, that the money arrived net of known deductions, and that anything outstanding is identified. Orders tie to gateway transactions, gateway transactions tie to settlement batches, and settlement batches tie to bank deposits, with fees, refunds, chargebacks, and holds explaining the differences.
​

The order-to-payout chain is the distinguishing feature. In a simple business a payment reconciles against a bank statement. In ecommerce there are at least two intermediaries between the customer and the bank, and each one applies its own deductions and its own timing.
​

Because of that chain, reconciling only the endpoints hides errors in the middle. A deposit that matches expected revenue in total can still contain a fee overcharge offset by an unprocessed refund. Tools built for this model the chain as distinct object types, covering payments, payouts, refunds, chargebacks, and deposits separately rather than as undifferentiated bank lines.
​

Because orders and deposits are different units. Orders are individual customer events; deposits are batch settlements covering many orders minus deductions. One deposit typically represents hundreds of orders, so the two can only be compared through the settlement detail that decomposes the batch.
​

Timing widens the gap further. Orders placed near a settlement cutoff fund in the next batch, authorizations that never capture create orders with no payment at all, and refunds reduce a later deposit for revenue recognized earlier. None of these are errors.
​

The structural point is that funding arrives net. Processors deduct interchange and fees before paying out, and the Federal Reserve defines interchange as a fee paid by a merchant or an acquirer to compensate the card issuer, which is deducted upstream of your bank account rather than billed to you separately.
​

A gateway settles transactions you originated and reports them individually. A marketplace pays you a net figure after its own commissions, advertising charges, returns, and reserve policies, often on a fixed schedule unrelated to when orders occurred. The reporting granularity is usually coarser and the deductions more varied.
​

That difference changes the reconciliation approach. Gateway settlements can be reconciled transaction by transaction. Marketplace payouts often must be reconciled by reconciling the marketplace statement itself, then tying the statement total to the deposit, because the payout is a settlement of an account rather than a batch of payments.
​

Marketplaces also introduce deductions with no equivalent in card processing, such as advertising fees or storage charges netted from the same payout. Treating those as payment fees misstates both marketing spend and processing cost. Engines that support 1:N and N:1 matching with thresholds handle this shape natively, since one payout legitimately corresponds to many orders and many deduction types at once.
​

The table compares the funding paths a typical store runs, on the dimensions that change how each must be reconciled: what the funding unit is, what gets deducted before payout, and what the reconciliation actually ties together. Mixing these into one process is the most common design error.
​

The last column is the operative one. Channels funding at transaction level reconcile directly; channels funding at batch or account level require an intermediate statement before order-level matching is possible at all.
​

Five: the order record from the store platform, the transaction record from each gateway, the settlement or payout report from each provider, the bank statement, and the refund and dispute log. A reconciliation missing the settlement report can confirm cash arrived but never that the amount was correct.
​

Settlement reports are the ones most often absent, because they require deliberate retrieval rather than arriving automatically. Most providers expose them through both a dashboard download and an API, and the API is worth the setup cost since manual retrieval is the step that quietly stops during peak trading.
​

Retention has to outlast the dispute window. Chargebacks arrive months after the sale, so order, settlement, and dispute records must remain joinable well past the close of the period that produced them.
​

Tooling that models payouts and disputes as first-class objects makes this join durable, whereas reconciling from bank lines alone discards the structure the later investigation will need.
​

Keep one clearing account per provider per entity rather than a single blended one. Netting a shortfall in one channel against a surplus in another produces a total that looks approximately right while concealing two separate errors, and it makes any individual channel unprovable.
​

Match rate should be tracked the same way. A blended figure averaging a clean gateway with a broken marketplace feed hides the only actionable fact, which is which specific integration needs attention.
​

Regional structures add an entity dimension on top of the channel dimension. Where a provider nets across entities before funding, the reconciliation has to be performed at the level where the netting occurred, because no single entity's ledger contains the full picture.
​

Engines designed for this reconcile AR, AP, bank, PSP, and intercompany data through one rule-based engine, which is the shape a multi-store, multi-entity operation actually needs.
​

Both reduce a later payout for revenue recognized earlier, so both must link back to the original order rather than appearing as unexplained deductions in the current period. A refund is a completed reversal; a chargeback is a contested one that may still resolve either way.
​

Refunds are straightforward once linkage exists, and painful without it. A refund netted into a settlement with no order reference leaves a deduction that reconciles to nothing, which is why refund records should carry the original transaction identifier through every system they touch.
​

Chargebacks need case tracking rather than a ledger entry. The disputed amount should sit as a receivable with an owner and a status until resolved. The Federal Reserve's Regulation II data collection gathers volumes and values of chargebacks and returns, which reflects that disputes are a routine feature of card systems rather than an edge case.
​

Selling in several currencies adds a conversion step between the order and the deposit, and the rate applied is the provider's rather than the one recorded at order time. The resulting difference is a foreign exchange effect, not a reconciliation break, and it needs its own account rather than being absorbed into fees.
​

The common failure is booking conversion differences as processing cost. That overstates fees, understates or overstates revenue depending on direction, and makes the effective processing rate untrackable, which removes the only signal that would reveal a pricing change.
​

Cross-border settlement standards are moving toward richer data that makes this easier to decompose. Swift states that ISO 20022 is now the global standard for cross-border payments, with the coexistence period having ended on 22 November 2025.
​

Daily at settlement level, with a fuller position check weekly. Ecommerce generates enough volume that a month of unreconciled activity becomes impractical to investigate, and the useful properties of a break, such as the surrounding orders and support history, decay quickly.
​

Daily also matches the funding rhythm. Most gateways settle daily, so a daily cycle reconciles one batch against one deposit, which is the smallest and most tractable unit the process offers. Monthly reconciliation forces the same work on thirty entangled batches at once. The reporting argument points the same way: a 2006 Journal of Accountancy analysis urged completing reconciliations early enough that adjustments feed reported figures rather than trailing them.
​

Marketplace channels are the exception and should follow their own payout schedule. Reconciling a marketplace daily when it pays fortnightly produces a permanent apparent shortfall that is really just the accrual between payouts.
​

On volume and on classification. Ecommerce reconciliation is high-volume and highly repetitive, which is exactly the profile automation suits, provided the rules distinguish expected differences from genuine ones rather than raising everything to a human. The distinction is the whole design: a rule that clears everything is not automation but suppression.
​

Tooling built for payment operations models the objects this domain actually produces. Ledge describes covering payments, payouts, refunds, chargebacks, and deposits as distinct types, which matters because a refund and a fee are not the same kind of deduction even though both reduce a payout.
​

What automation cannot fix is missing settlement detail. A channel that reports only a net payout with no line-level breakdown cannot be reconciled below the payout level by any tool, and the fix is obtaining better reporting from the provider. Extraction helps where advice exists but is unstructured, with capture from email, PDF, EDI, and portals, though it cannot create line detail a provider never published.
​

Put the order identifier in the payment itself wherever the rail allows, and fall back to a provider-side lookup only when it does not. A reference travelling with the funds is the difference between automatic application and a manual search through orders of a similar amount and date.
​

Card channels handle this through the gateway rather than the rail, since the gateway holds the order identifier and reports it in settlement detail. That is why gateway settlement reports are worth retrieving even when the bank deposit alone appears to reconcile.
​

Bank rails carry the reference in structured fields with defined limits, which is what the ANSI X12 820 payment order and remittance advice transaction set standardizes for ACH. Direct bank payments without that structure are the hardest ecommerce receipts to apply.
​

Cross-border flows are converging on richer structure. Swift describes ISO 20022 as enabling richer, better structured and more granular data end-to-end in payments messages, which is the same capability applied to international orders.
​

It reconciles daily per channel, holds a separate clearing account per provider, models expected fees so only variances surface, links every refund and dispute to its original order, and can state the unreconciled position by channel at any moment rather than only after close.
​

Exception routing is what keeps it working at volume. Each break should carry a cause, an owner, and an age, because a queue of undifferentiated items forces a human to classify every entry, which is the work the automation was bought to remove.
​

Reproducibility is the audit requirement. Under PCAOB AS 2201, a misstatement the company's own controls failed to catch is a strong indicator of a material weakness, so the reason a batch was accepted as matched needs to be a recorded rule rather than a recollection.
​

The same principle applies to document form. GAO has accepted digital rather than paper records provided controls ensure the images accurately represent the original, changes are detectable, and access is limited, which is a reasonable standard for retained settlement reports.
​

Finance owns the reconciled position, but the causes sit elsewhere. Gateway configuration belongs to whoever manages payments, marketplace deductions belong to whoever manages that channel, and refund policy belongs to customer operations. Routing every break to finance produces a queue manager with no authority over what generates the queue.
​

Separation is also a control requirement rather than a preference. GAO's internal control standards hold that key duties be divided among different people to reduce the risk of error and fraud, which in this context means the person configuring the gateway should not be the sole person confirming its settlements reconcile.
​

What should be centralized is the rule set: tolerances, aging thresholds, and write-off authority. Distributing resolution while centralizing the policy keeps treatment consistent when several channels are worked by different teams.
​

Fee expertise deserves a named owner too. Understanding why a deduction changed requires knowing how the deduction is constructed, and the Federal Reserve's definition of interchange as a fee paid by a merchant or an acquirer to compensate an issuer is the starting point for reading any card settlement correctly.
​

Four recur: reconciling to the bank deposit instead of the settlement report, booking fees net against revenue, treating marketplace commissions as payment processing cost, and leaving refunds unlinked to their original orders. Each produces books that balance while describing the business incorrectly.
​

Reconciling to the deposit alone is the most consequential. It confirms cash arrived and proves nothing about whether the amount was right, so a provider error or an unprocessed refund passes through undetected because the total still ties.
​

Netting fees against revenue understates both revenue and cost simultaneously, which hides the effective processing rate. Since that rate is the only signal that would reveal a pricing change or a rising downgrade pattern, netting removes the metric most worth watching.
​

Unlinked refunds are the quiet one. A refund deduction with no path back to its order reconciles to nothing and accumulates, and tools that treat refunds and chargebacks as distinct object types preserve that link where bank-line reconciliation discards it.
​

The fourth mistake is assuming extraction fixes missing data. Capture from email, PDF, EDI, and portals converts awkward formats into usable ones, but a provider that publishes only a net figure has not supplied detail for any tool to extract.
​

Onchain settlement funds at transaction level rather than in batches, which removes the intermediate settlement file from the chain entirely. There is no batch to decompose, no net funding to reverse-engineer, and no provider statement to obtain first, so the order-to-payout reconciliation collapses into a direct order-to-transfer match.
​

There is no fee model to maintain and no settlement cutoff to age out, which removes two of the three break categories a card channel generates and leaves identity as the remaining question.
​

The remaining question is identity, and it is the same one every rail has. A transfer proves an amount arrived from an address; tying it to an order still requires a reference travelling with the payment or a lookup on the merchant side. That is the same constraint bank rails impose, which is why Nacha's ACH network carried 35.19 billion payments worth $93.00 trillion in 2025 while still relying on separate remittance data to explain them.
​

Scale here is measurable. The stablecoin market held $311.0 billion in total supply as of September 9, 2026, led by USDT at $183.4 billion and USDC at $74.4 billion, according to DeFiLlama.
​

Eco operates the routing and execution layer that stablecoin payments move through, so the payment record and the settlement record originate together. For a store, that removes the batch and net-funding structure that produces most ecommerce reconciliation work, because there is no intermediary deducting fees before payout.
​

This does not replace card acceptance, and stores selling to card-paying customers will keep running the gateway reconciliation described above. The relevant comparison is for flows that do not need card rails, where the reconciliation burden is a property of the rail rather than of the sale.
​

For the record layer, Eco's comparison of stablecoin settlement APIs with audit trails covers what a settlement record should expose.
​

Methodology. The interchange definition is from the Federal Reserve's Regulation II compliance guide; chargeback data collection is per the Fed's Regulation II reports and data collections. Note that Regulation II governs debit interchange only and was vacated by a federal district court in August 2025 with the vacatur stayed pending appeal, so its standard is operative but contested. ISO 20022 statements are from Swift. Stablecoin supply is from DeFiLlama as of September 9, 2026 and moves intraday. No gateway, marketplace, or provider pricing is quoted, because those rates are contract-specific and not published in citable form.
​