Blog by Frederik Ahring Larsen
A higher auto-match percentage is directly correlated with more automation, less errors, and more flow in your daily business processes. A lot of companies accept status quo for the auto-matching instead of working to improve this key factor.
In this post, I will try to summarize a few things you can do to analyse and improve your auto-match logic.
What is a match percentage:
A match percentage is the amount of transactions, incoming or outgoing, that are matched with either a high or medium match. That means the amount of transaction that the system can settle automatically so they are ready for posting without user interference.
| High (Green) | A high-level match is achieved if we via unique references are able to find the invoice or invoices that the customer has paid (eg. payment ID, invoice number, end-to-end references). |
| Medium (Yellow) | A medium-level match means that there are no unique references available to identify invoices. Instead, we use the other unstructured information from the bank to identify the customer, after which an advanced algorithm ensures, via the amount, to find paid invoices (eg customer number, name, account number). |
| Low (Red) | A low-level match is achieved if the payment was matched against a customer or vendor, but was not able to identify, which open invoices/transactions to settle. In general a low match always originates from either a rule, high, or medium match, but has been degraded, because the settlement could not be completed, e.g. because of amount differences. |
| None (White) | The auto match was not executed or was not able to match the payment. |
Look at Outgoing payments and incoming payment separately
If your company doesn’t split your payment journals into outgoing and incoming journals, don’t worry.
The logic of the two directions is different, so figuring out where your manual labour goes to might make sense. Your customer payments are tricky, as a lot is outside your control, but vendor payments is your domain and can often be improved.
100% of payments debited from your account should be automatically settled
Payments created in AMC Banking Payment Journals are automatically matched using the end-to-end reference. If you create your posting journals from your CAMT.053 account statement, which I often recommend doing, you will also see bank fees, tax payments, currency fees and whatever else might exit your account.
Whenever you see a transaction that you must manually post to a ledger account, ask yourself: Will this recur and when it does how will it look? Search strings is of course the tool to use here to teach the system how specific payments should be booked based on a string.
The only thing left, is payments created outside of AMC Banking. It might be that there are good reasons to create a payment directly in the bank, but I can’t think of any, and any working time you might save from not creating it as a manual payment in AMC Banking will be lost again when it is time to post it.
Customer payments
CCustomer payments are unpredictable, and the harshest kinds of payments to master. Getting these up to a 100% match is like chasing a rainbow. You will never catch it perfectly, but a small step to the right could improve your horizontal view drastically. So let’s take a look at some of the steps you can take to improve the viewpoint of your unmatchable customer payments.
Choosing the right filetype:
A high match on customer payments is very dependable on the level of data in the files that create the posting journals.
The files that create posting journals are “payment specification files” – in ISO20022 jargon it’s CAMT.054C and CAMT.054D with one containing credits and one containing debits.
There are two options to get these files
- You get them from the bank
- AMC builds them based on your CAMT.053 (Account statement)
I will often recommend only importing the CAMT.053 due to the sheer simplicity of importing only a single file, and for most banks the CAMT.053 contains all the necessary information to do so. But it does happen that for certain banks the level of data is not sufficient to catch all the information your customers have provided you with and you will need to supplement with CAMT.054’s or other payment specification files.
If you are unsure about this, ask AMC to help you.
References and identifiers
AMC auto-match logic can usually find the correct customer and invoice based on data like customer name, customer account number, bank account etc. but if your customer stamps a unique reference like an invoice number or payment ID to a payment the system will find and apply it in no time.
Encourage your customers to write invoice numbers or payment ID’s in their payments, and make sure to do the same to your vendors, it’s common courtesy.
If your business is based in Scandinavia utilize the Nordic reference payments (FIK, Giro, KID) wherever possible.
Be wary of the low match
Low match means we identify the customer, but the amounts doesn’t mLow match means we identify the customer, but the amounts doesn’t match an invoice. This is usually due to an error on the customer’s side of an under- or overpayment. If you spent a lot of time handling these types of differences, consider extending your penny difference limit or accepted under- or underpayment limit in the accounts receivables parameters. Is it worth it to make the decision each time if you accept a few EUR difference? Usually not, and having strict rules makes it easier for the finance team to know whether the remainder should be paid by the customer or not.
Back to Search Strings
Search strings should get their own blog post as there is much to say, but for now just know, that they are a great tool for capturing the last posting-bits whenever you see a pattern in your payments that the auto-match can automatically settle. But note also that search strings are prioritized before anything else in the auto-match logic, so overusing them is not worth it.
Extension to the auto-match
You can easily adjust the prioritizing of the auto-match logic under AMC Banking -> setup -> automatch and apply specific auto-match priority lists on bank levels or even bank account levels.
The auto-match can also be extended to take new fields into account, this is especially useful if you have integrations to other systems for customer invoice handling, if you have added extra fields to customer cards, or if you simply wish to use other fields in the matching process than the standards AMC provides.
The logic is built to be extended, but will require a small customization delivered by AMC, reach out to us to hear more about it.
There you have it, my advice on improving your auto-match percentage level, hopefully you’ve gained something useful to apply to your own company, the most important part is the mindset, and looking at your postings as something that can be improved over time.