FINANCE DEPARTMENTS: RETHINK TRANSACTION MATCHING RECONCILIATION Save up to 80% of your time by identifying and overcoming commonly overlooked

Transcription

1 FINANCE DEPARTMENTS: RETHINK TRANSACTION MATCHING RECONCILIATION Save up to 80% of your time by identifying and overcoming commonly overlooked challenges

2 FINANCE DEPARTMENTS: RETHINK TRANSACTION MATCHING RECONCILIATION Save up to 80% of your time by identifying and overcoming commonly overlooked challenges For many finance departments, several of the serious challenges in transaction matching are often overlooked. This is largely because the exception matching process is so time-consuming and tedious without the proper tools. This document aims to help you identify, overcome and master these challenges. With a thorough review of the typical tasks and solutions related to transaction matching, you can find better ways to both utilize your time and reduce risk. The best practices outlined here serve as a guide to choosing the most effective tools and processes for your own organization, regardless of your current approach. Whether you use an in-house ERP system, Excel or manual matching, you are certain to find some essential tips on how to take your financial reconciliations to the next level. This definitive guide to transaction matching reconciliation: > > Thoroughly outlines the overall and detailed tasks related to transaction matching reconciliation. > > Outlines both well known and lesser known challenges, the latter of which may be inefficiently managed. > > Critically reviews the benefits and shortcomings of usual solutions. > > Provides proven approaches based on industry best practice. > > Guides you toward choosing the best Transaction Matching process and necessary tools to use within your own organization. ADRA MATCH TRANSACTION MATCHING. PAGE 2

3 EXECUTIVE SUMMARY WE MAY BE EXPERTS BUT SOMETIMES WE FINANCE PEOPLE DON T KNOW Transaction Matching is extensively applied in every financial department. Therefore finance staff often think they have all the knowledge they need. But the process is surprisingly intricate and, even worse, often solved in unacceptable ways. WHY UNACCEPTABLE? The unacceptable ways of solving non-matching transaction make it difficult to ensure the correctness of the reported figures for the Month End Close (which transaction matching aims to improve) and create difficulties in meeting the demands of Governance, Risk and Compliance. Off course this is not acceptable from a practice standard perspective and, if investigated, could be deemed illegal. For instance, to be compatible with the Sarbanes Oxley Act, account reconciliation is identified as a key internal control activity. Even if this is not a law for all companies, many have the same demand. Inaccuracies in this area have already had severe business consequences and will continue to do so. Several investigators like Deloitte, EY, KPMG, Price- WaterhouseCoopers and more, have in many cases found inappropriate solutions to reconciliation issues. THE SOLUTION? GET TO THE ROOT OF THE PROBLEM. It is important to realize the intrinsic nature of Transaction Matching and to see it with open eyes, even though you and your department have extensive experience in applying it. This white paper is a step-by-step guide through every matching step, and each progressive threshold of complexity, to examine the complex nature of Transaction Matching. In order to meet your demands, you need the proper tools to address the level of complexity of your matching. Each chapter presents the pros and cons of doing the work manually, or in Excel, or in an Accounting/Enterprise Resource Planning system (ERP), or in a purpose-built tool. With this understanding you will be able to assess your current level of intrinsic transaction matching, and thus have a clear picture of which solution is best for your needs. A valuable solution choice matrix is presented at the end. CONTINUE ADRA MATCH TRANSACTION MATCHING. PAGE 3

4 CONCLUSIONS FREE ASSESSMENT Contact us >> ACCOUNTS Video >> IN ALMOST ALL CASES, YOU MUST AUTOMATE. Some companies spend 95 percent of their time focusing on the transactions that match. This leaves only 5 percent for the exception investigation, which then is poorly executed, resulting in unacceptable applied solutions. Automation can change this: If 100 percent of the companies described above used automated software, 5 percent of their time would be spent on handling the transactions that match, and 15 percent on proper investigation, solutions and reporting. In addition, many times the non-matching items are the result of poor quality routines, division of labor, etc. This can also be detected and addressed within the proper investigation process. The remaining 80 percent of time can then be spent on other more important and motivating tasks. YOU NEED A TRANSACTION MATCHING RECON CILIATION SOLUTION WITH THE FUNCTIONALITY TO MEET THE COMPLEXITY OF YOUR TRANS ACTION MATCHING. Without such a solution, it remains impossible to satisfactory investigate the exceptions with respect to Governance, Risk and Compliance (GRC). So which is sufficient for your demands: paper, pen and calculator, Excel, Accounting/ ERP-systems, or a purpose-built tool? Only by assessing the complexity of your transaction matching will you know for sure. In most cases, insufficient knowledge of the intrinsic transaction matching is a reason many companies lack the proper tools, making it practically impossible to solve the exceptions regardless of how much time is available. WEBINAR Click here >> WHAT TO DO NOW? > > Read the full White Paper. FREE TRIAL Click here >> > > Get a FREE assessment of your transaction matching needs by Adra Match reconciliation experts. > > Learn more about Adra Match ACCOUNTS the market-leading transaction matching tool. > > Get a custom quote for your business case. Talk to a sales representative. ADRA MATCH TRANSACTION MATCHING. PAGE 4

