Multi tateJ O U R N A L O F

FEBRUARY 2012

I N C E N T I V E ST A X A T I O N A N DSBest Practices in

Transaction TaxSystems

ImplementationDiane L. Yetter

it is critical for businesses that sell itemsin multiple jurisdictions to implementtechnology solutions to accurately man-age their sales and use tax functions. Awide variety of software systems are avail-able today that can embed the tax calcu-lation within the systems that process acompany’s sales and purchases. Choos-ing the right system for a company is halfthe battle. Implementing the system is theother half.Implementing an indirect tax au-

tomation system—whether a new system,an upgrade, or a platform transfer—is nosmall task, but the results are well worththe investment of time, money, and effortwhen an effective system is finally in place.After all, the right system will help com-panies reduce errors, increase produc-tivity, and avoid the heavy fines andpenalties of a negative audit, not to men-tion avoiding the labor costs associatedwith correcting the mistakes that werefound in the audit. Given the quantity andvariety of users involved in making salesand use tax decisions within a company,automation is critical.Nevertheless, despite the sophisticated

technology available for managing salestax systems, many companies are still usingspreadsheets and manual entry to man-age their sales and use taxes. Or, they havean automated tax system but it is not pro-viding the desired results. Things are stillfalling through the cracks, eventually com-ing to the company’s attention in a gov-ernment audit after it is too late to collecttaxes from customers.

Especially in today’s economy, whencompanies are forced to do more withless, the right tax system, coupled withthe right implementation process, canbring about greater efficiency and a sub-stantial return on investment. Also, giventhe current economic conditions, statesare getting more aggressive in collectingsales taxes; therefore, companies musthave their sales tax systems in perfectworking order to avoid hefty fines. Inother words, this is the perfect time forcompanies to evaluate their systems anddecide whether improvements need to bemade.This article will explore the best prac-

tices needed to implement an effectivesales tax system. These best practices applyto companies that are in one of the fol-lowing situations: 1. Implementing an automated systemfor the first time.

2. Changing their systems—either the fi-nancial system or the tax engine.

3. Upgrading their existing tax system toa different version or platform.

4. Merging their data to another system. 5. Expanding into a new market and/ornew geographic area. Fortunately, there are experts who can

guide companies through this transition.Since these projects are not part of theday-to-day responsibilities of a transac-tion tax or information technology (IT)person, attempting to accomplish a proj-ect of this magnitude and importancewithout someone with significant expe-rience can add risk to the project. A sea-soned consultant should be able tosupplement in this situation, either as acoach and advisor or as a critical mem-ber of the team. Finding the right part-ner, one who knows the business, theindustry, the systems, and is willing toprovide the needed assistance can helpan implementation project succeed.

The following discussion may serve asa guide to companies during the transi-tion of a new tax system, from planning toexecution to maintenance.

Types of Tax Automation SystemsBefore selecting a software system, onemust understand the types of systems thatare available on the market today and theircapabilities. The decision as to which op-tion is most appropriate will depend on acompany’s tax and business requirements,the capabilities of the system, and, in largepart, the capabilities of the users. The moresophisticated the system, the less relianceon users for making tax decisions. The lessfunctionality in the system, the more de-cisions must be made by the users.

Host systems. Most financial systemsinclude some level of sales tax processingcapability. Whether the capability is suf-ficient to meet a business’s requirementsdepends on the complexity of the taxa-tion of its products and the jurisdictionswhere it does business.Determining whether to rely on the

standard delivered functionality entailsan evaluation of the user’s proficiency inmaking tax determinations, the effort re-quired to maintain the tax rules, and theflexibility in the system. Product taxabil-ity indicators are usually limited to a sin-gle indicator and do not allow for statespecific taxability indicators. For prod-ucts that have different taxability by ju-risdiction, this functionality will beinsufficient to meet tax calculation re-quirements.Customer taxability indicators are often

tied to an address. As long as unique ad-dress records are created for each deliv-ery address and all items sold to the givencustomer qualify for an exemption, theseindicators may be sufficient.

24 JOURNAL OF MULTISTATE TAXATION AND INCENTIVES February 2012 S P E C I A L R E P O R T

DIANE L. YETTER, CPA, MST, is a strategist, advisor,speaker, and author in the field of sales and use tax. She is pres-ident and founder of YETTER, a sales tax consulting andtax technology firm in Chicago, Illinois. She is also the founderof The Sales Tax Institute, a premier think tank that offers liveand online courses to educate business professionals about salesand use tax. She serves on the Executive Committee of theBoard of Advisors of the University of Kansas School of Busi-ness, where she is an adjunct professor.

With more than 7,000 different authorities imposingtheir own taxes in the U.S. alone,

Procurement systems, including pur-chasing and accounts payable functions,also may include some level of tax pro-cessing. This is generally limited, how-ever, and in some cases only a taxable orexempt indicator is permitted.Host systems typically rely heavily on

the users’ making tax decisions as they se-lect the correct tax codes that likely indi-cate taxability as well as rates. Companieswith complex taxability rules or significantbusiness in many states are likely not goodcandidates for this type of solution.

Bolt-on products. For more sophisti-cated tax processing, several third-party“bolt-on” products are available that willinterface with financial systems. In orderto communicate with the financial system,an interface must be established betweenthe bolt-on package and the financial sys-tem. Some financial systems have standardinterfaces available to select tax packages. Theinterface, however, may not utilize all func-tionality available in the tax package.To obtain full functionality as required

