Credit card reconciliation is the process of matching card transactions recorded in your ledger against the money a processor actually deposits. It is harder than bank reconciliation for one structural reason: the amount you charged and the amount you receive are never the same number, and the difference is not an error.
​

Processors fund net of fees. Your ledger records gross. A single deposit typically covers many transactions, minus fees, minus refunds, minus any amount held back. Every credit card reconciliation problem is a variation on reconstructing that arithmetic, and a process that does not model it explicitly will generate an exception for every deposit.
​

Credit card reconciliation matches three records that rarely agree on their own: the transactions your system captured, the settlement detail your processor reports, and the deposit that landed in your bank account. Agreement means every charged amount is accounted for as either funded, deducted as a fee, refunded, disputed, or still in transit.
​

It differs from ordinary bank reconciliation in that the processor sits between the customer and the bank. A bank statement line for a card deposit is a summary of processor activity, not a transaction, so reconciling to the bank alone confirms the deposit arrived without confirming it was correct.
​

The intermediary is structural rather than incidental: a Richmond Fed review describes interchange as the amount a merchant pays the cardholder's bank through the merchant acquiring bank, so at least two institutions sit between the sale and the deposit.
​

The three-way structure is what the work actually requires. Transactions tie to the settlement file, the settlement file ties to the deposit, and only the two together prove the money is right.
​

The gap between charged and deposited is made up of interchange, network assessments, and processor markup, plus any refunds, chargebacks, and reserve holdings applied in the same period. These are separate deductions with separate causes, and treating them as one lump makes the difference impossible to explain when it changes.
​

Interchange is the largest component and it is paid to the cardholder's issuing bank. The Federal Reserve defines an interchange fee as one established, charged, or received by a payment card network and paid by a merchant or an acquirer to compensate an issuer for its role in the transaction. It varies by card type, and that variation is why a flat fee assumption fails.
​

Debit and credit are regulated differently in the US, which matters when modelling expected fees. Regulation II caps debit interchange for large issuers at 21 cents plus 5 basis points of transaction value, with up to 1 cent more where the issuer meets fraud-prevention standards, per the Federal Reserve's compliance guide. Credit card interchange is not capped by that rule.
​

That standard is currently contested. In August 2025 a federal district court vacated Regulation II in its entirety in Corner Post, Inc. v. Board of Governors, then stayed its own vacatur pending appeal to avoid an unregulated market. The cap therefore still operates, but a fee model built on it should not assume it is permanent.
​

Four sources, and missing any one leaves a gap that cannot be filled by inference: the transaction log from your payment system, the processor settlement or batch detail, the bank statement showing deposits, and the dispute or chargeback report. The settlement detail is the one teams most often lack and most need.
​

The transaction log establishes what you charged. The settlement file explains what the processor did with it, including the fee decomposition and any refunds netted in. The bank statement proves the money moved. The dispute report explains reversals that would otherwise appear as unexplained debits weeks after the sale.
​

Most processors expose settlement detail through both a portal download and an API. The API is worth the setup cost, because manual retrieval is the step that silently stops happening during busy periods, and a reconciliation missing one day of settlement detail cannot be completed later without it.
​

Retention matters as much as retrieval. Disputes can arrive months after a sale, so the transaction and settlement records need to remain queryable well past the close of the period in which they originated. The Regulation II framework itself requires covered issuers to retain evidence of compliance for at least five years, which is a reasonable anchor for how long payment records stay relevant.
​

Processors group transactions into batches and fund each batch as one deposit. The batch, not the transaction, is the unit that reaches your bank, so matching at transaction level against bank data cannot work. Reconciliation has to happen at batch level first, then decompose into transactions using the settlement file.
​

Tools built for this model the flow rather than the statement, covering payments, payouts, refunds, chargebacks, and deposits as distinct object types rather than as undifferentiated bank lines.
​

Batch boundaries are the usual source of timing breaks. A transaction captured late in the day may settle in the next day's batch, so the sale and the deposit fall in different periods. That is a cutoff difference rather than a discrepancy, and it should age out automatically rather than being worked as an exception.
​

