Product Release: 1802

We are pleased to announce the latest release of Aqilla (1802) is now available to users.

Of particular note to many customers will be the introduction of a major new feature that allows the creation of Bank Transactions directly from imported Bank Statements. For a video on this click here.

Appealing especially to high volume bank transactions generated independently of Aqilla, users will able to automatically populate and process a Bank Transaction, applying rules at a system, bank account or creditor or creditor account level to filter out any that are not required (for example transactions already generated by the Aqilla Payments process) which will make the task quicker and more accurate.

A range of logic options from simple include and exclude to complex to “fuzzy” Regular Expression formats are available. Any statement format currently available for use with the Aqilla Automatic Bank Reconciliation process will be supported. Full details can be found below.

Along with a range of other enhancements it is now possible to pre-set any VAT code against a creditor or debtor account which prevents the VAT code being amended by a user whilst entering an invoice and is not overridden by any VAT codes defined against Items.

In addition and in response to feedback from users it now possible to set a flag in the Company Information Configuration screen to allow subsequent amendment and update of comments and attachments on posted documents. This is useful when one might, for example, wish to update the comments on an invoice awaiting payment or for example adding completion contract documentation to a sales invoice.

Full details of the principal enhancements in this release are as follows:

Bank Transactions created from Bank Statements

The Bank Transaction document now has two additional buttons:

Upload statement file. This is the same option that is available in Automatic Bank Reconciliation and a file may be uploaded in either function to be available to Bank Transactions.

Import Transactions. Import transactions from the uploaded statements with transaction dates up to the Document Date specified in the header of the Bank Transaction document. This will populate the document with any statement transaction that has not been already reconciled in the Automatic Bank Reconciliation function or has not been imported into another Bank Transaction document. Note that when first starting to use this feature, it is best to ensure that the bank reconciliation is up to date to avoid importing transactions that may have been already manually entered.

The bank transaction document will be populated similarly to the example below.

At this stage, no rules have been defined and the document is asking the user to specify the correct account for each line. The user may also delete lines or manually add lines.

As each line is completed, an icon is displayed to the left of the Account indicating whether any rules have been defined against the account (green icon) or no rules (grey icon).

In order to automate the identification of an account in future documents, the user may define matching rules. Clicking on the icon displays the rule definition dialog.

The setting of the rules is dependent on the information available from the bank statement. The rules can be based on either the Reference or Description. The most common and default option is to define an Accept rule where the Description Starts With a specified string.

Note that the rule needs to be defined to uniquely identify the account but to allow for variations in the description from one statement to another. For example, the above rule is checking the description starts with “Mobile phone rentals” and not “Mobile phone rentals Jan”.

The types of action are as follows (together with their negative equivalents):

  • Contains. True if the variable contains exactly the argument.
  • Contains At Position. As above, but at the designated position.
  • Contains Word. True if all words from the argument exist as words in the variable, ignoring whitespaces.
  • Ends With. True if ends exactly with the argument.
  • Equals. True if exact match.
  • Is Blank.
  • Starts With. True if starts exactly with the argument.
  • Case-sensitive: Less, Less or Equals, Greater, Greater or Equals. Alphanumeric comparison.
  • Case-insensitive: Less, Less or Equals, Greater, Greater or Equals. Alphanumeric comparison.
  • Matches Regular Expression: This is a complex expression language for situations not covered by the normal actions. A description of its features is outside the scope of this document.

An account may have multiple rules defined and each rule can have multiple conditions.

Rules may also be defined to Reject i.e. not match this account on certain conditions.

These account rules may also be reviewed or edited in the accounts summary or detailed functions – users will note a new column labeled “Import Rules” on Debtor, Creditor and General Ledger Summary screens. Clicking on the icon takes you straight to the rules editor for the selected account. If one or more rules is being applied to an individual account the icon is displayed in green.

The example so far assumes that you wish to import all bank statement lines into a bank transaction but in practice certain transaction types may be created in Aqilla by other means such as processing Payments. A set of common rules can be defined to filter out such transactions. This is accessed under the Configuration tab using the Bank Transactions Import Common Rules function.

The example above rejects any statement transaction that has a Reference of DIRECTDEBIT.

Strip Values Rules are designed to adjust the information in the bank statement to either simplify the matching conditions or improve the information being copied into Aqilla.

For instance, the statement description might contain some superfluous information such as “Payment payee name” where only “payee name” is required.

NOTE: In the initial release, there is an issue if there are any mandatory attributes that have been configured in the bank transaction document line. These will not be validated if the account has been automatically set by a matching rule.

Payments and Debits Process Enhancements

  1. The Total Due shown in the header area has been changed to show the Total to Pay. This is the total that has been selected to be paid taking into account any suppressed accounts.
  2. When the Pay or Pay & Remit buttons are selected the confirmation dialog displays the number of accounts to be paid and the total to pay.

The same enhancements have also been applied to the Debits process.

Document Enquiries – Additional Selection Criteria

Additional selection criteria is now available through the use of the “More Selections …”.

The example above enables invoices to be selected by currency code.

Pre-set VAT Codes

It is now possible to pre-set any VAT code against a creditor or debtor account. Previously it was only possible to pre-set not reported codes.

Note that pre-setting a VAT code against an account prevents the VAT code being amended by a user whilst entering an invoice and is not overridden by nya VAT codes defined against Items.

Account & Ledger Enquiry – Period Name

It is now possible to display the name of the period that a transaction relates to as well as the Period Posted Date. This can be useful when periods do not correspond to calendar months.

If you would like to have the period name displayed, contact support at and they will configure your system.

E-book: Dispelling the (five) myths of accounting in the Cloud

Month or year end doesn’t have to be slow or difficult. Here is a best practice guide to the busiest times of the accounting and finance year with 5 tips to facilitate a quicker and more efficient period end.