for tax management, enhancements to ei-ther the financial system or interface maybe required. User training may influencethe effectiveness of the tax package.These solutions are best suited for com-

panies with more-complex tax profilesand those that want to control the taxa-bility decisions among a limited numberof individuals—likely within the tax de-partment.

Custom designed systems. In com-panies that have created a custom billingsystem, custom tax determination may beincorporated into the billing calculation.This situation often exists for companiesin industries (e.g., food, medicine, telecom-munications and utilities) with unusualtax requirements or nonstandard sales taxrates. These customized systems, althoughmore difficult to maintain, often have beenenhanced over time and can be very so-phisticated and accurate. In some instances,a third-party rate package is incorporatedinto the custom calculation in lieu of man-ual rate updating. As custom systems areconverted to standard billing systems, thecustom tax functionality must be replacedwith canned programs.

Application service provider (ASP)/cloud-hosted systems. As an alternativeto installing and maintaining software on thecompany’s hardware, “application serviceproviders” are available to host and maintainsome tax and financial applications. ASP-hosted applications can be cost-efficient, as theASP will manage all the infrastructure in-cluding system and, usually, content updates.If an ASP hosts the tax application, the host-ing agreement should included arrangementsfor access to the tax data.These solutions are best suited for smaller

to mid-sized companies that have fairly stan-dard tax profiles. The systems usually donot facilitate complex rules that the tax en-gine may offer in an on-premises version.

These products/services are ideal for com-panies that have grown to such a size thatthey have tax-collection responsibilities inmultiple states but lack the full tax staff nec-essary to support an on-premises solution.

Non-interactive solutions. As an al-ternative to integrated sales and use tax sys-tems, there are non-interactive calculatingsolutions. These solutions are simplistic innature and require manual updating. Stan-dard office applications such as Excel andAccess can be used to build templates thatcan incorporate company-specific tax rulesfor calculating tax on outbound invoicesor on procurement transactions. Cus-tomized web applications also can be cre-ated that provide for more flexibility andcapabilities at reasonable costs. Mainte-nance of rules and rates is required to com-ply with tax changes as they occur.These systematic solutions may be best

suited for companies that have limitedbilling systems that cannot interface witha standard third-party tax package or thatdo not facilitate passing enough detailedinformation to the tax package, or usersthat are not connected to an interactivesystem at the time they are calculating tax.In some situations, a combination of anon-interactive solution with an interac-tive solution may be necessary.Many companies use hand-held units

to generate invoices upon delivery or serv-ice at a customer’s location. In some cases,the employee will not have connectivity,

February 2012 JOURNAL OF MULTISTATE TAXATION AND INCENTIVES 25S P E C I A L R E P O R T

thus requiring a non-interactive solution.In these cases, an off-line version of aninteractive or bolt-on solution may be ap-propriate. This will depend on the ap-proach being used for the hand-held unitsfrom an overall accounting perspective.

Implementation PlanBefore implementing a new tax system, com-panies must first formulate a plan to addresshow the change will affect the company asa whole, who will be involved in the change,who will be affected by the change, and howlong the changeover will take. The impactthat a transaction tax system has on the com-pany as a whole is often underestimated.Since sales and use taxes affect virtually all fi-nancial and business operations, a decisionshould not be entered into without a thoroughplan. To derive answers to these questions,company officials must ask themselves a se-ries of other questions.

Which processes require tax calcu-lation? There are many aspects of a busi-ness that are involved with sales and usetaxes, including: 1. Sales order processing. 2. Sales invoice billing. 3. Accounts receivable. 4. Credit processes. 5. Purchase order processing. 6. Accounts payable. 7. Purchasing cards. 8. Capital asset acquisitions. 9. Goods movement. 10. E-commerce. 11. E-procurement.

Who will be involved? A tax system im-plementation affects many departments of acompany. Too often, companies assign thetask to one department without seeking theinput of the other departments involved. Theteam and points of contact should be well-established at the project’s onset. Both the ITand tax departments, as well as third-partyimplementation consultants, must work to-gether as a team. Under a best practices ap-proach, the tax department, rather than IT,should lead a sales and use tax systems im-plementation project. The most critical de-cisions of the project should be made by thegroup that has the business technical knowl-edge to do so—the tax department. When theproject sponsor is from the IT department,decisions tend to be based on infrastructureor timing rather than business requirements.The following departments are inte-

gral to any sales and use tax process and

should be involved in all aspects of theimplementation process: 1. Tax. 2. Accounting, including fixed assets, gen-eral ledger, and financial reporting.

3. Accounts payable. 4. Accounts receivable. 5. Customer service. 6. Order entry. 7. Master data maintenance, includingcustomer, vendor, item, and plant (thecompany’s own locations).

8. Information systems. Effective communication, coopera-

tion, and knowledge-sharing among theentire team are crucial to the success ofthe implementation. Any decisions thathave been made and processes that havebeen agreed upon should be documentedand distributed to the implementationteam members.A kick-off meeting at the beginning of

