MT940

MT940 is a common bank statement file across Europe. Cashbook has an integrated MT940 solution allows companies to upload a bank statement and algorithms are applied so that cash receipts and manual payments are automatically applied to customer invoices. The module can automate anything from 30-90% of your daily cash transactions.

The process begins with uploading a MT940 (or other bank format for that matter) bank statement into Cashbook. If the bank statement includes good quality reference data our solution can automatically suggest invoice allocations for accounts receivable transactions. We also suggest manual journal postings as well based upon the reference data in the bank statement. The word “suggest” is used as no automatic postings are completed, everything must be approved by the appropriate credit controller.

Some bank files do not provide standard, mandatory reference data records, specifically record 86, in the MT940 file format. Bank contacts should be requested to improve the data supplied.

The variation in automation from 30-80% depends upon the bank that your business is using and the way your customers pay you. We can easily assess the level of automation you are likely to get at no charge if you supply an example of one of your daily bank statements. This module can be implemented in the Benelux region or anywhere across Europe. Our experience has been excellent (70-90%) in Sweden, Finland, Norway, Germany, Switzerland, Austria, and The Netherlands, okay in France and Belgium (30-50%) and across the UK the auto-matching is limited (10-20%) due to the quality of the bank statement data. The good news is with SEPA changes to the structure of payment files, our auto-matching with the MT940 bank statement files will result in higher automation percentages in the future.

Features

  • JDBC access to multiple ERP systems either directly integrating with system data or via staging databases.
  • Can be adapted for any Bank globally.
  • Standard bank statement upload process no matter what bank/currency or ERP you are using.
  • Supports algorithms across customer numbers, invoices, sales orders, customer bank accounts, pick list, packing numbers, customer purchase orders, shipment numbers, sales orders.
  • Uploads and stores multiple bank accounts, bank statement numbers, opening and closing bank balances.
  • Excellent validation rules around postings
  • Reports on all cash automatically applied and manually matched.
  • Can alias bank statement information that is incoming to improve auto-matching and not-upload specific bank account details.
  • Caters for partial payments, credit/debit notes, unallocated payments, multiple discount terms, foreign exchange gain or losses, write-offs, bank charges, suspense account postings.
  • Integrated with Excel, EDI, PDF and Customer Lockbox Modules and Bank Reconciliation which enables usage with high and low volume customers
  • Multiple sites, environments or ERP systems can be catered for.
  • Where codes or ‘character strings’ are used to identify transaction types and / or amounts – example ‘SKT’ = discount – we will automatically code these references to specific general ledger accounts
  • Ability to view all bank statement information through Cashbook journals.

Benefits

  • Elimination of manual effort allows companies to allocate more staff time to other higher-value activities
  • Creates the ability to run Shared Service Centers without the need for a common ERP platform or version updates.
  • Global companies can employ a global solution for all sites across multiple different banks.

Project Example

The matching process will incorporate the following rules: Only numeric characters will be searched. Any non-numeric will be ignored with the exception of special characters ‘+’ (plus), ‘-‘ (minus or hyphen), ‘/’ (slash), ‘,’ and ‘ ‘ (space).

  • The process will start from the left and if no successful invoice matches are found then the search will end.
  • Identification of the AR Customer for each AR receipt is dependant on finding a complete document number that falls within the range of open documents for the company/entity. If a complete valid document number is not found, there will be no proposed matches for the transaction.
  • Invoice allocation records for each search will be restricted to the company/entity of each Bank Account
  • The proposed Matches will apply to invoices, credit notes and debit notes (all records with balances outstanding on the invoice allocation file)
  • Discount will be assumed in all cases. Cashbook will analyse from the customer payment the discount due date of the invoice and accept the discount if it is within a two days tolerance of the due date.
  • Any matches proposed by Cashbook’s MT940 solution will be available for amendment by the users. No updates take place in AR or the general ledger until the full Bank Statement journal is posted.
  • At each search step, as invoices are matched, the total amount of the transaction will be compared to the amount to be allocated against the selected invoices (including discount). If the remaining amount to be allocated (whether positive or negative) falls outside the defined variance, the next search step will be applied.
  • Searching will continue over the reference details until all references have been matched, even if the remaining amount equals zero. This will avoid omitting matches on invoice and credit notes of equal value.
  • Invoice ranges must include “-“ (with no spaces) between the two numeric fields. This separator shall be defined in a Java Bean Discriminator.

 

Sample Files

Below are 4 examples of customer payments with corresponding invoices found on the right hand side.
© Cashbook Ltd.

Dutch German French spanish Italian Portugeuse Swedish Danish Norweigan Finnish Polish Czech Japanese Chinese