5 CONTENTS 1 TRANSACTION MATCHING RECONCILIATION 6 DEFINING TRANSACTION MATCHING 7 FOUR STEPS AND FOUR GENERIC METHODS 7 The four steps whichever method you use 7 The four methods 7 Any type of data, any type of transaction 8 STEP 1: DATA COLLECTION AND CONVERTING CHALLENGES 10 STEP 2: GETTING RID OF THE HORDES OF TRANSACTIONS THAT ALREADY MATCH 10 The unique matching reference (which isn t always unique ) 13 Do the easy one-to-one matches first 14 Deal with multiple data matching challenges 17 The detective search matches 19 STEP 3: INVESTIGATION AND EXCEPTION MANAGEMENT 20 The exceptions to the exceptions 23 STEP 4: CHECK CORRECTNESS AND REPORTING 24 Reporting at the click of a button 25 CONCLUSION 26 DON T TAKE OUR WORD FOR IT 26 SOLUTION CHOICE MATRIX ADRA MATCH TRANSACTION MATCHING. PAGE 5

6 DEFINING TRANSACTION MATCHING This White Paper deals with the area of Financial Reconciliation where the hordes of transactions from two different sources (whether debit versus credit, or bank account versus bank statement) must be reconciled by matching. The definition of transaction matching, in this context, is the process of comparing and matching corresponding transactions between two sets of data for a given period, which ultimately should be identical. The process also includes investigating the exceptions, finding errors to be corrected and/or identifying open posts to be reported. The frequency of transaction matching can span from daily, to weekly or monthly and include matching all transactions on the bank statement compared to those of the registered transactions on the bank account in the accounting system, or debit versus credit on a control account, etc. ADRA MATCH TRANSACTION MATCHING. PAGE 6

7 FOUR STEPS AND FOUR GENERIC METHODS We will describe the task, its challenges, as well as the pros and cons of carrying out the transaction matching in four different ways. THE FOUR STEPS WHICHEVER METHOD YOU USE In short, these are the four generic steps to all financial reconciliation matching: 1 Take the two data sets that need to be reconciled. Let s say you would like to automate your bank reconciliation. Initially you need to download the statement from the bank s website for a given period, before getting the corresponding general ledger from your accounting system for the same period. 2 3 Compare the data sets, and tick off the corresponding matching transactions. Investigate the unmatched transactions i.e. the list of exceptions. During your investigation you may actually find a way of matching some transactions, but sometimes faults are instead found in the Accounting process. If this is the case, a correcting journal entry has to be made into the Accounting system. This correcting journal entry is sometimes done with a statement explaining the identified fault, stemming from your investigation. 4 Report. The remaining and still unresolved transactions after your investigation are usually referred to as open transactions. They have to go into a report, which is signed off. If properly done this reconciliation matching should first be checked and then approved (and hence signed off) by another person, to ensure your Segregation of Duties, to reduce your exposure to risks of errors and fraud, and to improve your com pliance with regulatory and practice demands. Then this report is finalized and can be used for internal and external controls. The reports are sometimes used as supporting documentation in the month-end close process. FOUR GENERIC METHODS: > Manually > In Excel > Using an accounting/erp (Enterprise Resource Planning) system > Using a purpose-built software tool such as Adra Match ACCOUNTS ANY TYPE OF DATA, ANY TYPE OF TRANSACTION These simple four steps apply to all kinds of transaction matching processes. For example: Bank account versus bank statement reconciliation, cash & credit card reconciliation, sub-ledger reconciliation, inter-company reconciliation, debit versus credit recon ciliation in a control account, and so on. ADRA MATCH TRANSACTION MATCHING. PAGE 7