a project will help all team members un-derstand the overall project and how theirwork will affect it. Members of the third-party consulting team should be educatedon the client’s business and processes andparticipate in the initial meetings. Simi-larly, it is critical that IT, business, and taxparticipants, as well as key members of theconsulting and software team, are presentat the kick-off meetings to properly un-derstanding the business workflow.The team should understand the time

commitment required to ensure the pro-

ject’s success and timeliness, especially dur-ing the testing phase. Team members willneed to be flexible and willing to rearrangepriorities and schedules in order to keepthe project on track for the go-live date.Additionally, “enterprise resource plan-ning” (ERP) resources should be readilyavailable to the team for troubleshootingand integration issues if the need arises. Forany significant effort, a best practices ap-proach would be to temporarily reassignkey team members to the project team andrelieve them of their normal duties.Create an implementation plan that

describes each phase and the requiredsteps so that the entire team understandsthe timeline and responsibilities of theproject. This should include a thoroughtesting plan and a detailed go-live plan,with defined checkpoints and responsi-bilities. The implementation plan shouldbe used as a guide to ensure that all phasesare followed through to completion.

Project phases. Each phase in an im-plementation project is critical to the pro-ject’s success. Skipping or minimizing anyof the steps will impact the success of notonly the project as a whole, but each ofthe subsequent phases. Shortcuts in therequirements phase will result in chal-lenges during the functional design phase,which will then impact the development,research and configuration, and testingphases. Listed below are the most com-mon phases of an implementation project

26 JOURNAL OF MULTISTATE TAXATION AND INCENTIVES February 2012 S P E C I A L R E P O R T

with the relative portion of time thatshould be expended on each phase. It isdifficult to estimate how long each phaseand project typically takes since each proj-ect is unique. Nevertheless, focusing onthe relative percentage of time that eachphase should take will help a project teamunderstand the relationship of each phaseto the entire project.Each phase relies on team members’ fo-

cusing on certain responsibilities withintheir area of expertise. The team memberswho usually bear the primary responsibil-ities within each phase are included belowalong with the size of each phase (as to timeor cost) relative to the total project. 1. Requirements definition: Usually ledby the tax consultant or tax representative.All team members should participate intheir respective component discussions.Typically around 15% of project budget.

2. Tax software selection:Usually led byIT, tax, and procurement. May be co-ordinated by tax consultant or ERPconsultant. Typically around 7% ofproject budget.

3. Functional design:Usually led by taxconsultant or tax representative butinvolves all team members. Typicallyaround 5% of project budget.

4. Interface development: Led by eitherERP, tax engine technical consultant, orIT. Typically around 5% of projectbudget unless significant customiza-tion or development is required.

5. Tax research and configuration: Ledby tax representative and tax consult-ant. Will vary depending on complexityand ability to use tax content of tax en-gine. Configuration is typically around10% of project time.

6. Testing:Usually led by ERP or tax con-sultant, with appropriate team membersassisting. Typically around 22% of proj-ect time.

7. Reporting: Usually led by tax repre-sentative or general ledger/account-ing team member. Typically around4% of project time.

8. Training:Usually performed by eitherthe tax engine company or as knowl-edge transfer sessions with all con-sultants. Typically around 4% of theproject budget.

9. Production cutover:Usually led by theERP conversion team member. Most ofthis effort is related to master data con-version. Typically, the time to convert toproduction is about 2% of the project time.

10.Project management: Usually led byoverall project manager or tax con-sultant. Typically around 12% of proj-ect time.

11.Post-implementation maintenance:If provided by a tax consultant, theconsultant would work with either thehelp desk or tax representative. Thiswill vary depending on the level of sup-port required. Using an estimate of twoweeks of support after production cu-tover, this phase is typically around14% of project budget. Following best practices, for each of

these phases there are key questions andissues that should be addressed in order toensure a successful project. The responseshere can result in adjustments to the plan.As each phase is executed, flexibility iskey, given that sales and use taxes are com-plex, far reaching, and can be impactedby the business operations.

Requirements DefinitionThe first phase of any transaction tax sys-tems project should be the evaluation andgathering of all the business and tax re-quirements. Ideally, this phase should beconducted before a solution is selected, butthis rarely occurs. Since the optimal solutiondepends on the requirements, selecting aproduct before the requirements are knowncan lead to the need to either compromiseor incur more costs than necessary.

Of all the phases in the project, this isby far the most important and the onewhere the efforts of the entire team areneeded. When this phase is limited by ei-ther time, resources, or participation ofkey stakeholders, requirements that areundiscovered or not fully developed cre-ate challenges for the remainder of theproject. Ideally, this phase should be led bysomeone knowledgeable about the busi-ness, the potential tax systems being con-sidered, the financial system to which thetax engine will be connected, and the taxissues facing the business and the indus-try. Using someone who is familiar with allof these components is a best practicesapproach, as this person will be able toidentify the issues related to the require-ments, and understand and propose so-lutions on how they can be handled.The following questions will help direct

the project and shape the business, tax,and systems requirements.

Evaluation of system functionality.1. Is the project part of an overall ERP re-placement or upgrade, or is it a stand-alone tax system project?

2. Is the project an upgrade of an exist-ing tax engine, a replacement of an ex-isting tax engine, or a new solution?

3. Is the desired platform/architecture“enterprise/on-premise” or “softwareas a solution” (SaaS)?

4. Which processes currently have auto-mated sales and use tax functionality?

