In my last blog post, we covered the 5 steps to a successful sales tax implementation project. So why are Business Requirements so important? Frankly, this document provides the road map for the implementation of your project. I always include the following sections in my Business Requirements:
Document Control – Tracking your document versioning is essential: include a section # changed, high level description of the changes, date and author of change or modification. Be prepared for a number of versions as no one gets it exactly right on the first try. It makes it much easier to review the document with changes if you know what section has changes and how it’s been modified.
In Scope - Under this section you will describe a high level overview of the project, what systems (i.e. ERP, webstore), legal entities, jurisdictions (e.g. states, countries or regions), or tax software versions are in scope for the project.
Out-of-Scope – This section of the Requirements is important because it clearly defines what is out-of-scope for the project. Here you want to include any systems, processes, legal entities, jurisdictions etc. that will not be covered or addressed during project life cycle.
Definitions & Acronyms – These are important because it allows a reader who may not be an IT professional or Tax professional to understand special references, acronyms, and industry language in the document.
Assumptions - Define in this section the project assumptions that drive the requirements defined in the body. These assumptions may or may not be correct, but during a team review of the requirements, you will want to confirm these assumptions. See examples below of documented assumptions:
- Billing platform is capable of receiving more than one-line level sales taxations, for example district sales tax, county sales tax and state sales tax.
- Discounts will be netted against original price prior to being sent from ERP system to Vertex for sales tax calculation.
- ERP will make a separate XML call for each charge billed on an invoice. No XML call will contain multiple line items for application of sales taxes.
Diagram Flow – I like to include a pictorial presentation of how information will flow between the systems. It is helpful to give an overview of how the systems will interact and a quick reference point.
Requirements – Define the data elements, situsing rules, transaction processing (e.g. invoice dates, ship-from locations etc.), exemptions, reporting, and security for the new or upgraded tax system.
Test Considerations – Define at high levels how each phase of testing will be handled in the project: Unit, Integration and User Acceptance Testing.
Issue Log – Sometimes the Issue Log is maintained as a separate document from the Business Requirements. I, however, like to include the Issue Log as part of the requirements so we are able to track requirement specific issues or decisions that need to be addressed. It is also invaluable as this section documents the decisions related to the specific issues defined in the Tax Requirement.
Keep in mind your Business Requirements document is a fluid document that you can improvise to best fit your project situation. It is really dependent on various factors including the number and types of systems involved, domestic vs. international sales tax considerations, type of sales tax and the complexity of the company’s tax compliance process. Add sections, move them or delete them to meet your needs. Good Luck!!
Your comments and/or questions are welcome - and appreciated.
Other recent “Sales Tax Automation & Software” posts by Joni Johnson-Powe, JD, CPA:
- Sales Tax Systems: Business Requirements Document Is the Road Map
- The Key to a Successful Tax Software Implementation
- The Changing World of (Sales) Tax Technology