8 STEP 1/4 DATA COLLECTION AND CONVERTING CHALLENGES The first challenge in automating any matching is to get hold of the two data sets that need to be reconciled. Let s say you would like to automate your bank matching. Initially you need to get hold of the bank s statement on your account for a given period, and then get the corresponding general ledger account data for the same period, from your accounting system. IF DONE MANUALLY: If transaction matching is done by hand, you would typically have printouts from the two sources and manually tick off the matching ones. But since not all sources are easily printed in the date order, with the columns ordered as you need, you have a second challenge: data export. This is where many start using Excel. IF DONE IN EXCEL: Depending on which source data is to be matched, the process of getting the data can vary significantly. But normally the easiest way is to export data from the source system. There are many options here, like extracting data directly from the database using either so-called pull or push technologies. Data could also be fetched by transfer with an FTP service (File Transfer Protocol) or a secure FTP service. Among the more recent techniques are XML web services (extended Markup Language). Many of us are familiar with using files and most computer systems containing data can export a selection of data to a file. However, the lack of standards, or the fact that the few standards that exist are far too complex to use, has led to a multitude of file types and structures. OUR RECOMMENDATION is to use a so-called text file format for export with Comma Separated Values (CSV), in which all data is exported with a comma between each data field. This format is proven to provide a quick and easy way of getting data and works smoothly in cases where there are different systems from which data must be fetched. ADRA MATCH TRANSACTION MATCHING. PAGE 8

9 STEP 1/4 The third challenge is to ensure the exported data contains all the key elements of a transaction that you will need, for example the transactions, account, date, commenting text, amount, etc. Once all key elements are exported, data has to be restructured so that the two data sets are easily compared. Creating this structure involves looking into the files and identifying the key elements such as the date, amount, reference, text and other useful elements, and then mapping these to the same element field for the other data set perhaps into a new file or database. This is commonly known as converting the data. When this is done, your data collection challenge is overcome. Besides being time consuming, matching with Excel is also error prone. Once imported, data can be wrongly formatted (a numeric field can accidently be formatted as a text field) or accidently lost during reformatting due to a click of the mouse, a key stroke in the wrong cell or a comma in the wrong position. IF IN THE ACCOUNTING/ERP SYSTEM: Some companies use their Accounting/ERP System for transaction matching, which has limitations. Usually this is because it is difficult to manage data from other sources, for instance from another Accounting/ ERP System used in the Company group, or another sub ledger system. There are other limitations as well, which we will address later on. WITH A PURPOSE-BUILT SOFTWARE TOOL: Adra Match ACCOUNTS has a file/data converter that can handle literally all types of formats and structures. This is the easiest way of getting all the different files into a reconciliation system. Inside ACCOUNTS, during the initial set-up phase, data will be presented in a way that is easy to format, with columns in the best order, all of which makes it easy to compare different key elements with each other. The next time you have to match the same data, but for another period, this is automated, requiring just a click of the mouse. All data will be presented for your needs. Data is also thoroughly checked and never lost (every imported line receives a hidden identification, allowing full traceability including who has done what and when, regardless of matching or correcting action). ACCOUNTS also has advantages for larger companies with subsidiaries that use different financial Accounting systems/erp, as well as for inter-company reconciliations. This because the tool can import information from different systems, regardless of their differing file formats. ADRA MATCH TRANSACTION MATCHING. PAGE 9

10 STEP 2/4 GETTING RID OF THE HORDES OF TRANSACTIONS THAT ALREADY MATCH Once you ve overcome the data collection hurdle and compiled all the data you need in a clear, structured format so that the hordes of transactions from the two sources can be easily compared, you are ready to start the second step of the matching process: Ticking off everything that matches. THE UNIQUE MATCHING REFERENCE (WHICH ISN T ALWAYS UNIQUE ) The essence of matching sets of financial data is finding the unique reference in the first set of data that matches the same unique reference in the second data set. This might sound relatively simple, and many matches are, but one should beware! ONE TO ONE THE UNIQUE REFERENCE: In many types of financial reconciliation transactions, there is a clear and unique point of reference in the first set of data that corresponds to the same unique reference in the second set of data. This could be a number that appears on an invoice, purchase order, lease agreement or similar type of financial document. Date Bdate Period Reference Amount R V Text Acc. No Comment 28/07/ /07/ /2014 GL R GL CRD /07/ /07/ / R PAID BACS The unique match here is represented by the reference number (highlighted in orange), which appears in blue in the reference field of the GL account, and in yellow in the bank statement transaction, both in the reference and explanatory text fields. The example shown above is from Adra Match ACCOUNTS, a transaction matching software. As you can see, the bank uses both the transaction date and the booking date ( Bdate ). ADRA MATCH TRANSACTION MATCHING. PAGE 10