5. Are there limitations in the currentsystems that need to be enhanced?

6. Will all current functionality remainin the new system?

7. What are the efforts to dismantle thecurrent taxability process?

8. What systems will need to integratewith the selected tax system?

9. Is some of the tax logic currently han-dled in the interface instead of the taxsystem? Evaluation of tax requirements.

1. Which jurisdictions are included inthe project?

2. If jurisdictions outside the U.S. are in-cluded, is local country tax expertiseavailable to assist with defining the taxrequirements?

3. How is taxation handled currently? 4. What audit issues have been identified? 5. Will there be changes in taxation thatmay affect customers?

6. Is taxation based on customer exceptions? 7. Is taxation based on product exceptions?

February 2012 JOURNAL OF MULTISTATE TAXATION AND INCENTIVES 27S P E C I A L R E P O R T

8. Can tax groups be established for prod-ucts or customers?

9. Are there situations where informa-tion other than customer, product, andjurisdiction is needed to determine atax calculation?

10. Are there special rates or jurisdictionissues that need to be handled basedon product or customer?

11. Are there maximum tax rules basedon quantity?

12. How should tax be displayed on theinvoice, order, and the screen display?Should it be one line with a generic de-scription, one line with the state namein the description, multiple lines foreach level of tax with generic descrip-tions, or multiple lines for each levelwith the exact jurisdiction name?

Tax Software SelectionAll businesses are unique and host an arrayof different requirements. Once the typeof solution is identified, research the var-ious providers within that arena. Differ-ent software packages will offer differentsets of possibilities. The team should beaware of all the benefits/disadvantages ofthe different software packages beforemaking the final selection. Working witha consultant familiar with many differentoptions can help the team narrow downthe viable contenders. Not conducting afull evaluation of at least a reasonable por-tion or even all of the potential solutionsprior to selection puts fulfillment of allrequirements at risk.In making the software selection, con-

sider the following steps: 1. Determine the selection process (in-formal evaluation, on-site vendor demos,or rigorous “request for proposal” (RFP)).The larger the project and the more com-plex the tax requirements, the more rig-orous the evaluation should be.

2. Create evaluation criteria and scoringapproaches.

3. Develop RFPs and select vendors forevaluation.

4. Evaluate technical and functional ca-pabilities of tax software.

5. Schedule tax software vendor presen-tations.

6. Inform vendors of requirements for demoscenarios and other critical informationfor their presentation. Under a best prac-tice approach, the vendors should es-tablish that the software can meet your

specific requirements, rather than pro-viding merely a general sales demo orshowing their standard functionality.

7. Determine whether the tax software of-fers standard interfaces to the selectedfinancial systems. Is there an additionalcharge for the interface? Can enhance-ments be easily incorporated into theinterface?

8. Evaluate implementation specialists’experience with tax software and fi-nancial software.

9. Evaluate in-house implementation ex-perience and availability of tax and in-formation systems staff.

Functional DesignOnce the software is selected and the re-quirements are defined, the functional de-sign phase can be completed. In this phase,the information gathered in those priorphases is translated into the functional re-quirements within the tax engine, inter-face, and financial system. This phase alsowill help identify any business processchanges or additions that may be requiredto ensure success of the project within theproduction environment.The following questions will be used

to refine the requirements and translatethem appropriately into more systematicrequirements. 1. Will additional data elements be neededto be passed from the financial systemto the tax engine in order to handle taxrequirements?

2. Will the financial system’s screen/tabledisplays need to be altered to accom-modate the additional data elements, orare the required data elements already apart of the financial system structure?

3. Will required fields have to be alteredfor different types of information?

4. Will data values within existing datafields need to be adjusted or new val-ues added to the existing options?

5. How will freight and discounts be han-dled within the financial system?

6. Will the new system handle tax vari-ances on vendor-charged tax in the ac-counts payable system?

7. Will additional warning/error mes-sages be necessary?

8. Will customized reports be required,or do the standard reports availablewithin either the financial system orthe tax engine meet the needs of theend user?

Interface DesignDepending on the tax engine selected andthe financial system with which it is inter-facing, this phase can be either significantor limited. If a tax engine is selected that of-fers a standard interface to the financial sys-tem, the efforts will be limited to evaluatingany enhancements or custom data attrib-utes that are needed to meet the tax re-quirements. If a standard interface is notavailable, development of the interface willbe required. Additionally, if the financialsystem does not have standard integrationpoints for third-party tax engines, the inte-gration points must be created within thefinancial system. In these instances, a keymember of the project team should be a de-veloper familiar with the financial systemand able to understand not only how to codethe requirements but also the businessprocesses within the financial system.

Evaluation of standard interface topartner software.1. If a third-party tax software productis being considered, determine if a stan-dard interface has been written to thefinancial software package.

2. Evaluate release information for tax soft-ware and interface to financial software.

3. Contact other users to determine if theinterface works as described.

4. Contact other users to determine howthe tax engine provider and financialsystem company coordinate supportand work to resolve issues.

28 JOURNAL OF MULTISTATE TAXATION AND INCENTIVES February 2012 S P E C I A L R E P O R T

5. Investigate user groups supported by ei-ther the tax or financial software providerspecific to the tax interface.

6. Evaluate all the functionality of the taxsoftware and compare it to the function-ality provided in the standard interface.

