R

Reconciliation

Reconciliation

 

What is Reconciliation?

Reconciliation is the forensic accounting process of comparing two sets of records-typically the internal sales data from a merchant’s Order Management System (OMS) and the external settlement reports provided by Payment Service Providers (PSPs) and Acquiring Banks-to ensure they align. In fintech architecture, this is the critical "source of truth" mechanism. It validates that every dollar a customer "paid" at checkout was actually funded to the merchant's bank account, accounting for complex variables like interchange fees, refunds, chargebacks, and foreign exchange (FX) adjustments.

 

Deep Dive: The Mechanics of Financial Integrity

For enterprise merchants, reconciliation is not a simple "A equals B" check. It is a multi-dimensional puzzle involving time delays, currency shifts, and fee deductions.

1. The Technical Flow: The Three-Way Match

A robust reconciliation architecture typically enforces a "Three-Way Match" to ensure complete data integrity:

  • The Source (Merchant System): The record of the "Intent to Pay." (e.g., Order #123 for $100).

  • The Processor (Gateway): The record of the "Authorization." (e.g., Transaction ID ch_123 approved).

  • The Destination (Bank/Acquirer): The record of "Settlement." (e.g., Batch #99 deposited $97.50, deducting $2.50 in fees).

The logic engine must ingest disparate file formats-MT940 from banks, CSV/JSON from gateways, and SQL dumps from the ERP-and normalize them into a unified ledger. It then attempts to match transactions based on unique identifiers (like the Acquirer Reference Number or ARN).

2. Strategic Importance

  • Cash Flow Visibility: Without accurate reconciliation, a merchant is flying blind regarding their actual cash position. "Gross Revenue" (sales) is a vanity metric; "Net Settled Revenue" (cash in bank) is the reality.

  • Leakage Detection: Reconciliation automates the discovery of "Revenue Leakage"-money lost due to technical errors (e.g., a gateway marking a transaction as successful but failing to send it to the bank) or billing errors (e.g., an acquirer charging 3% fees instead of the agreed 2%).

  • Audit Readiness: Public companies and regulated entities must prove to auditors that their revenue recognition aligns with bank deposits. Automated reconciliation provides the audit trail required for SOX compliance.

3. Comparison: Net vs. Gross Settlement

The complexity of reconciliation depends largely on the settlement model used by the provider.

Feature

Gross Settlement

Net Settlement

Mechanics

The provider deposits the full transaction amount ($100). They invoice you separately for fees ($3) at month-end.

The provider deducts fees before the deposit ($100 sale results in $97 deposit).

Reconciliation

Easier. The deposit matches the order total.

Harder. The deposit does not match the order total. Logic is needed to "gross up" the net amount to match the ledger.

Cash Flow

Fees paid in arrears (better liquidity).

Fees paid immediately.

 

Common Pain Points in Multi-Provider Reconciliation

In a Composable/Multi-Acquirer setup, reconciliation complexity compounds exponentially.

  1. Data Fragmentation: Adyen reports in csv, Stripe in json, and Chase via SFTP. Finance teams often spend weeks manually consolidating these spreadsheets.

  2. Timing Mismatches: A transaction processed on Friday might not settle until Tuesday. In cross-border scenarios, settlement can take T+5 days. Managing "funds in transit" across months creates accounting nightmares.

  3. The "Black Box" of Bundled Fees: In blended pricing models, it is difficult to split out why a payout was lower than expected. Was it a refund? A chargeback fee? A rolling reserve deduction?

  4. Currency Variance: If a merchant sells in EUR but settles in USD, the exchange rate fluctuates between the moment of sale and the moment of settlement. This "FX Delta" creates small discrepancies that wreak havoc on balancing the books.

 

The Hellgate Approach

Hellgate Pulse transforms reconciliation from a manual spreadsheet exercise into an automated observability practice.

  • Unified Data Ingestion: Pulse acts as the central data aggregator. It connects to the APIs and SFTP servers of all your underlying providers (Link, Hub, Guardian). It ingests the raw settlement files and normalizes them into a standardized "Hellgate Financial Record."

  • Automated Matching: Pulse provides the granular transaction data-down to the ARN and Batch ID-needed to feed your ERP or reconciliation software. It creates a single "Source of Truth" that aligns the initial checkout attempt with the final bank deposit.

  • Fee Transparency: Because Pulse is built for complex setups (Interchange++), it breaks down the fees associated with every transaction. You can instantly see Net vs. Gross figures in the dashboard, identifying exactly how much the acquirer deducted before the money hit your account.

  • Exception Highlighting: Pulse visualizes "Breaks"-transactions that exist in the gateway but are missing from settlement reports-allowing your finance team to investigate lost revenue immediately rather than at quarter-end.

 

Frequently Asked Questions (FAQ)

Q: How often should I reconcile my payments?

A: High-volume merchants should reconcile daily. This allows you to catch technical errors (like a broken gateway connection) immediately. Waiting until month-end can result in massive accumulations of lost revenue.

Q: What is an ARN?

A: The Acquirer Reference Number (ARN) is a unique ID assigned to a credit card transaction as it moves through the payment flow. It is the "tracking number" for money and is essential for tracing missing refunds or settlements.

Q: Can software handle FX discrepancies automatically?

A: Yes. Advanced reconciliation engines allow you to set a "tolerance threshold" (e.g., +/- $0.05). If the discrepancy is due to FX rounding and falls within this threshold, the system automatically writes it off to a "Realized FX Gain/Loss" account.

Q: Why doesn't my bank deposit match my daily sales report?

A: This is usually due to Cut-Off Times. A transaction made at 11:55 PM might be included in today's sales report but tomorrow's banking batch. Reconciliation software aligns these by matching individual transactions rather than daily totals.

 

Latest News