11 STEP 2/4 ONE TO ONE THE UNIQUE REFERENCE BY COMBINATION: However, in certain types of reconciliations, there may not be a unique reference number for a single, stand-alone transaction (e.g. from one of the data sets). When this problem arises, the solution is to combine the different elements into a single transaction that forms a unique joint reference or at least a reference that is unique enough for that transaction. Such unique references can be made up of different combinations: a customer number combined with the amount, or an amount combined with a lease agreement and its date, and so on. The important thing is that the different fields in one transaction makes up for the reference. While this might sound relatively straightforward, it can be complex in reality. For example, sometimes the fact that the unique reference combines two elements in a single transaction means that it is also valid for both transactions from the two different data sets. In other words, different key elements on both transactions in the two data set may allow the reference number to be unique enough to complete the match. The common factor in the solution above is that there is enough data for the unique and common reference, in just one transaction from the first data set versus just one other transaction in the second data set. This is what we refer to as a one-toone matching. That is: One transaction in the first data set matches another transaction in the second data set. Here is an example: Date Bdate Period Reference Amount R V Text Acc. No Comment 28/07/ /07/ / R /07/ /07/ /2014 GL R GL CRD The two fields that make up the unique reference here the date and the amount are identical in both transactions. But is this really a unique match, or was there a transaction a day earlier or later with the same amount? In this case is an odd sum that is unlikely to reappear. But what if it was ? Note here how the two amounts from the bank account (in yellow) match the sum on the bank statement (in blue). According to the rules in ACCOUNTS, one would first group transactions with the same references from the account on the same day and then test to see whether they may match a sum of one transaction in the bank statement within the same period and that there In Adra Match ACCOUNTS there is a checking rule so that these transactions can only be automatically matched if there is no other transaction with the same amount within a date range in the reconciliation rule (for instance, two bank days before and two bank days after the actual matching date). MANY TO ONE FOR THE UNIQUE REFERENCE: Unfortunately, you are certain to encounter more complex transactions when the unique enough reference that allows you to match transactions from the first set of data with transactions from the second set of data are not found in one transaction. Instead, they are found in several transactions in the first data set. For example, it could happen that several bank transfers on the bank statement might have been combined into a single journal entry by the financial clerk. We refer to this as many-to-one matching. Date Bdate Period Reference Amount R V Text Acc. No Comment 28/07/ /07/ /2014 BACS0027-9, R /07/ /07/ /2014 BACS R /07/ /07/ /2014 GL , R GL BACS is only one such match. In this example, the two bank transactions add up to a balancing figure in the ledger and all references match this is an example of a manyto-one match. Please note: In such matching, it is important to have two fields that are identical, such as the date and the reference BACS0027 (in orange). ADRA MATCH TRANSACTION MATCHING. PAGE 11

12 STEP 2/4 ONE TO MANY for the Unique Reference: You may also encounter situations that are the opposite to the example above that is, when one transaction in the first data set can only be matched by several transactions in the second data set. We refer to this as one-to-many matching. Date Bdate Period Reference Amount R V Text Acc. No Comment 28/07/ /07/ /2014-1, R BACS /07/ /07/ / , R BACS /07/ /07/ /2014 GL , R GL CRD In this instance, although there is no easily matched reference, it is still possible to make a match. The two bank statement transactions (in yellow) have several matching fields that can be grouped. In addition to the date, we know it is an account from which the payment has been received. This grouping is then compared against the sum in the general ledger account. Again, a check must be done to ensure that no other match is possible, such as two bank days earlier or later, before this is accepted, as there is no other unique reference between the two different sources, the bank accounts or the bank statement transactions. MANY TO MANY For the Unique Reference: The most complex type of data matching involves matching many transactions in the first set of data with many transactions in the second data set. We call this simply many-to-many matching. In such cases, different key elements in both transactions in the two data sets provide a unique enough reference that allows your match. Date Bdate Period Reference Amount R V Text Acc. No Comment 28/07/ /07/ /2014 BACS , R CHRG /07/ /07/ /2014 BACS , R NI /07/ /07/ /2014 PL0027 8, R BACS /07/ /07/ /2014 GL , R GL CRD /07/ /07/ /2014 GL , R GL CRD As shown above, the general ledger account (in blue) can be grouped by date range, reference and text fields, and is now ready for preparation. But the matching cannot be resolved until transactions on the bank statement (in yellow) have been grouped too. In this case, the date, reference and 0027 reference need to be present in the text fields. The ACCOUNTS software can then see that the sums are identical and create a match. Many companies use codes for cost centers, projects and other items that can also be used as matching and grouping criteria for automatic matching. This is a classic example of a many-many match. This matching is particularly challenging in a manual system. ADRA MATCH TRANSACTION MATCHING. PAGE 12

