We test accounting and financial software on a daily basis. Probably the most prominent thing we have to keep in mind when testing are the business rules. With accounting software designed to service US-based companies, they must adhere to GAAP, while International Financial Reporting Standards (IFRS) have had effect mostly for international M&A and international subsidiary transactions. However, in May 2011, the SEC published a paper incorporating IFRS into US GAAP with a migration plan. So many public companies and hence the accounting and reconciliation software that they use will soon have to incorporate these changes. One of many elements includes revenue recognition. Differences require a detailed, transaction-based analysis and therefore an understanding of business rules in the way companies operate and provide services.
GAAP IFRS Software Testing Needs Domain Knowledge
As a project manager testing financial and accounting software, it will now require even deeper domain based knowledge to understand not only the software itself, but the intricacies of revenue recognition for different types of companies that use the software. For instance, revenue recognition for some companies such as Costco would be much simpler than revenue recognition for a company selling software solutions. Obviously the software solutions will have to adhere to it’s own set of recognition rules not only for the industry but within the company. Additionally, it could be possible for two different software companies to recognize revenue slightly differently. Although US GAAP guidance on software revenue recognition requires the use of vendor-specific objective evidence (VSOE) of fair value in determining an estimate of the selling price, this is further complicated by the packaging of services with software, and software-as-a-service offerings.
Other differences between IFRS and US GAAP that could impact the business rules of accounting software include the potential for revenue to be recognized earlier under IFRS when services-based transactions include a right of refund. These are just a few of hundreds of differences where understanding these differences will be critical to ensuring that the software has business rules that implement these details correctly. I didn’t know that when I signed up to be a project manager that I’d also end up being a part-time accountant, but I really feel it’s important to understand these principles as it really helps us to develop good user stories and test cases.