A payment processor deposits $9,000 into the bank. A bank rule labels it “sales.” The transaction is categorized, the dashboard looks tidy, and several different accounting questions have been collapsed into one number.
What customers bought, what the processor collected, what it withheld, and what reached the bank are separate events. A useful integration keeps enough detail to explain the path between them.
I would rather have an unexplained balance that is visible than a clean-looking reconciliation built on the wrong assumption.
Reconcile the movement, then explain the balance
Take a hypothetical business with no opening processor balance. During a month, customers pay $10,000 for goods delivered in that month. The processor handles $200 in refunds and deducts $300 in fees. By month-end, $9,000 has reached the bank and $500 remains in the processor account, awaiting payout.
Assume no sales tax, disputes, reserves, foreign exchange, or other adjustments. Those items would need their own treatment in a real reconciliation.
| Processor activity | Amount |
|---|---|
| Opening balance | $0 |
| Customer payments | $10,000 |
| Refunds | −$200 |
| Processor fees | −$300 |
| Payouts received in the bank | −$9,000 |
| Ending processor balance | $500 |
The activity reconciles: $10,000 − $200 − $300 − $9,000 = $500. The remaining $500 also needs support. A processor report and subsequent payout can help establish what it consists of and where it went.
Under the assumptions above, revenue after refunds is $9,800 and processor fee expense is $300. Recording only the $9,000 bank deposit as sales would lose both the fee expense and the unsettled balance. It would also make revenue depend on the payout schedule.
Payment timing alone does not establish revenue recognition. If the customer paid for work to be delivered later, the accounting analysis would change. That is why a payment feed needs a connection to the underlying sale, not just a category assigned to a deposit.
Choose reports that answer the same question
A calendar-month transaction report and a payout batch may contain different populations of activity. Trying to make them agree without identifying that difference creates unnecessary adjustments.
Stripe’s payout reconciliation documentation (opens in a new tab) distinguishes matching automatic payouts to their underlying transactions from reconciling the processor’s ending balance. It also explains limitations for manual and instant payouts. The report has to fit the payout method and the question being asked.
For the example, Keep a period activity report, the ending balance detail, and a mapping from each payout to the corresponding bank deposit. The relevant dates include transaction activity, the reporting cutoff, payout initiation, and bank posting. A consistent time zone matters when activity crosses midnight.
If a payout is sent before month-end and reaches the bank afterward, document where it sits in the reconciliation. Do not force it into the earlier bank statement simply because the processor calls it paid.
A matching rule needs a reason
Matching on amount and an approximate date can be useful, but identical deposits exist. Fees can change net amounts. A single deposit can represent many payments.
Where available, use durable transaction and payout identifiers. Preserve the original identifier when importing data into the accounting system. If a transformation combines several records, retain the mapping rather than replacing the source detail with a single unexplained total.
A practical exception record would contain the source transaction, expected amount, recorded amount, difference, reason, owner, and next review date. “Timing” is only a useful explanation when the expected clearing event can be named. A balance that rolls forward month after month deserves another look.
Marc Ursick’s account reconciliation article in the Journal of Accountancy (opens in a new tab) emphasizes risk-based attention and a consistent process. That means reviewing unexplained changes and aging items, instead of treating every green match as equally informative.
Automate preparation without erasing review
The software can import activity, check totals, propose matches, and group exceptions. It should also report whether the import is complete. A perfectly matched subset of transactions is still an incomplete reconciliation.
Before accepting an automated result, establish which accounts and dates were covered, whether any records failed to import, which rules produced the matches, and what remains unresolved. A reviewer should be able to move from a summary back to the source records.
This is also where a seemingly small integration decision becomes an accounting control. An import that silently drops an unsupported event type may keep running while becoming less complete. Changes to event types, fee treatment, and account mappings need review.
The finished work should explain both the movement and the ending balance. A zero difference is useful evidence when the population, period, and matching logic are sound. Without those, it is just a number that happens to agree.