13 STEP 2/4 DO THE EASY ONE-TO-ONE MATCHES FIRST The easiest matches are those with clear and unique reference numbers in the one-to-one matching category. These typically consist of one transaction and can be matched fairly easily. The only extra attention that might be required is if you have to combine elements into one single transaction to get that unique enough reference. IF DONE MANUALLY: Manual matching using pen and paper typically allows you to match some transactions in a minute unless the volume of transactions is large. In such cases, it is not uncommon that productivity drops off due to the fact that it becomes a mundane and boring task. During manual matching, simple challenges can easily arise. For example, one source might list the transactions starting with the earliest date, whereas the other source might list them with the latest transaction on top. The columns could also be in different orders, making it trickier to reconcile. IF DONE IN EXCEL: The difficulties that arise in manual matching, as mentioned above, are one reason to start using Excel for this purpose. With Excel, data can then be imported, resorted and columns rearranged all to produce a uniform listing of the two data sets that makes it easier to compare and facilitates the search for the unique match. By using Excel when the transactions in the two data sources are identical or equal enough so it is easy to spot the common identifier, all of these transactions can be matched in a minute. But for semi-manual matching, you can match around six to seven transactions a minute. This usually makes it a bit easier on the human eye. The search function can also be used to help find matches and further speed up the matching, but it becomes a tedious process of cutting and pasting into dialogue boxes and manual marking. But Excel can also be error-prone. For example, when imported, data can be wrongly formatted (e.g. a numeric field accidentally formatted as a text field), and when reformatting data can be accidently lost by a click of the mouse, a keystroke in the wrong cell or a comma in the wrong position. For smaller businesses, because the number of accounts to be reconciled is relatively small, it makes sense to continue using spreadsheets. The team required to manage the financial close process is also relatively small (one or two finance staff), so there is also less room for data handling errors. However, as the number of accounts to be reconciled grows and the team managing your monthly close process is expanded, errors can easily find their way into the reconciliation process. Once a business has reached a certain size, it makes sense to move away from Excel spreadsheets, particularly for tasks like matching. Working at full capacity, the finance department of a large organization can easily generate up to five hundred spreadsheets a month so it s easy to see how errors and duplications can creep in. Over the past 30 years, spreadsheets have become the mainstay of finance departments, used for all sorts of tasks, from reconciliation to reporting and everything in between. Despite their popularity with finance staff, they still expose your business to massive margin for error. Although the projected rate of error when matching with spreadsheets is only %, for a company with a $1m turnover it represents a risk of $80,000-$180,000. What s more, the damage done can also affect public perception and trust in your brand, leading to less tangible but just as dangerous losses. See ADRA MATCH TRANSACTION MATCHING. PAGE 13

14 STEP 2/4 IF IN THE ACCOUNTING/ERP SYSTEM: Some systems are equipped with matching functions that enable the matching of transactions if there is a clear unique reference on both of the data sets. But since the Unique Reference is made up of a combination of data elements, these systems often run into problems, even within a single transaction. They are typically not built to manage a degree of complexity beyond simple one-to-one matching. A few of the very large ERP systems have this type of functionality, but this can often be complex and less than user friendly. IF IN A PURPOSE BUILD SOFTWARE TOOL: ACCOUNTS automatically matches one-to-one records even if the unique reference is consists of two or more elements together with a transaction, and even if the date is close to the proximity in time, and if there is only one such match in the banking days close to the time of the transaction. DEAL WITH MULTIPLE DATA MATCHING CHALLENGES The next topic within transaction matching is to review the one-to-many, many-to-one and many-to-many matches. As noted earlier, such situations arise when the unique enough and common reference is not found in one transaction, but in many. That is, the matching process involves many transactions in the second data set (one-to-many), many transactions in the first data set (many-to-one), in both data sets (many-to-many), or that the unique identifier is made up of information in several fields. Such types of transactions typically take much more effort and time to match. come in. You need to find combinations of partial sums that eventually end up with a match. Sometimes this can be done without spending too much time on calculations, but at times it can actually take hours to make a single match. When the work is tedious, time consuming and the match-finding tools are limited this is when it becomes easily to believe that things are good enough, leaving the remaining transactions to be dealt with in incorrect ways. This is one of the situations where compromises tend to be made concerning Governance, Risk and Compliance. To get a match, you may also need to bring in additional sources such as the accounts receivable/sales ledger or customer register. This can be helpful if you have a payment with an amount but no code information, yet you can get information about which other bank account the payment arrived from. If you have your customer register at hand, you may be able to spot which customer s bank account it is, and hence draw an accurate conclusion about which invoice has been paid in the Accounts Receivables. The calculator is needed to add up transactions from one source and add up transactions from another source, so you can see if they match C AC x # = M IF DONE MANUALLY: When done manually, the matching process generally involves a piece of paper and a calculator. Even if you have a fairly good matching reference, you might not know how many transactions from each column need to be added up before you get an exact match. This is where the paper and the calculator ADRA MATCH TRANSACTION MATCHING. PAGE 14