Multi-currency and multi-entity setups compound this. When a processor nets across entities or converts currency before funding, the deposit reconciles to a combination of records that no single entity's ledger contains, and the reconciliation has to be performed at the level where the netting happened.
​

Fees should be recorded as expense at the gross amount rather than netted silently against revenue. Booking only the deposit understates both revenue and processing cost, hides fee changes, and makes the effective processing rate impossible to monitor. The reconciliation should prove gross revenue, total fees, and net deposit as three separate figures.
​

Regulators treat the fee decomposition as consequential too: the Federal Reserve's Regulation II final rule distinguishes interchange fees from network fees charged to merchants that are not credited to an issuer, which are different line items with different counterparties.
​

This is also a control matter, not only a presentation one. If fees are never recorded, a processor rate change or an unexpected downgrade shows up only as slightly smaller deposits, which is exactly the kind of drift no one notices.
​

The practical implementation is a fee model per processor that predicts the expected deduction for each batch. Reconciliation then compares actual to expected, and the exception is the variance rather than the whole fee, which shrinks the review queue to the cases that carry information.
​

The table below sets out the breaks a card reconciliation actually produces, what causes each, and how each should be resolved. Grouping by cause matters because these have different owners: some are expected arithmetic, some are timing, and only a minority are genuine discrepancies requiring investigation.
​

The distinction in the third column is the one that determines workload. Expected breaks should be absorbed by rules and never reach a human. Genuine breaks are few, and they are the only ones worth a person's attention, which is why classifying them at the point of detection matters more than raising the overall match rate.
​

A chargeback reverses funds after settlement, so it breaks a transaction that previously reconciled cleanly. It is not a matching failure but a new event against an old sale, and treating it as an unexplained difference in the current period loses the link to the transaction being disputed.
​

The correct treatment is to carry the disputed amount as a receivable with an owner and a status until the case resolves, then post the outcome. That keeps the reconciliation honest in both directions: the money is genuinely gone now, and it may genuinely come back later.
​

Volume here is measurable rather than anecdotal. The Federal Reserve's Regulation II data collection gathers information on the volumes and values of chargebacks and returns alongside debit transaction data, which makes chargeback activity a tracked feature of the payment system rather than an edge case.
​

Some processors withhold a percentage of funding as a rolling reserve against future chargebacks, particularly for newer merchants or higher-risk categories. The withheld amount is still yours, but it is not in your bank account, and a reconciliation that ignores it will show a permanent unexplained shortfall.
​

Reserves are also the component least visible in public data, since the Federal Reserve's Regulation II data collection gathers transaction, chargeback, and return volumes rather than merchant-level withholding, so the only authority on your reserve balance is your own processor agreement.
​

Reserves belong on the balance sheet as an asset with a release schedule, reconciled against the processor's own reserve reporting. The failure mode is treating each withholding as a fee, which quietly writes off money that was due to be returned.
​

Release timing deserves the same attention as the withholding. Reserve releases arrive as additional funding that matches no sale, and without an expectation recorded against them they arrive looking like an unexplained credit.
​

A working process reconciles daily rather than monthly, at batch level, using the processor settlement file rather than the bank statement alone. It models expected fees, ages out cutoff differences automatically, and routes only genuine breaks to a person with a reason code attached.
​

This is the same discipline a 2006 Journal of Accountancy analysis urged for balance sheet reconciliation generally: reconcile the high-risk accounts early enough that adjustments reach the ledger before reporting, rather than after.
​

Daily cadence is the single highest-value change for most teams. Card breaks are far cheaper to resolve while the surrounding context is fresh, and a daily cycle caps the size of any one investigation at a single day of activity rather than a month of it.
​

The second is source discipline. Reconciling to the deposit alone confirms cash arrived; reconciling to the settlement detail confirms it was the right amount. Only the second detects a processor error, and processor errors are precisely the class no internal control will otherwise catch.
​

Card type, presentment method, and whether the transaction met the network's data requirements all change the rate applied. Two identical amounts can settle at different effective costs, which is why a single blended percentage is a budgeting figure rather than a reconciliation tool and why fee variance needs its own explanation.
​