7. Determine if the standard interfacewill meet your needs or will requiremodifications.

8. If modifications are necessary, evalu-ate impact on tax software and finan-cial system upgrades. Design of interface if standard in-

terface to partner software is unavail-able. If a third-party software productis being considered and there is not astandard interface available to the fi-nancial system, a custom interface willbe required 1. Evaluate all the functionality of the taxsoftware and determine your require-ments.

2. Do not shortchange your design—buildthe required and desired functional-ity into the design, as it may not be im-plemented later.

3. Determine if internal or external pro-grammers will provide the interface.

4. Define the scope of the project and makesure the tax department is involved.

5. Coordinate with all the impacted busi-ness user functional areas to see whatchanges they would like built into thesystem and review proposed changeswith them.

Development of custom taxationfunctionality. If a third-party tax packagewill not be used, evaluate the standard salestax functionality in the financial software. 1. Many major financial systems may beable to handle value added taxes (VAT)but not U.S. sales taxes.

2. If custom tax functionality will be used,evaluate how tax rates will be obtained,interfaced, and maintained in the cus-tom system.

3. Evaluate all tax requirements to verifythat they will be programmed correctly.

4. Allow for variability for taxability de-termination

Tax Research and ConfigurationA critical phase in the project is definingthe tax rules. If the tax rules are not accu-rate, tax calculations will not meet the re-quirements regardless of all other efforts.Based on the business and tax requirementsestablished in the “requirements definition”phase and the information gathered in the“functional design” phase, which will de-termine how the data elements will be de-fined and what data will be available for agiven transaction, the tax rules need to be re-searched and configured in the tax system.In many cases, the tax software may con-

tain taxability content as well as tax rates.When this applies, the content categoriesmust be analyzed to select the appropriateones for each data value combination being

sent from the financial system. In a bestpractice scenario, this content should bereviewed and evaluated to determine if itmeets the company tax profile.Depending on the tax software engine

selected, additional configuration may benecessary to define the company’s rulesregarding nexus, customer exemptions,product rules, special rates, and authori-ties, as well as any other company-specificrules. Understanding the various meth-ods available within the tax system andhow all the functionality works togetherwill help determine the best practice forconfiguration. Keeping in mind the ef-forts not only to initially configure the sys-tem but also to maintain the rules andtroubleshoot errors, will help determinethe best approach.The following issues should be evalu-

ated during the configuration planningprocess.

Customer taxability issues.1. Are customers fully exempt on all itemspurchased?

2. Are customers taxed differently basedon product purchased?

3. Are customers taxed based on pur-chase order indication of usage?

4. Will customer groups be used to de-fine exempt status?

5. How will exemption certificates be ob-tained, reviewed, and entered into thetax system?

6. What is the timing between when anew customer is acquired and set upin the financial system and when thefirst order is taken?

7. Who will maintain exemption certifi-cate data?

8. In which system will exemption cer-tificate data be maintained—financialsystem, tax engine, or exemption cer-tificate system, and how will the databe integrated and kept in sync?

9. Will certificate images be stored? 10. How and when will the taxability de-terminations be researched and en-tered into the tax system? Product taxability issues.

1. Are there items that are taxed differ-ently regardless of the customer, suchas freight and labor, and statutory ex-emptions that do not require exemp-tion certificates?

2. Are there products that are exempt basedon customer usage, but all customersthat purchase the product are eligiblefor the exemption?

February 2012 JOURNAL OF MULTISTATE TAXATION AND INCENTIVES 29S P E C I A L R E P O R T

3. Are there special tax rates or maxi-mum taxes based on the product, suchas machinery and equipment rates?

4. How will taxable invoice additionssuch as freight be handled when theitem purchased is exempt?

5. How and when will the taxability de-terminations be researched and enteredinto the tax system? Jurisdiction issues.

1. How will the system handle interstatevs. intrastate transactions and the de-termination of the correct sales/usetax type?

2. How will the system determine the cor-rect local jurisdiction for intrastatetransactions (origin or destination)?

3. Are there home-rule local tax juris-diction issues?

4. Are there special jurisdiction rates thatapply because, e.g., a location is in anenterprise zone? Tax type issues.

1. Do you need the ability to determinewhether the transaction is a sale or arental or involves a service?

2. Are you subject to additional indus-try-specific taxes that may require sep-arate calculation rules and rates, suchas telecommunications, meals, lodg-ing, medical, or motor fuel?

3. Are there different tax rates or reportingrequirements for the different tax types(sales, use, or rental)? Credits and debits.

1. Will the system calculate taxes on creditand debit memos?

2. What date will be used as the transac-tion date for determining the correct taxrate for credits and debits?

3. Do you need the ability to process tax-only credits and debits?

4. How will the system properly accountfor tax credits and debits for accuratereturn reporting?

5. How will the taxability of pricing ad-justments be handled if the originalinvoice item is not identified?

6. Are there pricing and customer ac-commodation adjustments? If so, howshould these be taxed and how will theybe entered into the customer account? Procurement issues.

1. How will items be identified if a mate-rial group is not assigned in master data?

2. Will it be necessary to know accurateship-from information?

3. How will transactions be handled whenthe location of where items will be usedis unknown?

4. Is it necessary to track and documenttaxes paid to vendors?

