The magic of matching

What is matching about ?

Matching is about taking a bank transaction (BTX) and deriving what it means in the Civi world. Let's call that the CTX (Civi transaction) representing the cluster of entities that represent the semantic interpretation of the BTX. So potentially, a BTX is converted into a CTX containing a contribution linked to an existing contact, or a contribution linked to a membership linked to a new contact.

The questions to be answered are

• who is this BTX related to (who's the contact in the CTX)
• what does this BTX represent (what should the rest of the CYX contain)

A couple of remarks and observations of how people match stuff 'manually' :

1. first observation people make is what they call the 'type' of transaction : it's a way of quickly classifying a BTX as interesting or not, like in 'this is an invoice payment by us, not interesting'. So early on in the matching process, people tend to use patterns to detect the category of a BTX as a means of deciding the type of processing it needs to get. So in most implementations, there will be rules with a lot of weight (read: triggering early) which will classify a BTX, which suggests we would provide some form of tagging or typing on BTXs.
2. the first question answered is 'who is this about'. The reason for this is that the contact provides a context (a link to the current CTX) which can help explain what the BTX represents. The 'who' can be answered by looking up name, address etc. info on the payment against contacts, but also happens when there is an identifiable context (like a payment reference) which directly identifies the contact, and which is typically pre-existing (membership reference, pay-later contribution, ...). So rules looking for identifiable contexts will also trigger early.

Describing matching rules

Here's some examples. First off, let's throw away uninteresting BTXs :

if we are paying (BTX.amount < 0) and the purpose of the payment has the form 'NNN/NNNN/NNNNN' then the type of BTX is 'paying a supplier' and there is no CTX

or also

if we are receiving money and the purpose of the payment matches 'VFnn/nnnnn' then its money received for an invoice we sent, and accounting will handle it

Right, so that leaves the interesting ones. Let's see if we can take out membership renewals. We'll expect a number of conditions there : an existing contact, an active membership, the correct amount and/or a specific reference (like a membership number). Let's break that down into pieces :

• an existing contact : meaning, the bank account used is recognized and we have it linked to an existing contact
• active membership : the contact has an active membership
• correct amount : let's say membership fees are 25 EUR
• reference : we have asked people to mention 'membership' and their membership number

OK, but there are potential issues here. Perhaps we have already seen the bank account but have not tied it to a contact yet. Memberships may come in different types with different prices. What defines an 'active' membership -- perhaps we should look for memberships in a particular status (like expired). How about family or organisation memberships ? What about discounts, early-bird rates, combo pricing etc ? Yes, it can get complex. Here's where probabilities can help, by allowing each element to contribute to the total probability of the match.