Refunds and chargebacks across month-end

Refunds and chargebacks are the most common single cause of a clearing balance that will not resolve, because they break the assumption that a reduction sits in the same period as the sale it reverses.

The cross-period problem

A sale settles in one payout. Weeks later the customer is refunded, and that refund is deducted from a completely different payout, in a different period. The clearing account now holds a difference that is correct, temporary and completely opaque to anyone looking at a balance.

Chargebacks are worse in one specific respect: the deduction is initiated by the processor rather than by the merchant. Nothing in the order system triggers a ledger entry, so it is common to find the disputed amount and the dispute fee removed from cash with no corresponding entry in the books at all. Cash and books diverge, and nobody is notified.

The recurring patterns

• Refunds deducted from a later payout than the one carrying the original sale.
• Chargebacks deducted by the processor and never posted to the ledger.
• Dispute fees treated inconsistently, sometimes as a fee and sometimes netted into the disputed amount.
• Disputes later resolved in the merchant's favour, creating a reversal that also has to be tracked.
• Partial refunds against bundled orders, where the reduction does not map to a single order line.

What automation handles here

Attributing each refund and dispute to the payout that actually carried it, holding a payout rollup when a component has no ledger side, and surfacing the gap as a reason-coded exception with the processor's case reference attached.

In the reference build, a missing chargeback holds the whole payout with a named cause rather than leaving an unexplained difference. The accounting treatment of that chargeback remains a decision for the firm.

When standard software is enough

Standard connectors are often the right solution for standard workflows. If the connector posts activity correctly and the clearing account returns to zero without investigation, there is nothing here worth building. Keep the software you have.

When custom automation may be justified

The case for a custom reconciliation layer depends on recurrence, not on frustration. It is worth looking at when the same exception patterns return every close, several sources have to agree before the balance resolves, and meaningful staff time goes into work that follows repeatable rules.

If you want a structured answer rather than an opinion, the Fit Score scores one workflow against recurrence, effort, source complexity, rule repeatability and portfolio reuse. It runs in your browser and takes a couple of minutes.