Reconciliation with CRM payment data

So, you have decided to bring your payments to your CRM. Either because you want to tailor the payment experience to the expectations of each customer, you want your team to make more data-driven decisions or because you want to increase operational efficiency by incorporating payments into the customer 360.

In this blog, I’d like to talk about the last of those three, operation efficiency. One under-appreciated fact about bringing payments to your CRM, is the new dynamic between CRM and your Accounting System (AS). When done right, it can lower reporting demands on your finance department, simplify certain processes and even lower the configuration complexity of your AS.

Payment data as customer data

Traditionally, the distinction between a CRM system such as Salesforce and the accounting system was pretty clear. The CRM deals with details about people, and the AS deals with finance transactions and payments. Even within ERP systems, customer and financial features were kept separate.

Today, as the world moves toward customer-centric thinking. More organisations want to enhance their payment journeys using their customer data. And since they manage and maintain their customer 360 from the CRM system, more and more, payment management is moved to the CRM system where payment data is treated as customer data.

This change causes a shift in the application landscape. Previously payment information was exchanged between the bank and your AS (and sometimes your payment gateway, more on that in a future blog), we now add CRM to this process.

One key element to remember is that payment management often has a different meaning when approached from a CRM (customer & execution focused) perspective as opposed to the AS perspective (reporting focused). Both are essential to the overall process, so we can’t simply “replace” the AS with the CRM. They have to work in conjunction with each other.

How do we integrate two different perspectives and roles in the overall payment management process into one application landscape with a logical flow of information?

The triangle

The triangle of reconciliationOne simplified but helpful way of thinking about this is the triangle of reconciliation. We have the bank at the top. Your bank accounts have every single transaction, both credit and debit, of your organisation. After all, all money eventually goes through a bank account, including money captured via a payment service provider or other external processor.

The AS has all the organisation’s money accounted for. All credit and debit is meticulously tracked and recorded. As such, this is the only system that can give you a complete insight into the full financial status of the organisation.

Finally we have the CRM system. This system usually only has a subset of all payment data, namely those transactions that pertain to the customer 360 such as invoice payments, donations, refunds and reversals.
Context based insights

Traditionally, the finance department is the primary source of reports as they used to be the only department able to enrich reports with actual financial data such as ROI on campaigns, popular payment methods and unpaid invoices.

However, this has always been a challenge. Not every AS is designed to handle all these reporting dimensions, and what’s more, a lot of this information doesn’t actually originate from the accounting system at all but is stored in the CRM.

Consider the following example:

Your reporting requirement includes the ability to report on which payment methods are most popular in terms of highest amounts as well as number of transactions at certain times of day. You need to compare that across particular direct mail and online ad campaigns.

For every transaction, your finance system would have to keep track of:

• Payment method
• Payment channel
• Campaign, project or other cause for the transaction

In some cases, this might be a complex multi-variable calculation based on customer campaign participation and detailed analysis of the payment service provider notifications. For instance, a Google Pay transaction might be a regular credit card transaction, paid via Google Pay.

To capture all this in the AS is no trivial task. The AS needs to have a record of every campaign activity, a way to capture communication and payment channels, and so forth. All this contextual information is already captured in your CRM, and a good CRM-based payment management solution like FinDock will be able to put every payment in the correct context of campaigns, channels and payment methods to enrich the customer 360.

By adding payment data to your CRM, you can really start to leverage the customer 360 because the CRM can:

• Distill all that complex context around the payment down to the specific ledger information and reporting dimensions to benefit the reporting requirements of the AS.
• Provide the compiled data directly, allowing finance and fundraising to benefit from the flexibility, in the case of Salesforce, the CRM offers users in creating reports and dashboards quickly and easily.

So, having payments as an integral part of your CRM and customer 360 has clear advantages over keeping the data just in the AS. But this leaves the question: how is the payment data in CRM and AS related? In other words: is the payment data relocated or replicated?

Relocation or Replication

Which option is best for your organisation depends on your use case, reporting requirements, business processes and payment management solution. Ideally, your payment management solution in your CRM will be able to support both models, of course.

With relocation, as the name suggests, the payments are only stored in the CRM system. With replication the payment data is stored in both systems.

What do these two options look like in the context of our triangle of reconciliation?

In both scenarios, the CRM – through the payment management system – keeps a record of all payments, including those imported from your bank. It puts every payment into the relevant customer 360 and applies the reporting dimensions for context.

Also, in both cases the accounting system will have balance information for that same bank account. As such, it knows how much money has come and gone.

However, after that the two models diverge. With relocation, the AS treats the CRM as a sub-administrator, usually represented as a subledger. This means the AS can credit and debit nearly all transactions initially to the CRM subledger.

After CRM has processed all transactions and matched all the payments. the information is aggregated into journal entries based on the reporting dimensions required by the AS, such as b2c income, b2b income, recurring income, one-time income etc. – all the information needed by the AS to create the necessary and sometimes legally required reports.

Relocation is often used by organisations in the nonprofit sector. Typically, accounting systems don’t handle unsolicited payments very well. They expect invoices or some other form of accounts receivable to be present for a payment to be booked against. With unsolicited donations, we typically don’t have an invoice. The donor might not even be a contact in the system yet. Payment processing systems like FinDock that specialize in payments on Salesforce are better suited to handle these types of transactions.

With replication, both systems have the full set of customer related payment data. The CRM system doesn’t need to provide all details to the AS as the AS already has all the individual payments and booked them against their respective general ledgers.

That being said, CRM can still provide details for which the context isn’t readily available in the AS. For example, the CRM can easily identify the primary campaign source, or it could provide additional contact details for first time payers that are stored in the CRM but not in the AS.

In this scenario, however, the most important thing to do is compare the data. In order for both systems to be reliably used, everybody needs to be able to trust the quality of the payment data.

Replication is often used by organisations that, for instance, have a complex logistical process that is embedded in their ERP and partially driven by individual payments on invoices.

What about payment service providers?

Perhaps you are wondering now about how this applies to payments that don’t originate at the bank but at a payment service provider. In my next blog, I will take a look at how credit card payments fit into the triangle model.

I hope this gave you some food for thought on how to think about restructuring your application landscape around CRM and accounting systems. If you have any questions or thoughts on this subject, don’t hesitate to reach out!