The Payments data challenge
In the first part of this series, we explored the Triangle of Reconciliation, a visualization of the relationship between Cashflow as provided by the Bank, Customer Intent as stored in CRM and the financial records as recorded in the General Ledger.
In order to balance the triangle correctly, Salesforce requires all detailed payment and transaction records from the bank and payment service providers to be captured, processed and matched against customers and invoices. In this blog we’ll explore why importing payments is hard, and how FinDock provides a solution through Bank Feed and Guided Matching.
Why importing payment data is hard
Importing payments data is not just another data import, there are specific challenges to overcome. Let’s break it down.
Importing Bank Transactions into the CRM
Despite the advantages of bringing payments data to the platform, unlike ERP systems, Salesforce out-of-the-box isn’t equipped to handle large volumes of financial transactions. And while there are plenty of ETL/Dataloader tools available, the specific formats banks use are rarely supported. Most bank payment related information is provided in specialized formats like:
- ISO 20022 XML formats such as CAMT.053
- SWIFT fixed width formats such as MT940
- Local legacy formats like CODA in Belgium or N43 in Spain
- PSD2/open banking API’s
And while some banks will also provide more generic formats like comma/tab separated files (csv/tsv) or excel, these often lack some important information like date, account, and balance details. As for the API connections, while the PSD2 initiative made APIs for account information mandatory, the actual implementation and technical specifications of the APIs was left open, this unfortunately means that there are nearly as many different APIs as banks.
External Processing Systems
And while the net cashflow might go through the bank, detailed transaction information might originate from a whole different system. Systems and platforms, like Point-of-Sale (POS) terminals or Billing engines like NetSuite ERP or Zuora, produce different formats with different levels of detail on each transaction and payment.
Even though many of these solutions might come with their own Salesforce integration package, they usually also implement their own data model. Meaning, even within the Salesforce platform, your payment information might be scattered across multiple different transaction and payment objects. All without any relation to your invoices and customers.
Payment Service Provider notifications
Even if your CRM is set up to handle PSP webhook notifications (e.g. Stripe, Adyen, PayPal), they often send multiple messages when initiating and processing a transaction, these have to be processed in the correct order regardless of the order in which they are received. The PSP might have the final success or failure status of an individual transaction, but the corresponding order or payment intent might not be ready yet in Salesforce.
Image: events for a single payment with Stripe
All of these factors combined means parsing and mapping these formats into Salesforce or any other CRM requires specialized tooling. Even when that’s available, you still need logic to match transactions to existing records, such as payment intents or open invoices. Without strong matching and reconciliation logic, you’re left manually piecing together fragments of information from different systems.
The Triangle in action: How FinDock Helps
At FinDock, we’ve embedded the triangle of reconciliation into the way we manage payment lifecycle data in Salesforce. We employ specific features to tackle the different challenges listed above:
- Our Unified Payments Data Model registers every payment, regardless of method, processor in the same way. Allowing for easy reporting, no matter where the payment was processed or imported from.
- Bank Feed automates Bank Payment import, with coverage for 2500+ banks throughout Europe and the UK, FinDock Bank Feed automatically fetches bank transactions and imports them into Salesforce in a structured format.
- ProcessingHub automatically recognizes, deduplicates and parses bank files
- FinDock’s Heroku hosted Notification Gateway allows webhook notifications from payment service providers to be securely received, validated, ordered, and imported, with caching and queuing to minimize the chance of data loss, even if Salesforce is down for maintenance.
- Finally, Guided Matching (next in this series) is the core matching engine in FinDock. Through specialized rule-sets, it is able to process and match payment data with information in the org. Extracting references and other remittance information, querying Salesforce standard and custom objects and fields for related records, creating or updating records, and matching transactions & notifications to invoices, pledges, premiums etc.
The end result is a unified, matched, and audit-proof record of every payment transaction, visible to both finance and customer-facing teams.
Closing the Loop on Payment Data
Importing and matching payments in Salesforce is not just a technical challenge, it’s a business-critical process fueling the Triangle of Reconciliation. When the flow of information between your bank, CRM, and general ledger is broken, the consequences ripple across finance, operations, and customer service.
With FinDock, those gaps close. Bank Feed, ProcessingHub, and Notification Gateway bring transaction details into Salesforce in the right format and the Unified Payments Data Model makes them consistent. And with Guided Matching – the next topic in this series – payments find their rightful place against the correct customer and invoice, automatically & and scale.
If you recognize these challenges in your own organization, don’t wait for reconciliation issues to surface in an audit or a customer complaint.
- Read the next blog in this series to see how Guided Matching works in detail.
- Or reach out to our team to explore how FinDock can bring balance to your own Triangle of Reconciliation, right inside Salesforce.








