Testing Accounting Software – Account Reconciliation

We’ve been testing accounting software for many years. And have become very familiar with one of the primary tasks that accountants undertake: Account reconciliation.

Ins and Outs of Account Reconciliation

Reliable accounting software — covering expenses, payroll, inventory, and more — is crucial for every business.

Account reconciliation has many rules that drive the operations in any accounting application. These rules are well known by accounting staff as part of their job knowledge. But, as we work on the software they will be using, we need to know the rules too.

Roles and permissions comprise one of the key principles in accounting and account reconciliation.

Only certain roles have access to certain accounts and these roles are able to certify or verify whether a transaction is valid or complete. This process is also very date sensitive as you can’t have someone go backward in time and change information.

Before we move to an example to explain the above, the following assumption should be clarified:

• Account reconciliation can be either on a single account or an account group for a certain period.
• Account group here refers to an uncertified group to simplify the example.

Two Types of Accounts Require Multiple Testing Paths

An example of this date sensitivity is that you can decertify accounts as of the add date, and include the accounts in a new group. This means you can add two types of accounts in a group. One kind is brand new, never-been-certified accounts while the other kind is already-certified accounts.

• Type 1 – Brand new accounts (never been certified)
• Type 2 – Already certified accounts

This provides flexibility for users to make decisions, allowing users to either add accounts of Type 1, Type 2 or both into a group. So, when testing “create a group” you need to consider the different types of accounts, both already certified and never before certified. There are also many other parameters to consider when adding different types of accounts into a group depending on user permissions and many other factors.

Let’s dig deeper into an example to help explain. Say that account #1000, “petty cash for dev department,” has been certified in 2016 of January and February. I want to add this account to the account group “petty cash of all departments,“ starting from the 2016 — January (an uncertified group). After users specify the add date of the account to the account group, pointing out from when this account reconciliation should be considered to be reconciled in an account group, the system/application will automatically proceed by decertifying the certified accounts after the “add date” because they have been added to a group that is not certified.

In short, for this case, the data can produce different system behaviors when testing the account reconciliation function.

After software engineers learn the “business” rules, there are many underlying nuances that we need to understand in order to conduct thorough testing.

Let’s continue diving into the example described above:

• What should we test for adding the second type of accounts to an account group?
• Having multiple accounts in an account group with the same add date.
• Having multiple accounts in an account group with different add dates.
• Having both type1 and type2 accounts in an account group.
• Having the same account in two account groups covering different periods.
• Trying to have the same account in two account groups for the same period.
• Having an account added to account group A, remove the account from the group; then add the same account to account group B for the same period.
• Having an account in an account group, update the add date from the period A (account not certified for) to period B (account certified for).
• Having an account in an account group, update the add date from the period A (account certified for) to period B (account not certified for).

Being able to develop the test scenarios above, you, as a QA engineer, need to understand account, account reconciliation and account group and their relationship.

What else should we check?

Oh, each account reconciliation has its own items, comments, documents, and others. And they all have their own lifecycle. More specifically, a piece of comment is alive or visible for a certain period or it can be carried forward to all future, non-certified reconciliation.

Based on this, you will have to test that:

• If adding the certified account with temporary comments for the certified reconciliation in a period, the comment should still be seen after adding to an account group.
• If adding the certified account with carry-forward comments for the certified reconciliation in a period, the comment should still be seen after adding to an account group.
• If adding the certified account with carry-forward comments for the certified reconciliation in a period, the comment should still be seen after adding to an account group. Remove the account from the group, the comment should be included in all future, non-certified reconciliations.

Of course, this is just the tip of the iceberg.

We’ve got to know all the business rules and really understand an accountant’s job to test the accounting software thoroughly. In this particular instance, when testing account reconciliation, we, as software testers, need to be sensitive to the lifecycle of any items not only to roles and certifications but the timing of these activities.

Want to learn more about the intricacies of testing financial and accounting software? Read this blog post, Financial Software Testing Best Practices.