Software Testing Advice for Accounting and Financial Software
By Jan Lundeen, Guest Contributor
As an accountant, CPA, and Quality Assurance Analyst, I’ve done, reviewed, and tested many reconciliations during my career. When I saw XBOSoft’s posts on account reconciliation and financial software testing, I was curious to see what they had to say. It was good, but I think that a few real-life examples from an accountant’s point of view would help clarify things.
Certification of Accounts
One of the topics discussed in the account reconciliation blog was the certification of accounts. If it’s been reviewed and approved by someone else (not the person reconciling the account), an account has been “certified.” 
The three people or roles that certify accounts are external auditors, internal auditors, and supervisors. Sometimes, after completing our reconciliations, our supervisor will review reconciliations completed by the junior staff.
For the more experienced accountants, our supervisor won’t review each reconciliation unless there are issues reported by the accountant. Usually, the auditors will spot check the reconciliations.
Reconciling Accounts
Reconciling accounts on a timely basis is an internal control or procedure to ensure that the account balances are accurate. Since these balances are used in financial statements, it’s important that they are correct so investors get a true picture of how the company is doing.
Many accounting systems allow users to compare transactions making up the account balance with the matching transaction from an outside source, such as a bank statement or a download of information from an independent source (like a bank).
The person who reconciles the account puts a check by any unmatched transactions when they find the matching transaction in the outside source. After all transactions in the account are checked, the difference should be zero.
From A Software Tester’s Perspective
Regarding the mechanics of reconciling an account, accountants use various strategies to do this. The tester can use these strategies to test the account reconciliation features of an accounting system. They need to create an expectation of what the balance should be and see if the system matches expectations.
Matching Calculations to Expectations
Many times, that might involve running through a calculation and seeing if it matches. For example, when reconciling a bank account, the tester may want to calculate that the bank credited their account with the correct amount of interest.
Companies want to keep their inventory moving, focusing on assets. They rely on accounting software to reconcile financials.
If the tester is reconciling an asset account (e.g. vehicles), they might want to calculate the amount of depreciation for the company truck. If you have an account that has the wrong balance, that’s a red flag. For example, a payment account (a liability) should ordinarily be a credit balance (negative).
If you see an instance when the payment account is the debit account (positive), this doesn’t match the expectation for a payment account. Since this was the opposite sign of what we would expect, the tester should research this account further.
Look for Patterns
Another way to determine if the account balance is off is to look at expected patterns. For example, you can compare the sum of the account detail file to the balance for the account summary file. If they don’t match, we know that we still have a problem.
Chart of Accounts Key to Testers
When reconciling an account, the tester needs to ensure that the correct account numbers from the Chart of Accounts are included in the account reconciliation.
The Chart of Accounts is the listing of all account numbers used in the accounting system. Each type of account will have a range of numbers. For example, asset accounts will have a range of 2000–2999, liability accounts will have a range of 3000–3999 and the owner’s equity will have a range of 4000–4999. The double entry system of accounting requires two account numbers to be used. One will be a debit (positive sign) and the other will be a credit (negative sign), which should balance to zero.
One of those accounts should be from the account number you are reconciling (e.g. if reconciling an asset account [vehicle account number 2300], 2300 needs to be listed once in the transaction). The tester can look in the Chart of Accounts and verify that the correct account numbers are included in the account.
Anything that is unexpected should be flagged and looked at more closely.
Timing and Transaction Dates
In accounting, the timing is important, so the tester needs to look at transaction dates. The original blog by Jeade touched on this when they mentioned something about the “add date” of an account. The tester should ask about the source of the add date. Is it manually keyed in the system by the user? Or is it system generated (e.g. numbers from a download from the bank)? For example, with a bank reconciliation, you might want to verify that deposits were received by the bank at a certain date. If they aren’t received in time, they risk an overdraft of the account and possible bank fees.
Posting Transactions
Besides the account reconciliation blog, I also looked at the financial software best practices article. The article covered important areas to look at when testing financial systems, but there are a few other items I’d like to mention:
- Transactions entered in the accounting system need to be posted properly to the general ledger. To do this, we would run a routine to post it. The system will generate a posting code to show that it was properly posted and recorded in the database.
- Sometimes, this routine would get interrupted (e.g. the power shut off) and partial transactions would post. For example, a debit (positive number) to an expense account for $1,000 may be posted, but the other part of the transaction — the credit (negative number) to the payable account of $1,000 — will not get posted, so both the expense and payable accounts will be out of balance.
- Depending on the accounting system, the accountant may receive something as simple as an error log saying that the account was out of balance. Or the accountant may receive a detailed report (integrity report) showing the partial balances on a report.
- It’s very difficult to test since you have to recreate partial transactions in the database to test whether the system created accurate integrity reports. However, it can be done if you can create partially posted test data in the database.
Understanding Accounting Systems as a Tester
As you can see, when you’re a software tester in the accounting and financial software domain, you really need to understand how to use the software from an accounting point of view.
Not only putting yourself in the shoes of the many different roles in certifying accounts but also understanding the business rules in how transactions are posted and how all transactions must flow from account to account, ending up in the general ledger.
Sometimes, those circuitous paths have zig-zags along the way, and that’s where software testers with domain expertise and knowledge can really shine.
Leave A Comment