Reconcile payment-processor settlements cleanly

Why processor settlements become difficult

The processor has its own timing and data model. A sale can occur on Friday, be included in a Monday batch, reach the bank on Tuesday, and be corrected by a dispute weeks later. Fees may be deducted per transaction or per batch. Reserves may be withheld now and released later. Multiple currencies may be converted before settlement.

Those events answer different questions:

• Transaction export: What customer activity did the processor record?
• Batch report: Which activity and adjustments were grouped into this settlement?
• Fee or dispute evidence: Why did the processor retain or reverse an amount?
• Bank statement: What cash arrived, when, and in which currency?
• Open settlement ledger: Which amounts remain between activity and cash?

If these layers are collapsed into “bank receipt minus fee”, review loses transaction completeness, correction history, and the distinction between current and carried amounts.

Minimum evidence package

The exact files differ by provider. The control design should be stable even when labels and export formats are not.

Synthetic example: two batches, two different bridges

The following processor and figures are invented.

Kanalwerk Commerce GmbH receives two EUR deposits for one business day.

The bank shows two deposits, €14,080.00 and €8,400.00, so the combined cash receipt is €22,480.00. That cash agreement is necessary but not sufficient.

For Batch A, the €300 reserve remains an open settlement asset or balance to track; it is not automatically a fee. For Batch B, the €200 release comes from an earlier hold and must not be recreated as current sales. The €335 chargeback needs its original transaction and dispute evidence. The prepared result keeps those paths separate while the two bank rows settle only the net batch amounts.

A processor label describes the provider's report. It does not, by itself, determine the legal, VAT, or account treatment.

The repeatable settlement control

1. Define account and period scope

Record the legal entity, processor account, merchant or marketplace role, currencies, time zone, and period cutoff. Do not combine two accounts merely because the brand is the same.

2. Validate the transaction population

Check unique transaction IDs, record count, gross totals, status changes, duplicates, and gaps. Preserve cancelled or reversed records where they explain the audit trail. If the provider issues updates, retain the version and extraction date.

3. Link transactions to batches

Use the provider's payout or batch identifier where available. If only a time range is supplied, document the rule and test boundary transactions. Transactions outside the stated range stay open instead of being pulled into the nearest deposit.

4. Reconstruct every component

Separate sales, refunds, disputes, fees, reserve holds, reserve releases, other adjustments, and currency conversion. Calculate the signed bridge independently and compare it with the reported net amount.

5. Match the settlement to bank

Use payout identity, reference, amount, currency, and value date. A one-to-many or many-to-one bank pattern must remain visible. Do not merge batches simply to reach the same daily total.

6. Roll forward the residual ledger

For each processor account and currency, reconcile opening unsettled balance plus current activity and adjustments minus bank settlements to closing unsettled balance. A residual needs an identified transaction, timing reason, reserve, or unresolved exception.

7. Prepare reviewer decisions

The reviewer should see the source row, proposed meaning, linked evidence, calculated effect, and why review is needed. Questions should be narrow: “Does the €335 dispute relate to transaction KWC-8821, and is the provider decision final?” is actionable; “Payout differs” is not.

A public settlement control sheet

A useful control sheet can use public, non-proprietary fields:

This schema does not prescribe accounts, VAT codes, or thresholds. Those remain organisation- and case-specific professional decisions.

What DeinHans prepares

For supported processor or platform formats, DeinHans can keep the report as a payout case, separate visible components, prepare the signed gross-to-net bridge, create targeted questions, and connect the result to bank evidence. A controlled template makes repeated files efficient without hiding the original data.

Coverage remains provider- and format-dependent. DeinHans does not claim a universal Stripe, PayPal, or other processor integration, does not infer the meaning of every new row, and does not approve fee, VAT, reserve, or currency treatment. Unrecognised or changed formats remain visible exceptions until validated.

Responsibility split

Review-ready outcome

A processor period is review-ready when each transaction belongs to one supported outcome, every settlement has a reproducible bridge and bank link, reserve and carried balances roll forward, currency remains explicit, and unresolved items name the missing evidence and decision owner. A zero unexplained residual is the result of evidence—not a plug used to make the control sheet look complete.