5. Is it necessary to perform vendor taxvalidation on accounts payable invoices?If so, what will be done with the differ-ences—reject the invoice, pay as charged,or short-pay the vendor?

6. Is there a need to determine use tax orvalidate tax on procurement card trans-actions?

7. Will the company be using any sort ofe-procurement processing such as “elec-tronic data interchange” (EDI)1 or “eval-uated receipts settlement” (ERS)2 orweb store? If so, how will the tax sys-tems interact with these processes? Foreign transactions.

1. Is there a need to calculate any foreigntransaction taxes?

2. What impact does the different taxstructure have on the tax calculationprogram?

3. What country-specific rules are there ei-ther for language, reporting, or invoicing?

4. Does the tax engine fully support theforeign jurisdiction for rates, rules, andcontent?

TestingWithin a tax system implementation, vari-ous different types of testing are requiredfor a successful project. The tests shouldsimulate real business transactions andprocesses, and the affected business stake-holders should provide input on the devel-opment of the test scenarios. Ideally,super-users from the business should exe-cute the tests. A detailed test plan for each testphase should be developed that includesthe type of tests needed, the data values to beused within the test scenario, the expected

results, and the functionality that is beingtested. The results of each test scenario shouldbe documented. As development changesoccur, test scenarios should be re-executedto ensure there is no impact on the results.

Tax system unit testing. Once thetax rules are configured within the tax en-gine, unit testing should occur using thetax engine internal testing functionality.This can be done by creating test scenar-ios that simulate all complex transactionsthat employ the different types of tax con-figuration settings.Once the tax system unit testing is suc-

cessful, it is easier to troubleshoot testing er-rors in the integration testing. If the test wassuccessful during this phase but fails when itis executed from the financial system, thesource of the error can be isolated to eitherthe financial system or the integration.

Basic system functionality testing.Once the basic tax and financial system func-tionality is available, testing should be con-ducted to determine if all the types of businesstransactions will be handled appropriately.The initial test should validate that the con-nection is operating as expected betweenthe tax engine and the financial system. Oncethe connection is validated, all interface logicshould be validated to ensure that the correctdata fields are passing from the financial sys-tem into the correct tax engine fields.Be sure that the formatting of data values

is as expected. All types of order entry meth-ods, including all fields that can be used,should be tested to ensure that no func-tionality has been compromised. All mod-ules (order entry, invoice billing, creditprocessing, purchasing, accounts payable)should be tested to make sure all function-ality is appropriate. The company shouldconfirm that the transactions are correctlyposting to the financial systems and gen-eral ledger. This test should be conductedin each environment to ensure there are nochanges in the system environments. If a fi-nancial system conversion is in process, it

30 JOURNAL OF MULTISTATE TAXATION AND INCENTIVES February 2012 S P E C I A L R E P O R T

1 EDI is the computer-to-computer exchange of busi-ness transactions in a standardized, structured elec-tronic format without human intervention, resultingin transactions where the only record is electronic.

2 ERS involves a formal agreement between a buy-er and a seller that places directly on the buyer thecalculation burden for not only the sales/use tax butalso the purchase itself. Rather than having the sell-

er issue an invoice, the buyer relies on pre-estab-lished terms, presented in a purchase order or sim-ilar agreement, to calculate its obligations and remitpayment directly to the seller, based on the ac-ceptance of goods or services delivered. Up-to-dateknowledge of the seller’s tax status (i.e., where ithas nexus) must be maintained by the buyer in or-der to assess the proper tax (sales or use) at theproper rate.

A wide variety of software systems are available today.Choosing the right system is half the battle; implementing

the system is the other half.

is important that all tax system testing isdone in the same release and same envi-ronment as the live production system.

Integration testing. Once basic systemfunctionality is approved, full integrationtesting, which will include tax-specificfunctionality, should be conducted. Testthe various combinations of special taxrules to ensure that all results are as ex-pected. Also, correct interpretation of pa-rameters that trigger special tax rules,such as customer number or product iden-tification, should be tested.A best practice is to develop a list of

integration test transactions and expectedresults that can be used repeatedly to testthe system when patches or upgrades areapplied. This practice will minimize ef-forts to keep the software current and alsocan be used during troubleshooting.

ReportingA key output of any tax calculation systemis the ability to provide reports for tax com-pliance, financial reporting, and manage-ment. Most third-party bolt-on tax enginesinclude functionality to capture tax-calcu-lation results within a database for use inreporting. Standard reports provided bythe tax engines may be sufficient for somebusinesses, while others will require moresophisticated reporting options. Enhancedreporting components are included in themore sophisticated tax engines. It will benecessary, however, to generate tax reportsfrom the financial systems for reconcilia-tion purposes. If the tax engine reportingfunctionality is not sufficient for the busi-ness requirements, other business report-ing tools should be evaluated. If the taxcalculation tool selected does not capture taxresults in a reporting or results database,then all reporting will be done from the fi-nancial system.

Reconciliation. As part of the testing ofthe reports, the results in the tax system andin the financial system general ledger shouldbe reconciled. Issues that can create differencesinclude transaction dates, adjustments, re-versals, and voids. Understanding how theseare processed between the financial systemand tax engine, and confirming that they arehandled in the same manner, will ensure thatthe systems will reconcile. If there are dif-ferences with processes that cannot be re-solved, a manual process should be createdso that the necessary adjustments can bemade to the appropriate system.

