🔍 What is solution confirmation?
Solution Confirmation is the stage where architectural and configuration decisions are made, business process designs are validated, and a minimum Viable Product is set up.
1. Global Indirect Tax requirements
Solution confirmation starts with gathering Global Indirect Tax requirements. These consist of the localized:
1) Trade flows of all scenarios that have a VAT impact.
2) (e-)invoice requirements
3) Other Indirect Tax requirements; such as rules around tax point date and archiving.
Global transition and transformation projects are split into different deployments. For each regional or jurisdictional deployment, a solution confirmation phase is part of the project life cycle. It is important that in the early phase of the project (during the Pilot or Market Approach phases) a design is laid down that can be used as a global roadmap. In this roadmap, one can find the key decisions on how the business processes will be designed and built globally.
2. Alignment workstreams
Indirect Tax is not considered an independent workstream. It is part of the workstream Account to Report and is regarded as a sub-workstream. When it comes down to transformation and transitioning, the current business state the workstreams Order to Cash, Source to Settle, Make to Report and Account to Report are included quite early in the decision-making process of the global design. In contrast, experience shows that tax is invited quite late or does not even have a seat at the table at all. Configuration requirements related to the financial process are often already made by the other workstream. Bear in mind that although Order to Cash (OTC) and Source to Settle (STS) look at the same data, they are focused on the legal requirements and KPIs they need to meet according to commercial or accounting principles, which do not necessarily always cover the Indirect Tax compliance requirements.
As an example, let us take an import transaction in the UK with the use of the Postponed Import VAT (PVA) method. From an accounting perspective, the PVA has no financial implication, whereas, from an Indirect Tax compliance perspective, the PVA needs to be reported in the UK VAT return.
In order to automatically include the PVA as a line item in the standard VAT report, it needs to be recorded in the ERP system. The accounting process is most of the time available when import VAT is paid when clearing the goods with Customs, however not for import transactions with the use of the PVA regime. So, for this purpose, a separate configuration is required. Both from an accounting perspective (set up of two GL accounts) as well as from a determination perspective (separate Tax code).
3. Creation of user stories
User stories are basically global Indirect Tax requirements that are translated into system requirements. The suggested format is as follows: “As an Indirect Tax Manager, I want to make sure that the customer invoice shows all the required parameters, such as invoice reference, invoice date, items, Company legal name address, VAT registration number, customer legal name, address, VAT registration number, Base Tax amount, VAT calculation so that the invoice meets all Indirect Tax requirements. The fixed formatting helps the System Integrator to understand what they need to build. Important is to also create user stories for scenarios that are not in the current business but are foreseen in the near future.
4. Discuss user stories with local finance and tax teams
The global Indirect Tax requirements are based on local Indirect Tax law and are very general. They need to be adjusted to the internal processes and business requirements. As a consequence, the draft user stories based on the legal Indirect Tax requirements only need to be supplemented with data elements of the accounting process or customer/vendor master when they impact the VAT determination.
For example, the flow mapping shows that the business is in VAT-exempt sales. To be able to apply the VAT exemption, it is important the system knows for which sales the exemption applies, or which customers have a certificate or have gained a certain status. The user story should then be complemented and need to reflect which data elements from the customer master need to be retrieved to determine the correct tax treatment.
Consequently, meetings need to be set up with local teams to validate whether user stories are complete and correct. In the end, the user stories will provide a comprehensive list of business scenarios, processes, system features and configurations and facilities needed to fulfil the business needs and comply with the legal requirements.
5. Confirm the solution with System Integrator.
Once the user stories are finalized, the System Integrator will perform a fit/gap analysis. The System Integrator needs to confirm whether the user stories are:
– a fit (features are available for configuration)
– a gap
– no feature and not possible to be configured.
– possible to be configured but needs customization.
When the System Integrator concludes a gap, it will be taken to the Project Management Organization to decide whether or not customization needs to take place within the project timeline and before go-live or whether it will be delayed.