15 STEP 2/4 Usually this manual work results in several transactions being unmatched. And yet, they could have been matched it s just that the process is too complex process for manual matching. So, instead of the data being matched in this second step, it is moved to the next third step of investigation where it will take up valuable time. In other words, manual work is not so effective. Sometimes faults are found, such as a previously checked-off transaction that should be used for another match. Undoing a previously checked-off grows difficult as it can be difficult to know which other transaction it was paired with. As these faults increase, it often becomes too difficult to continue, and some people find that they need to start all over again. IF DONE IN EXCEL: Sometimes described as a Swiss-army knife for finance departments, Excel is often the tool that s instinctively turned to for making life easier. But is it really ideally suited for everything? To handle the one-to-many, many-to-one, and many-to-many transactions with Excel, you need to use various functions and sometimes do a bit of programming. There are several extreme challenges with using Excel in these cases, one of which is the Vlookup function, which is less than ideal for your reconciliation process. Vertical lookups, or Vlookups, return searches for a value (unique identifier) in columns of information (vertical lists) and return data associated with that value. Vlookup is a function that is most useful when you are repeatedly retrieving the same information from a large spreadsheet with different values, rather than for repeated searches for different criteria (where every match is different). The Vlookup function is usually executed by the user as follows: =vlookup(lookup_value, table_array, col_index_num). Lookup_value is the action to search for the unique identifier, for example a code. Table_array identifies the table where the value resides and Col_index_num is the column number where the values are located. Excel executes Vlookup by using a binary search technique to look up data. When searching through large amounts of data, the most efficient way for a program to retrieve results is to begin at the middle of the listed data. The program then determines which direction the required value is likely to be in, in relation to the middle value. It then searches the data on that side, repeating the method and narrowing the search until the value is found. Vlookup formula: vlookup(lookup_value, table_array, col_index_num) ADRA MATCH TRANSACTION MATCHING. PAGE 15