The regulated debit case shows the mechanism clearly. Regulation II sets a base standard plus a conditional adjustment available only where the issuer meets fraud-prevention requirements, and the Federal Reserve's final rule also prohibits an issuer from receiving net compensation from a network. Fee outcomes depend on qualifying conditions, not on the amount alone.
​

For unregulated card types the same principle operates through network interchange schedules, where transactions that fail to supply required data settle at a less favourable rate. Reconciliation surfaces this as a persistent negative fee variance on a specific transaction pattern, which is genuinely useful operational information.
​

That makes fee variance worth reading rather than merely clearing. A variance concentrated in one channel usually indicates a data or configuration problem upstream that is quietly raising cost on every transaction through it.
​

Each processor is its own reconciliation with its own fee model, file format, batch schedule, and reserve terms. They do not merge into a single process. What can be shared is the structure: the same four record types, the same break taxonomy, and the same rule that expected differences never reach a human.
​

The common mistake is one blended clearing account for all card activity. It nets one processor's shortfall against another's surplus and produces a balance that looks approximately right while hiding two errors. A clearing account per processor makes each one provable on its own.
​

Match rate should also be tracked per processor rather than blended, for the same reason. Vendors that treat payments, refunds, and chargebacks as distinct object types make this segmentation straightforward; those that reconcile bank lines alone cannot express it. An overall figure that averages a clean processor with a broken feed conceals the only fact worth acting on, which is which specific integration needs work.
​

Adding a processor is a good moment to insist on API access to settlement detail and a written description of the fee structure, because both are far easier to obtain during onboarding than after the relationship is live.
​

Card revenue usually flows through a small number of high-value accounts, so an unreconciled card position concentrates risk rather than spreading it. Auditors test whether the control that should have caught a misstatement actually operates, and an unreconciled processor balance is a visible gap in exactly that control.
​

The standard framing is explicit about consequences. Under PCAOB AS 2201, a material misstatement identified in the financial statements that the company's own internal control did not first detect is treated as a strong indicator of a material weakness. A card reconciliation that is not performed is not a housekeeping backlog; it is the control that was supposed to detect.
​

A 2006 Journal of Accountancy analysis made the same point about balance sheet account reconciliation generally, recommending that accounts be risk-rated and the higher-risk ones reconciled early enough for adjustments to reach the ledger. Card clearing accounts are usually near the top of that risk rating by value.
​

The practical requirement is reproducibility. An auditor will ask why a given batch was accepted as matched, and the answer needs to be a recorded rule and a settlement reference rather than a person's recollection.
​

Faster settlement narrows the timing window but does not remove fee arithmetic. A card transaction settling same day still funds net of interchange and markup, so gross and net still differ. What compresses is the cutoff problem, because sales and deposits stop landing in different periods.
​

Conventional rails have already moved in this direction. Nacha reported Same Day ACH volume growing 16.7% in 2025 to 1.45 billion payments worth $3.92 trillion, which shortens the gap between a payment instruction and available funds.
​

Onchain settlement changes the shape further, because settlement and record creation are the same event. There is no batch, no funding delay, and no separate settlement file to reconcile against. 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 stablecoin payments move through, producing one record rather than a transaction log and a settlement file that must be tied together afterward. That removes the batch and fee-netting structure that generates most card reconciliation breaks, because there is no intermediary funding net of deductions.
​

This does not make Eco a card processing alternative for card acceptance. Businesses accepting cards will keep reconciling cards, and the process above still applies. The relevant comparison is for flows that do not have to run over card rails at all, where the reconciliation burden is a consequence of the rail rather than of the payment.
​

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

Methodology. The interchange fee definition and the 21 cents plus 5 basis points debit standard are from the Federal Reserve's Regulation II small entity compliance guide, last updated June 23, 2023. The August 2025 vacatur and stay in Corner Post, Inc. v. Board of Governors are per a Cooley alert dated August 15, 2025; the appeal was pending at that date and readers should check current status. Regulation II governs debit interchange only and is not extended to credit here. ACH figures are Nacha's ACH Network statistics for full year 2025. Stablecoin supply is from DeFiLlama as of September 9, 2026 and moves intraday. No processor pricing is quoted, because processor rates are contract-specific and are not published in a form that can be cited.
​