I remember how all entrepreneurs began their adventure with the White List. Of course, everything started with a great deal of chaos. Sometimes I wonder if every change has to start this way. But in fact, changes are good. At least, I like it very much when something is still happening. Going back to the White List, everyone was afraid, nervous about how it would function. And it turned out that the devil’s not as bad as he seems. All in all, Bond did not use this saying, but I’m sure he had it in his blood. Sitting with Przemek and sipping coffee, I heard a bit about the White List:
With the expert’s eye:
Since 2019, there is an obligation to verify counterparties with the so-called White List in Poland. It is a government list (search engine) of all companies, indicating their status as a VAT payer.
There are solutions in the market that allow for the mass polling of the White List database via the API, although they are dedicated to and tailored-made for a specific customer and ERP system. They also have certain limitations, directly derived from the principles of the law, with regard to the maximum number of daily enquiries that can be made, as well as the maximum amount of data to be processed (maximum 300 records).
As XELTO DIGITAL, we have developed another way of verifying the White List based on an automated search on the website, without using the API.
The user provides a list of tax ID numbers and/or bank account numbers of the counterparties. Then the robot checks each number one by one on the VAT taxpayers’ search engine page and collects the necessary information such as: the status of the taxpayer, validation whether the account number(s) is (are) on the list of verified accounts, the search date and the unique ID. Next, it saves this data in an output file that can be placed in any location or emailed to the ordering person.
In contrast to the already existing solutions, the advantage of this one is its considerable freedom in configuration for the customer, enabling them to tailor it to their specific needs.Another great advantage is circumventing the limits that exist for API queries, because in this solution we simulate human operation, opening the website and searching for payers ‘manually’.
If the process is automated using the user interface, it is slower than sending queries via the API. Yet, it is still many times faster than a person would do it, and you can avoid the limit on the number of searches. Technically, the process development requires attention to be paid to selectors of the search buttons – after the first search, the button moves to a different location on the screen, and although it looks exactly the same, its selector is different in subsequent queries. If the input file contains both the tax ID numbers and the bank account numbers, the list should be separated in the robot code.
The robot first checks the bank accounts and only then the tax ID numbers, thus avoiding unnecessary switching between screens to search.
Author: Przemysław Wal – RPA Developer
