Closing the loop on payments data
Welcome to the third and final part of this blog series on the Triangle of Reconciliation. In the first part, we explored the concept of reconciliation between 3 systems as a triangle, in part two, we looked at overcoming the challenges of importing payment data into Salesforce. In this final piece, we’ll take a look at the matching process.
Let’s start with the question; How do we turn unstructured, chaotic data into information and link it to the right customer & invoice?
FinDocks answer: Guided Matching. It is designed to help you do just that, extract remittance information from transaction data, query the Salesforce standard and custom objects for related records, and finally match this to customers and invoices. Automated where-ever possible, and with minimal human guidance where needed.
Matching; sometimes easy, sometimes really complicated.
Matching inbound payment data to Salesforce customer records can sometimes be really straightforward, if the customer copies over the invoice reference exactly as it’s stored in the database, or includes their customer id, matching becomes a breeze. However, in most cases, we are not so lucky and have to extract and clean data before we can even start to use it. Common issues we see with inbound transactional data include:
- Customer omitting or mistyping (parts) of the payment reference
- Customers listing multiple references in a single transaction
- Mistakes in the amount transferred, leading to over- or underpayments
This lack of correct or complete remittance information often leads to manual work. And unfortunately, when people have to do manual work, people make mistakes. In this case, causing incorrect allocations, leading to time-consuming corrections and lower data quality.
Flexible, Collaborative matching at speed
To combat this problem, in 2018 we started designing and building Guided Matching. Over the years, this functionality has had many, many updates and improvements and now is cornerstone functionality for reconciliation in FinDock. Responsible for parsing, matching, and reconciling all inbound payments data. What really sets Guided Matching apart from most, is its incredible flexibility, speed, and its collaborative approach.
To start with the latter, Guided Matching will not simply sift transactions into “Matched” and “Do manually”, while it might require human input on specific data points, it will then try and continue fully automatically. Essentially only asking for human intervention on what it can’t or isn’t allowed to do on its own. This speeds up the process tremendously and ensures that the whole process is as consistent as possible.
Through its configurable rules and settings, Guided Matching can fit almost any business process for matching. It can extract remittance information, and use that information to find relevant data in your Salesforce data model, even if that information is stored in custom fields, or even custom objects. This allows Guided Matching to be adjusted to almost any situation and be used to great effect in processing bank transactions, but also payment service provider notifications and even Payment Intent API requests. And perhaps its most technically amazing feature, is the speed at which Guided Matching is able to do its work. Built on a custom-designed a-sync Apex framework, it is capable of handling thousands of records per minute. While automated retry mechanisms ensure that locked-row errors are mitigated as much as possible.
With Guided Matching, National Youth Orchestra was able to achieve an automated matching rate of 99.9%.
Rule-based field enrichment
Every matching type (specific bank statement, file format, or PSP notification) has its own specific ruleset. Some of these rulesets will be based on your business process and rules around matching transactions on a particular bank account or imported through a specific file, others are FinDock standard rulesets from processing payment service provider notifications for instance. Each ruleset consists of rules designed to extract and normalize data, enrich fields, or find data in Salesforce. In essence, rules are intended to provide data to the field they are configured on. In the example here, we can see a number of different rules on both Contact and Account fields to identify the correct customer. Some of this information has to be surfaced by other rules before it can be used here. As such, rule ordering is based on the rules themselves and not on the fields.
A typical workflow in Guided Matching is to:
- Extract information using pattern recognition
- Normalise that information so it can be used to search with
- Search Salesforce for a record referring the extracted information
- Use that record to find the related customer and/or installment.
All of these steps are modelled as rules in the Guided Matching setup and executed as part of the ruleset when it is used to match, for instance a bank transaction.
What was very important to us, from the very beginning, is transparency. We did not want Guided Matching to be a black box, but give insight into how it processed the data, what rules have been executed etc. To this end we have a full detailed log of all the guided matching activity on each record, which is parsed into a visual overview in the Guided Matching Progress component. Using this, any finance employee can trace and audit not just the outcome, but the actual process, they can see why a transaction was matched the way it is. What rules have been executed and the outcome of each rule.
This insight into the inner workings of the matching gives controllers and auditors confidence and trust that each transaction was correctly processed. After all, ‘Trust, but verify” is a key principle in due diligence for finance!
Some examples:
The best way to see how Guided Matching works, is by looking at some example transactions and how Guided Matching matched them.
Multiple invoice references
In this transaction, there is no end-to-end id, and only a written message containing multiple invoice references. Alongside the regular information about each transaction of course, IBAN, value date, credit/debit indicator etc.
Based on pattern recognition and extraction rules, Guided Matching correctly identifies first the 3 invoice references.
Next, it uses the IBAN on the transaction to find the customer.
Now we have two points to match against, the invoice reference and the customer. With these data points, Guided Matching selects the installments for those invoices and matches the transaction against them. Automatically dividing the money across the different open invoices in the order we specified (in this case, low to high).
Notice how the final installment is marked as partially paid, this is because the transaction amount was not sufficient to cover the full open amount. We could configure Guided Matching to ask a human for help, but in this case it simply processed the payment. Now, reporting or process automation can be used to trigger a follow-up process to recover the remainder of that invoice.
Duplicate IBAN found
With this transaction we also try to find the correct customer, but here we encounter a problem. The same IBAN is found connected to two different customers. This is cause for alarm as it might have implications for the data quality in our org. Guided Matching could in theory still apply additional criteria to determine the correct record. Such as inclusion of the Holder name. But in this case, we opted to let a human take the decision. By presenting a list of possible options, guided matching allows for quick resolution, allowing the process to continue quickly.
Search by name
Invoice references, end-to-end id’s, and IBANs are great for finding the relevant information. But sometimes that information is not available or not complete. Notice how in this transaction, the payment reference doesn’t contain a full invoice reference. If we also can’t find the customer by IBAN, we should perhaps search through invoices ending in 044, but since we are handling B2B transactions in this example, a search by name is actually a very valid option. Searching by name on consumers is much harder, since there is much more duplication compared to businesses. By finding the relevant customer by name, we can then easily select the correct invoice from the list. Again, this could be more automated, but since with a search by name, a human verification is a good idea, for the sake of simplicity we use a list and ask a human to select.
Payment Intent API
Finally, let’s look at a totally different example.
This is how Guided Matching handles the inbound Payment Intent API call for a PayLink. We extract the unique identifier from the API call, find the relevant installment, find the customer record (in this case, the contact portion of the person account FinDock is stored on the installment, hence the extra step to get the correct customer)
And finally, the installment is updated with the new payment method.
This is then resolved when Stripe sends the “charge.succeeded” message, which is also resolved by Guided Matching.
The “Is it my turn?” rule ensures the ordering of the messages in the asynchronous context and makes processing this message wait until the payment intent call has been completed.This is a way of ensuring order of operations. When many messages or tasks are flowing through the system, you don’t want them processed out of order. The “Is it my turn?” rule means each message checks whether it’s next in line before being handled. Then the message can be acted upon and the installment is marked as “Collected” and the payment created.
All of this shows how versatile Guided Matching really is in handling the different types of inbound payments data, from completed bank transactions, to API calls and PSP notifications.
Extending Guided Matching even further
But sometimes Guided Matching alone is not enough. Despite the flexibility and power of Guided Matching, sometimes you need that little bit of extra control or a very complex query to find the results you need.
Formulas, Apex and Flow
Every rule in Guided Matching has the “Update And Refresh Before Processing” checkbox. This incredibly powerful feature allows Guided Matching to store and re-query the record it is processing prior to executing the rule. This refreshes all formula fields on the record, allowing you to use the new value in other rules, but more importantly, it also fires all Apex and flow triggers. This means you can have a flow run just before the rule is executed, performing actions, querying records and updating values. The possibilities are endless. The choice between Flow and Apex usually has to do with whatever you are more comfortable with, or with volume based assessments. If you expect this ruleset to execute tens, or even hundreds of thousands of records on a regular basis, Apex might be better suited for the job. Most of the time, Flow will perform perfectly fine, and using some checkboxes and conditional visibility, you could even run a screenflow as part of the guided matching process!
Agentforce
Guided Matching is at its core a deterministic system. It is built from logic steps and auditable if-then-else constructs. As opposed to modern AI systems, which are less predictable.
A deterministic system is a system that operates with no randomness, meaning it will always produce the same output or sequence of states when given the same initial conditions and inputs.
Predictability and auditability is exactly what you want from a matching and reconciliation system. However, there are instances where AI can play a role, specifically its ability to understand and interpret human text.
Take this transaction for example:
Notice how the payment reference has a list of instructions, however, these instructions are not formatted in a way which can be reliably extracted by Guided Matching, and even if we could read this exact phrasing, if the next donor uses the description “water 20, education 30 and the rest to biodiversity” it becomes completely impossible to make any sense of it using pattern recognition or if-then clauses.
That is where the modern LLM based AI’s like Agentforce come into play. Using Agentforce we can easily let the AI model interpret the data, extract the meaning and provide us with the correct actions.
Leading to a fully automatic list of new donations, all assigned to the correct campaign and with the correct amount.
Where before, this had to be handled by a human agent, we can now utilize agentic AI to quickly and automatically match, process, and reconcile these complex transactions. All while maintaining auditability.
Guided Matching helps complete the triangle
Regardless of whether you use Relocation or Replication, Guided Matching helps Salesforce make sense of the incoming payments data by matching it to relevant information. This is the basis on which aggregated or detailed Journal Entries can be created to feed into the general ledger.
Guided Matching makes the process faster by reducing manual workload through automation and a reduction in faulty matches. This is what ultimately makes the Triangle possible, without GM, it would be a very time-consuming process to implement and maintain, but with GM in place, matching and reconciling inbound payments data becomes substantially easier.
If you’d like to learn more about how Guided Matching can impact the Triangle of Reconciliation in your organization, reach out to us! We’re always happy to talk!