Accounting Validation

Summary

Background: One of the biggest risks to customers using Financials which we want to catch using Smart Accounting Validation is misstatement (which a CEO & CFO can go to jail for).

Misstatement: A misstatement is an incorrect statement, or the giving of false information. Financial misstatement is when amounts disclosed in finical statements are incorrect or misleading as to the true health of the businesses financial position. Material misstatement (which a CEO & CFO can go to jail for) is when the user of a set of financial statements alters their economic decisions because of the misstatement (e.g. overstating revenue could cause share price to increase which in turn has altered the decision-making process of an investor). Because a lot of the transactions in WD are driven by rules (e.g. account posting rules) it’s easy following updates to other areas of the configuration (like a cost centre hierarchy) to cause transactions to post the wrong ledger accounts. Now in most cases this is unlikely to cause “material misstatement” but it’s still advisable to test these kinds of unintended issues don’t happen.

In Workday there are two types of journals (1) Manual Journals and (2) Operation Journals (Automated transactions in Workday are referred to as “Operation Journals”). The reason these are so important is that 90% of all transactions in Workday are Operation Journals.

Operation Journals are automated by a set of rules, such as account posting rules, tax and currency etc. The risk we want to mitigate by testing is that if one of these rules are misconfigured or if the dimensions, they depend upon are misconfigured, customers transactions could post to the wrong ledger accounts (giving rise to misstatement).

Without exception all rules that govern Operational Transactions are driven by Worktags in some way, an example of this is Account Posting Rules. Workday will decide which ledger accounts an Operation Transaction posts too based on the Worktags it contains such as Cost Centre, Company, Location, Spend / Revenue Category etc. This is key to understanding that Operational transactions are actually very straight forward as to test these we just need to understand the Worktags that drive them.

Smart Accounting Validation allows us to test the Workday Financials specific rules which govern how Operational Transactions post to the customers General Ledger (GL). What we are testing is how these rules dictate the content of an operation transaction and the potential impact to the GL when something changes.

Using Accounting Validation in Smart

The purpose of Smart Accounting Validation is to enable users to test the Workday Financials specific rules, which govern how transactions post in accordance with your tenant configuration and how these rules dictate the content of an operation transaction. Some common use cases include:

  1. Account Posting Rules
  2. Currency Rules
  3. Revenue Recognition Rules
  4. Tax
  5. Intercompany
  6. Alternate Account Mapping Rules

What Smart will do is store the output from an operational journal from a test execution and compare it when the test is re-executed, pointing out where things have stayed the same and where things have changed (e.g. resulting ledger accounts etc).

Smart supports Accounting Validation for the business processes (listed below). This feature enables users to validate the integrity of operational journals created by Workday as part of a Smart test.

Smart will carry out Accounting Validation on the Business Processes listed below

Business Processes WD Functional Area
Issue Asset Business Asset
Dispose Asset Business Asset
Capital Project Workbench Business Asset
Create Expenses Report Expenses
Create Expense Report for Worker Expenses
Supplier Invoice workbench Procurement
Create Prepaid Spend Amortization for Instalment  Procurement
Create Ad Hoc Payment Supplier Accounts
Create Supplier Invoice Supplier Accounts
Create Supplier Invoice Adjustment Supplier Accounts
Customer Invoice for Billing Installment
Revenue Management
Create Customer Invoice Revenue Management
Create Revenue Recognition Accoutning Revenue Management
Record Customer Payment
Revenue Management

Test Case Creation

For the purposes of the User Guide, we will look at the Create Supplier Invoice and Create Customer Invoice Business Processes as examples. Like all tests in Smart Accounting Validation tests are data driven, let’s look at two example scenarios:


E.g 1: Testing Account Posting Rules

In order to test account posting rules we need to create a transaction which contains the correct dimensions to trigger the rule. Take the below rule as an example.

This rule should cause journals to post to the “6800: Travel & Entertainment” ledger account provided the company on the Supplier Invoice is “WEN Wayne Enterprises Inc” and at least one item on the invoice has a Spend Category of “Travel and “Entertainment”.

To test this, we will simply create a standard Smart Business Process test and populate the Company in the test template with “WEN Wayne Enterprises Inc”

and the Spend category with “Travel & Entertainment”.

Otherwise the test template will to contain the typical fields (per your tenant configuration) to initiate and complete the business process.

 

E.g 2: Testing Tax

In order to test Tax rules, we need to create a transaction which contains the correct dimensions to trigger the appropriate Tax rule/s. Take the below rule as an example.

The above tax rate will calculate tax at 20% and based on the below posting rule, the tax amount should post to ledger account “2210:VAT Payable”.

To test this, once again we will simply create a standard Smart Business Process test and populate the Tax Applicability field with “Input VAT” and the Tax Code as “UK Input VAT (20%)” in the test template as shown below.

We will also set the invoice line item amount to £15,000 in the test template (so the expected result is tax will be calculated as £3,000, and posted to the “2210:VAT Payable” ledger account).

Otherwise the test template will to contain the typical fields (per your tenant configuration) to initiate and complete the business process.

As you will see from the above both test cases are data driven and the process of creating a Smart Accounting Validation test is the same as a Business Process Test.

Once the test templates have been uploaded to Smart and the tests have been successfully executed you will see a new tab within the test case details page called “Test Output Data”, this shows the content of the journal created as part of the most recent execution.

Once your test has executed you should ensure the test result is as expected, this can be done by either reviewing the “Test Output Data” tab OR using the “View accounting Details” link in Smart to link directly the operational journal in Workday (this is within the “Steps” tab).

Once you have reviewed the journal and confirmed the results are as expected you can set the baseline results in Smart (which tells Smart that on each test execution we expect the journal to post exactly the same as the baseline).

When the test is then re-executed Smart will compare each field on journal from the current execution with the baseline, if any value is different Smart will fail the test and give you an error message to help triage why the test failed.

Note:Generally Smart compares ALL fields across ALL tabs on the baseline operational journal to operational journal from the current execution however some fields like “date” are excluded from the comparison but they are output to the “Test Output Data” tab.

For more information on Accounting Validation, please contact a member of the Kainos Smart Customer Support team.

For more information on Accounting Validation, please contact a member of the Kainos Smart Customer Support team.