The road to VAT (indirect tax) automation - Testing from A to Z

 

20+ years of experience in VAT automation motivated me in writing the ‘road to VAT automation’.

I tried to formulate it in different topics. This is the last episode of my blog whereby I discuss the testing. 

My texts are meant to trigger discussion: How did you cope with VAT Automation in your company? What experiences you want to share? What questions you have? 

I will be using the word 'VAT' throughout the entire blog, but it does cover indirect  systems called GST as well as sales tax.

Off we go again ... let's hit the road to VAT Automation for the seventh and last time.

Testing from A to Z

Testing your VAT automation solution is the most important part of your project.

As said in one of my previous posts, VAT reporting has become more and more an IT driven activity whereas in the past it were VAT people taking care of the filing whereby they were verifying at the same time whether there were no errors. The reason therefore is twofold: the increased digitized filing requirements by the authorities and the automation within the businesses themselves. Today, many invoices are issued, and many declarations or reports are filed without being checked by any VAT manager. Currently, in many businesses, due to the changed nature of VAT reporting, VAT managers act at the moment of setting up the VAT treatment of transactions in the system, at the moment of implementing the VAT automation solution, and … when the tax inspector comes in. Needless to say that when the VAT inspector comes in, it may be too late already.

At the moment the tax manager receives the VAT declaration for approval, sometimes limited only to when payments must be done, the tax manager has very little information to evaluate the correctness of the declaration.

Therefore, it is extremely important that all steps in the automation process are thoroughly tested. End-to-end testing is a necessity to avoid structural errors.

 

Where to start?

A first step in the testing process is in principle to verify whether what has been programmed / entered in the system or extracted from the system works: Is the connection between the ERP system and VAT automation tool working? Is the data extraction correct and complete? Is the data correctly returned to the ERP system if applicable? Is there an actual calculation made?

So, not necessarily, it is being checked whether the outcome is already correct. Tax people may find this uncomfortable, but this is normal practice and it is nothing to worry about.

However, in order to involve VAT people as soon as possible in the testing phase of the project it is important that real scenarios are used from the very beginning when testing; this way, VAT people will feel much more involved and motivated, as they will be able to follow the increase of the correctness of the outcome. It is much more comforting, and it is a lot easier to follow. It can only contribute to the quality of the UAT (User Acceptance Tests), see below. It also contributes to the learning process VAT people will need to go through in respect of dealing with test scenarios in the scope of the automation process. In the end, to me, the UAT is the only one that really counts: is the outcome correct? Yes or no. For sure, before doing any UAT tests, there are sometimes many test cycles to go through.

 

Selections to be made

What jurisdictions?

Since, hopefully, you will be implementing your VAT automation per region or country, for testing purposes, select a pilot country which is rather easy from a VAT automation perspective. In another post I referred to the Netherlands; this country is often a good candidate for this purpose too.

If the outcome of the UAT tests for your pilot can be signed off, you can start testing other jurisdictions in the same region. As a second pilot, select the country where the selected company in your first pilot country has a lot of transactions with on an inter-company level. This way you can check at both ends whether the transactions are correctly dealt with. Again, if this second country can be signed off, you should be fully ready for testing the rest of the region. In my blog post about the country selection, in which I also touch upon the testing, I suggested implementing as a second country after the first simple country a very complex one. Ideally this is a country with which your first pilot country’s selected company has a lot of transactions, if this is not the case, have then three pilot countries.

 

What transactions?

After having selected a jurisdiction, then, select a straightforward transaction for sales and purchases. Can it be more straightforward than a domestic sale of a standard rated good sold by a supplier established in the country where the sale takes place to a customer also established in the country where the sale takes place? Stay away at this stage from any specific status of the supplier or the customer or of the good or service or any cross-border transactions. Keep it as simple as possible and do the same for the purchase side.

The selection of these straightforward examples should be made up of transactions for the pilot country and taken from the initial selection period. See below.

Encourage IT / ERP developers also to use these real data scenarios for their preliminary testing instead of them just using random parameters. See above.

If those transactions work out well, you can add more transactions to be tested. Always add transactions with one more new or different parameter and see whether the outcome is correct.

It is important to always retest your initial test examples, a new development may influence the outcome of yet proven transactions.

 

What company?

I do realise not having elaborated on the selection of the company for test purposes. Unless completely unavoidable, do not start with a company who has the status of a mixed tax payer, however, do not leave it until last either.

Otherwise, it is not so much the company that matters, but far more important are the type of transactions and the jurisdictions. It speaks for itself that for the preliminary testing, the selection of a simple company will eventually result from the selection based on jurisdictions and transactions.

