ReconcileCSVUnlock full export · $39 once

Exception review playbook

Exception handling in reconciliation: classify unmatched payout rows

An exception is not automatically an error. It is a record that did not meet the matching rule and needs evidence, classification, and a next action. Leave ambiguous rows unmatched. Document the queue so a reviewer can clear it without forced plugs.

Start with a complete exception population

Build the exception list only after confirming that both source files cover the intended accounts, period, and currencies. A payout that appears unmatched because the bank export stops too early is a range problem, not a transaction problem. Likewise, a bank deposit can look unexplained when the processor export belongs to a different entity or destination account.

Retain all source rows and separate confirmed matches from open records. The exception population should include unmatched processor payouts, unmatched bank lines, ambiguous candidates, and amount differences. Give every item a stable source reference such as payout identifier, statement row, transaction identifier, or original filename and row number.

Build the open-item list from two CSVs

Load processor + bank exports in the browser when you need a starting exception population from confirmed matches versus unmatched rows. Files stay local; $39 unlocks export of the ledger, print view, and exceptions list.

Good exception control: every open item has a category, evidence, owner, next action, and aging date. No item disappears merely because someone changed a filter.

Triage before investigating deeply

Sort the queue into categories that suggest the next step. Useful categories include timing, fee netted, refund or dispute, reserve or adjustment, split or combined settlement, duplicate import, wrong account, wrong currency, source mapping problem, missing bank line, missing processor payout, and unknown. Keep unknown as a temporary state, not a final explanation.

Prioritize by risk rather than working only from largest to smallest. Large amounts matter, but old items, repeated discrepancies, unexpected debits, failed payouts, and transactions near reporting cutoffs can also deserve early attention. Establish a materiality threshold for escalation without using that threshold to delete or hide smaller open items.

A compact first-pass checklist

  • Verify exact currency and normalized sign.
  • Check the ordinary settlement window, weekends, and holidays.
  • Search by payout identifier and bank description, not amount alone.
  • Look for equal-and-opposite reversals or duplicated source rows.
  • Compare the difference with supported fees, refunds, disputes, or adjustments.
  • Check other authorized destination accounts before calling a deposit missing.

Resolve timing differences without losing them

A payout initiated before period end and posted afterward is a valid timing difference when processor evidence shows its status and destination. Record the expected arrival date and carry the item into the next period. At the next close, verify that it cleared and reference the bank posting. An aging report is useful because normal timing should not remain open indefinitely.

If the payout status changes to failed, canceled, or returned, reclassify it. Trace replacement payouts and bank reversals separately. Never keep an item labeled in transit simply because that was the first explanation. The category should reflect the latest source evidence.

Investigate amount differences

Calculate the variance between the processor payout and proposed bank counterpart, then search the processor detail for the same amount. A plausible percentage is not sufficient proof of a fee. Processing fees are often already included before the payout net is calculated, so subtracting them again can create a false explanation.

Review instant payout fees, bank charges, refunds, disputes, reserves, balance adjustments, and currency conversion. If several processor payouts sum to one bank line, or one payout is split across bank lines, list every component and confirm the sum by currency. Preserve the original rows instead of replacing them with a typed total.

When the bank amount differs because of a bank fee, retain the gross deposit and fee evidence if the statement provides both. When only a net bank amount is visible, obtain support from the bank before deciding the accounting treatment. The exception note should say what happened and identify the source, not merely say adjusted.

Handle ambiguous matches carefully

Ambiguity occurs when more than one candidate fits the amount and date rule. Round payout values and repeated daily deposits make this common. Use payout references, destination details, descriptions, exact timestamps, and surrounding settlement activity to identify the correct pair. If the sources do not distinguish candidates, leave the item open rather than choosing one for convenience.

Do not expand the date window until an amount finds something. A wider rule can silently pair unrelated records. If a broader window is appropriate because the processor has a documented delay, apply it consistently, record why, and rerun the exception review for all affected records.

Find source and mapping errors

Some exceptions originate in the import rather than the underlying cash. Check whether the mapped amount column is gross instead of net, whether debits and credits were combined correctly, and whether date formats were interpreted as month first or day first. Confirm that subtotal rows, opening balances, and blank values were excluded appropriately.

Duplicate exports can create duplicate payouts or deposits. Compare stable identifiers, filenames, row counts, and export ranges. Remove duplicates from the working population only after documenting which source was retained. Never edit the original export in place. A clean, repeatable import is part of the reconciliation evidence.

Warning: plugs, unsupported manual matches, deleted rows, and vague variance labels create a zero that cannot survive review. A supported open item is better than an unsupported match.

Write notes a reviewer can use

A strong exception note states the cause, evidence, accounting impact, next action, owner, and expected resolution date. For example: payout po_123 for USD 842.75 was marked paid on July 31 to the operating account, expected August 2, no July bank line, carried as cash in transit and cleared on August 2. This is much more useful than timing.

