Comment 1 for bug 537362

I'm afraid no matching algorithm isn't going to be 'full proof' to cover all possibilities. Even humans make mistakes. I can see your point, but there is a reason why all this was coded the way it is.

1. This covers two cases:
  a) The payer adds text to the reference number, say invoice was '2009.03' and payment says 'Factuur 2009.03'
  b) There is a payer is a different party than the one the invoice was sent to, which is quite common.

  This can be improved by requiring an exact match for b) and extending a) with a similarity match on name, although neither are very sound.
  Also it helps big time to make your invoice references longer. The shorter, the greater chance of false positives.

2. When the invoice was credited, this is a valid match. Same for incoming payments and incoming invoices.

3. This creates false positives, indeed. Can be enhanced by keeping track of matched invoices. I'll pick that up.

4. I'm not sure I understand your point. Amount matching is only performed when no exact match on other identifiers can be made. When there are multiple identical positives within this context, I can see no way to make a safe and valid choice. If you have some smart ideas, I welcome your input.