16 STEP 2/4 DO YOU SEE A PROBLEM? Although it is commonly used in Excel to retrieve spreadsheet information, Vlookup is nevertheless a database function. As a result, using it in Excel in this manner causes problems. One major challenge is that accountants do not base their work on roundings or approximates. Yet Vlookup returns only an approximate match by default, resulting in potentially incorrect results. Many users are unaware of this. An optional argument, [range_lookup] can then be added to the Vlookup formula to obtain exact matches. However, this search method requires data that is arranged in order. If the data is not organized prior to execution, inaccurate results can be produced. Since your business relies on details and accuracy, a binary search technique is liable to cause errors that can be catastrophic (remember The Vlookup function in Excel is merely one of many limitations associated with this software. It is also part of the reason Excel spreadsheets are liable to error rates of %. While this might sound insignificant, for a company with sales of 1,000,000, it equates to 80, ,000 no small sum. With Vlookup, Excel can help you find the matching data in the other data set, speeding up your reconciliation process. However, it does not make matching all that much quicker, since it involvess a complex process of finding the different elements that make up the unique and common reference. This still requires the human eye, thought and an exceedingly good memory to be effective. In finance departments, we know that keeping a security-relevant chronological record, or Audit Trail function, is of utmost importance. With so many transactions occurring in your business every day, how will you later be sure of how a match actu ally was made? Unfortunately, Excel has no traceability function, which becomes evident when you find a set of data that was previously used for a particular match, now is better suited for a different match. How do you backtrack? = 345 = = = = = = = = = = = = = = = = = 345 = = = = = = = = = 345 = = = = = = = = = 345 = = = = = = = = = = = = = = = = = 345 = = = = = = = = = 345 = = = = = = = = Another area of importance is Segregation of duties. Yes, Excel has read and write protection, but cannot trace who did what and how. In short, the strength of using spreadsheets is also part of the weakness. Their flexibility makes it possible for us to do practically anything with the tool. A great principle, however, is to not rely on Excel for your business processes but to look at purpose-built tools instead. IF IN THE ACCOUNTING/ERP SYSTEM: Some accounting systems have basic functions for matching, but most systems start to show their limitations when the Unique Reference includes several data elements. When the match is made over several fields in one transaction or more, it can be difficult to do the job. But a few of the very large ERP systems do have functions for matching even many-to-many. The system s lack of user-friendliness, however, is a common customer response. IF IN A PURPOSE-BUILT SOFTWARE TOOL: While the matched transactions above in Excel are done semi-manually, Adramatch ACCOUNTS matches transactions automatically even if they are many-to-many matches. In contrast to Excel, no user intervention is needed since the software is fully automatic. Should a roll-back be required, the tool knows exactly how to do it, meaning you won t be forced to remember the previous matching, along with other transactions for which you now need to find a new match. ADRA MATCH TRANSACTION MATCHING. PAGE 16

17 STEP 2/4 THE DETECTIVE SEARCH MATCHES However, in some cases the matching reference is only part of an element in a transaction. For example, on one side it could be something like banktx-12345, while on the other side it could read gl12345, where the matching reference is Date Bdate Period Reference Amount R V Text Acc. No Comment 28/07/ /07/ /2014 GL , R GL CRD /07/ /07/ /2014 BACS0039-2, R CHRG /07/ /07/ /2014 BACS R NI /07/ /07/ /2014 PL0039-5, R BACS Note here that the general ledger account transaction (in blue) has a text with a dash in the middle as well as a dash and an additional number after -13. The bank statement transactions (in yellow), however, do not just 0039 without a dash and no suffix. Knowing that this is the correct reference, this is easy enough to see. But if you have hordes of transactions, you need search criteria for all possible codes, regardless of dashes, prefixes or suffixes, which is not simple. Again, the ACCOUNTS solution is capable of matching here by seeing through the inconsistency in the data. IF DONE MANUALLY: If you do the detective work manually, it occasionally pays off, but rarely on a consistent basis over many transactions (remember that the examples above are easy ones). IF DONE IN EXCEL: If you use Excel and enter different search strings, and perhaps use programmed functions like Vlookup, you will be a more effective detective, spotting many corresponding transactions. But this usually requires entering the search string again and again. However, in many cases, identifying the many transactions that could make the match and making sure that the sums of these numbers adds up to the sum you are looking for, will mostly have to be calculated separately by you. If you later find that a better match could have been done, you have no automatic support for reversing it, or even finding the transaction that you now have unmatched. Many are convinced that Excel can improve transaction matching, although programming is needed. If programming has been to approximations, it usually becomes a trick to use the smart rules in the correct order whilst still demanding a lot of manual work such as building up the sums. Research reveals that despite Excel, transactions are not properly matched and resolved. Still it is tedious and time-consuming. Still problems exist. Therefore, this is usually the threshold for what one can match manually. This is also why many transactions that actually do have a complex match are not matched when you do it manually. Instead, transactions that could have been matched, transactions that are due to different errors or rounding, and true open posts are all clumped together. And they result in unnecessary write-offs or material misstatements. Don t forget that the unnecessary write-offs create additional minor challenges down the line in the accounting work due to the double entry logic, with one or several small loose ends creating errors in the precise logic of accounting. This is one reason for why finance staff often find it difficult to trust their own reported and reconciled figures. This is one reason why demands on Governance, Risk and Compliance are not met. Possible matches, errors and open posts are simply grouped together and therefore treated in a common and often incorrect way. Date Bdate Period Reference Amount R V Text Acc. No Comment 28/07/ /07/ /2014 BACS R CHRG /07/ /07/ /2014 BACS0027-7, R NI /07/ /07/ /2014 PL R BACS /07/ /07/ /2014 GL , R GL CRD /07/ /07/ /2014 GL , R GL CRD If one manages to separate the dates above in Excel and then search for in Excel, there is a match on two transactions in the general ledger account (in blue). But the match is made by three transactions in the bank statement where the search has to be 0027 (e.g. similar to the first search but without a dash). Even if programmed, Excel seldom helps by making it easy to search for similar but different criteria in two data sets, or to see that the sum for the blue account transactions matches the sum of the yellow bank statement transactions. Instead, these usually have to be calculated separately. Therefore you still have to do a lot of tedious manual work in Excel to get the job done. ADRA MATCH TRANSACTION MATCHING. PAGE 17

18 STEP 2/4 IF IN THE ACCOUNTING/ERP SYSTEM: Some accounting systems have functions for matching, but these can slows down their abilities since the Unique Reference is made up by a combination of data elements, which we already stated. Even in the few large ERP systems, a common response is that user friendliness is an issue. IF IN A PURPOSE BUILD SOFTWARE TOOL: In Adra Match ACCOUNTS there is a rules engine. One rule could be to search for the five digits at the end of an information block like banktx and see if the same five digits are present at the beginning of another information block, such as GL. In addition, it could check whether the sums of transactions in the first data set, versus the other data set, plus or minus two banking days can make a match, plus or minus a half Euro for instance. If so, this sum can be presented to the user who can now decide whether the deviation is a matter of rounding off by the payer or not. If the user accepts it as a match, an accounting journal for the correction of the half Euro can be generated. But there will not be one such set of rules. Instead, there will be many rules in which the first set of rules identifies and makes all the simple unique matches, and then execute the rule for the more and more complex matches. If there is a need to reverse a match later on, this can not only be easily done, but with full traceability. It is also easy to go over and match the transactions that are still unmatched. An in-depth description of the features and benefits of our pattern-based search functionality is outside the scope of this document. You will hopefully understand the possibilities it brings since we have many such rules that are applied for any transaction matching. With this tool, it does away with all the matches that actually do match, although several in complex ways, so the time can be spent on the ones that do not match. ADRA MATCH TRANSACTION MATCHING. PAGE 18

19 STEP 3/4 INVESTIGATION AND EXCEPTION MANAGEMENT The next step in the reconciliation process is to investigate the exceptions that is, the transactions that were not matched in the previous step. Even if there are relatively few compared to the hordes that have already been matched, there may still be many left if you have large volumes of transactions. The findings of your investigation into the unmatched transactions may take several different directions: 1) You may eventually find a match in this step, although this may be tricky, 2) There may be a transaction that is the result of an error, in which case a correction must be made in the source, or 3) You might reach the conclusion that some unmatched transactions will actually be resolved in the coming period, in which case these transactions should be registered as open, before being transferred to the next period where they will be resolved. In certain cases, your investigation might lead to the conclusion that some un-matched transactions will actually be resolved in the coming period. These transactions should then be registered as being open and transferred to the next period where they will be dissolved. But some transactions are dealt with in the wrong way, due to shortcomings in the way they are investigated. IF DONE MANUALLY: If you are matching manually, you will usually end up with more transactions to investigate than when using Excel or a purpose-build matching tool. Secondly, there might be simple exceptions that can be identified as errors or open postings that will be resolved in the next period. But because the complex exceptions are too complex to be resolved manually, they are often not treated correctly. As a result, they are clumped together and treated in one way errors, written off, or rolled forward although they probably should be resolved in different ways. These types of transactions also create challenges in the accounting process further down the line, due to its strict logic of maintaining a perfect balance between debits and credits. ADRA MATCH TRANSACTION MATCHING. PAGE 19