Attach or reference supporting processor detail, bank statement lines, support correspondence, and relevant policy. Keep private account information only in approved storage. The exception export can hold references and summaries without copying credentials or unnecessary personal information.

Close and roll forward the queue

At close, total exceptions by category and currency. Tie matched items plus open processor items back to the payout report. Tie matched items plus unexplained bank items back to the bank statement. Have a reviewer challenge old, unknown, and manually matched items. Record review completion and any required journal entries outside the matching tool.

Roll unresolved items forward with stable identifiers so they can be compared across periods. When an item clears, link the resolution to its original record and remove it from the open queue through a documented status change. Track recurring causes. Frequent mapping errors may call for a saved import profile, while recurring late payouts may call for a different cutoff procedure.

What ReconcileCSV can and cannot do

ReconcileCSV can compare payout and bank CSV files, normalize mapped date and amount fields, propose deterministic matches, and separate ambiguous and unmatched rows. The free preview shows the result. A one-time $39 purchase unlocks full ledger, print, and exceptions exports. File parsing and matching occur in the browser.

The product does not retrieve live statuses, connect to bank accounts, contact processors, post journal entries, or decide whether an explanation satisfies company policy. It cannot prove a cause absent from the source reports. Preparers remain responsible for mapping columns, reviewing candidates, obtaining evidence, and approving accounting treatment.

FAQ

When should I leave a row unmatched instead of forcing a match?

Leave the item open when sources do not distinguish candidates, evidence is incomplete, or the only way to clear it is a plug. Ambiguity is common with round payout amounts and repeated daily deposits. A supported open item with category, evidence, owner, next action, and aging date is better for review than an unsupported match. Do not expand the date window until an amount finds something; a wider rule can pair unrelated records.

What are the risks of force-matching ambiguous candidates?

Force-matching can hide failed payouts, wrong-account deposits, duplicates, or timing items that still need follow-up. Once a pair is marked matched, completeness checks against the payout report and bank statement become harder to trust. If multiple candidates fit the amount and date rule, use payout references, destination details, descriptions, timestamps, and surrounding settlement activity. If those still do not separate the candidates, keep the row open.

How should I treat fee lines that create amount differences?

Calculate the variance, then search processor detail for the same amount. A plausible percentage is not proof of a fee. Processing fees are often already included before the payout net is calculated, so subtracting them again creates a false explanation. Review instant payout fees, bank charges, refunds, disputes, reserves, adjustments, and currency conversion. When the bank shows a fee separately, retain gross deposit and fee evidence; when only a net appears, get bank support before choosing accounting treatment.

What if one payout is split across bank lines, or several payouts land as one deposit?

Preserve the original rows. List every bank or processor component and confirm the sum by currency using dates and references, not amount alone. Do not replace components with a typed total. Document the one-to-many relationship in the exception note so a reviewer can reconstruct the grouping without reopening the raw files.

How do I document exceptions for support tickets or audit review?

Write a note that states cause, evidence, accounting impact, next action, owner, and expected resolution date. Example shape: payout ID, amount, currency, paid date, destination, expected arrival, why no bank line yet, and how it cleared later. Attach or reference processor detail, bank lines, and support correspondence in approved storage. Keep credentials and unnecessary personal data out of the exception export; store references and summaries instead.

How does this exceptions guide relate to the Stripe, PayPal, Square, and Shopify guides?

Processor guides cover export choices, payout-level matching, and processor-specific failure modes. This page owns the work after matching: triage categories, timing roll-forward, amount-difference investigation, ambiguous matches, source/mapping errors, and close procedures. Use a processor guide to build the comparison; use this guide to classify and resolve what did not match. Keep Stripe-only export and fee examples on the Stripe guide so this page stays reusable across processors.

What belongs in the exception population before deep investigation?

After confirming both files cover the intended accounts, period, and currencies, include unmatched processor payouts, unmatched bank lines, ambiguous candidates, and amount differences. Give every item a stable source reference such as payout identifier, statement row, transaction ID, or original filename and row number. A payout that looks unmatched only because the bank export ends too early is a range problem, not a transaction problem.

Which triage categories are useful on the first pass?

Useful categories include timing, fee netted, refund or dispute, reserve or adjustment, split or combined settlement, duplicate import, wrong account, wrong currency, source mapping problem, missing bank line, missing processor payout, and unknown. Keep unknown temporary. Prioritize by risk—large amounts, aged items, repeated discrepancies, unexpected debits, failed payouts, and cutoff-period activity—not only by size. Do not delete small open items solely because they fall under a materiality threshold.

What can ReconcileCSV do with exceptions, and what must preparers still do?

ReconcileCSV compares payout and bank CSVs, normalizes mapped date and amount fields, proposes deterministic matches, and separates ambiguous and unmatched rows. The free preview shows the result; a one-time $39 unlock includes full ledger, print, and exceptions exports. Parsing and matching run in the browser. The product does not retrieve live statuses, contact processors or banks, post journal entries, or decide whether an explanation meets company policy. Preparers still map columns, review candidates, obtain evidence, and approve accounting treatment.