Why an e-commerce clearing account will not reconcile

Start by decomposing, not investigating

The instinct with a stubborn clearing balance is to hunt for the transaction that caused it. In multi-channel e-commerce that instinct is usually wrong, because there is no single transaction. The balance is an accumulation.

A more productive first step is to ask what the balance should contain. At any month-end, a correct clearing balance holds sales that have settled in the ledger but whose payout has not yet reached the bank. If you can compute that figure independently, the difference between it and the actual balance is the real problem, and it is usually much smaller than the balance itself.

The six recurring causes

1. Timing across the period boundary

Orders placed near month-end settle in the following period. This is correct behaviour, not an error, but it means a non-zero balance is expected. Treating it as a problem sends teams looking for errors that do not exist.

2. Fees netted at payout level

Revenue posts gross, the deposit arrives net. Unless the fee is posted separately with the same period attribution, the difference lands in clearing.

3. Refunds against earlier periods

A refund is deducted from whichever payout is current when it is issued, not the payout that carried the original sale.

4. Chargebacks never posted

The processor removes the disputed amount and a dispute fee from the balance. Nothing in the order system generates a ledger entry. Cash and books diverge with no notification.

5. Multiple processors in one account

Two gateways clearing through the same account produces one balance that is the sum of two unrelated reconciliations. Neither can be resolved without separating them first.

6. FX and rounding

Cross-border settlement introduces variances that are legitimate, tiny per transaction and persistent in aggregate.

A practical decomposition

1. Compute expected in-transit: settled sales without a corresponding bank deposit at period end.
2. Subtract that from the actual balance. The remainder is what needs explaining.
3. Pull processor dispute activity for the period and check each item exists in the ledger.
4. Confirm fees are posted with the same period attribution as the sales they relate to.
5. If more than one processor shares the account, split the population before going further.

Most teams find the remainder after step two is far smaller than expected, and steps three and four account for the bulk of it.

When standard software is enough

If you run one channel with one processor and a properly configured connector, this problem largely does not arise, and adding custom logic would be a waste of money. Keep what you have.

When custom automation may be justified

When several sources share the account, the decomposition above is repeated every close with the same logic, and the work takes meaningful staff time. Repeating a deterministic procedure monthly is the definition of something a rule can express.