PSP Reconciliation Checklist for Finance Teams

Reconciling PSP payouts and payment gateway records is a routine but critical finance operation. When internal sales or ledger entries (Side A) are compared against PSP reports or bank statements (Side B), small mismatches can cascade into larger accounting problems if not caught early.

This checklist gives finance teams a practical, step-by-step approach to perform PSP reconciliation efficiently: what to prepare, how matching engines work, how to triage exceptions, and when to automate.

Use these steps to reduce manual ticking-and-tying, produce audit-ready outputs, and create a repeatable process that scales with transaction volume.

Why this topic matters

PSP reconciliation sits at the intersection of revenue recognition, cash application, and operational controls. Delays or errors in matching payments to sales can cause misstated revenues, unallocated cash, delayed vendor payments, and strained partner relationships.

For controllers, CFOs, and finance managers, a reliable reconciliation process reduces month-end stress, uncovers fee or settlement issues early, and provides clear evidence for auditors and stakeholders.

For small finance teams and SMBs, a checklist helps prioritize tasks so limited resources address the highest-risk mismatches first.

Core components

A robust PSP reconciliation process has four core components: inputs, data standardization, matching layers, and outputs.

Inputs: Side A and Side B

• Side A: internal records such as orders, invoices, ledger entries, or ERP exports that your team expects to reconcile.
• Side B: PSP reports, payment gateway settlements, bank statements, or marketplace payout files provided by external systems.
• Supporting data: fee schedules, refund logs, product masters, or mapping files used to enrich and align primary data.

Ensure files are in CSV/XLS/XLSX format with clear date, amount, and reference columns.

Data standardization and mapping

• Normalize date formats and timezones.
• Standardize amounts (currency and sign conventions) and round consistently.
• Clean and normalize identifiers and textual fields (trim spaces, remove prefixes, unify case).
• Map columns during upload: header row, date column, amount column, and primary identifier(s).

Derived columns (calculated fields) and lookups using supporting data close common gaps—examples include net amount calculations after fees or flags to exclude test transactions.

Matching layers: rule-based and AI

• Rule-based matching: deterministic one-to-one or grouped rules using identifiers, date windows, and exact amount matches. This layer gives high-confidence matches quickly.
• Flexible matching: one-to-many, many-to-one, net-to-net, and contra matching handle real-world reporting patterns such as summary settlements or split payouts.
• AI-based matching: when identifiers are missing or inconsistent, AI looks at amounts, descriptions, and contextual patterns to suggest high-confidence matches while avoiding forced or low-confidence ties.

Outputs and status definitions

• Fully matched: identifiers and amounts reconcile according to configured logic.
• Partially matched: a likely related record with amount variance requiring review.
• Unmatched: present on one side only.
• Skipped: invalid or incomplete rows excluded from reconciliation but visible for review.

Reports should be audit-ready, showing original file references, matching rules applied, and a clear exception list.

Practical implementation steps

Step 1: Prepare and validate inputs

1. Export the period-specific files from your PSP and your internal system in CSV/XLS/XLSX.
2. Confirm required columns exist: date, amount, and at least one identifier (transaction ID, settlement ID, order ID).
3. Upload supporting files such as fee schedules, refund logs, and product masters to enrich records.
4. Run a quick schema check to detect missing columns or malformed rows before running reconciliation.

Step 2: Configure matching logic

1. Map the header row and select the date, amount, and identifier columns for both sides.
2. Create derived columns if needed (for example, net payout = gross minus fees) using simple formulas or AI-generated expressions.
3. Define primary matching rules: exact identifier matches, then date+amount windows for fallback.
4. Configure grouped or contra rules for summary settlements or aggregated payouts.

Step 3: Run reconciliation and triage exceptions

1. Execute the reconciliation run and let the rule engine perform high-confidence matches.
2. Review partially matched and unmatched lists. Sort by exposure (amount) and frequency to prioritize work.
3. Use contextual filters (date range, payment method, gateway) to isolate problem areas quickly.
4. For true exceptions, add comments or tags, perform manual matches where totals justify, and mark records as investigated.

Step 4: Document, report, and automate

1. Export an audit-ready report that includes matched, partially matched, unmatched, and skipped records along with the matching logic applied.
2. Store supporting evidence (source files, mapping notes) in a centralized folder for audit trails.
3. If the reconciliation is stable, schedule automated data ingestion and runs via API, SFTP, or scheduled uploads to reduce manual work.
4. Reuse the configured reconciliation for future periods to maintain consistency.

Common mistakes to avoid

• Relying on a single weak identifier; if order IDs are inconsistently populated, supplement with amount+date matching.
• Ignoring skipped records: skipped rows often contain formatting or data issues that explain downstream mismatches.
• Over-matching: forcing low-confidence AI matches without human review can hide real problems.
• Not accounting for fees, chargebacks, or refunds separately; these items change net amounts and require derived columns or supporting files.
• Failing to version or document matching rules, which makes months or quarters hard to compare during audits.

Key Takeaways

• Standardize and validate Side A and Side B files before running reconciliation to reduce avoidable exceptions.
• Use deterministic rules first, then AI for messy or incomplete references—always prioritize high-confidence matches.
• Enrich data with supporting files and derived columns to handle fees, refunds, and grouped settlements.
• Triage exceptions by exposure, document investigation steps, and produce audit-ready reports.
• Automate recurring reconciliations once rules are stable to cut manual effort and improve consistency.

Conclusion

A repeatable PSP reconciliation process limits cash allocation errors, surfaces fee and refund issues, and produces evidence suitable for audit and operational review. Use the checklist above to build a defensible workflow and reduce month-end friction.

For teams ready to scale reconciliation, consider tools that support Side A/Side B matching, derived columns, rule-based and AI matching, and audit-ready exports. Start your 14-day free trial with Cointab. No credit card required. 14-day free trial.