Balancing Payment Data Across Systems

Back in 2021, I introduced the Triangle of Reconciliation, a model that shows the critical flow of payment data between three systems: your CRM, your bank, and your general ledger.

At the time, my focus was on nonprofits and fundraising operations, where donor communications and financial tracking rely heavily on CRM accuracy. But in recent years, we’ve seen a growing number of for-profit companies adopting FinDock, including housing organizations, service businesses, and membership organizations. Discovering that the same principles apply just as strongly to any organization handling customer payments, whether for products, services, or recurring billing.

Today, we revisit the Triangle with a broader lens, looking at how to keep payment data aligned across your CRM, bank, and ledger for improved operational efficiency, customer satisfaction, and financial integrity.

Why Reconciliation is so important

Reconciliation ensures:

• Customer intent (CRM)
• Cashflow (bank)
• Financial records (General Ledger)

…are all in sync.

When these systems drift out of alignment, problems follow:

• Customers chased for payments they’ve already made.
• Revenue misreported in financial statements.
• Business decisions made on unreliable data.

Small errors accumulate until they surface during audits or through customer complaints. Keeping the triangle balanced prevents these issues.

The three corners of the Triangle

The Bank

Every payment transaction uses one of two possible core systems: Cash or Bank. Even card payments, often seen as a separate category, result in a bank transaction in your account. Some might argue Crypto is a third way, but in general accounting this is often treated as a valuable asset, similar to stocks, not as currency, so we will ignore it for now. 

When a payment is received, settled, or refunded, your bank statement or transaction file reflects it. But while the bank confirms that money has moved, it doesn’t necessarily tell you who the customer is, what it was for, or whether it matches your internal expectations. In other words, the bank tells you about cashflow, but it doesn’t link it to the revenue. 

The CRM System

Your CRM is where customer intent and context live. CRM systems in general, and Salesforce in particular, are designed to capture all customer details, including preferences like payment methods and communications. Often, the core CRM functionality is extended with CPQ-esque solutions like Salesforce Revenue Cloud or GoMeddo. This means Salesforce now is the system of record for not only customer contact details, but also quote, order, and most importantly for us, invoice information. In other words, it keeps a debtor administration.

The General Ledger/Accounting System

The General Ledger  is your financial system of record. It keeps track of all incoming and outgoing value transactions through changes recorded as journal entries. As part of that, it needs to reflect cash flow and revenue linked together. The general ledger itself is purely composed of transactions against the numbered accounts detailing assets, revenue, and liability. The accounting system feeding into the general ledger can keep additional information to generate the journal entries, as such when it comes to registering sales orders/invoices and received payments, there are two main ways to configure the accounting system; where all individual customers and their invoices are registered as separate entities and every transaction can be seen in detail, or one where the general ledger only contains aggregated high level information on how much money was received on a given day, but doesn’t have the detail of the individual transactions or debtors/customers. 

Focus on customer payment data

The triangle of reconciliation applies to customer payments only. There are many other pieces of data that are just as important; depreciation, interest, remuneration payments and many other categories of financial transactions which are not customer related. 

Just like your internal Teams/Slack messages and emails are an important stream of information, you don’t necessarily need or want to record all of it in your CRM system. That invite to the office pizza party is not exactly customer related. Financial transactions work the same way, the “internal” transactions are no less important, but since they are not customer related, they don’t belong in the CRM but only in the general ledger. 

But customer payments, both inbound and outbound, play an important role in completing the customer profile in CRM, and help the reconciliation process by providing the needed context to accurately record the resulting general ledger transactions.

Two approaches to balancing

There are two main ways of balancing payment information between Salesforce and the accounting system/general ledger.

1.Replication

Here we duplicate all the relevant information (debtors, invoices, and payments) from the CRM to the accounting system, which in turn then updates the general ledger. This way, all of the details are in the accounting system and we can run all reporting and see all individual transactions in the accounting system. This model is often used when the number of customers is relatively low, accounting systems often aren’t well-equipped to handle tens, or hundreds of thousands of customer records. A potential downside to this approach is that you will have to maintain a pretty intensive two-way synchronization between CRM and the general ledger to ensure all data is accurate in both systems. And you will need a way to resolve sync conflicts if data is updated in both systems in between synchronizations. 

2.Relocation

One way to combat this, is through relocation, where we make CRM become part of the financial record by treating it as a subledger. All customer, invoice, and related payment information is recorded primarily in the CRM with aggregated journal entries feeding directly into the general ledger. Since Salesforce is designed to handle large amounts of data, handling hundreds of thousands or even millions of customers is not a problem. However, since your CRM is now part of your financial system of record, you will need to impose stricter governance on change management, data security, and backup. And of course, your finance team requires access to the CRM and some reports will need to be generated from Salesforce as the accounting system simply doesn’t have all the detailed information anymore.

There is no one best model, but rather it depends on your situation, customer base, application landscape, complexity of the general ledger, and how the mentioned up- and down-sides balance out for your organization.

Data Flow

Replication

Here, the full details of the bank transactions are sent to both the accounting system and the CRM. Matching of bank transactions is done in CRM and together with all other payments that are received, synced to the general ledger using individual journal entries. Any new/updated customers and invoices will also be synced from the CRM to the accounting system (and possibly vice versa). 

Payments and transactions not related to customers are already in the accounting system and can easily be matched and reconciled there.

Relocation

Here the bank sends the full transaction details only to the CRM with only balance information going into the accounting system. Salesforce will match the individual bank payments to outstanding invoices, credit invoices, customers etc. Any transaction not related to customer payments, such as interest, bank fees, internal transfers etc. will be essentially ignored. These transactions will need to be transferred to the accounting system for processing. 

Salesforce will generate balanced journal entries based on the payment method, processor, account, customer type, product, and all other defining criteria for the general ledger.

Net vs Gross payouts

One of the biggest challenges in balancing incoming payments with outstanding balances through the bank, is the fact that not all payment processors transfer the gross amount. When handling online payments through credit cards or other online payment methods, for instance, often the payment processor will subtract the fees before transferring the money. This leads to a discrepancy between the outstanding invoices and the received amount, where the latter might not cover the full expected invoice amount. And you would need to have a detailed breakdown of what invoices are included in this payout in order for the reconciliation to work. This is where FinDock on Salesforce helps with providing that detailed breakdown out of the box. 

By booking all these payments to a suspense account and balancing that out with the payout from the processor, combined with the invoice for the fees, the general ledger can balance the gross payment amounts with the net payout from the processor. All without the need to split that one net transaction across multiple accounts/invoices using a pdf breakdown and lots of manual work.

This principle can apply to a number of different scenarios from online payment processing to point of sale platforms.

The Payments data challenge

Balancing the Triangle means ensuring CRM, bank, and general ledger agree, not just on the totals, but on the detail behind every payment.

Whether you choose Replication or Relocation depends on your customer volumes, systems, and operational priorities. But in both models, accurate, timely customer payment data exchange is non-negotiable.

Next in this series: We’ll explore how Salesforce receives payment information from banks, PSPs, and other sources, and how FinDock’s Bank Feed and Guided Matching streamline the process.