If there is a company (or various ones) with a mixed tax payer status within the project scope, then, as soon as the UAT has been signed off for the first pilot country, it is recommendable to start with the mixed tax payer’s business flows. You could see it as a fourth pilot country/company. Often, where there is only one entity within the group having a mixed tax payer status, this entity is left out from the automation project. Mixed tax payers often need a far broader set of parameters to be foreseen in the ERP system in order to cater for their needs. Therefore, they do require an individual approach when automating and testing. Why not wait until the very end? Given the fact that other and more parameters may play a role, it may well be the case that in order to be able to automate the operations of the mixed tax payer, quite some adaptations – not to say customizing – are needed, which may influence the other companies' flows’ automation. If the complexities of the mixed tax payer are taken into account from the very beginning, then you are able to either decide to streamline the automation so that your configuration works for your entire automation scope or you may decide to take it out and do a separate configuration for this type of business or leave it out completely. In the first instance, you should then have this development (and testing) done in the beginning of the project, in the latter instance, you can leave it until the end.

 

What test period?

Since testing is utmost important, it is necessary to decide upon a fixed test period from which the entire data set is being taken as reference period. This means that all data for that period should be copied into the test system.

The period should be recent; legislation is changing fast, so you don’t want to be testing old data in a legal framework which has changed in the meantime. The latter is to be avoided as much as possible, however you will not always be able to avoid this.

The first period chosen for testing should be one month – assuming that there is a monthly aggregate filing obligation in most jurisdictions which are part of the automation project. Also, for VAT determination purposes, the period of one month is mostly covering most of the invoicing (issued and received) scenarios. Take for example the month of March when you physically start writing your test scenarios in April.

If the outcome of the result (UAT) is signed off as fully in line with the expectations (thus not, reasonably okay, but fully okay), then extend the testing period to a quarter. In the above example add February and January. In principle the outcome should be also okay. Adding these two months will allow you to fine tune the results. The month of December (assuming your fiscal year ends in December) is also often a very interesting candidate for a test period due to the fact that many one-off invoices are issued or received in December.

Who should test?

Above, I already referred to the fact that IT developers do preliminary testing just to see whether ‘it works’.

Test scenarios should not only be written by VAT managers, but they should also be executed by local specialized VAT managers. Initial tests, per new transaction, until they work out well, should be performed by VAT specialists. The correct result could then be made part of a so called unit test which can be run automatically to see whether new developments or changes made have any impact on the outcome.

Further bulk testing can be performed manually by testing teams (see my earlier post about the implementation team) or/and testing teams can take care of the outcome of the unit tests. As said, all tests performed should be retested after each new development or change, an ideal task for bulk testing teams.

Local VAT managers and their assistants should be responsible for the final User Acceptance Testing. They should be allowed enough time to perform this task and come back with remarks. Since they have been involved in the initial testing, they will have been trained already and they should be able to focus on the desired outcome (and not the testing procedures).

When is the test considered to be okay?

When working with a test period which coincides with a legally required reporting period, there is no manipulation to be done in the existing system to be able to compare the data.

When your UAT results are exactly matching your current system’s results for that period, the conclusion is easy: the test is fine, the UAT can be signed off. However, this sign-off may not be final: keep on re-testing after new developments or changes have been done.

When your test results are not matching, you must investigate every single difference, however small it may be, to explain the differences. It is fairly possible that there are errors in your current system, automating your process is just meant to solve those errors. Just be careful not to try and manipulate your data in order to have it all match, this is very dangerous; the last thing you want is to have structural errors in your automation exercise.

Testing may be extremely time consuming however competent people are. Especially when investigating differences. This should be well explained to the VAT people testing to avoid them manipulating data to have it match so that ‘the job is done’. People may easily be tempted to manipulate test results for several reasons: they just hate it and want to get over with it, but they may also feel uncomfortable with the fact that they have not found anything, since it may look as if they haven't done anything at all during the entire day.

Also, for testing a VAT determination engine it is useful to use a legal reporting period, even when not linked to the automation of VAT reporting. It will avoid missing month-end transactions, but it will also allow you to compare your GL-account postings which are often cleared at month-end.

 

Testing after going live

Once the implementation has gone live, it is important to continue the testing every time a change is made in the system or when new parameters are supplied. Therefore, it may be important to invest in an automated test system that runs a certain set of test-scenarios and automatically compares those tests with the outcome each time a change or update is performed or even on a regular basis. 

VAT managers are e.g. not always aware of changes in master data; small changes in master data may heavily influence the outcome for VAT.

 

Writing test-scenarios

Test-scenarios should be drafted by one member of the team, a highly experienced international VAT expert. After having written out the scenarios, those should be discussed with the other ‘regional VAT managers’ and adjusted.

Further, local VAT managers (see my post on the project team), with an in-depth knowledge should be involved in the test-scenario writing in order to add missing scenarios. This way, the test-scenarios will be set-up in a harmonised way and be complete as well.

 

End-to-end testing

When writing test-scenarios, those scenarios should entail the entire chain. In many cases the (automated) creation of a purchase request or purchase order at purchase side is the very first step in the entire purchase process which eventually leads to VAT obligations and VAT reporting. This should thus also be your first step when executing the testing. All steps in between should be tested up to the very end, being the reporting of the transaction for which the VAT regime had been determined.

If the automation solution is limited to the reporting of VAT, then it is sufficient to start testing from the data download. Hence, the reason why only implementing an automated VAT reporting solution requires less time (see my first post under this blog).

 

The END

And once testing is over … well, then it is time to go live …