Audit documentation. All companiesshould ensure that the data used to preparetheir tax returns is sufficient and avail-able for use during an audit. In evaluat-ing the reporting approach that will impactthe ease of audit defense, some key issuesto consider include: 1. What information will be availablefrom either the tax or financial systemto support a taxing authority’s salesand use tax audits?

2. Does either the tax or financial systemfacilitate computerized audit techniques?

3. Will the tax department be able to ac-cess and generate reports as required foraudits when needed from historicalrecords?

4. How will data be generated from priortax systems or earlier versions?

5. If a SaaS solution is implemented, willaccess to the tax data be maintained ifthe contract is terminated?

6. How much data can be accessed livevs. archived access? Who has access tothe archived data and how will it beaccessed? Return reporting functionality. Since

one of the critical needs of the tax calcu-lation data is the preparation and filing

of the periodic tax returns, the function-ality of the reports module related to sum-marization and export of data forcompliance packages should be evaluatedand tested. Consider the following issuesnot only in the report testing but also inthe evaluation of the tax calculation andreporting solutions. 1. If a third-party tax software partner isselected, does it offer an integrated re-turns package that is consistent withyour filing needs?

2. Is there an electronic import processavailable to enter the tax informationfrom the tax calculation system intothe returns package, or does an inter-face need to be developed?

3. Does the tax return package includeall the jurisdictions for which you arerequired to file?

4. What is the acceptance rate of the ju-risdictions for the computer-gener-ated returns?

5. If you currently report using EDI or webfiling, does the tax return package sup-port these file-generation formats?

6. Does the tax return package have anylimitations that should be considered interms of reports or payment processes?

February 2012 JOURNAL OF MULTISTATE TAXATION AND INCENTIVES 31S P E C I A L R E P O R T

Training/Knowledge TransferDepending on the project team membersand the implementation approach, thedetermination of what training is requiredfor which team members, and the timing,will vary. If a consultant familiar with thetax engine will be directing the projectand handling the development and con-figuration of the system, the in-houseteam may not require training at the proj-ect outset. It is advisable for the consult-ant to provide at least overview training ofthe functionality of the tax system dur-ing the requirements phase to level-setthe understanding of the entire projectteam. If the project will be run by in-housetax and/or IT staff, however, these indi-viduals should attend the tax systems train-ing prior to the initiation of the project.At the end of the project, appropri-

ate knowledge-sharing sessions shouldbe conducted to transition the informa-tion gathered, business process changes,and technical knowledge to the individ-uals who will have responsibility formaintaining the system in production.Different types of training will be ben-eficial for different team members as de-scribed below.

Tax system training for program-mers. If a third-party tax package is used,evaluate the need for internal program-mers or support staff to attend training.Even if internal resources will not be han-dling the implementation, it is neverthe-less advisable for them to be familiar withthe tax system for maintenance tasks.Training should occur in a timely fash-ion—generally near the beginning of theimplementation process.

Tax system training for tax profes-sionals. If a third-party tax package is used,tax department personnel should attendtraining. If possible, also train a back-upperson. If tax personnel will not be per-forming the tax-system configuration, itis likely better to delay training until theend of the project in order to minimizeknowledge-loss over time.

Financial system training for users.If there are any changes in the financialsystem to handle new tax requirements,be sure business users obtain the appro-priate training in a timely fashion. If userswill be maintaining any tax software set-tings, provide appropriate training.

Financial system training for taxprofessionals. In order to conduct test-

ing, tax department personnel will needtraining, access, and support from otherusers in most aspects of the financial sys-tem. This will include order entry, in-voicing, billing, credits, purchasing, andaccounts payable.It will also be beneficial—and a best

practice—for the primary tax departmentpersonnel working on the tax-system im-plementation to be very familiar with thefinancial systems. Their understandingof the business transaction processes anddata available will facilitate the identifi-cation of business and tax requirements,configuration needs, and testing re-quirements. Other processes to which thetax department will need access in the fi-nancial system include testing taxabilitytransactions, issuing tax credits/debits,and generating reports for reconciliationwith the tax system. Tax department per-sonnel will need additional access if thetax calculation is not a third-party prod-uct but is built into the financial system.

Project knowledge transfer. If theproject team includes individuals otherthan those who will be maintaining thesystem after it moves to production orwho have responsibility for tax functions,a full knowledge transfer session shouldoccur. The project team should providecomprehensive documentation of all con-figurations in the financial and tax sys-tems, design requirements, interface logic,and test results. The individuals respon-sible for ongoing maintenance shouldhave a complete understanding of all theconfiguration and update processes.

Project ManagementKey to the success of any project is strongproject management. A tax system im-plementation spans many departments,involves internal and external resources(even if only the tax engine and financialsystem providers) and has significant de-pendent activities. Without strong projectmanagement and oversight, including theinvolvement of an executive sponsor andsteering committee, risks to the projectincrease.Someone with project management

experience should serve in this role. Abest practice is to fill the role with an in-dividual familiar with tax systems imple-mentation projects as well as havingknowledge of the specific systems (fi-nancial and tax) being implemented.

32 JOURNAL OF MULTISTATE TAXATION AND INCENTIVES February 2012 S P E C I A L R E P O R T

