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.