20 STEP 3/4 IF DONE IN EXCEL: Even if you are working in Excel, far too much time is often spent on data export, import to and restructuring, not to mention the manual and semi-manual matching involved, according to our research. Secondly, you will also be left with many more transactions to investigate, which together with the limited time available, implies you won t have the time to find all the actual matches. As a result, too little time is usually left for this third step investigation and exception management. If this is the case, the time you have left over for the investigation phase is usually severely reduced. In other words, instead of finding the true cause for the exceptions, simpler solutions are applied. In their research, the Global Best Practice team at Price Waterhouse Coopers found that many companies just roll the balance forward (Connected Thinking). Again, one reason for this is the limited time available to conduct a thorough investigation. What eats up all the time is matching all the transactions that already match. IF IN THE ACCOUNTING/ERP SYSTEM: Some accounting systems have functions for matching, but falter as the matching becomes more complex. For example, in situations that require a unique key from two fields (where none is the date field), or where more than two transactions are to be matched. Having support tools or functions for the investigation phase is uncommon. While a few large ERP systems have these functions, they often have problems related to user friendliness. IF IN A PURPOSE BUILD SOFTWARE TOOL: As you have now understood, our transaction matching software tool, ACCOUNTS, provides an efficient alternative. It automatically imports, restructures and matches so many more transactions in so little time that you will now only be presented with the few transactions that can t be matched, even for a complex automatic match. THE EXCEPTIONS TO THE EXCEPTIONS However, even if you have the best matching engine available, there are some transactions that should not be checked off automatically. They just have to be investigated, since sometimes they just do not make sense or can be difficult to determine given the information in front of you. Open Reconciled Search Reconcole The dates above are matching on these transactions, and the sums of the blue accounting transactions are just 0.35 away from the yellow bank statement transactions. But there is no field data reference that ensures this is a match. It could be a coincidence, especially since the reference fields for the blue transactions have two different numbers. It needs Debit Credit Count debit Count credit Ledger 2, Bank , Sum 0.35 Sum remaining Date Bdate Period Reference Amount R V Text Acc. No Comment 28/07/ /07/ /2014 PL0027-2, R BACS /07/ /07/ /2014 GL , R NS.SYSTELMPA /07/ /07/ /2014 GL , R NS.SYSTELMPA to be further investigated, particularly due to the deviation of Note: This picture also includes the tabs in ACCOUNTS allowing you to see only the open items, the reconciled items and the simple yet advanced search tab. As part of your investigation, you may want to cross check information from another source system. Or you may want to call or a colleague with the information to get his or her input. As a result of these cross checks, you may have to revoke some of your previous matches. In the process, you need to keep track of them too since at a later stage your investigation might lead you to the understanding that one of your previous matches has to be revised. ADRA MATCH TRANSACTION MATCHING. PAGE 20