Production CutoverOnce the system project is fully tested, mi-gration to production can begin. There aresome key considerations and steps necessaryto ensure a successful move to production.

Transition date. The company must se-lect an appropriate transition date for thenew tax system. If the project is part of anoverall financial system project, the selec-tion of the transition date is often tied tominimizing the impact on all affected users.Calendar or fiscal month-end is desirablein order to minimize the reporting issuesthat come with merging multiple systems inthe same reporting period. From a financialreporting perspective, however, this mayprovide challenges with month-end ac-counting activities. Determine if there areany “lock-out” time frames during the cu-tover process that would impact tax com-pliance. Coordinate the transition date toensure that regular compliance activitiesare not compromised with system or per-sonnel resources.

Address cleanup. The accuracy of anytax calculation depends on accurate andvalid address data. As part of the cutoverprocess, the company must decide whethera customer/vendor/facility address recordcleanup is necessary. Issues to consider in-clude whether multi-county or outside-city-limits issues apply, whether the use of“ZIP+4” or street-level address validationwithin the tax or financial system shouldoccur and, if necessary, whether a separateaddress-validation package should be used.Allow sufficient time for customer/ven-

dor contact and the updating of systemrecords. Establish a contingent address-handling plan for nonresponsive cus-tomers/vendors. A best practice approachis to include an exemption certificate up-date request at the same time.

Pre-implementation transactions con-version. As part of the cutover plan, opentransactions need to be migrated to the newsystem. Develop a conversion plan for theseitems, such as orders entered but not yetbilled. Establish conversion rules for all pa-rameters that may have changed (e.g., cus-tomer number, product number, jurisdictionidentification, and taxability indicators), andset up a method for adding data elements tothese transactions that may not have existedin the prior system. Also, establish a method

for handling credits in the new system fororiginal transactions from the prior system.It is also necessary to include in the

plan whether closed transactions will bemigrated to the new system. This is pri-marily an issue in a financial system changebut could apply also to a tax engine change.If the archived transactions will not bemigrated to the new system, it is importantto ensure that access to the prior system ismaintained or that data is exported insuch a way that all elements and data in-tegrity are maintained, and that appro-priate backup and access are available tothe tax department. Conversion tablesthat are necessary to translate data shouldbe maintained. If new exemption certifi-cates are obtained, prior certificates shouldbe maintained until the periods coveredby the certificates either expire or are au-dited.

Customer relation issues. If changesto taxation policy could impact customer in-voices, customers should be so notified.Regardless of whether customers are noti-fied, all customer-service and sales repre-sentatives should be made aware of anychanges in taxation policy so they can beresponsive to inquiries. The company shoulddetermine a conversion policy for customersthat have been exempt but did not respondto exemption certificate update requests.

Post-Implementation MaintenanceOnce the system has moved into produc-tion, efforts shift to maintenance. Theseactivities will vary depending on the de-sign, configuration, and business processes.At a minimum, tax content updates forrates and rules will be required. Other main-tenance activities will vary.

Customer taxability maintenance.Maintenance of exempt customer data willbe required on an ongoing basis after im-plementation. Determine which depart-ment will have responsibility for this function.Monitor and maintain any special taxationrules based on customers in the tax system.

Product taxability maintenance. Asthe business adds new products or prod-uct groups, it is necessary to maintain prod-uct tax mapping and rules in the tax system.A tax department representative should bepart of the creation and approval process

for new tax groups. In addition, someonefrom the tax department should be assignedto monitor the assignment of tax productgroups to new products.

Jurisdiction maintenance. The tax de-partment must monitor business activitiesto determine when new jurisdictions areentered that require registration. Once anew jurisdiction is entered, the tax systemshould be updated accordingly. This processwill include not only the nexus tables butalso a review of customer and product taxrules. If a custom tax calculation system isbuilt, tax rates and jurisdiction rules mustbe monitored and maintained.

System maintenance. Software providersfrequently release patches and updatesfor their products. It is important to tracknew releases and updates for tax softwareand for the financial system interface to thetax software in order to evaluate if anyfunctionality changes impact the com-pany’s implementation. Set up policies toprovide for monthly updating of rates,content, and other releases from all taxsoftware partners, including who has up-date responsibility, which environmentsare updated and in what order, the extentof testing to be performed on the updates,and any necessary communication to usersaffected by the changes.A best practice policy is to establish a key

contact in the company’s information sys-tems department who will tend to systemneeds and who understands the tax system andits integration with the financial system. It isalso critical to educate upper managementabout the need, early in the process, for taxpersonnel involvement in system changes.

ConclusionImplementing a new transaction tax sys-tem is undoubtedly a large undertaking,but companies that take shortcuts or do notapply best practices during implementa-tion will find that their new systems willyield less-than-ideal results. To the con-trary, companies that invest the time andmoney necessary to properly implement anew system will find that their new systemwill help improve company efficiency, reducethe number of government audits, decreaseassessments, and even help contribute tothe company’s bottom line. n

February 2012 JOURNAL OF MULTISTATE TAXATION AND INCENTIVES 33S P E C I A L R E P O R T

Despite the sophisticated technology available, manycompanies are still using spreadsheets and manual entry to manage their sales and use taxes.

REPRINTED WITH PERMISSION WARREN, GORHAM & LAMONT OF TTA