<%BANNER%>

An Architecture for a certified service provider (CSP) to collect sales and use tax from online commercial transactions

University of Florida Institutional Repository

PAGE 1

AN ARCHITECTURE FOR A CERTIFIE D SERVICE PROVIDER (CSP) TO COLLECT SALES AND USE TAX FROM ONLINE COMMERCIAL TRANSACTIONS By MANAV CHIMAKURTHI A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2002

PAGE 2

Copyright 2002 by Manav Chimakurthi

PAGE 3

For friends..

PAGE 4

ACKNOWLEDGMENTS I would like to express my gratitude to the chair of my thesis committee, Dr. Joseph Wilson, whose ideas and dedicated support have made this work possible. His incredible patience and kindness have made a lasting impression. I would also like to thank the other members on my committee, Drs. Douglas Dankel and Joachim Hammer. If it were not for all my teachers, my friends and my parents, I could not have gotten to where I am. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS ................................................................................................. iv LIST OF FIGURES ......................................................................................................... viii ABSTRACT....................................................................................................................... ix CHAPTER 1 INTRODUCTION ...........................................................................................................1 2 OVERVIEW OF ONLINE SALES TAX COLLECTION ISSUES, LANDMARKS, AND INITIATIVES........................................................................................................6 The Issue......................................................................................................................... 6 Scenario 1................................................................................................................. 6 Scenario 2................................................................................................................. 8 Scenario 3................................................................................................................. 8 Judicial and Legislative Background.............................................................................. 9 States Arguments and Other Tax Issues ....................................................................... 10 Erosion of Tax Base............................................................................................... 10 Cost of Collecting Taxes........................................................................................ 11 Incidence and Sourcing.......................................................................................... 11 Acts and Initiatives Affecting Sales and Use Tax ........................................................ 12 Internet Tax Freedom Act 1998............................................................................. 12 Advisory Commission on Electronic Commerce (ACEC) .................................... 12 Streamlined Sales Tax Project (SSTP)................................................................... 13 National Conference of State Legislatures (NCSL)............................................... 13 3 ARCHITECTURE OF THE CERTIFIED SERVICE PROVIDER (CSP) TAX COLLECTION MECHANISM. ...................................................................................15 Seller Site...................................................................................................................... 15 CSP Site ........................................................................................................................ 20 4 THE CSP ARCHITECTURE, MECHANISMS, AND ISSUES. .................................23 CSP Architecture and Implementation Issues............................................................... 25 Resolution of Item Being Taxed ............................................................................ 25 The Money Trail .................................................................................................... 26 v

PAGE 6

Buyer Exemption Certificate Security ................................................................... 28 Privacy Safeguards................................................................................................. 29 Message Passing Protocol...................................................................................... 29 CSP Tax Resolution Issues........................................................................................... 29 Sales or Use Tax .................................................................................................... 29 Sourcing the Transaction: Origin or Destination ................................................... 30 Multiple Use Locations, Multiple Delivery Locations .......................................... 31 Zip Code Area Aggregates Based Jurisdictions..................................................... 32 Caps, Thresholds, and Tax holidays ...................................................................... 33 Study in Control Minutiae: Tax Based on Gross, Quantity and Price ................... 33 Tax based on gross...........................................................................................34 Tax based on quantity......................................................................................34 Tax Based on Price ..........................................................................................35 Study in Exemption Minutiae: Exempted Entity-Jurisdiction-Item-Percentage of Exemption.......................................................................................................... 36 Exemption Registration Procedure ........................................................................ 37 5 IMPLEMENTATION DETAILS: HOW TO RUN THE APPLICATIONS ................38 How to Start the CSP.................................................................................................... 38 How To Start the Seller................................................................................................. 39 How To Start The Interfaces......................................................................................... 39 6 IMPLEMENTATION DETAILS: THE CLASSES......................................................40 TaxML Object Classes.................................................................................................. 40 CSP Site Java Classes................................................................................................... 43 Seller Site Java Classes................................................................................................. 45 General Utility Classes ................................................................................................. 47 Configuration Files and Classes.................................................................................... 48 Interfaces....................................................................................................................... 48 Seller Interface ....................................................................................................... 48 Shop Interface ........................................................................................................ 48 Shopping cart ...................................................................................................48 New user ..........................................................................................................49 Buyer Interface....................................................................................................... 49 Jurisdiction Interface.............................................................................................. 49 CSP Interface ......................................................................................................... 49 Interface Objects........................................................................................................... 49 7 CONCLUSION AND FUTURE WORK ......................................................................52 APPENDIX A TAXML DTD AND DOCUMENT TYPES.................................................................54 B INTERNET TAX FREEDOM ACT.............................................................................60 vi

PAGE 7

C ADVISORY COMMISSION ON ELECTRIC COMMERCE (ACEC).......................63 C STREAMLINED SALES TAX PROJECT (SSTP) EXECUTIVE SUMMARY. .......66 E NETWORK MESSAGE PASSING SCENARIOS.......................................................71 F DEFINITIONS OF TERMS..........................................................................................76 TaxML ................................................................................................................... 76 Certified Service Provider-CSP ............................................................................. 76 Participating States Portal-PSP .............................................................................. 77 LIST OF REFERENCES...................................................................................................78 BIOGRAPHICAL SKETCH .............................................................................................79 vii

PAGE 8

LIST OF FIGURES Figure page 3.1 The CSP in relation to sellers and their customers. .....................................................16 3.2 XML data flow.............................................................................................................17 3.3 Functions, data flow and interaction at the seller site..................................................18 3.4 Functions, data flow, and interaction at the CSP site ..................................................21 4.1 Illustration of the quantity based slab rate system.......................................................34 4.2 Illustration of the price based slab rate system............................................................35 6.1 XML entities map to respective Java objects ..............................................................41 6.2 The TaxML DTD maps to the TaxInfo Java object.....................................................42 6.3 Information containers and paths.................................................................................43 A.1 TaxML Query. ............................................................................................................56 A.2 TaxML Reply..............................................................................................................58 E.1 Scenarios with passing Query and Query-Acknowledgement....................................72 E.2 Scenarios with passing Reply and Reply-Acknowledgement.....................................74 viii

PAGE 9

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science AN ARCHITECTURE FOR A CERTIFIED SERVICE PROVIDER (CSP) TO COLLECT SALES AND USE TAX FROM ONLINE COMMERCIAL TRANSACTIONS By Manav Chimakurthi December 2002 Chair: Dr. Joseph Wilson Major Department: Computer and Information Sciences and Engineering Towards the latter half of the 21 st century, states have shown an increasing reliance on sales and use taxes as sources of revenue. This is evidenced by a casual study of the increase in rates and the number of local jurisdictions that now levy such taxes (more than 7,500). Gravitation towards sales and use taxes has been attributed towards their general acceptability: they consistently score as being among the fairest taxes in surveys conducted since 1973. Efforts at collecting sales and use taxes from out-of-state businesses that do business in a state have been mired in constitutional, economic, and jurisdictional issues. The supreme court has consistently ruled in favor of the out-of-state businesses stating that it was far too great a burden for them to keep track of changes to tax rates, exempted items, exempted buyers, tax holidays, caps, and thresholds in each of the taxing jurisdictions. Confronted with a colossal erosion of their tax base from Internet based retailers, the states embarked on initiatives such as the Streamlined Sales Tax Project to explore, recommend, and institute changes to participating states tax systems ix

PAGE 10

so as to make it easier for out-of-state businesses to collect taxes. A technological solution that simplifies many aspects of tax collection and administration while preserving the status quo has percolated through the streamlining efforts as an agreeable alternative to otherwise lengthy and contentious efforts at real simplification. The work in this thesis is based on the recommendations for a technological solution: a Certified Service Provider (CSP) that collects sales and use tax from online commercial transactions. Online retailers submit an XML document of their imminent transaction to the CSP, which calculates and sends the tax back in another XML document. The retailer remits the tax due on the transaction to the CSP and is absolved of filing tax returns to and audits from the states and jurisdictions. The implementation uses Java, XML, Sybase, and Java Servlets. x

PAGE 11

CHAPTER 1 INTRODUCTION One of the reasons formulating fair tax laws for the Internet is complicated has to do with the location independence of entities on the net. Transactions are made possible on the Internet through web sites that have their physical servers, management establishment, and customers-all in different states. Online retail companies can be perceived as the natural extension to traditional mail order firms. The business model is nearly intact: a catalog, a customer, an order, and a shipment. The verdicts from court trials that mail order firms endured from their inception have set the foundation for the manner in which online commercial transactions have come to be considered for tax purposes. Mail order firms have gained significant decisions made in their favor by the Supreme Court in accordance with its interpretation of the commerce clause and the due process clause put forth in the constitution. In the landmark 1967 National Bellas Hess v. State of Illinois decision, the court ruled that out-of-state mail order firms could not be required to collect state and use taxes for states in which their only business presence consists of distributing catalogs and other advertising materials [ADV86, p.56]. This decision has subsequently been upheld in the 1992 Quill v. North Dakota case. The commerce clause safeguarded a national market by allowing the free flow of interstate commerce: it was far too great a burden to require an out-of-state firm to comply with sales and use tax laws in the states that it does business in, where it did not have nexus in. Nexus was clarified with help from the due process clauses as being the establishment of 1

PAGE 12

2 sufficient minimum linkage between a state and the firm it seeks to tax as evidence of benefits received by the tax remitting firm from the taxing state [ADV86, p.56]. The festering nature of the conflicts inherent in implementing a fair and efficient sales and use tax system was noted by Robert Hawkins, chairman of the Advisory Commission on Intergovernmental Relations in a revelatory 1986 report on the State and Local Taxation of Out-Of-State Mail Order Sales: Not withstanding the philosophical and constitutional issues involved, the conflict is a classic one. That between the national interest in protecting the free flow of interstate commerce from unreasonable imposition of state and local taxes, and the rights of the individual states to protect the integrity of their taxing authority and their revenue system [ADV86, p.iii]. The mail order industry in 1967 was based on a very traditional way of doing business that was predominantly oriented toward physical presence. Limited communication avenues and distribution channels required businesses to have local offices to conduct significant commercial activities in a state. In 1992, even with fast growing 1-800 number sales through newspapers, magazines, television, and computer terminals with catalogue linkup in work places, the court still upheld the Hess judgment. The furious growth of the Internet in the 90s has substantially changed the fundamental nature in the way commerce is conducted in some industries. Despite the dot com crumble of the late nineties, the simple truth is, commerce via the Internet is sensible for these industries, and as business models evolved, it has grown to be even critical for some. It was in the boom years, however, that states became increasingly alarmed at the real and perceived notion of loss of sales revenue from online sales. Sales tax losses

PAGE 13

3 owing to mail order companies never quite managed to have the critical mass to warrant a sales tax system overhaul but with the proliferation of online businesses, large numbers of transactions were slipping by the obligation to collect sales tax under the nexus requirement. In late 1999 and most of 2000 as e-commerce was making its biggest strides in terms of media hype, capital generation and IPO racketeering, concerns of tax revenue lost and unfairness to main street businesses (that had to collect tax), the states and other concerned parties undertook a search for feasible solutions to collect tax from online businesses. Among the proposals were those to simplify and standardize taxation rules and systems various jurisdictions employed so as to make collecting taxes easier for out-of-state businesses. Simplification is viewed by many as a wicked, unrelenting objective that has failed past attempts at its reckoning. Perhaps what it seeks to accomplish sets it up against forces destined to undermine it in their own efforts at self-preservation. Local jurisdictions have no interest in giving up their specially tailored tax system to one that is more standardized. Local rates, exempted items, exempted consumers, limits, ceilings, and holidays are the result of the community deciding what is best for itself. Any attempt at standardization should ideally allow the leeway for a jurisdiction to customize its tax system, which of course means little or no standardization is possible. Technological intervention, bemoaned by fans of simplification as a patch that sidesteps the real issue, surfaced as a pragmatic solution that preserved the status quo of customization while alleviating some of the real administrative and logistic annoyances that out-of-state businesses faced. The Streamlined Sales Tax Projects broad definition of a technological solution in terms of a certified service provider (CSP) that acts as a third-party conduit between online businesses and tax jurisdictions is the basis of this thesis.

PAGE 14

4 The CSP implementation in this work takes into account most of the recommendations made by the SSTP for a streamlined tax system. Ideas not within the framework of, and at times contradicting the tenets of, the SSTP were also explored and implemented. This work contributes an XML DTD, termed TaxML (Appendix A) to interface between sellers and the CSP. TaxML defines entities and attributes that abstract this works unique resolution of tax issues-either in accordance, in extension, or in contradiction to SSTP recommendations. Among other contributions, of particular interest to jurisdictions would be the slab based tax system for items in the tax base that require special handling. Different tax rates can be set for items depending on either the quantity in which they are sold or the price at which they are sold. Jurisdictions can encourage or discourage the economic destiny of items by adjusting the slab rates. This will be appreciated by jurisdictions but at the same time be seen as a step in the wrong direction by those who seek simplification-which in the extreme amounts to a single rate in all jurisdictions, across all items. Other significant contributions are in the areas concerning multiple use locations and exemptions. Buyers can have different quantities of the same item delivered and used in different locations. Tax is assessed based on the final use location and not the delivery location. Exemptions are handled using an elaborate mechanism. Exemptions are resolved by considering the buyer exemption period, the jurisdictions for which the buyer has valid exemption, the items that were approved for exemption for that buyer, and the percentage of exemption on the regular tax rate that was granted for that item, for that buyer, in that jurisdiction (details are provided in Chapter 4).

PAGE 15

5 The SSTP is still evolving as it deals with more issues in hearings and meetings, but regardless of the version of the recommendations that are finally binding, the CSP in this work provides a working model that deals with the issues involved in a way that presumably gives all parties involved, despite concessions some may have to make, a system that is still worth the fairness and convenience it ultimately achieves. A brief overview of the issues surrounding collecting taxes over state lines is presented in Chapter 2. The working mechanism and architecture of the CSP is introduced in Chapter 3. Issues involved in collecting tax are explored based on their relation to the CSP architecture in Chapter 4. Implementation details including information on various technologies used, the data structuring, data flow, and implementing objects interaction are dealt with in Chapters 5 and 6. Chapter 7 summarizes the contributions made by this thesis and discusses future work in this area. From mid-2001 when the implementation was complete to the time this thesis was submitted, the economy has taken a few tough knocks. Corporate accounting scandals, copious layoffs, pre-emptive strikes, and stock market lows have contributed to a general weariness and a slippery slope to recovery. E-commerce today is more rational in its expectations and scope. It is hoped that the states will find the work in this thesis useful when the economy improves.

PAGE 16

CHAPTER 2 OVERVIEW OF ONLINE SALES TAX COLLECTION ISSUES, LANDMARKS, AND INITIATIVES. The United States constitution mandates that states shall not enact laws that hamper the free flow of interstate commerce. Thereby Florida must not impose prohibitive tariffs on peaches coming into the state from Georgia and Georgia likewise for oranges. From the earliest cases in the 1930s, states have been grappling with issues of jurisdiction to tax out-of-state businesses that sold goods to in-state customers. Is it possible, the Advisory Commission on Intergovernmental Relations (ACIR) asked in its 1986 report on mail order taxation, to shield interstate commerce from undue tax burdens without causing revenue losses for state governments? This chapter starts with an illustration of the fundamental issues and introduces various efforts at their resolution over the past decades. The Issue Take for example three firms: firm A incorporated in Kansas; firm B also incorporated in Kansas but having offices and retail outlets in Florida; and firm C having a retail outlet in Florida. Scenario 1 A Florida resident chooses to purchase a big-ticket item costing $1000 from firm A. As firm A does not have nexus or any minimum presence in Florida, it is not required to collect the sales and use tax which at a 6% rate would amount to $60. 6

PAGE 17

7 The $60 however is still due to the state of Florida as the use tax. This has always been the case but such is rarely ever remitted by customers owing to widespread ignorance on the subject, or as was studied, people generally tend towards non-compliance when they observe others doing the same. The inordinate administrative task of collecting use tax from a large number of buyers as opposed to a small number of sellers has resulted in non-enforcement. Shipping and handling charges would ultimately reduce what seems to be a substantial saving but in general the savings depend on a unique relationship for that item derived from the kind of item it is, its price, and its shipping component. Based on this relationship is a more important and general concept of the price elasticity of demand for that item. Relative to income, the elasticity of demand for a product determines how people base their decisions on which of two or more closely related products to purchase. Price differences might effect either avoiding a purchase or a shift to a closely related product. For example, salt being cheap relative to most peoples incomes, on a price increase for their brand, they might never the less continue to purchase their brand. Salt is then said to be inelastic. If on the other hand, people choose to shift between Delta and United Airlines based on a small fare difference, the demand is said to be price elastic. For such products, the tax may become the deciding factor that pushes customers online. But choosing an out-of-state online retailer over an in-state bricks and mortar retailer for closely related elastic products also comes down to the difference not in the products themselves but the sellers. Clothes can be tried out at the store but some guess work goes into purchasing them online. Other considerations such as the shopping and customer service experience that real stores offer (easy store returns, servicing, etc.) overcome

PAGE 18

8 advantages that the tax break might portend to give online stores. However, over time certain categories of products are becoming more apparent in the advantages they possess in their purchase online. Scenario 2 The Florida resident chooses to purchase from firm B. As firm B has offices and retail outlets (or nexus) in Florida it is required to collect the sales and use tax. This scenario would be no different from the one played out with an in-state or main street retailer. Interestingly enough, when going online, some nation-wide retailers who had nexus in all states sidestepped the nexus issue by spinning off separate online companies, incorporating them presumably in the state that had the fewest customers. The online companies would then enter into a contract with the brick and mortar parent company to handle their deliveries, returns, etc. Such distortion of economic behavior is wryly noted by David Hardesty The loophole becomes part of the economics of the industry. In order to perpetuate the industry, the loop hole must be perpetuated [HAR01b]. Scenario 3 The Florida resident purchases from firm C which is a local bricks and mortar retailer. Sales and use tax is collected by the firm and remitted to the state. The unfairness inherent in applying the same law differently was grudgingly tolerated until the cumulative effects of sales steadily shifting to tax free out-of-state retailers were beginning to seriously jeopardize local retail viability in certain segments.

PAGE 19

9 Judicial and Legislative Background The due process clause mandates linkage between the state and the business firm as defined by a minimum presence or nexus. The commerce clause safeguards a national market free from local entanglements. The threshold of presence a firm has to exceed to qualify for nexus in a state has varied in quality and degree as evidenced by the courts stand in some landmark cases. The earliest mail order sales related case of Nelson v. Sears, Roebuck established that sellers with retail outlets in a state were required to remit use tax even on mail order sales delivered through common carrier rather than through the retail outlet [ADV86, p.54]. The linkage issue was furthered in five subsequent cases: 1954 Miller Brothers v. Maryland where sporadic deliveries by company truck to another state were not considered an adequate business presence. In 1960 Scripto, Inc. v. Carson, the presence of ten independent jobbers in the taxing state (no offices, property, or full time employees) met the requirement [ADV86, p.55]. In the landmark 1967 National Bellas Hess v. State of Illinois case, the court ruled that on account of the firm not having sufficient nexus in the state of Illinois, was not required to collect sales tax from its customers in the state. National Bellas Hess business presence in Illinois was limited to the distribution of sales catalogs and flyers. This overturned the statutory provisions of twelve states that had specifically identified mail order sales and advertising to have sufficient nexus at that time. In 1977 National Geographic Society v. California Board of Equalization, the existence of two small offices which provided only advertising support was found to have an adequate nexus to collect use tax [ADV86, p.56]. The Internet Tax Freedom Act 1999 includes a provision that states the accessibility of a website in a state does not by itself constitute nexus. It is open to interpretation when the website is hosted

PAGE 20

10 on an in-state computer [HAR98]. In Virginia, however, a ruling was issued that stated an out-of-state auto parts seller whos own web server was located at a hosting companys in-state facilities (that provided hookup and maintenance services) did not constitute nexus [HAR00a]. During the sixties and through the seventies various committees and bills such as the Willis committee bills, Mathias bill, and Mondale bills attempted to seek common ground between the taxing authorities and businesses by introducing ideas such as a registration mechanism for buyers that would remit tax independently, a de-minimis provision to exempt small out-of-state businesses from the burden of collecting tax and the Traigle plan to register a combined state and local tax rate. These attempts helped expand the avenues of resolutions and perhaps simplification. They appeared in several hearings to congress over the late seventies and eighties [ADV86, p.59]. States Arguments and Other Tax Issues Erosion of Tax Base The argument from the states point of view was principally that of the erosion of the tax base. States have the obligation to protect their revenue streams to provide for the services it renders to its citizens. Concerns from main street retailers grew over time as to the competitive disadvantage out-of-state businesses place them at by not having to collect sales tax. The arguments from the out-of-state businesses have evolved over the years to be almost insurmountable: The out-of-state business does not benefit from the services a state provides to in-state businesses (that are financed by the sales taxes collected) and, therefore, should be absolved of the obligation to collect tax. To this, the states, and Justice Fortas in his dissent in National Bellas Hess, put forth that they (the states) undertake in creating, developing, and sustaining the customer base, banking and

PAGE 21

11 commercial institutions, and communication and transport infrastructure within the state, which by themselves are the services the state provides. A very serious issue out-of-state businesses raise though is one of the costs associated with having to collect tax. A local business has to deal with only one rate, the state rate, or at most two, the local jurisdiction rate that is just added to the state rate. It is a reasonable expectation that a local business can keep track of changes to the tax base. Items such as food, medicines, and clothing are exempt from taxes in some states or are taxed less. New items may be made exempt and currently exempt items may be made taxable. There are temporary changes to the tax rate (tax holiday) along with permanent rate changes. Then there are the exempted buyers such as orphanages, religious, and charitable institutions that get special exemption rates for certain categories of items [ADV86]. Cost of Collecting Taxes Consider, the sale of a $10 item for which a 6% Florida state sales tax and a 1% Alachua county sales tax is levied. Suppose a hypothetical 10% gross profit or 100 cents was made by the vendor, the cost associated with remitting tax collected on the sale through either monthly or quarterly returns to the state will factor in as an operating cost. This cost is defrayed in some states by allowing the sellers to keep a percentage of the tax collected. In other states, the costs are entirely borne by the seller. Clearly, the cost of collecting taxes has an impact on profit, and thus, prices [ADV86, p.43]. Incidence and Sourcing The legal incidence of sales tax is on the buyer in some states (consumer taxes) and on the vendor in some (vendor taxes) and on both in some states (hybrid). The economic incidence however shifts between a higher price paid by the buyer and lower net revenues made by the seller. Regardless of incidence however, sales tax is most commonly

PAGE 22

12 collected and remitted to the state on the buyers behalf by the vendor as this is easier from an administrative and cost point of view. The sale is said to be sourced not at the sellers location (origin) but at the location of the buyer (destination) and tax laws in the buyers jurisdiction apply on that sale. As most of the incidence falls on the buyer, it is logical that his or her jurisdiction, that provides services to its residents, has a stronger claim on the tax. Also treating all out-of-state sellers alike creates a level playing field as opposed to distortions where a seller might be selected based solely on being based in a state, for instance that has low or no taxes [ADV86, p.45]. Acts and Initiatives Affecting Sales and Use Tax Internet Tax Freedom Act 1998 The Internet Tax Freedom Act (ITFA) passed on October 21, 1998 imposed a 3-year moratorium on the following 1) Taxes on Internet access unless such taxes were imposed and enforced prior to October 1 st 1998 and 2) Multiple or discriminatory taxes on electronic commerce. In essence, the ITFA defined a narrow, tax-exempt service (internet access) and a few guidelines to guard against choking e-commerce from zealous taxation. More information about the ITFA is presented in Appendix B. Advisory Commission on Electronic Commerce (ACEC) The advisory commission was to conduct a thorough study of federal, state, local, and international taxation and tariff treatment of transactions using the Internet. Its report and recommendations were to be submitted to congress in June 2000. The ACEC, chaired by Virginia governor James S. Gilmore, III, an anti-tax advocate, submitted its report and recommendations, well ahead of schedule in April 2000. On perusing the report, it might

PAGE 23

13 be observed that the formal findings and recommendations dealt with safe and broad issues (privacy and the digital divide). The real, industry-changing issues (sales and use tax) on which congress would have needed guidance, rallied only a majority vote. Out of the 19 member committee, there were 7 abstentions for each of the majority vote proposals. The abstentions could probably be interpreted due to a lack of clear information on what is essentially an evolving, contentious issue (ACEC). More information about the ACEC can be found in Appendix C. Streamlined Sales Tax Project (SSTP) From its inception in March 2000, the SSTP has made significant strides in its objective to find a solution to simplifying and modernizing the complex tax systems that has been a hindrance to efficient tax collection and administration, both within states and across state lines. The general objectives of the SSTP closely follow the proposals set forth for a simplified tax system by the ACEC. It is one of the recommendations of the SSTP, namely a third party service provider for tax collection which forms the basis for this thesis. The SSTP will be cited continuously through the text of this report. Readers are urged to read the executive summary of the SSTP reproduced in Appendix D. National Conference of State Legislatures (NCSL) In the early months of 2001, the National Conference of State Legislatures had approved the SSTPs final draft of recommendations albeit with some very crucial amendments. The NCSLs version of the SSTPs tax agreement omits several provisions that were considered to be controversial. The proposal for a uniform tax base was removed, and the provision on caps and thresholds were removed. The NCSL also voted to move the SSTP from a lead position to an advisory position. This was reported to have

PAGE 24

14 been done to move the process from the tax administrators realm to that of the politicians. The NCSLs revised plan has generally found more acceptance among states as it is less threatening than the SSTP recommended changes. As more states enact legislation to participate in the SSTP, it remains to be seen if the states that have enacted legislation to explore the NCSLs amended version make progress in a direction that is more viable [HAR01a].

PAGE 25

CHAPTER 3 ARCHITECTURE OF THE CERTIFIED SERVICE PROVIDER (CSP) TAX COLLECTION MECHANISM. The CSP architecture developed in this thesis, is currently a single tax server established at the machine and port identified in the configuration information. Sellers registered with the CSP send requests in a TaxML (see Appendix A) query document to the CSPs tax server (the CSPs tax server is frequently identified in the text of this report simply as the CSP). The CSP calculates the tax due and sends a TaxML reply document back to the seller. The CSPs bank is credited the tax amount due on the transaction by the seller. Figure 3.1 illustrates the general relationship between the CSP, the sellers, and their customers. The architecture of the CSP tax collection mechanism, shown in Figure 3.1, can be described in two functional sections: Seller site and Certified Service Provider site. The functionality of each section is described in detail in the following pages. Seller Site The level of intrusion of the CSP software at the sellers site is minimal consisting of a thin network protocol client henceforth described as the stand-alone network client module as shown in Figure 3.2. It requires certain networking services and information in the form of an XML document from the seller. Figure 3.2 is a birds-eye view of the data flow between the seller site and the CSP in the form of an XML document. 15

PAGE 26

16 Figure 3.1 The CSP in relation to sellers and their customers. 1) Customers send information about purchasing items, quantities, locations of use, and other information to the seller. To provide for scalability, the following is proposed: 2) Several ports can be established for servicing requests, and for sending back replies. 3) A reliable service can be made available by replicating the CSPs tax server at several sites. Sellers can be given a choice of machines and ports from which to choose, which they prioritize through analysis of their experience with their various choices. A distributed CSP tax server system will need an application to maintain a protocol that ensures coherency and concurrency of distributed objects such as the tax base.

PAGE 27

17 Figure 3.2 XML data flow The description below expands on the role of each module while walking through the process from transaction initiation, tax retrieval to funds transfer. Figure 3.3 shows the overall transaction data flow. A user initiates a transaction by acknowledging intent to purchase merchandise (that is assumed to be in stock) by asserting a submit button on the sellers web site. The acknowledgement is handled by the sellers transaction processor. Information about the user is either retrieved from file or is submitted by the user prior to asserting the submit button.

PAGE 28

18 Figure 3.3 Functions, data flow and interaction at the seller site The transaction processor creates a transaction ID and returns it along with user information to an XML converter that converts the received objects into a TaxML query document conforming to the TaxML DTD (Appendix A). The TaxML query document is submitted to the stand-alone network client module, which transmits the same to the CSP. The transaction processor meanwhile creates a transaction thread christened with the transaction ID, which blocks for activation from the stand-alone network client module upon arrival of tax information from the CSP. If a reply from CSP does not come in a specified timeout period, the current implementation sends a notice to the customer of

PAGE 29

19 network problems and makes a suggestion to resume shopping after some appropriate time period. The TaxML reply contains the tax calculated and the corresponding transactionID. Upon a TaxML replys arrival, the stand-alone network client module wakes up the thread blocked at the transaction processor whose name corresponds to the received transactionID. The received TaxML document is extracted into objects and passed on to this awoken thread. The objects are processed and the final amount due is displayed to the customer. When the customer sends acknowledgement to the final amount due (price of merchandise plus the tax), the update module (not implemented) temporarily freezes or debits the inventory database for the number of items being processed in the transaction for a reasonable timeout period for transfer of funds (or presumably to select an alternate source of funds should one fail). 1 The verification module (not implemented) checks to see if the source of funds (SF) (credit card or bank) has sufficient funds for the transaction to go through and if so freezes or commits the amount due. If a negative response is returned from the SF due to an insufficient balance, the user is asked to use an alternate source or is led through whatever mechanism the seller has created to handle such a situation. 1 A potential security hazard exists wherein a malicious customer might freeze large chunks, or even the entire inventory only to have the transaction intentionally fail due to insufficient funds. This temporary freeze would hurt legitimate customers who might get a not sufficient items in inventory notice. Alternatively we can avoid freezing till the very last moment. Once the customers source of funds are identified to be sufficient, one can perform an inventory check and freeze if sufficient items available, otherwise notify customer to reselect the items. As the customers funds are not frozen there is no problem on the part of the credit card issuer or bank

PAGE 30

20 On a positive response (with the amount due frozen at the SF for transfer to the seller) the transaction is said to have gone through. The customer is notified of the successful transaction along with shipment and tracking details. Meanwhile, a funds transfer module (not implemented) initiates a transfer protocol with the source of funds, the sellers bank, the CSP, and the CSPs bank. The funds transfer module sends a request (tracked by a transaction ID) to the SF to transfer funds to its bank. Once it receives confirmation from its bank that the transfer has taken place, it retains the price of the merchandise and initiates transfer of the tax amount to the CSPs bank. When it receives confirmation from its bank that the tax has been remitted to the CSPs bank, it sends a transaction termination message to notify the CSP that the funds have been sent for the corresponding transactionID. The underlying protocol addresses the details of tracking messages through a transactionID and about lost transfers and messages. Updates are committed to the inventory database, user information tables, and merchandise shipment tables. A tax log is also maintained for all the taxes that were paid. CSP Site The CSP site has its functionality divided in several modules as shown in Figure 3.4. The most important module, the database controller accesses the ZIP code indexed tax base, retrieves corresponding taxes, information on exempted items, and exempted buyers and tax holidays. The network module at the CSP site receives the TaxML query document and initiates an extractor. It then goes back to listen for more TaxML documents. The

PAGE 31

21 extractor parses the TaxML document into objects and sends them to the database controller. The database is queried for the tax percentages values for the listed items, in their associated use locations. Items can have a quantity based tax or a price based tax (explained in Chapter 4). Figure 3.4 Functions, data flow, and interaction at the CSP site If the item is tax exempt, that information is returned. If exemption is being sought (certain buyers have exemption privileges, as discussed in Chapter 4), the buyers tax ID is checked to see if he/she is approved for exemption. If the buyer is exempt, the

PAGE 32

22 exemption percentage for that buyer, for that item, in the use jurisdiction is retrieved. Otherwise notes detailing why the exemption is not valid anymore are returned. Tax holidays are checked for the item, following which tax is calculated (taking into consideration exemption percentage or tax holidays) and recorded in objects maintained through the process. The tax calculated for each item in the transaction and exemption status notes are returned to the sellers site. This is accomplished by converting the information accumulated in various objects (that were maintained in the tax extraction process) into a TaxML reply document, and dispatching it through the network module to the seller. The transaction information is sent to a recorder module that logs each request. All the information relating to the transaction, including the time at which the tax quotation was sent to the sellers site is stored in the log and a receipt is flagged on the tax due for the transaction. A timeout period is initialized for the receipt. Logs are to be cleared periodically of transactions that have a receipt flagged on them after the timeout period. It is assumed that the transaction did not go through at the sellers end. In the unforeseen case that the transfer of tax due from the sellers site is received after the timeout period, the sellers site is asked to send the transaction details once again. Transfer of funds confirmation from the CSPs bank initiates retrieval of the record with the corresponding transactionID. The receipt flag is removed. Upon receiving a transaction termination message from the seller, the CSP returns a transaction termination message.

PAGE 33

CHAPTER 4 THE CSP ARCHITECTURE, MECHANISMS, AND ISSUES. Using the SSTP recommendations as a model to address issues surrounding tax collection, other ideas and solutions were explored. This chapter introduces various issues and discusses how the proposed architecture and the implemented architecture differ from, extend upon, or conform to SSTP guidelines. Table 4.1 SSTP recommendations. Proposed architecture and implementation information. Uniform definitions in Tax base Collection cost allowance Centralized exemption Centralized seller registration Tax rate database SSTP guidelines Present Present Identification numbers Present Publicly accessible databases Architecture proposed Present. Described in section below. Described in section below. Highly flexible system described below. Present Database replicated as distributed object at CSP mirror sites Implemented Database has standardized tax bases referenced by their version numbers. TaxML documents have version numbers tags on items. Transfer of funds from credit card and banks are not implemented. Database keeps track of exempted buyers, items exempted, percentage of exemption in relation to jurisdictions where such apply. Interface for registration provided. Interface provided Interface provided to jurisdictions to modify tax rate database. Distributed objects and mirror sites are not implemented. 23

PAGE 34

24 Table 4.1 (continued) Multiple locations of use Taxing jurisdiction resolution Tax Holidays Caps and thresholds Confidentiality SSTP guidelines For digital products, sellers need not collect tax if customer applies for multiple points of use exemption Delivery location is the taxing jurisdiction. Locations resolved by mapping ZIP code areas to jurisdictions. Only for goods specifically defined in the agreement. Member states must eliminate caps and thresholds. Only information required for calculation of tax to be given to CSPs. Architecture proposed Provides for tracking and assessing taxes on quantities of an item being shipped to/used in different jurisdictions. Details in section below. Use location is the taxing jurisdiction. Zip code areas map to jurisdictions. Described in section below. Tax holidays for any goods the jurisdiction sees fit. A slab based tax rate system is proposed and is explained in detail in section below. This gives jurisdictions exacting control over their tax base. Only customers that request exemptions have their exemption certificate presented to the CSP for verification and resolution of exemption percentages. Implemented The TaxML document holds information on items, and their constituent individual quantities being shipped to/used in various jurisdictions. Interface provided for modifying ZIP code area information. Jurisdiction can log into its database and create tax holiday periods for any item. Jurisdictions can log into their database and specify tax slabs for items in tax base. Buyer tax id for buyers requesting exemptions. The seller tax id for keeping track of transaction-tax remittance, and audits in case of irregularities.

PAGE 35

25 CSP Architecture and Implementation Issues Resolution of Item Being Taxed Items listed on a sellers website are identified differently at various levels in the tax extraction process. Take for instance a particular shoe on display for sale among hundreds of others that are also available. The seller in his database uniquely identifies this shoe by an item code. Associated with the item code is presumably an entry that spells out in a human-readable, perhaps non-unique language, a brief description of said item. In the seller site implementation of this work, the following colon delimited format is used: [Description of item:customer_site_item_code]. The description is permitted to have spaces while the item code is not. The shoe in the example above might have the following entry associated with it: [Operating room moccasins:med34554]. For taxation purposes, the shoe is determined as belonging to the category Hospital Supplies. Yet another shoe might belong to the category Extreme Sports. The collection of such categories is listed in a standardized tax base. All conceivable items, taxable or otherwise, presumably map to one of the categories in the tax base. The tax base technically should contain only the categories that are taxable but this architecture considers all items as belonging to the tax base. The actual determination of whether an item is taxable or not is a jurisdiction specific issue. 2 2 The standardized tax base was one of the items left out in the National Conference of State Legislatures (NCSL) version of the SSTP agreement-the justification being that more states would be interested in signing up when not confronted with an undertaking that mandates relinquishing their tailored mapping system, built perhaps over several years consuming committee man hours and good intentions. And then there is the resistance from some states where industry lobbyists, as David Hardesty reports, complained about the potential negative impact of standard definitions (preceding categorization). For example, confectioners fear that by creating a separate category within food for candy, some states might be encouraged to tax candy [HAR 2001-a].

PAGE 36

26 The standardized tax base is created once all the participating states in the SSTP formulate and agree upon the definitions and mapping. Once ratified, it is frozen. A version number assigned to it and transferred to each seller. The seller uses the frozen version to map the items in its inventory, manually, perhaps in consultation with an SSTP designated office for resolving difficult to map items. There will be items that belong to several categories either in a vertical or horizontal manner. Vertical relationships between categories are represented by a hierarchy with increasing specialization on the way down. For example three categories that are related vertically: Food, Recreational food and Candy. An item will belong to the category that represents it the closest. Horizontal relationships between categories can be represented by a Venn diagram. Two categories such as Jewelry and Industrial tools may lay claim to diamonds. An item will be classified in the category with which its use is most closely associated. The tax base category name is user-friendly and may contain spaces, while the tax base code consists of an alpha-numeric sequence strictly meant for database interaction and storage. Item name resolution traces its path from the seller site code to tax base code and tax base version. The seller site name and tax base name are used for describing items to humans. The Money Trail When the extracted tax information is passed to the waiting transaction object, the customer is presented with the final amount due. The customer acknowledges the final amount and sends a confirmation. The current seller site implementation handles only The standardized tax base is arguably one of the most critical components in the CSP architecture without which the automated mapping process would be dealing with 50 hashes from the states or infinitely more frightening, 7500 hashes that includes all the taxing jurisdictions.

PAGE 37

27 credit cards and checks for sufficient funds in a dummy method, which always returns true. The architecture envisages a production version in which the seller site then commences a transfer of the amount due towards tax to the CSPs bank. The CSP is also sent a notice of the imminent transfer with a reference to the transactionID. Needless to say, all transfers of notices or messages over a network are acknowledged through some protocol. The seller site logs the transfer in its transaction files and terminates that thread. The CSP, upon receipt of the transfer information from its bank, logs the same information in its transaction logs. An alternative that reduces the number of transactions, and is therefore more attractive is where the CSP maintains credit accounts or direct-debit information such as a bank routing number for each seller. Upon sending the tax information, the CSP awaits a go ahead from the seller confirming the sale. Then depending on the setup, either the sellers credit account is charged or a transfer of funds is commenced. If the go ahead is not received within a reasonable duration of time, it is safe to assume that the sale failed as a result of the customer canceling the transaction after being presented with the final amount or due to insufficient funds. The CSP can choose to remit the tax due to jurisdictions in real time, or on a daily, weekly, or in some other suitable interval of time. The cost of services provided by the CSP is deducted by it as a percentage of the tax collected or through some other arrangement between it and the participating states. As is provided in the SSTP agreement, the seller is absolved of having to file returns, and from audits considering items that tax information was sought on were represented correctly.

PAGE 38

28 Buyer Exemption Certificate Security Buyers that qualify, apply once at the participating states portal (PSP) for exemptions on particular items and the ZIP codes in which they seek exemptions. The jurisdictions deal with exemption requests on a case-by-case basis and grant or deny exemption status. On receipt of at least one exemption status, the buyer is issued a buyer exemption certificate as represented by an alphanumeric code. This code is used by buyers when purchasing items. In the current implementation, the code is entered in-securely i.e. the seller interface does not implement a secure form for buyer information input. However, a secure form addresses only part of the security concern-that of the buyer exemption certificate being intercepted by an eavesdropper. The other security concerns or potential misuse scenarios include a) buyer exemption certificate deliberately given to friends or b) stolen through conventional non-electronic methods. There are several possible methods that address these concerns: 1) For each exempted buyer certificate, register the I.P. number of the computer that the buyer would be using to make purchases. This requirement will exclude those buyers that do not own computers and are opportunistic in their usage. 2) Register delivery addresses associated with the certificate. This, however, does not solve the case where in a buyer may register the address of the person to whom he is giving the certificate. Damage is limited when compared to a free for all type of development such as when a certificate is published online or distributed in news groups or group mails. 3) Public key cryptography: The buyer is issued a private key, the public key for which is stored along with his other account information at the CSP. When a transaction is commenced, the buyer, prior to asserting the purchase button that sets in motion the tax retrieval and exemption verification and calculation process, uses his private key to encode a challenge c sent by the seller site. The encoded message e(c) and the actual message c are sent by the seller site to the CSP along with the transaction information. Verification is successful when the CSP extracts the encoded message d(e(c)) using the public key of the buyer and positively matches it to the actual message (d(e(c)) = c).

PAGE 39

29 Privacy Safeguards The name or any other form of identification of the buyer is not sent to the tax jurisdiction. The buyerTaxID is sent only in the case exemptions are sought so as to enable the CSP to approve the buyer. This would enable CSPs to store this information-which might be beneficial in analyzing exemption irregularities. Future analysis of log data at the tax jurisdiction can be made only by zip code. The credit card company or any of the banks involved are not informed of the items purchased by the buyer. Only the seller information is sent. Message Passing Protocol The CSP has a well-identified address and port to which the sellers connect. The machine used to host the CSP was taproot on the CISE network listening on the port 8277. Any seller wishing to communicate with the CSP sends the TaxML query to taproot on port 8277 using UDP. UDP was used as it is fast, but since it is unreliable, a protocol of acknowledgements between the CSP and the seller is required to ensure a measure of reliability. For sellers that have a volume of transactions beyond a certain threshold a connection oriented communication service is justified. Multiple transaction threads can use a single connection. An additional layer would interface with the shared connection to keep track of out-going packets, and pass in-coming packets to their rightful thread owners. Appendix E addresses a few scenarios that the UDP based protocol generates. CSP Tax Resolution Issues Sales or Use Tax The distinction between sales tax and use tax is one of vendor collection obligation more than a meaningful economic one [ADV86, p.23]. Out-of-state businesses are not

PAGE 40

30 obligated to collect and remit a use tax on behalf of its in-state customers. It is the customers that are required to conscientiously apply the local tax laws to their purchases and remit the same to the states exchequer. This arrangement is plainly un-enforceable due to its cost in-effectiveness and the administrative drudgery involved in keeping track of a large number of customers and an exponentially larger number of transactions. Solutions and agreements to aid in the collection of use tax are the basis for the SSTP. The CSP is such a mechanism to collect the use tax due on an item in the location of its usage. 3 Sourcing the Transaction: Origin or Destination A transaction is legally said to have taken place or sourced at the point of delivery of goods or services. The SSTP recommends for a digital product (software, books, movies, music, news, information, and services) delivered electronically, the buyers billing address be used as the taxing jurisdiction. If the buyers address is not known then the sourcing is at the server used to deliver the service. To prevent servers from being relocated to tax free states, the agreement stipulates that a server alone without an administrative setting, is not acceptable [HAR00b]. This architecture sources the sale at the location of usage and not the location of delivery, i.e. the tax is determined from the usage jurisdictions tax base and not the delivery jurisdictions. Customers explicitly 3 Most states that enacted sales taxes followed them shortly thereafter with a use tax, the main purpose of which was to tax purchases made in other jurisdictions by residents of the state. Typically, the use tax is a tax on the enjoyment of that which is purchased when the purchase would, in the absence of vendor collection problems, be subject to the sales tax [ADV 1986]. Significant differentiation was made between the sales tax and the use tax in a series of cases heard during the mid forties wherein the court indicated that the standards for collecting sales and use taxes from vendors were different. Out-of-state vendors were not to collect sales tax in most cases though a use tax might be acceptable in some cases. This legal distinction was supplemented by linkage issues in later cases [ADV 1986, p.54].

PAGE 41

31 select a use location, if different from the delivery location, for each item in their shopping cart. This is an important addition that this work makes to SSTP recommendations as it is the use tax that is being collected. In most cases the delivery location and the use location are the same, but there are classes of transactions where they might differ. A company might have items delivered to its corporate head office from which consignments may be sent out to branch offices. People might use for delivery, the nearby address of a friend in a neighboring jurisdiction that has lesser taxes. Stretching further on that line of reasoning, rather thin perhaps, customers might purchase items while living temporarily out-of-state whereas the significant enjoyment of the item takes place on their return. In all cases cited, the actual usage of the item takes place in a different jurisdiction from the delivery jurisdiction and it is but logical to let the use location prevail. Multiple Use Locations, Multiple Delivery Locations The most common case would be that of a head office of a corporation that has a centralized purchasing system. Local branches purchasing requests are channeled to the head office that approves and processes the orders. The same item can then have multiple delivery locations, which again engender multiple usage locations. Another significant class of transactions are gifts. A customer might order items to be shipped to various delivery locations. The CSP implementation handles transactions with multiple items, being delivered/used in varying quantities at multiple locations. The use location associated with the delivery location is always used to compute tax for the quantity of the item destined there.

PAGE 42

32 Zip Code Area Aggregates Based Jurisdictions Currently, forty five states and the District of Columbia impose sales and use taxes on purchases of tangible goods. In addition, 4,696 cities, 1,602 counties, and 1,113 other tax jurisdictions also impose sales taxes [SST02a]. The physical location of all customers map to these 7457 taxing jurisdictions in a hierarchical fashion. That is, as jurisdictions enclose other jurisdictions, an items tax is calculated cumulatively by adding the state tax, to the county tax if any, and to the city tax if any. The precise determination of a customers address to its enclosing jurisdictions has to be done on an address by address basis and can be automated with a database of address and their corresponding enclosing jurisdictions (perhaps MapQuest, Yahoo maps, MSN maps, or another company that has already charted a large number of US addresses can help in jurisdiction resolution). The current CSP implementation in this work uses a ZIP-code-based mapping system and aggregates individual ZIP code areas to form jurisdictions (the implementation does not however cumulatively apply taxes of enclosing jurisdictions). This aggregation of ZIP code areas to jurisdictions is not precise as jurisdiction boundaries are not defined by ZIP codes areas and there will be customers on border ZIP code areas that may map to a jurisdiction to which they do not belong. In a production version of the CSP, some optimization is possible by only having to map those customers living in border ZIP code areas. The current CSP implementation also does not calculate cumulative taxes from enclosing jurisdictions. Recommended CSP future release work should include ZIP code areas that are aggregated to form enclosing jurisdictions. Cumulative taxes from such enclosing jurisdictions can then be calculated. Production version work should have the jurisdiction

PAGE 43

33 of customers on border ZIP code areas resolved by using the services of a commercial mapping company or by using such a database if developed. Caps, Thresholds, and Tax holidays Some jurisdictions use a measure of caps to either exempt, or assess less tax. In New York, clothing sales up to $100 are exempt from tax. In other places there are thresholds, or a volume of purchase beyond which tax exemptions or lesser rates apply. Tax holidays are used by various jurisdictions to give a temporary reprieve from taxes on certain goods. A popular tax holiday in some jurisdictions is the one before school starts. In the current CSP implementation, caps and thresholds are dealt with in terms of the concepts introduced in the next section. Jurisdictions can log into their account and set tax holidays for items in their tax base. Start dates and end dates are specified for each item. When an item with a tax holiday flag set, it is universally granted the reprieve from tax regardless of the type of buyer. Study in Control Minutiae: Tax Based on Gross, Quantity and Price The current CSP implementation gives jurisdictions intricate control over how items in its tax base might be taxed. At a broad level, items can be deemed to fall under two categories. Those that are quantity oriented and those that are quality-price oriented. Quantity oriented goods are those that are usually purchased by weight (with an avoirdupois or quantitative measure): two metric tons of sugar, three hundred cases of oranges, 800 liters of sunflower oil etc. Quality-price oriented goods are those that are usually purchased in singles: a house, car, computer etc.

PAGE 44

34 Tax based on gross Most items in the tax base do not require specific control as it is neither desired nor required. Tax based on gross is the most common type of tax across the item spectrum (both quantitative and qualitative). A percentage of the total transaction amount is assessed as the tax. A 6% tax on a $100 transaction would yield $6 in tax revenue. Tax based on quantity There are times when jurisdictions might want to base tax on the quantity of an item being sold. An overabundance of oranges in a particular season might merit from a lesser tax rate for purchases beyond a certain quantity. The current CSP architecture provides for 20 slab rates based on measure. For example: A jurisdiction might change its rates to a 6% rate for oranges up to 600 cases, a 2% rate for oranges more than 600 cases-up to 1000 cases, and a 0% rate for above 1000 cases. On the other end, consumption of commodities may be controlled by adjusting the tax rates applicable at different quantities. Figure 4.1 charts out sample slabs to encourage or discourage purchase and consumption. Item: Oranges Quantity (in cases) Tax Rate 1 600 6% 601 1000 2% 1001 + 0% Perhaps in a war-time economy, oil may be charged at 2% for purchases up to 20 liters and 10% for purchases above 20 liters. Item: Oil Quantity (in liters) Tax Rate 1 20 2% 21+ 10% Figure 4.1 Illustration of the quantity based slab rate system

PAGE 45

35 The architecture envisions that jurisdiction representatives log into their accounts and set up the hash table for items that need quantitative controls. Future implementation work includes the following 1) Users upon selection of an item that has a quantity based tax rate would be given details about the same to aid in decision making and 2) Provide a mechanism to track users so they do not make multiple purchases of an item just below the cap beyond which it is charged at a higher rate. Tax Based on Price For items such as cars and houses, a jurisdiction might have social goals that seek to rectify in some measure, inequalities. Taxes can be based on the price of an item. The current CSP architecture allows for 20 slab rates based on price. For instance, a car that costs less than $4,000 may be taxed at .5% (subsistence). A car that costs between $4,000 and $10,000 taxed at 2%. Cars costing between $10,000 and 20,000 may be taxed at 4.5% and so forth. Figure 4.2 charts a sample price based slab. Item: Car Price Tax Rate < $4,000 .5% 4,001 $10,000 2% $10,001 $20,000 4.5% $20,001 $35,000 6% $35,001 $55,000 7% $55,001 $90,000 8% $90,000 $200,000 10% $200,001 + 14% Figure 4.2 Illustration of the price based slab rate system Such a micro controlled system can easily get out of hand if not handled with care. A worst-case scenario where every item in the tax base has a different slab is frightening.

PAGE 46

36 Jurisdictions should exercise prudence and use slab-based rates for a very selective set of items. Inclusion of items in this selective list must be justifiable, and approved by a special panel set up for that purpose. Those items for which the slab rate has outlived its usefulness should revert to a gross rate. Study in Exemption Minutiae: Exempted Entity-Jurisdiction-Item-Percentage of Exemption A variety of users are exempt from paying taxes owing to concessions that society and the government makes to help in their livelihood, or maintenance and upkeep. Charitable institutions, religious institutions, senior citizens, disabled war veterans, persons with challenges, or unemployed citizens, might, among others, fall into this category. The implementation in this architecture gives each jurisdiction control over many aspects of exemptions. A user is exempt in a particular jurisdiction for a particular item at a particular percentage of exemption. For instance, a person identified as a disabled war veteran may be set in a particular jurisdiction to receive a 100% exemption of tax on food, a 95% exemption on clothing, a 80% exemption on appliances, and a 45% exemption on all other items in the tax base. The current CSP implementation employs this multi-variant exemption schedule and envisions jurisdictions to be able to log in and make changes to these tables. An exempted entity has the following data items associated with it: 1) Exemption period validity period (identified by a date). 2) Notes on exemption certificate usage. Irregularities or investigations currently in process or past will appear here. 3) For each item exempt in tax base, an exemption percentage. Future work should include a mechanism for selecting groups of items-created especially for each exempt group. To enable more flexibility, a few general groups

PAGE 47

37 should also be created. This would vastly simplify the exemption process enabling a scenario where a senior citizen might request and be approved for the Senior Citizen Exemption Package along with General Exemption Packages No. 45A and No. 332B. Exemption Registration Procedure The Participating States Portal (PSP) has a centralized form that users may fill out to request tax exemption. The user specifies the items and the jurisdictions in which exemptions are sought. This form is sent to each jurisdiction where they show up in a request for exemptions list. Jurisdictions manually inspect the credentials of the requesting user. Upon verification and approval, an exemption certificate ID is created and sent to the user. The format of the ID must be standardized. A central PSP mechanism that issues IDs is envisioned.

PAGE 48

CHAPTER 5 IMPLEMENTATION DETAILS: HOW TO RUN THE APPLICATIONS The implementation of the CSP is done in Java. It was developed and tested in the Java 2 platform version 1.3.1 on a Sun Microsystems Ultra5 (sparc) running Solaris version 5.8. The database used was Sybase. Java Servlets were used to create all interfaces. Though initially developed and tested using the TomCat 3.3 server, the servlets now run, on the TomCat 4.1 server. Sellers communicate with the CSP at an established machine and port. The CSP identifies the machine on which it is running and the port it is using through a configuration file in the form of static objects in a public java class called ConfigData.java. The Seller implementation is started by the servlet that handles user transactions ShoppingCartNew.java. A text file or an XML configuration file are the desirable methods for configuring any application. The next release should have XML configuration files. How to Start the CSP To run the CSP on a particular machine and port, follow directions 1 through 4. If no configuration is desired, follow steps 3 and 4. The CSP machine by default is taproot.cise.ufl.edu and the port is 62974. 1) Identify the machine and port on which to run the CSP. 2) Change ConfigData.java to reflect the machine and port. Compile it. 3) Login into any machine on the cise.ufl.edu sun machines network or network that has the machine identified in step 1. The network has to be configured such as to allow remote running of processes using the rsh command. 38

PAGE 49

39 4) Run StartCSP.java using the command: java StartCSP 5) The CSP generates a log file csplog in the directory of execution. How To Start the Seller The seller is started automatically by the servlet ShoppingCartNew.java, which handles user interaction. The Interfaces are all hard coded to run on the machine sun114-44 on the cise.ufl.edu network. A small script at the root of the servlets directory by the name of start.sh can be used to start all servlets as described in the next section. The default port for the seller is 8277 on the machine the servlets are running on: sun114-44. The default port can be changed in the ConfigData.java, which will need to be compiled for the change to take effect. The machine can be changed only as described in the next section. How To Start The Interfaces 1) Login into sun114-44 on the cise.ufl.edu network. 2) Run the start.sh script using the command:./start 3) If servlets are to run on another machine, each reference to the machine sun114-44 in the servlet programs have to be changed to reflect the new machine. The servlets use static html pages currently hosted at http://www.cise.ufl.edu/~mc1/thesis/SellerSiteShopping/ and http://www.cise.ufl.edu/~mc1/thesis/Interface/ and these files will become unavailable when the mc1 account ceases to exist. They would need to be copied to a fresh location and references to them in the servlet programs have to be changed to reflect the new location.

PAGE 50

CHAPTER 6 IMPLEMENTATION DETAILS: THE CLASSES The implementation uses Javas net, sql, and swing packages, and programming features such as synchronized monitors. The following is a discussion of the classes that compose the various applications, how they relate to each other and what they accomplish. TaxML Object Classes The TaxML object classes hold the data parsed from the TaxML documents. Each object is designed so as to parallel an XML entity. The attributes of the XML entity become the corresponding objects primitive data fields. An XML entity that have other entities ensconced within them are represented as user defined object data fields. For instance, the object class TaxInfo is the big wrapper that parallels the outermost entity in the TaxML document-taxinfo. version, taxbaseversion and query are attributes to the taxinfo entity which are reflected by primitive type attributes of the same names in the object class TaxInfo. Buyer, Seller, and JurisdictionTaxAggregate are three user-defined objects that have their own primitive attributes and user defined objects within them paralleling the TaxML document structure. Figure 6.1 illustrates the parallel mapping schema. 40

PAGE 51

41 . . This translates to an object called TaxInfo as defined below: class TaxInfo { String version; String taxBaseVersion; String type; Buyer buyer = new Buyer(); Seller seller = new Seller(); JurisdictionTaxAggregate jurisdictionTaxAggregate = new JurisdictionTaxAggregate(); . } Figure 6.1 XML entities map to respective Java objects A TaxInfo object that bears query type information usually has a null JurisdictionTaxAggregate object. A TaxInfo object that bears reply type information usually has null Buyer and Seller objects. The TaxML object classes laid out in Figure 6.2 illustrate their enclosing structure that parallels the TaxML query and reply type documents. The Buyer and Seller parts together parallel a TaxML query while the JurisdictionTaxAggregate part parallels a TaxML reply.

PAGE 52

42 The query type TaxInfo object is initially assembled by the seller as the customer makes item choices including quantity, delivery, and use locations for portions thereof of the quantity. A complete query type TaxInfo object is then converted to a TaxML TaxInfo { Buyer { Item { DeliveryLocation } } Seller { Transaction { MyDate MyTime } } JurisdictionTaxAggregate { TaxItem { TaxAmt { Notes } } } } Figure 6.2 The TaxML DTD maps to the TaxInfo Java object query type document and is sent across the network. The CSP receives the TaxML query type document, parses it, and forms the same query type TaxInfo object that initially existed at the sellers site. Tax is calculated and put together in a reply type TaxInfo object, which is converted into a TaxML reply type document and is sent across to the

PAGE 53

43 seller. The seller parses the received document into the same reply type TaxInfo object that existed at the CSP. Information is extracted from the reply type TaxInfo object to the interface objects servicing the customer. The entire process is illustrated in Figure 6.3 Figure 6.3 Information containers and paths CSP Site Java Classes The CSP site is comprised of a collection of classes that perform different functions. The CSP receives TaxML messages and spawns separate threads to handle them. Tax is calculated and put together in an out-going TaxML message. It is then sent to the requesting seller. StartCSP.java StartCSP.java is the class that starts the CSP on the machine identified in ConfigData.java. The rsh facility is used to start the CSP process remotely from

PAGE 54

44 any computer on the CISE network. A log file called csplog holds progress messages from the CSPs startup process. CSPListener CSPListener initializes a socket listening to the port identified in ConfigData.java. It spawns a CSPExtracterHandler if it receives a TaxML query document. If it receives an acknowledgement it sets the same in the class StationHash that maintains a static hash of messages. The CSPListener also has static methods that send acknowledgements and TaxML documents using the socket established previously. This arrangement is not scalable. A socket pool from which a socket is selected based on some criteria (queue on gross load) for sending messages will scale well as traffic increases. DataBaseController The heart of the CSP, the DataBaseController class is given a TaxInfo object for which all the query type attributes are all filled with data parsed from the TaxML query document (the reply type attributes are null for the same TaxInfo object). DataBaseController proceeds to make database accesses collecting tax and exemption information for the items listed, calculating tax due and storing the same in objects that will eventually come together in another TaxInfo object as the reply type attributes. It creates a log of the final TaxInfo object created in the database. TaxDispatcher Part of the network protocol group of classes, TaxDispatcher receives a reply type TaxInfo object that it converts to a TaxML reply document and takes care of

PAGE 55

45 sending it to the seller. It also accesses, updates hashtables that keep track of acknowledgements and information related to the transactionID being processed. StationHash StationHash is a data holder class that maintains static hashtables of transactionID related information. CSPExtractorHandler Activated by the CSPListener on receiving a TaxML query doc as a separate thread, CSPExtractorHandler proceeds to extract the same to a query type TaxInfo object, which it passes to a new DataBaseController thread. Seller Site Java Classes Station Station parallels CSPListener from the CSP site. It starts a socket using the port specified for the seller in ConfigData.java. It is used to send TaxML query type docs to the CSP at the machine and port specified in ConfigData.java. On receiving an acknowledgment to the sent TaxML query doc, it sets the same in the class Dispatcher that handles message passing. On receiving a TaxML reply document, it spawns an ExtractorHandler. ExtractorHandler This class is given a DatagramPacket received by Station. It extracts the TaxML reply document into a reply type TaxInfo object, which it sends across to TransactionManagement that subsequently un-blocks the thread waiting for the reply.

PAGE 56

46 Dispatcher Spawned with a query type TaxInfo object, Dispatcher converts it to a TaxML query document and uses the socket at Station to send it to the CSP. Dispatcher is part of the messaging protocol group of classes and among other things, maintains and updates hashtables that enable it to maintain the messaging protocol. TimeBomb Once a request is sent, a TimeBomb thread is spawned that ticks down to the timeout allowed for the round-trip, i.e. from the time of sending the TaxML query to the time of receiving the TaxML reply. If the TaxML reply is received before timeout, the TimeBomb thread is interrupted and it stops execution. If the timeout occurs first, then the thread sets a Boolean value timeout to true and executes another indefinite wait(). It will subsequently be interrupted by TransactionManagement upon noting the timeout value. TransactionManagement Two static hashtables are maintained by TransactionManagement. One is for holding received reply type TaxInfo objects set by the ExtractorHandler. One is for holding the TimeBomb objects mapped to transactionIds, ticking down to their timeouts. A TransactionManagement thread is spawned by the servlet that processes user interaction: ShoppingCartNew.java. The servlet then proceeds to call, with a transactionID, a synchronized method that checks the TaxInfo hash and the transactionIDs corresponding TimeBomb threads timeout variable for the TimeBomb thread belonging to the transactionID. The synchronized method blocks the thread with either of the checks returning a false. On either arrival of reply

PAGE 57

47 type TaxInfo object it returns the same to the requesting servlet and interrupts the TimeBomb thread. On a timeout, it simply interrupts the TimeBomb thread. The corresponding entries in the TimeBomb has are removed and are automatically garbage collected. General Utility Classes The utility classes are used by many other classes common at both the CSP and the seller sites. They mainly comprise of the scanner, parser, and the reverse-parser. Token.java Token.java is a wrapper class representing an individual character of information in a document. Scanner.java Scanner.java decomposes a document fed to it into tokens. Extracter.java Extracter.java takes a vector of tokens and extracts TaxInfo object (query or reply) from it. Converter.java Converter.java takes a query or reply type TaxInfo object and creates a TaxML query or reply type document respectively. Dgram.java Dgram.java is a general datagram utility class that creates a Datagram, given required parameters.

PAGE 58

48 Configuration Files and Classes ConfigData.java ConfigData.java holds various configuration data as static variables. These include durations for timeout periods, a back-up federal tax rate to use if a problem is encountered trying to assess tax on an item, CSP machine and port, seller machine and port, etc. Interfaces The interfaces are all java servlets. Originally written and tested in the TomCat 3.3 server, they now run on the Tomcat 4.1 server. Seller Interface SellerInterface.java The Participating States Portal uses a central seller registration system. The SellerInterface collects information about the seller and makes database entries that are manually checked for approval. Shop Interface The shop interface is divided into two parts: the part that implements the functionality to handle user interaction and the shopping cart, and the part that implements the functionality to handle new users. Shopping cart ShoppingCartNew.java The most important interface as far as demonstrating the seller side of the CSP architecture. It interacts with the user with login, catalog display and selection, and display of a final invoice with tax information.

PAGE 59

49 New user NewUser.java NewUser is used by new users wanting to register with the seller as a customer at their site. Buyer Interface BuyerInterface.java Used by the Participating States Portal, BuyerInterface handles interaction with buyers seeking exemptions. Jurisdiction Interface JurisdictionInterface.java Jurisdictions login into their respective accounts to view or update information about buyers exempt in their jurisdiction, requests for exemptions, tax base items, etc. As each jurisdiction has complete control over its tax base, changes made are immediately noticeable at the CSP. This solves the tedious problem of having a central body keep track of changes in each jurisdiction. CSP Interface CSPInterface.java The CSP uses this interface to keep track of the various transactions, jurisdictions, and sellers that interact with it. Interface Objects Interface objects hold information for servlets. The data fields are either set either by interaction with the user or through database access. Interface objects used by the servlet ShoppingCartNew.java (at the sellers site) are at the ends of the process of

PAGE 60

50 sending for and receiving tax information. The toPrint() method present in each of these classes returns an HTML formatted string of the classes data fields. Info This is the parent class of UserInfo, TransactionInfo, BuyerInfo, SellerInfo, JurisdictionInfo, and CSP info. Info has a large number of the common data items shared by all the inheriting classes. UserInfo Used by ShoppingCartNew.java, UserInfo holds all the information about a user including all his credit cards and delivery locations on file (in the database). TransactionInfo Used by the CSP interface, TransactionInfo object holds information about a transaction. The query date-time, the payment (from seller) date-time, and the payment remitted (to jurisdiction) date-time among other data items. BuyerInfo Used by the BuyerInterface at the Participating States Portal, BuyerInfo holds information on the exemption request being made by the buyer. SellerInfo Used by the SellerInterface at the Participating States Portal, SellerInfo holds information on the sellers industry, website address along with other information required to process a sellers registration with the PSP. JurisdictionInfo JurisdictionInfo is used by the JurisdictionInterface to handle and keep track of buyers approved for exemptions, requests for exemptions it its jurisdiction, items in its tax base, and the tax due to it from transactions.

PAGE 61

51 CSPInfo CSPInfo is used by the CSPInterface. CreditCard CreditCard abstracts a real world credit card. Address Address abstracts a real world address. CustomerItem CustomerItem abstracts an item listed for sale at the sellers site. ItemInfo ItemInfo abstracts an item listed for sale at the sellers site along with tax holiday information and hashtables to hold quantity based or price based tax slabs. TaxDue Roughly paralleling the TaxML class TaxAmt, TaxDue is an interface class used as a convenience class for holding and producing data for Interfaces that use it. ExemptionItem ExemptionItem holds exemption related data for a particular item.

PAGE 62

CHAPTER 7 CONCLUSION AND FUTURE WORK This work focuses on designing and implementing an architecture for a Certified Service Provider that can give taxing jurisdictions a flexibility that even the currently in use customized tax systems do not provide. Jurisdictions have intricate control over their tax base and can tailor it to fit their needs. Changes made are instantly and transparently visible to all sellers through the CSP. Exemptions are handled to give better control over how best to serve a particular community of buyers. Multiple locations for use are handled, so certain groups of buyers such as corporate offices making purchases for branch offices are not left out of the loop. Given the nature of the implementation, jurisdictions should find this architecture beneficial although they would have to give up customized definitions for items in their current tax base. It is likely that those preferring a simple, one-rate, or few rate type of tax system would find this architecture leaving far too much discretion in the hands of jurisdictions (elaborated on page 35). However, the simplification achieved in centralizing administration, registration, and automating tax collection should make for a balancing argument in favor of the proposed CSP. TaxML provides for a smooth interface between the sellers and the CSP. All the sellers programming staff needs to consider is how to present the data from their transactions in the TaxML query format and how to extract information from a TaxML reply. As TaxML evolves, subsequent versions will include additional features and improvements. 52

PAGE 63

53 References to future work have been identified within the text of the thesis where they had contextual significance. The major ideas that future work can accomplish would be in setting up mirror CSP sites that have local databases. A network file handling system or protocol must be used to maintain distributed file system goals for replicated resources (database). After issues in the message passing protocol are addressed, CSPs should be made capable of handing requests from a pool of available ports. The most pressing need is to expand upon TaxML to define an entity for conveying error messages (to the seller) encountered in the tax resolution process. Various procedures in the code currently catch exceptions which would need to be dealt with by higher routines that log such errors and convey the same, when relevant, to the seller.

PAGE 64

APPENDIX A TAXML DTD AND DOCUMENT TYPES TaxML Document Type Definition (DTD) 54

PAGE 65

55

PAGE 66

56 TaxML Query TaxML documents are either queries or replies. A query is sent from the seller to the CSP requesting tax information on an assortment of items. The reply is the itemized list of taxes due. The sub-parts for Figures A.1 and A. 2 are described below the respective figures. Figure A.1 TaxML Query. 1) All TaxML documents will conform to the Document Type Definition specified in taxinfo.dtd. As TaxML evolves, subsequent versions of the DTD released will bear the same name. The version number itself will be specified as an attribute (to the taxinfo entity) within the document itself. 2) version pertains to the version of the taxinfo being used for the document. 3) taxbaseversion pertains to the version of the standardized tax base (page. 25) 4) type pertains to whether the particular document is a query or reply. 5) buyertaxid defaults to 12341234ex for all buyers that are not registered for exemptions, otherwise it is the id that is given to buyers registered at the

PAGE 67

57 centralized exemption registration center maintained at the Participating States Portal (Appendix F) 6) customersitecode is the code used to identify the item at the sellers location (page. 25) 7) taxbasecode is the code that that item maps to from the standardized tax base (page. 25) 8) taxbaseversion is the version of the standardized tax base that was used for this particular items mapping. A different version here overrides the global taxbaseversion being used in (3). 9) price is the price for the sale unit of the item. If the item is standardized in the tax base for sale in pounds, the price is the price per pound. If it is standardized to be sold in dozens, then the price is the price per dozen. 10) totalquantity is the number of units of sale. 11) deliverylocation is indexed by zip code as jurisdictions are zip code based (page. 31) 12) uselocation is the location used to assess taxes (page. 31) 13) quantity pertains to the quantity of the item destined to the delivery location specified in (11). The same item can be delivered to multiple locations in various quantities. 14) sellertaxid is an id sellers are given by the centralized registration system maintained at the Participating States Portal (Appendix F) 15) transactionid is an unique id generated by the seller for that transaction. It has a few standardized requirements that are meant to enforce uniqueness and enable tracking or retrieval, such as having the seller id included as the last fragment in the id. 16) Transaction time is tracked to the nearest second.

PAGE 68

58 TaxML Reply Figure A.2 TaxML Reply 1) The type attribute specifies that this particular TaxML document is of type reply sent from the CSP to the seller bearing tax information. 2) The total tax amount due on the transaction has to be rounded according to the rules specified in the agreement. At the time of the implementation, the rounding rules were yet to be decided. The next CSP release will have this Figure rounded appropriately. 3) The attribute totaltaxamount pertains to the total tax due on a particular item calculated by taking into account all the individual quantities of that item being delivered to individual jurisdictions. 4) taxamt is the tax due for a certain quantity of an item being delivered to a jurisdiction. 5) exemption holds the values approved to convey approval for exemptions for the buyer, for that particular item, for that jurisdiction. A value of not approved

PAGE 69

59 coveys the opposite due to various reasons such as having a certificate that has expired, or cancelled or suspended due to irregularities (page. 35). 6) The entity notes holds details about the exemption status. If approved, it will have the period for which the certificate is valid, along with, in some cases, other notes pertaining to the certificate.

PAGE 70

APPENDIX B INTERNET TAX FREEDOM ACT The Internet Tax Freedom Act (ITFA) passed on October 21, 1998 imposed a 3-year moratorium on the following 1) Taxes on Internet access unless such taxes were imposed and enforced prior to October 1 st 1998 and 2) Multiple or discriminatory taxes on electronic commerce. In essence, the ITFA defined a narrow, tax-exempt service (internet access) and a few guidelines to guard against choking e-commerce from zealous taxation. One of the interesting exceptions to the Internet access provision is that it does not cover entities that engage for commercial profit, in communication of material that can also be accessed by minors, and is harmful to them, unless safeguards are implemented to restrict access. The exception does not apply to telecommunication providers such as AT&T; ISPs such as AOL; search engines such as Yahoo; or web hosting services such as Tripod to the extent that they are providing their core services. Those entities engaging by any means, in providing unrestricted access to materials harmful to minors would be partly taxable [HAR98]. David Hardesty, an adjunct professor of taxation at the Golden Gate University notes that this can be viewed as congress using the ITFA as a backhanded way of forcing self-regulation on the Internet community, which has resisted any form of formal or direct control. The discriminatory provision prohibits taxes imposed on electronic commerce transactions that are not generally imposed on equivalent transactions accomplished by 60

PAGE 71

61 other means. For example, a state could not impose a tax on access to an online newspaper where the sale of newspaper from a street corner is free of tax [HAR98]. It also prohibits imposition of a higher tax on electronic commerce than on the same transactions accomplished by other means. For example, a state could not impose a 7 percent sales tax on sales of flowers via the Internet where it imposes a 5 percent tax on sales from a local flower shop [HAR98]. The ITFA also provides provisions that clarify the sales and use tax liability of online entities. States cannot impose a remote seller to collect sales tax if the sole ability to access a site on a remote sellers out-of-state computer server is considered a factor in determining a remote sellers tax collection obligation [HAR98]. For example, consider a Washington based sports equipment company xsports.com that has its online shopping web site hosted on its servers located in Washington. The fact that its website is accessible in Nevada or any other state cannot be used to determine if the company has nexus in these states. A similar rule applies to ISPs. This concept is central to the definition of e-commerce taxation. However, the ITFA does not explore the situation where xsports.coms website is hosted on a server located in Nevada. Presumably, Nevada can interpret the ITFA to find that xsports.com does have sufficient nexus as a result of the server [HAR98]. However, one of the only instances that the ITFAs discriminatory tax guideline was interpreted was in a private ruling made by the Web friendly state of Virginia (home of AOL), which ruled that a Web site, hosted on a server in Virginia does not by itself result in sales tax nexus in that state [HAR00a].

PAGE 72

62 The ITFA also prevents states from imposing an obligation to collect or pay the tax on a different person or entity than in the case of equivalent transactions of goods and services accomplished by other means. For example, owing to xsports.com servers and administration in the state of Washington, it is deemed that it has nexus in that state. Consider ysports an unrelated specialty company that xsports hosts and services on the same server that it uses. The company ysports does not have nexus in Washington. Though Washington can enforce xsports collection of sales and use tax on items xports sells to Washington residents, it cannot compel xsports to collect sales and use tax on behalf of ysports for the sales ysports makes to Washington customers. Perhaps owing to the glamour inherent in its name (Tax Freedom), the ITFA has been a source of misunderstanding and hype since its inception. The belief that anything sold over the Internet is free of sales tax has been perpetuated either intentionally or unintentionally [HAR01b]. Online companies have always been responsible for sales tax in states that they have sufficient nexus in and therefore have always collected tax from their in-state customers. As for the states that the online companies did not have nexus in, the buyers were responsible for filing a use tax to their states tax authority. Such a responsibility often imposes a burden on individuals that goes beyond a reasonable expectation of their diligence, organization, and effort. Most people that shop on the internet are unaware of this responsibility-partly due to online companies not stating as much so their products will appear cheaper, but mostly due to non-enforcement of this requirement. The ITFA deserves much credit in the establishment of the Advisory Commission on Electronic Commerce [HAR98].

PAGE 73

APPENDIX C ADVISORY COMMISSION ON ELECTRIC COMMERCE (ACEC) The advisory commission was to conduct a thorough study of federal, state, local, and international taxation and tariff treatment of transactions using the Internet. Its report and recommendations were to be submitted to congress in June 2000. The ACEC, chaired by Virginia governor James S. Gilmore, III, an anti-tax advocate, submitted its report and recommendations, well ahead of schedule in April 2000. On perusing the report, it might be observed that the formal findings and recommendations dealt with safe and broad issues (privacy, digital divide). The real, industry-changing issues (sales and use tax) that congress would have needed guidance on, rallied only a majority vote. Out of the 19 member committee, there were 7 abstentions for each of the majority vote proposals (listed below). The abstentions could probably be interpreted due to a lack of clear information on what is essentially an evolving, contentious issue [ADV00]. The following is a reproduction of the ACECs majority vote proposals. The ACECs majority vote proposal on Sales and Use Taxes [ADV00] 1) For a period of five years, extend the current moratorium barring multiple and discriminatory taxation of e-commerce and prohibit taxation of sales of digitized goods and products and their non-digitized counterparts; 2) Clarify that the following factors would not, in and of themselves, establish a sellers physical presence in a state for purposes of determining whether a seller has sufficient nexus with that state to impose collection obligations: a. a sellers use of an Internet service provider ( ISP ) that has physical presence in a state b. the placement of a sellers digital data on a server located in that particular state 63 c. a sellers use of telecommunications services provided by a telecommunications provider that has physical presence in that state

PAGE 74

64 d. a sellers ownership of intangible property that is used or is present in that state e. the presence of a sellers customers in a state f. a sellers affiliation with another taxpayer that has physical presence in that state g. the performance of repair or warranty services with respect to property sold by a seller that does not otherwise have physical presence in that state h. a contractual relationship between a seller and another party located within that state that permits goods or products purchased through the sellers Web site or catalogue to be returned to the other partys physical location within that state; and i. the advertisement of a sellers business location, telephone number, and Web site address. 3) Encourage state and local governments to work with and through NCCUSL in drafting a uniform sales and use tax act within three years after the expiration of the current Internet Tax Freedom Act moratorium (i.e., by October 21, 2004) that would simplify state and local sales and use taxation policies so as to create and maintain parity of collection costs (net of vendor discounts) between remote sellers and comparable single-jurisdiction vendors that do not offer remote sales, including providing the following a. uniform tax base definitions b. uniform vendor discount c. uniform and simple sourcing rules d. one sales and use tax rate per state and uniform limitations on state rate changes e. uniform audit procedures f. uniform tax returns/forms g. uniform electronic filing and remittance methods h. uniform exemption administration rules (including a database of all exempt entities to determine exemption status) i. a methodology for approving software that sellers may rely on to determine state sales tax rates

PAGE 75

65 j. a methodology for maintaining revenue neutrality in overall sales and use tax collections within each state (such as reducing the state-wide sales tax rate) to account for any increased revenues collected (on a voluntary basis or otherwise) from remote sales. 4) Formation of advisory commission and reports to congress: a. Establish a new advisory commission responsible for oversight of the progress of NCCUSLs efforts to create a uniform sales and use tax act. b. Within six months after the completion of NCCUSL s work, the commission shall transmit to Congress for its consideration a report containing the following (i) findings, for the period from 1999 through 2004, regarding the growth of e-commerce, the impact of e-commerce on traditional retailers, and the impact of remote sales on state tax revenues (ii) an assessment of whether the uniform sales and use tax act meets the standards listed in (3)(a) through (j) above (iii)an assessment of whether the adoption of the uniform sales and use tax act would result in equal tax collection burdens (net of vendor discounts) for remote sellers and comparable single-jurisdiction vendors that do not offer remote sales (iv) an assessment of whether requiring all remote sellers to collect and remit sales and use taxes to those states that adopt the uniform sales and use tax act would impose any unreasonable burden on interstate commerce or would otherwise adversely impact economic growth and activity through remote electronic channels (v) a recommendation as to whether states that adopt the uniform sales and use tax act should be permitted to collect sales and use taxes on all remote sales; and (vi) any other recommendations as required to address the findings of the commissions report [ADV00]. Such an advisory commission was not instated by congress but the states and local governments moved to independently work on a streamlined sales tax project (SSTP).

PAGE 76

APPENDIX D STREAMLINED SALES TAX PROJECT (SSTP) EXECUTIVE SUMMARY. The following document is reproduced from the executive summary of the SSTP available online at the SSTP website: www.strealinedsalestax.org [SST02b]. The Streamlined Sales Tax Project is an effort created by state governments, with input from local governments and the private sector, to simplify and modernize sales and use tax collection and administration. The Projects proposals include tax law simplifications, more efficient administrative procedures, and emerging technologies to substantially reduce the burden of tax collection. The Projects proposals are focused on improving sales and use tax administration systems for both Main Street and remote sellers for all types of commerce. Thirty-nine states and the District of Columbia are involved in the Project. Thirty-four states and the District of Columbia are voting participants in the Project because their legislators have enacted enabling legislation or their governors have issued executive orders or similar authorizations. Five states are non-voting participants in the work of the Project because they do not have the formal commitment of the state executive or legislative branches, but are still participating. Forty-five states and the District of Columbia impose a sales and use tax. The Project was organized in March 2000. The Project is conducting its work through a steering committee with co-chairs, four work groups, and a number of sub-groups. Project participants are generally state revenue department administrators but there are also representatives of state legislatures and local governments. Businesses 66

PAGE 77

67 including national retailers, trade associations, manufacturers, direct marketers, technology companies, and others have actively participated in the project by offering expertise and input, reviewing proposals, suggesting language, and testifying at public hearings. The goal of the Streamlined Sales Tax Project is to provide states with a Streamlined Sales Tax System that includes the following key features Uniform definitions within tax laws. Legislatures still choose what is taxable or exempt in their state. However, participating states will agree to use the common definitions for key items in the tax base and will not deviate from these definitions. As states move from their current definitions to the Projects definitions, a certain amount of impact on state revenues is inevitable. However, it is the intent of the Project to provide states with the ability to closely mirror their existing tax bases through common definitions. Rate simplification. States will be allowed one state rate. Local jurisdictions will be allowed one local rate. A state or local government may not choose to tax food at one rate and all other items of tangible personal property or taxable services at another rate. State and local governments will accept responsibility for notice of rate and boundary changes at restricted times. State tax administration of all state and local taxes. Businesses will no longer file tax returns with each local government within which it conducts business in a state. States will be responsible for the administration of all state and local taxes and the distribution of the local taxes to the local governments. A state and its local governments will use common tax bases. Uniform sourcing rules. The states will have uniform and simple rules as to how they will source transactions to state and local governments. The uniform rules will be destination/delivery based and uniform for tangible personal property, digital property, and services. Simplified exemption administration for useand entity-based exemptions. Sellers are relieved of the good faith requirements that exist in current law and will not be liable for uncollected tax. Purchasers will be responsible for paying the tax, interest, and penalties for claiming incorrect exemptions. States will have a uniform exemption certificate in paper and electronic form. Uniform audit procedures. Sellers who participate in one of the certified Streamlined Sales Tax System technology models will either not be audited or will have limited scope audits, depending on the technology model used. The states may conduct joint audits of large multi-state businesses.

PAGE 78

68 State funding of the system. To reduce the financial burdens on sellers, states will assume responsibility for funding some of the technology models. The states are also participating in a joint business-government study of the costs of collection on sellers. The Project proposes that states change their sales and use tax laws to conform with the simplifications as proposed by the project. Thus, the simplifications would apply to all sellers. Participation in the Streamlined Sales Tax System is voluntary for sellers who do not have a physical presence or nexus with a state unless Congress chooses to require collection from all sellers for all types of commerce. Also, registration by sellers to voluntarily collect sales and use taxes will not infer that the business must collect business activity taxes, such as the corporate franchise or income tax. The Streamlined Sales Tax System will provide sellers the opportunity to use one of three technology models. A seller may use Model 1 where a Certified Service Provider, compensated by the states, will perform all of the sellers sales tax functions. A seller may use Model 2, a Certified Automated System, to perform only the tax calculation function. A larger seller with nationwide sales that has developed its own proprietary sales tax software may use Model 3 and have its own system certified by the states collectively. However, some sellers may choose to continue to use their current systems and still enjoy the benefits of the Projects simplifications. The Streamlined Sales Tax Project envisions two components to the legislation necessary to accomplish the Projects goals. First, states would adopt enabling legislation referred to as the Uniform Sales and Use Tax Administration Act (Act). The Act allows the state to enter into an agreement with one or more states to simplify and modernize sales and use tax administration in order to reduce the burden of tax compliance for all

PAGE 79

69 sellers and all types of commerce. The Act does not require any amendments to a states sales and use tax law. Secondly, states would amend or modify their sales and use tax laws to achieve the simplifications and uniformity required by the participating states working together. The Project refers to this legislation as the Streamlined Sales and Use Tax Agreement (Agreement). Some states will require only minor changes to current law to implement the requirements of the Agreement. Other states with more complicated sales tax laws may require significant changes to current law to be in accord with the Agreement. A certificate of compliance will document each states compliance with the provisions of the Agreement and cite applicable statutes, regulations or other authorities supporting such compliance. Public notice and comment will be provided before a state becomes part of the interstate Agreement. A state is expected to be in compliance with the requirements of the Agreement and to never substantially deviate from the requirements of the Agreement. If a state does substantially deviate, it will not be accepted into the interstate Agreement or will be expelled by the other participating states. In a voluntary system, sellers who are voluntarily collecting sales taxes for participating states may decide to no longer collect for the expelled state. Also, that state would not have a vote on changes in the Agreement. As of July 2002, thirty-five states and the District of Columbia have enacted the Act. These states are considered the Implementing States and will control the provisions of the initial Agreement. Adoption of the Agreement will require an affirmative vote of three-fifths of the Implementing States. On all other matters (e.g., amendments to the Agreement), action is final by majority vote. Matters involving

PAGE 80

70 interpretation of the Agreement may be brought before the Implementing States acting jointly. The Implementing States acting jointly are empowered to issue an interpretation of the Agreement, subject to approval by a majority of the states. An advisory council, including representatives from business, will advise Implementing States. It is anticipated that states that enact the provisions of the Agreement as approved by the Implementing States in the summer of 2002 will continue as the governing states of the interstate Agreement of the future. The project website is www.streamlinedsalestax.org.

PAGE 81

APPENDIX E NETWORK MESSAGE PASSING SCENARIOS Figure F.1 illustrates some of the scenarios that the UDP based message protocol generates. The text below explains the implementation significance of each scenario and is provided for documentation purposes. Future work includes fixing the problems identified with a caution note, along with the functionality to report to higher modules that take alternate courses of action. 71

PAGE 82

Figure E.1 Scenarios with passing Query and Query-Acknowledgement. A) Ideal world example: The Query is sent, received, and acknowledged without delays. The CSP processes the Query and sends across a Reply, which is received and acknowledged without delay. B) Query lost: Q is sent 5 times before Dispatcher gives up. Higher module to be notified. C) Q-Ack lost: Duplicate queries at CSP site area added to the StationHash.sHash, if one is present already, no harm done. D) Duplicate Q-ACK: Duplicate acks are inserted into Dispatcher.ackHash as long as TransactionManagement has the transactionID still active (no harm done). Caution: ackHash is not cleared. E) Delayed-duplicate Q-ACK: It is presumed TransactionManagement does not have the transactionID still alive, the ack is NOT inserted. Caution: ackHash is not cleared. F) Delayed-duplicate Q: The incoming duplicate Q is counted as a fresh Q: caution.

PAGE 83

73

PAGE 84

Figure E.2 Scenarios with passing Reply and Reply-Acknowledgement. A) R lost: Replies are sent by the TaxDispatcher 5 times before giving up. Higher module to be notified. B) Duplicate R: Duplicate replies are discarded if an entry with the same transactionID is already present. C) Delayed-duplicate R: Duplicate replies are discarded as the entry is still available in the ExtractorHandler.receivedType2DocHash. Caution: The hash table is not being cleared. D) Duplicate R-ACK: The duplicate ack is inserted into TaxDispatcher.ackHash: caution. E) Delayed-duplicate R-ACK: Delayed, duplicate acks are inserted into TaxDispatcher.ackHash

PAGE 85

75

PAGE 86

APPENDIX F DEFINITIONS OF TERMS TaxML XML is used to transfer information about transactions between the CSP and its clients, the sellers. A DTD defines a standard structure for the query that all sellers must conform to when requesting tax information from a CSP. The CSP returns information in another XML document (reply) that conforms to the same DTD. The prescribed DTD is called the TaxML DTD and documents that conform to it (query and reply) are called TaxML documents. Certified Service Provider-CSP The certified service provider is defined by the Streamlined Sales Tax Project as a certified third party firm that provides a technological mechanism to enable sellers to look up taxes for items they are selling, and for consequently transferring the tax calculated to the CSPs bank. The CSPs tax server that sellers connect to, and are returned tax information is frequently identified in the text of this report simply as the CSP. The SSTP agreement states that a CSP will file periodic returns to various jurisdictions. Tax is remitted after debiting a portion of the collected taxes as a servicing fee (cost of collection). The sellers are absolved of remitting taxes directly to the taxing jurisdictions and from audits as long as they have represented the goods they sought tax information on correctly. 76

PAGE 87

77 Participating States Portal-PSP States have come together to participate in the Streamlined Sales Tax Project either as direct participants or as observers. When five participant states have legislative approval of the tax simplifications and other mechanisms outlined in the SSTP agreement, the same goes into effect and is deemed to be binding in these five states. The agreement outlines a centralized mechanism for some administrative tasks such as having customers register for exemptions at a central location, or for sellers to register themselves using a single form etc. The central location where such forms can be found is at the Participating States Portal. The term PSP is not part of the SSTP terminology but the recommendation for a centralized mechanism is.

PAGE 88

LIST OF REFERENCES [ADV86] Advisory Commission On Intergovernmental Relations. State and local taxation of out-of-state mail order sales. U.S. Government Printing Office, Washington, D.C.: 1986 [ADV00] Advisory Commission on Electronic Commerce. Report to congress. http://www.ecommercecommission.org/report.htm 2000. Accessed Feb 21, 2001 [HAR98] Hardesty, David. Internet Tax Freedom Act. http://www.ecommercetax.com/doc/102198.htm Oct 21, 1998. Accessed Feb 21, 2001 [HAR00a] Hardesty, David. Web server does not create nexus in Virginia. http://www.ecommercetax.com/doc/073000.htm Jul 30, 2000. Accessed Feb 21, 2001 [HAR00b] Hardesty, David. Road rules for the streamlined stales tax. http://www.ecommercetax.com/doc/123100.htm Dec 31, 2000. Accessed Feb 21, 2001 [HAR01a] Hardesty, David. Streamlined sales tax gets political. http://www.ecommercetax.com/doc/021101.htm Feb 11, 2001. Accessed Feb 21, 2001 [HAR01b] Hardesty, David. Is it time for congress to act on sales tax? http://www.ecommercetax.com/doc/031101.htm Mar 11, 2001. Accessed Jun 15, 2001 [SST02a] Streamlined Sales Tax Project. Public-private sector study of cost of collecting state and local sales and use taxes. http://www.geocities.com/streamlined2000/ .Accessed Sep 10, 2002 [SST02b] Streamlined Sales Tax Project. Executive summary. http://www.geocities.com/streamlined2000/ Accessed Sep 10, 2002 78

PAGE 89

BIOGRAPHICAL SKETCH Manav Chimakurthi was born and raised in India. His schooling from 6 th grade through 12 th grade was at Bhavans Gandhi Vidyashram, a small school in the Annamalai mountain range in South India. He attended the College of Management Studies at GITAM, Vishakapatnam, where he received a bachelors in business management in 1995. His received his second degree, a masters diploma in journalism and mass communication, from Symbiosis, Pune. His first career as a copywriter in Pune and then in Hyderabad found him work at advertising agencies and design houses in these cities. While attending the University of Florida in August, 1997, his growing interest in computer science precipitated a career shift to the field. He commenced his studies towards a masters in computer science at Computer and Information Sciences and Engineering Department (CISE) in spring 1999. Nurturing an interest in technologies that can be applied to find feasible solutions to real world problems on the Internet, he pursued his current research work. His other interests lie in the field of delivering educational content over the Internet using interactive technologies. 79


Permanent Link: http://ufdc.ufl.edu/UFE0000514/00001

Material Information

Title: An Architecture for a certified service provider (CSP) to collect sales and use tax from online commercial transactions
Physical Description: Mixed Material
Language: English
Creator: Chimakurthi, Manav ( Dissertant )
Wilson, Joseph N. ( Thesis advisor )
Dankel, Douglas ( Reviewer )
Hammer, Joachim ( Reviewer )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2002
Copyright Date: 2002

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, M.S
Dissertations, Academic -- UF -- Computer and Information Science and Engineering
Electronic commerce -- Software
Electronic commerce -- Taxation

Notes

Abstract: Towards the latter half of the 21st century, states have shown an increasing reliance on sales and use taxes as sources of revenue. This is evidenced by a casual study of the increase in rates and the number of local jurisdictions that now levy such taxes (more than 7,500). Gravitation towards sales and use taxes has been attributed towards their general acceptability: they consistently score as being among the fairest taxes in surveys conducted since 1973. Efforts at collecting sales and use taxes from out-of-state businesses that do business in a state have been mired in constitutional, economic, and jurisdictional issues. The supreme court has consistently ruled in favor of the out-of-state businesses stating that it was far too great a burden for them to keep track of changes to tax rates, exempted items, exempted buyers, tax holidays, caps, and thresholds in each of the taxing jurisdictions. Confronted with a colossal erosion of their tax base from Internet based retailers, the states embarked on initiatives such as the Streamlined Sales Tax Project to explore, recommend, and institute changes to participating states tax systems so as to make it easier for out-of-state businesses to collect taxes. A technological solution that simplifies many aspects of tax collection and administration while preserving the status quo has percolated through the streamlining efforts as an agreeable alternative to otherwise lengthy and contentious efforts at real simplification. The work in this thesis is based on the recommendations for a technological solution: a Certified Service Provider (CSP) that collects sales and use tax from online commercial transactions. Online retailers submit an XML document of their imminent transaction to the CSP, which calculates and sends the tax back in another XML document. The retailer remits the tax due on the transaction to the CSP and is absolved of filing tax returns to and audits from the states and jurisdictions. The implementation uses Java, XML, Sybase, and Java Servlets.
Subject: CSP, e commerce, tax, taxation, TaxML, XML
General Note: Title from title page of source document.
General Note: Document formatted into pages; contains 89 p.
General Note: Includes vita.
Thesis: Thesis (M.S.)--University of Florida, 2002.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000514:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000514/00001

Material Information

Title: An Architecture for a certified service provider (CSP) to collect sales and use tax from online commercial transactions
Physical Description: Mixed Material
Language: English
Creator: Chimakurthi, Manav ( Dissertant )
Wilson, Joseph N. ( Thesis advisor )
Dankel, Douglas ( Reviewer )
Hammer, Joachim ( Reviewer )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2002
Copyright Date: 2002

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, M.S
Dissertations, Academic -- UF -- Computer and Information Science and Engineering
Electronic commerce -- Software
Electronic commerce -- Taxation

Notes

Abstract: Towards the latter half of the 21st century, states have shown an increasing reliance on sales and use taxes as sources of revenue. This is evidenced by a casual study of the increase in rates and the number of local jurisdictions that now levy such taxes (more than 7,500). Gravitation towards sales and use taxes has been attributed towards their general acceptability: they consistently score as being among the fairest taxes in surveys conducted since 1973. Efforts at collecting sales and use taxes from out-of-state businesses that do business in a state have been mired in constitutional, economic, and jurisdictional issues. The supreme court has consistently ruled in favor of the out-of-state businesses stating that it was far too great a burden for them to keep track of changes to tax rates, exempted items, exempted buyers, tax holidays, caps, and thresholds in each of the taxing jurisdictions. Confronted with a colossal erosion of their tax base from Internet based retailers, the states embarked on initiatives such as the Streamlined Sales Tax Project to explore, recommend, and institute changes to participating states tax systems so as to make it easier for out-of-state businesses to collect taxes. A technological solution that simplifies many aspects of tax collection and administration while preserving the status quo has percolated through the streamlining efforts as an agreeable alternative to otherwise lengthy and contentious efforts at real simplification. The work in this thesis is based on the recommendations for a technological solution: a Certified Service Provider (CSP) that collects sales and use tax from online commercial transactions. Online retailers submit an XML document of their imminent transaction to the CSP, which calculates and sends the tax back in another XML document. The retailer remits the tax due on the transaction to the CSP and is absolved of filing tax returns to and audits from the states and jurisdictions. The implementation uses Java, XML, Sybase, and Java Servlets.
Subject: CSP, e commerce, tax, taxation, TaxML, XML
General Note: Title from title page of source document.
General Note: Document formatted into pages; contains 89 p.
General Note: Includes vita.
Thesis: Thesis (M.S.)--University of Florida, 2002.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000514:00001


This item has the following downloads:


Full Text











AN ARCHITECTURE FOR A CERTIFIED SERVICE PROVIDER (CSP) TO
COLLECT SALES AND USE TAX FROM ONLINE COMMERCIAL
TRANSACTIONS
















By

MANAV CHIMAKURTHI


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2002




























Copyright 2002

by

Manav Chimakurthi






























For friends..















ACKNOWLEDGMENTS

I would like to express my gratitude to the chair of my thesis committee, Dr. Joseph

Wilson, whose ideas and dedicated support have made this work possible. His incredible

patience and kindness have made a lasting impression.

I would also like to thank the other members on my committee, Drs. Douglas

Dankel and Joachim Hammer.

If it were not for all my teachers, my friends and my parents, I could not have

gotten to where I am.
















TABLE OF CONTENTS
page

A C K N O W L E D G M E N T S ................................................................................................. iv

LIST OF FIGURES .................. ............ ............................. viii

ABSTRACT ........ .............. ............. ...... ...................... ix

CHAPTER

1 INTRODUCTION .............. ................. ........... ....................... ..1..

2 OVERVIEW OF ONLINE SALES TAX COLLECTION ISSUES, LANDMARKS,
AND INITIATIVES ........ ... ... ......................... ........... ...........

T he Issu e ........... ...................................... ................... ........... ..... 6
Scenario 1 ................. ......... ..... .............. ........................ 6
Scenario 2...................................... ................ .......... 8
Scenario 3 ................ ........ ....... .... ............. .................... 8
Judicial and Legislative Background............................... ................... 9
States Arguments and Other Tax Issues ....................................................... 10
Erosion of Tax B ase ......... .... ................................................... ....... 10
Cost of Collecting Taxes ......... ..................................... ....................... 11
Incidence and Sourcing .......... .. .. ..... .......................... .. ....... ............. 11
Acts and Initiatives Affecting Sales and Use Tax ............................................. .. 12
Internet Tax Freedom A ct 1998 ....................................... ................... 12
Advisory Commission on Electronic Commerce (ACEC) .................................... 12
Stream lined Sales Tax Project (SSTP)......................................... .................... 13
National Conference of State Legislatures (NCSL)............................................. 13

3 ARCHITECTURE OF THE CERTIFIED SERVICE PROVIDER (CSP) TAX
COLLECTION M ECHANISM .................................. ..................................15

S eller S ite ............................................................................ .............. 15
C SP Site ......................... ......... .................... ........ ......... ...... 20

4 THE CSP ARCHITECTURE, MECHANISMS, AND ISSUES. .............................23

CSP A architecture and Im plem entation Issues..................................... .................... 25
Resolution of Item B eing Taxed .................................... .......................... ........ 25
T he M money T rail .... ........................ ........ ............................ .............. 26









Buyer Exemption Certificate Security ......................................... ..... ......... 28
P rivacy Safeguards................................ ............ .................... .. ................ 29
Message Passing Protocol ............ ..... .............. .............. 29
C SP Tax R solution Issues .............. ................................................... .............. 29
Sales or U se Tax ......................................... ............... ....... ..... 29
Sourcing the Transaction: Origin or Destination .............. .... ................ 30
Multiple Use Locations, Multiple Delivery Locations ....................................... 31
Zip Code Area Aggregates Based Jurisdictions................................. ............. 32
Caps, Thresholds, and Tax holidays .......................................................... ... 33
Study in Control Minutiae: Tax Based on Gross, Quantity and Price................... 33
T ax based on gross ..... ....................................... ...................... 34
T ax based on quantity ............................................. ............................. 34
T ax B ased on Price ............... ....... ...... .... .. ....... ...... .... ............. .35
Study in Exemption Minutiae: Exempted Entity-Jurisdiction-Item-Percentage of
E xem ption ................... .................. ........................... ..... ......... 36
Exemption Registration Procedure ........................................................ 37

5 IMPLEMENTATION DETAILS: HOW TO RUN THE APPLICATIONS ................38

H ow to Start th e C SP .......................................................................... ................ .. 3 8
H ow T o Start the Seller..................................................... ...................................... 39
H ow T o Start T he Interfaces........................................................................... ............ 39

6 IMPLEMENTATION DETAILS: THE CLASSES ............................................... 40

T axM L O object C lasses ........... .... .... .. ............ .................... ........ ............. 40
C SP Site Java Classes ......... ........................... ........ ........ ...... .. .......... .. 43
Seller Site Java Classes ........ .... .... .................... ........ ..... ...... .. .......... .. 45
General Utility Classes .. ................. ........................ ................ 47
C configuration F iles and C lasses.......................................................... ... ................. 48
Interfaces...................................... .............. 48
Seller Interface .............. ... ................... ........... 48
S h o p In terface ........................................................................ 4 8
S h o p p in g c a rt ............................................................................................. 4 8
N ew u se r ................................................................4 9
Buyer Interface ............... ......... .................. 49
Jurisdiction Interface................................. .............. 49
C SP Interface .............................................................. ............ .... .......... 49
Interface Objects ............. ........ ...................... ......... ...... ........ 49

7 CONCLUSION AND FUTURE WORK ........................................... ............... 52

APPENDIX

A TAXML DTD AND DOCUMENT TYPES........................................ 54

B INTERNET TAX FREEDOM ACT ...................... ................... 60









C ADVISORY COMMISSION ON ELECTRIC COMMERCE (ACEC).....................63

C STREAMLINED SALES TAX PROJECT (SSTP) EXECUTIVE SUMMARY. ......66

E NETWORK MESSAGE PASSING SCENARIOS ..................................................71

F D E FIN ITIO N S O F TE R M S ............................................................... .....................76

T ax M L .............................................................................. 7 6
Certified Service Provider-C SP ........................................ .................. ...... 76
Participating States Portal-PSP ...................................... .......................... ........ 77

L IST O F R E F E R E N C E S ....................................................................... ... ................... 78

B IO G R A PH IC A L SK E TCH ..................................................................... ..................79
















LIST OF FIGURES

Figure page

3.1 The CSP in relation to sellers and their customers. .............................................. 16

3.2 XM L data flow ............... ................ .......... ................ .......... 17

3.3 Functions, data flow and interaction at the seller site...............................................18

3.4 Functions, data flow, and interaction at the CSP site ..............................................21

4.1 Illustration of the quantity based slab rate system.............. .... .................34

4.2 Illustration of the price based slab rate system ...................................................35

6.1 XML entities map to respective Java objects ..................................... ..........41

6.2 The TaxML DTD maps to the TaxInfo Java object...................... .................42

6.3 Inform ation containers and paths........................ ... ........................... .... .......... 43

A. 1 TaxML Query ....................................... .... .... ...56

A .2 T axM L R eply .................. .... ...... .... .. .... .............. .. ............. ............ ... 58

E. 1 Scenarios with passing Query and Query-Acknowledgement..................................72

E.2 Scenarios with passing Reply and Reply-Acknowledgement...................................74















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

AN ARCHITECTURE FOR A CERTIFIED SERVICE PROVIDER (CSP) TO
COLLECT SALES AND USE TAX FROM ONLINE COMMERCIAL
TRANSACTIONS

By

Manav Chimakurthi

December 2002

Chair: Dr. Joseph Wilson
Major Department: Computer and Information Sciences and Engineering

Towards the latter half of the 2lst century, states have shown an increasing reliance

on sales and use taxes as sources of revenue. This is evidenced by a casual study of the

increase in rates and the number of local jurisdictions that now levy such taxes (more

than 7,500). Gravitation towards sales and use taxes has been attributed towards their

general acceptability: they consistently score as being among the fairest taxes in surveys

conducted since 1973. Efforts at collecting sales and use taxes from out-of-state

businesses that do business in a state have been mired in constitutional, economic, and

jurisdictional issues. The supreme court has consistently ruled in favor of the out-of-state

businesses stating that it was far too great a burden for them to keep track of changes to

tax rates, exempted items, exempted buyers, tax holidays, caps, and thresholds in each of

the taxing jurisdictions. Confronted with a colossal erosion of their tax base from Internet

based retailers, the states embarked on initiatives such as the Streamlined Sales Tax

Project to explore, recommend, and institute changes to participating states' tax systems









so as to make it easier for out-of-state businesses to collect taxes. A technological

solution that simplifies many aspects of tax collection and administration while

preserving the status quo has percolated through the streamlining efforts as an agreeable

alternative to otherwise lengthy and contentious efforts at real simplification.

The work in this thesis is based on the recommendations for a technological

solution: a Certified Service Provider (CSP) that collects sales and use tax from online

commercial transactions. Online retailers submit an XML document of their imminent

transaction to the CSP, which calculates and sends the tax back in another XML

document. The retailer remits the tax due on the transaction to the CSP and is absolved of

filing tax returns to and audits from the states and jurisdictions. The implementation uses

Java, XML, Sybase, and Java Servlets.














CHAPTER 1
INTRODUCTION

One of the reasons formulating fair tax laws for the Internet is complicated has to

do with the location independence of entities on the net. Transactions are made possible

on the Internet through web sites that have their physical servers, management

establishment, and customers-all in different states. Online retail companies can be

perceived as the natural extension to traditional mail order firms. The business model is

nearly intact: a catalog, a customer, an order, and a shipment. The verdicts from court

trials that mail order firms endured from their inception have set the foundation for the

manner in which online commercial transactions have come to be considered for tax

purposes. Mail order firms have gained significant decisions made in their favor by the

Supreme Court in accordance with its interpretation of the commerce clause and the due

process clause put forth in the constitution. In the landmark 1967 National Bellas Hess v.

State of Illinois decision, the court ruled that out-of-state mail order firms could not be

required to collect state and use taxes for states in which their only business presence

consists of distributing catalogs and other advertising materials [ADV86, p.56]. This

decision has subsequently been upheld in the 1992 Quill v. North Dakota case. The

commerce clause safeguarded a national market by allowing the free flow of interstate

commerce: it was far too great a burden to require an out-of-state firm to comply with

sales and use tax laws in the states that it does business in, where it did not have nexus in.

Nexus was clarified with help from the due process clauses as being the establishment of









sufficient minimum linkage between a state and the firm it seeks to tax as evidence of

benefits received by the tax remitting firm from the taxing state [ADV86, p.56].

The festering nature of the conflicts inherent in implementing a fair and efficient

sales and use tax system was noted by Robert Hawkins, chairman of the Advisory

Commission on Intergovernmental Relations in a revelatory 1986 report on the State and

Local Taxation of Out-Of-State Mail Order Sales: "Not withstanding the philosophical

and constitutional issues involved, the conflict is a classic one. That between the national

interest in protecting the free flow of interstate commerce from unreasonable imposition

of state and local taxes, and the rights of the individual states to protect the integrity of

their taxing authority and their revenue system" [ADV86, p.iii].

The mail order industry in 1967 was based on a very traditional way of doing

business that was predominantly oriented toward physical presence. Limited

communication avenues and distribution channels required businesses to have local

offices to conduct significant commercial activities in a state. In 1992, even with fast

growing 1-800 number sales through newspapers, magazines, television, and computer

terminals with catalogue linkup in work places, the court still upheld the Hess judgment.

The furious growth of the Internet in the 90s has substantially changed the fundamental

nature in the way commerce is conducted in some industries. Despite the dot com

crumble of the late nineties, the simple truth is, commerce via the Internet is sensible for

these industries, and as business models evolved, it has grown to be even critical for

some.

It was in the boom years, however, that states became increasingly alarmed at the

real and perceived notion of loss of sales revenue from online sales. Sales tax losses









owing to mail order companies never quite managed to have the critical mass to warrant a

sales tax system overhaul but with the proliferation of online businesses, large numbers

of transactions were slipping by the obligation to collect sales tax under the nexus

requirement. In late 1999 and most of 2000 as e-commerce was making its biggest strides

in terms of media hype, capital generation and IPO racketeering, concerns of tax revenue

lost and unfairness to main street businesses (that had to collect tax), the states and other

concerned parties undertook a search for feasible solutions to collect tax from online

businesses. Among the proposals were those to simplify and standardize taxation rules

and systems various jurisdictions employed so as to make collecting taxes easier for out-

of-state businesses. Simplification is viewed by many as a wicked, unrelenting objective

that has failed past attempts at its reckoning. Perhaps what it seeks to accomplish sets it

up against forces destined to undermine it in their own efforts at self-preservation. Local

jurisdictions have no interest in giving up their specially tailored tax system to one that is

more standardized. Local rates, exempted items, exempted consumers, limits, ceilings,

and holidays are the result of the community deciding what is best for itself. Any attempt

at standardization should ideally allow the leeway for a jurisdiction to customize its tax

system, which of course means little or no standardization is possible. Technological

intervention, bemoaned by fans of simplification as a patch that sidesteps the real issue,

surfaced as a pragmatic solution that preserved the status quo of customization while

alleviating some of the real administrative and logistic annoyances that out-of-state

businesses faced. The Streamlined Sales Tax Project's broad definition of a technological

solution in terms of a certified service provider (CSP) that acts as a third-party conduit

between online businesses and tax jurisdictions is the basis of this thesis.









The CSP implementation in this work takes into account most of the

recommendations made by the SSTP for a streamlined tax system. Ideas not within the

framework of, and at times contradicting the tenets of, the SSTP were also explored and

implemented. This work contributes an XML DTD, termed TaxML (Appendix A) to

interface between sellers and the CSP. TaxML defines entities and attributes that abstract

this work's unique resolution of tax issues-either in accordance, in extension, or in

contradiction to SSTP recommendations. Among other contributions, of particular

interest to jurisdictions would be the slab based tax system for items in the tax base that

require special handling. Different tax rates can be set for items depending on either the

quantity in which they are sold or the price at which they are sold. Jurisdictions can

encourage or discourage the economic destiny of items by adjusting the slab rates. This

will be appreciated by jurisdictions but at the same time be seen as a step in the wrong

direction by those who seek simplification-which in the extreme amounts to a single rate

in all jurisdictions, across all items. Other significant contributions are in the areas

concerning multiple use locations and exemptions. Buyers can have different quantities

of the same item delivered and used in different locations. Tax is assessed based on the

final use location and not the delivery location. Exemptions are handled using an

elaborate mechanism. Exemptions are resolved by considering the buyer exemption

period, the jurisdictions for which the buyer has valid exemption, the items that were

approved for exemption for that buyer, and the percentage of exemption on the regular

tax rate that was granted for that item, for that buyer, in that jurisdiction (details are

provided in Chapter 4).









The SSTP is still evolving as it deals with more issues in hearings and meetings,

but regardless of the version of the recommendations that are finally binding, the CSP in

this work provides a working model that deals with the issues involved in a way that

presumably gives all parties involved, despite concessions some may have to make, a

system that is still worth the fairness and convenience it ultimately achieves.

A brief overview of the issues surrounding collecting taxes over state lines is

presented in Chapter 2. The working mechanism and architecture of the CSP is

introduced in Chapter 3. Issues involved in collecting tax are explored based on their

relation to the CSP architecture in Chapter 4. Implementation details including

information on various technologies used, the data structuring, data flow, and

implementing objects interaction are dealt with in Chapters 5 and 6. Chapter 7

summarizes the contributions made by this thesis and discusses future work in this area.

From mid-2001 when the implementation was complete to the time this thesis was

submitted, the economy has taken a few tough knocks. Corporate accounting scandals,

copious layoffs, pre-emptive strikes, and stock market lows have contributed to a general

weariness and a slippery slope to recovery. E-commerce today is more rational in its

expectations and scope. It is hoped that the states will find the work in this thesis useful

when the economy improves.














CHAPTER 2
OVERVIEW OF ONLINE SALES TAX COLLECTION ISSUES, LANDMARKS,
AND INITIATIVES.

The United States constitution mandates that states shall not enact laws that hamper

the free flow of interstate commerce. Thereby Florida must not impose prohibitive tariffs

on peaches coming into the state from Georgia and Georgia likewise for oranges. From

the earliest cases in the 1930's, states have been grappling with issues of jurisdiction to

tax out-of-state businesses that sold goods to in-state customers. Is it possible, the

Advisory Commission on Intergovernmental Relations (ACIR) asked in its 1986 report

on mail order taxation, to shield interstate commerce from undue tax burdens without

causing revenue losses for state governments? This chapter starts with an illustration of

the fundamental issues and introduces various efforts at their resolution over the past

decades.

The Issue

Take for example three firms: firm A incorporated in Kansas; firm B also

incorporated in Kansas but having offices and retail outlets in Florida; and firm C having

a retail outlet in Florida.

Scenario 1

A Florida resident chooses to purchase a big-ticket item costing $1000 from firm

A. As firm A does not have nexus or any minimum presence in Florida, it is not required

to collect the sales and use tax which at a 6% rate would amount to $60.









The $60 however is still due to the state of Florida as the use tax. This has always

been the case but such is rarely ever remitted by customers owing to widespread

ignorance on the subject, or as was studied, people generally tend towards non-

compliance when they observe others doing the same. The inordinate administrative task

of collecting use tax from a large number of buyers as opposed to a small number of

sellers has resulted in non-enforcement.

Shipping and handling charges would ultimately reduce what seems to be a

substantial saving but in general the savings depend on a unique relationship for that item

derived from the kind of item it is, its price, and its shipping component. Based on this

relationship is a more important and general concept of the price elasticity of demand for

that item. Relative to income, the elasticity of demand for a product determines how

people base their decisions on which of two or more closely related products to purchase.

Price differences might effect either avoiding a purchase or a shift to a closely related

product. For example, salt being cheap relative to most people's incomes, on a price

increase for their brand, they might never the less continue to purchase their brand. Salt is

then said to be inelastic. If on the other hand, people choose to shift between Delta and

United Airlines based on a small fare difference, the demand is said to be price elastic.

For such products, the tax may become the deciding factor that pushes customers online.

But choosing an out-of-state online retailer over an in-state bricks and mortar retailer for

closely related elastic products also comes down to the difference not in the products

themselves but the sellers. Clothes can be tried out at the store but some guess work goes

into purchasing them online. Other considerations such as the shopping and customer

service experience that real stores offer (easy store returns, servicing, etc.) overcome









advantages that the tax break might portend to give online stores. However, over time

certain categories of products are becoming more apparent in the advantages they possess

in their purchase online.

Scenario 2

The Florida resident chooses to purchase from firm B. As firm B has offices and

retail outlets (or nexus) in Florida it is required to collect the sales and use tax. This

scenario would be no different from the one played out with an in-state or main street

retailer.

Interestingly enough, when going online, some nation-wide retailers who had nexus

in all states sidestepped the nexus issue by spinning off separate online companies,

incorporating them presumably in the state that had the fewest customers. The online

companies would then enter into a contract with the brick and mortar "parent" company

to handle their deliveries, returns, etc. Such distortion of economic behavior is wryly

noted by David Hardesty "The loophole becomes part of the economics of the industry.

In order to perpetuate the industry, the loop hole must be perpetuated" [HAR01b].

Scenario 3

The Florida resident purchases from firm C which is a local bricks and mortar

retailer. Sales and use tax is collected by the firm and remitted to the state.

The unfairness inherent in applying the same law differently was grudgingly

tolerated until the cumulative effects of sales steadily shifting to "tax free" out-of-state

retailers were beginning to seriously jeopardize local retail viability in certain segments.









Judicial and Legislative Background

The due process clause mandates linkage between the state and the business firm as

defined by a minimum presence or nexus. The commerce clause safeguards a national

market free from local entanglements.

The threshold of presence a firm has to exceed to qualify for nexus in a state has

varied in quality and degree as evidenced by the court's stand in some landmark cases.

The earliest mail order sales related case of Nelson v. Sears, Roebuck established

that sellers with retail outlets in a state were required to remit use tax even on mail order

sales delivered through common carrier rather than through the retail outlet [ADV86,

p.54]. The linkage issue was furthered in five subsequent cases: "1954 Miller Brothers v.

Maryland where sporadic deliveries by company truck to another state were not

considered an adequate business presence. In 1960 Scripto, Inc. v. Carson, the presence

of ten independent jobbers in the taxing state (no offices, property, or full time

employees) met the requirement" [ADV86, p.55]. In the landmark 1967 National Bellas

Hess v. State of Illinois case, the court ruled that on account of the firm not having

sufficient nexus in the state of Illinois, was not required to collect sales tax from its

customers in the state. National Bellas Hess' business presence in Illinois was limited to

the distribution of sales catalogs and flyers. This overturned the statutory provisions of

twelve states that had specifically identified mail order sales and advertising to have

sufficient nexus at that time. In 1977 National Geographic Society v. California Board of

Equalization, the existence of two small offices which provided only advertising support

was found to have an adequate nexus to collect use tax [ADV86, p.56]. The Internet Tax

Freedom Act 1999 includes a provision that states the accessibility of a website in a state

does not by itself constitute nexus. It is open to interpretation when the website is hosted









on an in-state computer [HAR98]. In Virginia, however, a ruling was issued that stated an

out-of-state auto parts seller who's own web server was located at a hosting company's

in-state facilities (that provided hookup and maintenance services) did not constitute

nexus [HAROOa].

During the sixties and through the seventies various committees and bills such as

the Willis committee bills, Mathias bill, and Mondale bills attempted to seek common

ground between the taxing authorities and businesses by introducing ideas such as a

registration mechanism for buyers that would remit tax independently, a de-minimis

provision to exempt small out-of-state businesses from the burden of collecting tax and

the Traigle plan to register a combined state and local tax rate. These attempts helped

expand the avenues of resolutions and perhaps simplification. They appeared in several

hearings to congress over the late seventies and eighties [ADV86, p.59].

States Arguments and Other Tax Issues

Erosion of Tax Base

The argument from the states point of view was principally that of the erosion of

the tax base. States have the obligation to protect their revenue streams to provide for the

services it renders to its citizens. Concerns from main street retailers grew over time as to

the competitive disadvantage out-of-state businesses place them at by not having to

collect sales tax. The arguments from the out-of-state businesses have evolved over the

years to be almost insurmountable: The out-of-state business does not benefit from the

services a state provides to in-state businesses (that are financed by the sales taxes

collected) and, therefore, should be absolved of the obligation to collect tax. To this, the

states, and Justice Fortas in his dissent in National Bellas Hess, put forth that they (the

states) undertake in creating, developing, and sustaining the customer base, banking and









commercial institutions, and communication and transport infrastructure within the state,

which by themselves are the services the state provides. A very serious issue out-of-state

businesses raise though is one of the costs associated with having to collect tax. A local

business has to deal with only one rate, the state rate, or at most two, the local jurisdiction

rate that is just added to the state rate. It is a reasonable expectation that a local business

can keep track of changes to the tax base. Items such as food, medicines, and clothing are

exempt from taxes in some states or are taxed less. New items may be made exempt and

currently exempt items may be made taxable. There are temporary changes to the tax rate

(tax holiday) along with permanent rate changes. Then there are the exempted buyers

such as orphanages, religious, and charitable institutions that get special exemption rates

for certain categories of items [ADV86].

Cost of Collecting Taxes

Consider, the sale of a $10 item for which a 6% Florida state sales tax and a 1%

Alachua county sales tax is levied. Suppose a hypothetical 10% gross profit or 100 cents

was made by the vendor, the cost associated with remitting tax collected on the sale

through either monthly or quarterly returns to the state will factor in as an operating cost.

This cost is defrayed in some states by allowing the sellers to keep a percentage of the tax

collected. In other states, the costs are entirely borne by the seller. Clearly, the cost of

collecting taxes has an impact on profit, and thus, prices [ADV86, p.43].

Incidence and Sourcing

The legal incidence of sales tax is on the buyer in some states (consumer taxes) and

on the vendor in some (vendor taxes) and on both in some states (hybrid). The economic

incidence however shifts between a higher price paid by the buyer and lower net revenues

made by the seller. Regardless of incidence however, sales tax is most commonly









collected and remitted to the state on the buyer's behalf by the vendor as this is easier

from an administrative and cost point of view. The sale is said to be sourced not at the

sellers' location (origin) but at the location of the buyer (destination) and tax laws in the

buyers' jurisdiction apply on that sale. As most of the incidence falls on the buyer, it is

logical that his or her jurisdiction, that provides services to its residents, has a stronger

claim on the tax. Also treating all out-of-state sellers alike creates a level playing field as

opposed to distortions where a seller might be selected based solely on being based in a

state, for instance that has low or no taxes [ADV86, p.45].

Acts and Initiatives Affecting Sales and Use Tax

Internet Tax Freedom Act 1998

The Internet Tax Freedom Act (ITFA) passed on October 21, 1998 imposed a 3-

year moratorium on the following

1) Taxes on Internet access unless such taxes were imposed and enforced prior to
October 1st, 1998 and

2) Multiple or discriminatory taxes on electronic commerce.

In essence, the ITFA defined a narrow, tax-exempt service (internet access) and a

few guidelines to guard against choking e-commerce from zealous taxation. More

information about the ITFA is presented in Appendix B.

Advisory Commission on Electronic Commerce (ACEC)

The advisory commission was to conduct a thorough study of federal, state, local,

and international taxation and tariff treatment of transactions using the Internet. Its report

and recommendations were to be submitted to congress in June 2000. The ACEC, chaired

by Virginia governor James S. Gilmore, III, an anti-tax advocate, submitted its report and

recommendations, well ahead of schedule in April 2000. On perusing the report, it might









be observed that the formal findings and recommendations dealt with safe and broad

issues (privacy and the digital divide). The real, industry-changing issues (sales and use

tax) on which congress would have needed guidance, rallied only a "majority vote." Out

of the 19 member committee, there were 7 abstentions for each of the majority vote

proposals. The abstentions could probably be interpreted due to a lack of clear

information on what is essentially an evolving, contentious issue (ACEC). More

information about the ACEC can be found in Appendix C.

Streamlined Sales Tax Project (SSTP)

From its inception in March 2000, the SSTP has made significant strides in its

objective to find a solution to simplifying and modernizing the complex tax systems that

has been a hindrance to efficient tax collection and administration, both within states and

across state lines. The general objectives of the SSTP closely follow the proposals set

forth for a simplified tax system by the ACEC. It is one of the recommendations of the

SSTP, namely a third party service provider for tax collection which forms the basis for

this thesis. The SSTP will be cited continuously through the text of this report. Readers

are urged to read the executive summary of the SSTP reproduced in Appendix D.

National Conference of State Legislatures (NCSL)

In the early months of 2001, the National Conference of State Legislatures had

approved the SSTP's final draft of recommendations albeit with some very crucial

amendments. The NCSL's version of the SSTP's tax agreement omits several provisions

that were considered to be controversial. The proposal for a uniform tax base was

removed, and the provision on caps and thresholds were removed. The NCSL also voted

to move the SSTP from a lead position to an advisory position. This was reported to have






14


been done to move the process from the tax administrators' realm to that of the

politicians.

The NCSL's revised plan has generally found more acceptance among states as it is

less threatening than the SSTP recommended changes. As more states enact legislation to

participate in the SSTP, it remains to be seen if the states that have enacted legislation to

explore the NCSL's amended version make progress in a direction that is more viable

[HARO1a].














CHAPTER 3
ARCHITECTURE OF THE CERTIFIED SERVICE PROVIDER (CSP) TAX
COLLECTION MECHANISM.

The CSP architecture developed in this thesis, is currently a single tax server

established at the machine and port identified in the configuration information. Sellers

registered with the CSP send requests in a TaxML (see Appendix A) query document to

the CSP's tax server (the CSP's tax server is frequently identified in the text of this report

simply as the CSP). The CSP calculates the tax due and sends a TaxML reply document

back to the seller. The CSP's bank is credited the tax amount due on the transaction by

the seller. Figure 3.1 illustrates the general relationship between the CSP, the sellers, and

their customers.

The architecture of the CSP tax collection mechanism, shown in Figure 3.1, can be

described in two functional sections: Seller site and Certified Service Provider site. The

functionality of each section is described in detail in the following pages.

Seller Site

The level of intrusion of the CSP software at the seller's site is minimal consisting

of a thin network protocol client henceforth described as the stand-alone network client

module as shown in Figure 3.2. It requires certain networking services and information in

the form of an XML document from the seller. Figure 3.2 is a birds-eye view of the data

flow between the seller site and the CSP in the form of an XML document.











n90



ToToFragrances.com







letail.com



-


S Seller
CSP Certified Service Provider
(-) Customer


Figure 3.1 The CSP in relation to sellers and their customers. 1) Customers send
information about purchasing items, quantities, locations of use, and other
information to the seller. To provide for scalability, the following is proposed:
2) Several ports can be established for servicing requests, and for sending
back replies. 3) A reliable service can be made available by replicating the
CSP's tax server at several sites. Sellers can be given a choice of machines
and ports from which to choose, which they prioritize through analysis of their
experience with their various choices. A distributed CSP tax server system
will need an application to maintain a protocol that ensures coherency and
concurrency of distributed objects such as the tax base.











TaxML Query


CSP


Network module
Network module


Seller






CSP's Thin Network
client module


TaxML Reply


Figure 3.2 XML data flow

The description below expands on the role of each module while walking through

the process from transaction initiation, tax retrieval to funds transfer. Figure 3.3 shows

the overall transaction data flow. A user initiates a transaction by acknowledging intent to

purchase merchandise (that is assumed to be in stock) by asserting a submit button on the

seller's web site. The acknowledgement is handled by the seller's transaction processor.

Information about the user is either retrieved from file or is submitted by the user prior to

asserting the submit button.


m


ck-







18



TaxML TaxML document
document from CSP
to CSP




Inventory Tax
CSP stand-alone module: Database Log
thin network client Transfer
Log

Update module
Objects 'XML text'
o'XMLtext to objects
Converter Extractor
Funds Transfer
module

TaxML TaxkML
Dispatcher Extractor Handler
TaKInfo Reply Objects:
a ns, tax, exemption
Transaction 1 status and notes Funds Verification
Management module
L --. I Transaction
Processor

TaxInfo Query Objects:
items, use locations,
exemption id
User and transaction Seller Site
Information

User Location


Figure 3.3 Functions, data flow and interaction at the seller site

The transaction processor creates a transaction ID and returns it along with user


information to an XML converter that converts the received objects into a TaxML query


document conforming to the TaxML DTD (Appendix A). The TaxML query document is


submitted to the stand-alone network client module, which transmits the same to the CSP.


The transaction processor meanwhile creates a transaction thread christened with the


transaction ID, which blocks for activation from the stand-alone network client module


upon arrival of tax information from the CSP. If a reply from CSP does not come in a


specified timeout period, the current implementation sends a notice to the customer of









network problems and makes a suggestion to resume shopping after some appropriate

time period.

The TaxML reply contains the tax calculated and the corresponding

transactionID. Upon a TaxML reply's arrival, the stand-alone network client

module wakes up the thread blocked at the transaction processor whose name

corresponds to the received transactionID. The received TaxML document is

extracted into objects and passed on to this awoken thread. The objects are processed and

the final amount due is displayed to the customer. When the customer sends

acknowledgement to the final amount due (price of merchandise plus the tax), the update

module (not implemented) temporarily freezes or debits the inventory database for the

number of items being processed in the transaction for a reasonable timeout period for

transfer of funds (or presumably to select an alternate source of funds should one fail).1

The verification module (not implemented) checks to see if the source of funds (SF)

(credit card or bank) has sufficient funds for the transaction to go through and if so

freezes or commits the amount due. If a negative response is returned from the SF due to

an insufficient balance, the user is asked to use an alternate source or is led through

whatever mechanism the seller has created to handle such a situation.






1 A potential security hazard exists wherein a malicious customer might freeze large
chunks, or even the entire inventory only to have the transaction intentionally fail due to
insufficient funds. This temporary freeze would hurt legitimate customers who might get
a 'not sufficient items in inventory' notice. Alternatively we can avoid freezing till the
very last moment. Once the customers source of funds are identified to be sufficient, one
can perform an inventory check and freeze if sufficient items available, otherwise notify
customer to reselect the items. As the customer's funds are not frozen there is no problem
on the part of the credit card issuer or bank









On a positive response (with the amount due frozen at the SF for transfer to the

seller) the transaction is said to have gone through. The customer is notified of the

successful transaction along with shipment and tracking details.

Meanwhile, a funds transfer module (not implemented) initiates a transfer protocol

with the source of funds, the seller's bank, the CSP, and the CSP's bank. The funds

transfer module sends a request (tracked by a transaction ID) to the SF to transfer funds

to its bank. Once it receives confirmation from its bank that the transfer has taken place,

it retains the price of the merchandise and initiates transfer of the tax amount to the CSP's

bank. When it receives confirmation from its bank that the tax has been remitted to the

CSP's bank, it sends a transaction termination message to notify the CSP that the funds

have been sent for the corresponding transactionID. The underlying protocol

addresses the details of tracking messages through a transactionID and about lost

transfers and messages.

Updates are committed to the inventory database, user information tables, and

merchandise shipment tables. A tax log is also maintained for all the taxes that were paid.

CSP Site

The CSP site has its functionality divided in several modules as shown in Figure

3.4. The most important module, the database controller accesses the ZIP code indexed

tax base, retrieves corresponding taxes, information on exempted items, and exempted

buyers and tax holidays.

The network module at the CSP site receives the TaxML query document and

initiates an extractor. It then goes back to listen for more TaxML documents. The











extractor parses the TaxML document into objects and sends them to the database


controller.


The database is queried for the tax percentages values for the listed items, in their


associated use locations. Items can have a quantity based tax or a price based tax


(explained in Chapter 4).


Listener

Confirmation
from bank


Listener

Message from
Seller regarding
funds transfer/
transaction terminat



Tax
Database

Item, E"


Confirmation to
seller


Tax
Log


ion Obects to 'XML text'

Recorder module

Exemp Q Tax dispatcher
statufrm tc. TaxInfo Reply
| | Objects
SDatabase Controller
emptP site#

TaxInfo Query Obje ts

*XML text'to Objects
__ CSP network module
Extractor TaxML Query
From Seller's site TaxML Reply
I to Seller's site

CSP site


Figure 3.4 Functions, data flow, and interaction at the CSP site

If the item is tax exempt, that information is returned. If exemption is being sought


(certain buyers have exemption privileges, as discussed in Chapter 4), the buyer's tax ID


is checked to see if he/she is approved for exemption. If the buyer is exempt, the









exemption percentage for that buyer, for that item, in the use jurisdiction is retrieved.

Otherwise notes detailing why the exemption is not valid anymore are returned.

Tax holidays are checked for the item, following which tax is calculated (taking

into consideration exemption percentage or tax holidays) and recorded in objects

maintained through the process.

The tax calculated for each item in the transaction and exemption status notes are

returned to the seller's site. This is accomplished by converting the information

accumulated in various objects (that were maintained in the tax extraction process) into a

TaxML reply document, and dispatching it through the network module to the seller.

The transaction information is sent to a recorder module that logs each request. All

the information relating to the transaction, including the time at which the tax quotation

was sent to the seller's site is stored in the log and a receipt is flagged on the tax due for

the transaction. A timeout period is initialized for the receipt. Logs are to be cleared

periodically of transactions that have a receipt flagged on them after the timeout period. It

is assumed that the transaction did not go through at the seller's end.

In the unforeseen case that the transfer of tax due from the seller's site is received

after the timeout period, the seller's site is asked to send the transaction details once

again. Transfer of funds confirmation from the CSP's bank initiates retrieval of the record

with the corresponding transactionID. The receipt flag is removed. Upon receiving

a transaction termination message from the seller, the CSP returns a transaction

termination message.














CHAPTER 4
THE CSP ARCHITECTURE, MECHANISMS, AND ISSUES.

Using the SSTP recommendations as a model to address issues surrounding tax

collection, other ideas and solutions were explored. This chapter introduces various

issues and discusses how the proposed architecture and the implemented architecture

differ from, extend upon, or conform to SSTP guidelines.

Table 4.1 SSTP recommendations. Proposed architecture and implementation
information.
Uniform Collection Centralized Centralized Tax rate
definitions cost exemption seller database
in Tax base allowance registration
SSTP Present Present Identification Present Publicly
guidelines numbers accessible
databases
Architecture Present. Described in Highly Present Database
proposed Described section flexible replicated as
in section below, system distributed
below, described object at CSP
below. mirror sites
Implemented Database Transfer of Database Interface Interface
has funds from keeps track provided provided to
standardized credit card of exempted jurisdictions
tax bases and banks buyers, items to modify tax
referenced are not exempted, rate database.
by their implemented. percentage Distributed
version of exemption objects and
numbers. in relation to mirror sites
TaxML jurisdictions are not
documents where such implemented.
have apply.
version Interface for
numbers registration
tags on provided.
items.









Table 4.1 (continued)
Multiple Taxing Tax Caps and Confidentiality
locations of jurisdiction Holidays thresholds
use resolution
SSTP For digital Delivery Only for Member Only
guidelines products, location is goods states must information
sellers need the taxing specifically eliminate required for
not collect jurisdiction, defined in caps and calculation of
tax if Locations the thresholds. tax to be given
customer resolved by agreement. to CSPs.
applies for mapping
multiple ZIP code
points of use areas to
exemption jurisdictions.
Architecture Provides for Use location Tax A slab Only
proposed tracking and is the taxing holidays for based tax customers that
assessing jurisdiction, any goods rate system request
taxes on Zip code the is proposed exemptions
quantities of areas map to jurisdiction and is have their
an item jurisdictions, sees fit. explained in exemption
being Described in detail in certificate
shipped section section presented to
to/used in below, below. This the CSP for
different gives verification
jurisdictions. jurisdictions and resolution
Details in exacting of exemption
section control over percentages.
below, their tax
base.
Implemented The TaxML Interface Jurisdiction Jurisdictions Buyer tax id
document provided for can log into can log into for buyers
holds modifying its database their requesting
information ZIP code and create database exemptions.
on items, area tax holiday and specify The seller tax
and their information, periods for tax slabs for id for keeping
constituent any item. items in tax track of
individual base. transaction-tax
quantities remittance,
being and audits in
shipped case of
to/used in irregularities.
various
jurisdictions.









CSP Architecture and Implementation Issues

Resolution of Item Being Taxed

Items listed on a seller's website are identified differently at various levels in the

tax extraction process. Take for instance a particular shoe on display for sale among

hundreds of others that are also available. The seller in his database uniquely identifies

this shoe by an item code. Associated with the item code is presumably an entry that

spells out in a human-readable, perhaps non-unique language, a brief description of said

item. In the seller site implementation of this work, the following colon delimited format

is used: [Description of item:customersiteitem_code]. The description is permitted to

have spaces while the item code is not. The shoe in the example above might have the

following entry associated with it: [Operating room moccasins:med34554].

For taxation purposes, the shoe is determined as belonging to the category Hospital

Supplies. Yet another shoe might belong to the category Extreme Sports. The collection

of such categories is listed in a standardized tax base. All conceivable items, taxable or

otherwise, presumably map to one of the categories in the tax base. The tax base

technically should contain only the categories that are taxable but this architecture

considers all items as belonging to the tax base. The actual determination of whether an

2
item is taxable or not is a jurisdiction specific issue.2



2 The standardized tax base was one of the items left out in the National Conference of
State Legislatures' (NCSL) version of the SSTP agreement-the justification being that
more states would be interested in signing up when not confronted with an undertaking
that mandates relinquishing their tailored mapping system, built perhaps over several
years consuming committee man hours and good intentions. And then there is the
resistance from some states where industry lobbyists, as David Hardesty reports,
complained about the potential negative impact of standard definitions (preceding
categorization). "For example, confectioners fear that by creating a separate category
within food for 'candy', some states might be encouraged to tax candy" [HAR 2001-a].









The standardized tax base is created once all the participating states in the SSTP

formulate and agree upon the definitions and mapping. Once ratified, it is frozen. A

version number assigned to it and transferred to each seller. The seller uses the frozen

version to map the items in its inventory, manually, perhaps in consultation with an SSTP

designated office for resolving difficult to map items. There will be items that belong to

several categories either in a vertical or horizontal manner. Vertical relationships between

categories are represented by a hierarchy with increasing specialization on the way down.

For example three categories that are related vertically: Food, Recreational food and

Candy. An item will belong to the category that represents it the closest. Horizontal

relationships between categories can be represented by a Venn diagram. Two categories

such as Jewelry and Industrial tools may lay claim to diamonds. An item will be

classified in the category with which its use is most closely associated.

The tax base category name is user-friendly and may contain spaces, while the tax

base code consists of an alpha-numeric sequence strictly meant for database interaction

and storage. Item name resolution traces its path from the seller site code to tax base code

and tax base version. The seller site name and tax base name are used for describing

items to humans.

The Money Trail

When the extracted tax information is passed to the waiting transaction object, the

customer is presented with the final amount due. The customer acknowledges the final

amount and sends a confirmation. The current seller site implementation handles only


The standardized tax base is arguably one of the most critical components in the CSP
architecture without which the automated mapping process would be dealing with 50
hashes from the states or infinitely more frightening, 7500 hashes that includes all the
taxing jurisdictions.









credit cards and checks for sufficient funds in a dummy method, which always returns

true. The architecture envisages a production version in which the seller site then

commences a transfer of the amount due towards tax to the CSP's bank. The CSP is also

sent a notice of the imminent transfer with a reference to the transactionID.

Needless to say, all transfers of notices or messages over a network are acknowledged

through some protocol. The seller site logs the transfer in its transaction files and

terminates that thread. The CSP, upon receipt of the transfer information from its bank,

logs the same information in its transaction logs.

An alternative that reduces the number of transactions, and is therefore more

attractive is where the CSP maintains credit accounts or direct-debit information such as

a bank routing number for each seller. Upon sending the tax information, the CSP awaits

a go ahead from the seller confirming the sale. Then depending on the setup, either the

seller's credit account is charged or a transfer of funds is commenced. If the go ahead is

not received within a reasonable duration of time, it is safe to assume that the sale failed

as a result of the customer canceling the transaction after being presented with the final

amount or due to insufficient funds.

The CSP can choose to remit the tax due to jurisdictions in real time, or on a daily,

weekly, or in some other suitable interval of time. The cost of services provided by the

CSP is deducted by it as a percentage of the tax collected or through some other

arrangement between it and the participating states. As is provided in the SSTP

agreement, the seller is absolved of having to file returns, and from audits considering

items that tax information was sought on were represented correctly.









Buyer Exemption Certificate Security

Buyers that qualify, apply once at the participating states portal (PSP) for

exemptions on particular items and the ZIP codes in which they seek exemptions. The

jurisdictions deal with exemption requests on a case-by-case basis and grant or deny

exemption status. On receipt of at least one exemption status, the buyer is issued a buyer

exemption certificate as represented by an alphanumeric code. This code is used by

buyers when purchasing items. In the current implementation, the code is entered in-

securely i.e. the seller interface does not implement a secure form for buyer information

input. However, a secure form addresses only part of the security concern-that of the

buyer exemption certificate being intercepted by an eavesdropper. The other security

concerns or potential misuse scenarios include a) buyer exemption certificate deliberately

given to friends or b) stolen through conventional non-electronic methods. There are

several possible methods that address these concerns:

1) For each exempted buyer certificate, register the I.P. number of the computer that
the buyer would be using to make purchases. This requirement will exclude those
buyers that do not own computers and are opportunistic in their usage.

2) Register delivery addresses associated with the certificate. This, however, does
not solve the case where in a buyer may register the address of the person to
whom he is giving the certificate. Damage is limited when compared to a free for
all type of development such as when a certificate is published online or
distributed in news groups or group mails.

3) Public key cryptography: The buyer is issued a private key, the public key for
which is stored along with his other account information at the CSP. When a
transaction is commenced, the buyer, prior to asserting the purchase button that
sets in motion the tax retrieval and exemption verification and calculation process,
uses his private key to encode a challenge c sent by the seller site. The encoded
message e(c) and the actual message c are sent by the seller site to the CSP along
with the transaction information. Verification is successful when the CSP extracts
the encoded message d(e(c)) using the public key of the buyer and positively
matches it to the actual message (d(e(c)) = c).









Privacy Safeguards

The name or any other form of identification of the buyer is not sent to the tax

jurisdiction. The buyerTaxID is sent only in the case exemptions are sought so as to

enable the CSP to approve the buyer. This would enable CSP's to store this information-

which might be beneficial in analyzing exemption irregularities. Future analysis of log

data at the tax jurisdiction can be made only by zip code. The credit card company or any

of the banks involved are not informed of the items purchased by the buyer. Only the

seller information is sent.

Message Passing Protocol

The CSP has a well-identified address and port to which the sellers connect. The

machine used to host the CSP was taproot on the CISE network listening on the port

8277. Any seller wishing to communicate with the CSP sends the TaxML query to

taproot on port 8277 using UDP. UDP was used as it is fast, but since it is unreliable, a

protocol of acknowledgements between the CSP and the seller is required to ensure a

measure of reliability. For sellers that have a volume of transactions beyond a certain

threshold a connection oriented communication service is justified. Multiple transaction

threads can use a single connection. An additional layer would interface with the shared

connection to keep track of out-going packets, and pass in-coming packets to their

rightful thread owners. Appendix E addresses a few scenarios that the UDP based

protocol generates.

CSP Tax Resolution Issues

Sales or Use Tax

The distinction between sales tax and use tax is one of vendor collection obligation

more than a meaningful economic one [ADV86, p.23]. Out-of-state businesses are not









obligated to collect and remit a use tax on behalf of its in-state customers. It is the

customers that are required to conscientiously apply the local tax laws to their purchases

and remit the same to the states' exchequer. This arrangement is plainly un-enforceable

due to its cost in-effectiveness and the administrative drudgery involved in keeping track

of a large number of customers and an exponentially larger number of transactions.

Solutions and agreements to aid in the collection of use tax are the basis for the SSTP.

The CSP is such a mechanism to collect the use tax due on an item in the location of its

3
usage.

Sourcing the Transaction: Origin or Destination

A transaction is legally said to have taken place or sourced at the point of delivery

of goods or services. The SSTP recommends for a digital product (software, books,

movies, music, news, information, and services) delivered electronically, the buyer's

billing address be used as the taxing jurisdiction. If the buyer's address is not known then

the sourcing is at the server used to deliver the service. To prevent servers from being

relocated to tax free states, the agreement stipulates that a server alone without an

administrative setting, is not acceptable [HAROOb]. This architecture sources the sale at

the location of usage and not the location of delivery, i.e. the tax is determined from the

usage jurisdiction's tax base and not the delivery jurisdiction's. Customers explicitly


3 "Most states that enacted sales taxes followed them shortly thereafter with a use tax, the
main purpose of which was to tax purchases made in other jurisdictions by residents of
the state. Typically, the use tax is a tax on 'the enjoyment of that which is purchased'
when the purchase would, in the absence of vendor collection problems, be subject to the
sales tax" [ADV 1986]. Significant differentiation was made between the sales tax and
the use tax in a series of cases heard during the mid forties wherein the court indicated
that the standards for collecting sales and use taxes from vendors were different. Out-of-
state vendors were not to collect sales tax in most cases though a use tax might be
acceptable in some cases. This legal distinction was supplemented by linkage issues in
later cases [ADV 1986, p.54].









select a use location, if different from the delivery location, for each item in their

shopping cart. This is an important addition that this work makes to SSTP

recommendations as it is the use tax that is being collected. In most cases the delivery

location and the use location are the same, but there are classes of transactions where they

might differ. A company might have items delivered to its corporate head office from

which consignments may be sent out to branch offices. People might use for delivery, the

nearby address of a friend in a neighboring jurisdiction that has lesser taxes. Stretching

further on that line of reasoning, rather thin perhaps, customers might purchase items

while living temporarily out-of-state whereas the significant enjoyment of the item takes

place on their return. In all cases cited, the actual usage of the item takes place in a

different jurisdiction from the delivery jurisdiction and it is but logical to let the use

location prevail.

Multiple Use Locations, Multiple Delivery Locations

The most common case would be that of a head office of a corporation that has a

centralized purchasing system. Local branches' purchasing requests are channeled to the

head office that approves and processes the orders. The same item can then have multiple

delivery locations, which again engender multiple usage locations. Another significant

class of transactions are gifts. A customer might order items to be shipped to various

delivery locations. The CSP implementation handles transactions with multiple items,

being delivered/used in varying quantities at multiple locations. The use location

associated with the delivery location is always used to compute tax for the quantity of the

item destined there.









Zip Code Area Aggregates Based Jurisdictions

"Currently, forty five states and the District of Columbia impose sales and use taxes

on purchases of tangible goods. In addition, 4,696 cities, 1,602 counties, and 1,113 other

tax jurisdictions also impose sales taxes" [SST02a]. The physical location of all

customers map to these 7457 taxing jurisdictions in a hierarchical fashion. That is, as

jurisdictions enclose other jurisdictions, an item's tax is calculated cumulatively by

adding the state tax, to the county tax if any, and to the city tax if any. The precise

determination of a customer's address to its enclosing jurisdictions has to be done on an

address by address basis and can be automated with a database of address and their

corresponding enclosing jurisdictions (perhaps MapQuest, Yahoo maps, MSN maps, or

another company that has already charted a large number of US addresses can help in

jurisdiction resolution). The current CSP implementation in this work uses a ZIP-code-

based mapping system and aggregates individual ZIP code areas to form jurisdictions (the

implementation does not however cumulatively apply taxes of enclosing jurisdictions).

This aggregation of ZIP code areas to jurisdictions is not precise as jurisdiction

boundaries are not defined by ZIP codes areas and there will be customers on border ZIP

code areas that may map to a jurisdiction to which they do not belong. In a production

version of the CSP, some optimization is possible by only having to map those customers

living in border ZIP code areas. The current CSP implementation also does not calculate

cumulative taxes from enclosing jurisdictions.

Recommended CSP future release work should include ZIP code areas that are

aggregated to form enclosing jurisdictions. Cumulative taxes from such enclosing

jurisdictions can then be calculated. Production version work should have the jurisdiction









of customers on border ZIP code areas resolved by using the services of a commercial

mapping company or by using such a database if developed.

Caps, Thresholds, and Tax holidays

Some jurisdictions use a measure of caps to either exempt, or assess less tax. In

New York, clothing sales up to $100 are exempt from tax. In other places there are

thresholds, or a volume of purchase beyond which tax exemptions or lesser rates apply.

Tax holidays are used by various jurisdictions to give a temporary reprieve from taxes on

certain goods. A popular tax holiday in some jurisdictions is the one before school starts.

In the current CSP implementation, caps and thresholds are dealt with in terms of the

concepts introduced in the next section. Jurisdictions can log into their account and set

tax holidays for items in their tax base. Start dates and end dates are specified for each

item. When an item with a tax holiday flag set, it is universally granted the reprieve from

tax regardless of the type of buyer.

Study in Control Minutiae: Tax Based on Gross, Quantity and Price

The current CSP implementation gives jurisdictions intricate control over how

items in its tax base might be taxed. At a broad level, items can be deemed to fall under

two categories. Those that are quantity oriented and those that are quality-price oriented.

Quantity oriented goods are those that are usually purchased by weight (with an

avoirdupois or quantitative measure): two metric tons of sugar, three hundred cases of

oranges, 800 liters of sunflower oil etc.

Quality-price oriented goods are those that are usually purchased in singles: a

house, car, computer etc.









Tax based on gross

Most items in the tax base do not require specific control as it is neither desired nor

required. Tax based on gross is the most common type of tax across the item spectrum

(both quantitative and qualitative). A percentage of the total transaction amount is

assessed as the tax. A 6% tax on a $100 transaction would yield $6 in tax revenue.

Tax based on quantity

There are times when jurisdictions might want to base tax on the quantity of an

item being sold. An overabundance of oranges in a particular season might merit from a

lesser tax rate for purchases beyond a certain quantity. The current CSP architecture

provides for 20 slab rates based on measure.

For example: A jurisdiction might change its rates to a 6% rate for oranges up to

600 cases, a 2% rate for oranges more than 600 cases-up to 1000 cases, and a 0% rate for

above 1000 cases. On the other end, consumption of commodities may be controlled by

adjusting the tax rates applicable at different quantities. Figure 4.1 charts out sample

slabs to encourage or discourage purchase and consumption.


Item: Oranges
Quantity (in cases) Tax Rate
1 600 6%
601 1000 2%
1001+ 0%

Perhaps in a war-time economy, oil may be charged at 2% for purchases up to 20
liters and 10% for purchases above 20 liters.

Item: Oil
Quantity (in liters) Tax Rate
1 20 2%
21+ 10%


Figure 4.1 Illustration of the quantity based slab rate system









The architecture envisions that jurisdiction representatives log into their accounts

and set up the hash table for items that need quantitative controls. Future implementation

work includes the following

1) Users upon selection of an item that has a quantity based tax rate would be given
details about the same to aid in decision making and

2) Provide a mechanism to track users so they do not make multiple purchases of an
item just below the cap beyond which it is charged at a higher rate.

Tax Based on Price

For items such as cars and houses, a jurisdiction might have social goals that seek

to rectify in some measure, inequalities. Taxes can be based on the price of an item. The

current CSP architecture allows for 20 slab rates based on price.

For instance, a car that costs less than $4,000 may be taxed at .5% (subsistence). A

car that costs between $4,000 and $10,000 taxed at 2%. Cars costing between $10,000

and 20,000 may be taxed at 4.5% and so forth. Figure 4.2 charts a sample price based

slab.


Item: Car
Price Tax Rate
< $4,000 .5%
4,001 $10,000 2%
$10,001 $20,000 4.5%
$20,001 $35,000 6%
$35,001 $55,000 7%
$55,001 $90,000 8%
$90,000 $200,000 10%
$200,001 + 14%



Figure 4.2 Illustration of the price based slab rate system

Such a micro controlled system can easily get out of hand if not handled with care.

A worst-case scenario where every item in the tax base has a different slab is frightening.









Jurisdictions should exercise prudence and use slab-based rates for a very selective set of

items. Inclusion of items in this selective list must be justifiable, and approved by a

special panel set up for that purpose. Those items for which the slab rate has outlived its

usefulness should revert to a gross rate.

Study in Exemption Minutiae: Exempted Entity-Jurisdiction-Item-Percentage of
Exemption

A variety of users are exempt from paying taxes owing to concessions that society

and the government makes to help in their livelihood, or maintenance and upkeep.

Charitable institutions, religious institutions, senior citizens, disabled war veterans,

persons with challenges, or unemployed citizens, might, among others, fall into this

category. The implementation in this architecture gives each jurisdiction control over

many aspects of exemptions. A user is exempt in a particular jurisdiction for a particular

item at a particular percentage of exemption. For instance, a person identified as a

disabled war veteran may be set in a particular jurisdiction to receive a 100% exemption

of tax on food, a 95% exemption on clothing, a 80% exemption on appliances, and a 45%

exemption on all other items in the tax base. The current CSP implementation employs

this multi-variant exemption schedule and envisions jurisdictions to be able to log in and

make changes to these tables. An exempted entity has the following data items associated

with it:

1) Exemption period validity period (identified by a date).

2) Notes on exemption certificate usage. Irregularities or investigations currently in
process or past will appear here.

3) For each item exempt in tax base, an exemption percentage.

Future work should include a mechanism for selecting groups of items-created

especially for each exempt group. To enable more flexibility, a few general groups









should also be created. This would vastly simplify the exemption process enabling a

scenario where a senior citizen might request and be approved for the Senior Citizen

Exemption Package along with General Exemption Packages No. 45A and No. 332B.

Exemption Registration Procedure

The Participating States Portal (PSP) has a centralized form that users may fill out

to request tax exemption. The user specifies the items and the jurisdictions in which

exemptions are sought. This form is sent to each jurisdiction where they show up in a

requestfor exemptions list. Jurisdictions manually inspect the credentials of the

requesting user. Upon verification and approval, an exemption certificate ID is created

and sent to the user. The format of the ID must be standardized. A central PSP

mechanism that issues IDs is envisioned.














CHAPTER 5
IMPLEMENTATION DETAILS: HOW TO RUN THE APPLICATIONS

The implementation of the CSP is done in Java. It was developed and tested in the

Java 2 platform version 1.3.1 on a Sun Microsystems UltraS (sparc) running Solaris

version 5.8. The database used was Sybase. Java Servlets were used to create all

interfaces. Though initially developed and tested using the TomCat 3.3 server, the

servlets now run, on the TomCat 4.1 server.

Sellers communicate with the CSP at an established machine and port. The CSP

identifies the machine on which it is running and the port it is using through a

configuration file in the form of static objects in a public java class called

ConfigData. j ava. The Seller implementation is started by the servlet that handles

user transactions ShoppingCartNew. j ava. A text file or an XML configuration file

are the desirable methods for configuring any application. The next release should have

XML configuration files.

How to Start the CSP

To run the CSP on a particular machine and port, follow directions 1 through 4. If

no configuration is desired, follow steps 3 and 4. The CSP machine by default is

taproot.cise.ufl.edu and the port is 62974.

1) Identify the machine and port on which to run the CSP.

2) Change ConfigData.java to reflect the machine and port. Compile it.

3) Login into any machine on the cise uf 1 edu sun machines network or
network that has the machine identified in step 1. The network has to be
configured such as to allow remote running of processes using the rsh command.










4) Run StartCSP.java using the command: java StartCSP

5) The CSP generates a log file csplog in the directory of execution.

How To Start the Seller

The seller is started automatically by the servlet ShoppingCartNew. j ava,

which handles user interaction. The Interfaces are all hard coded to run on the machine

sun 114 4 4 on the cise. u f edu network. A small script at the root of the servlets

directory by the name of start.sh can be used to start all servlets as described in the next

section. The default port for the seller is 8277 on the machine the servlets are running on:

suni 14-4 4. The default port can be changed in the ConfigData. j ava, which will

need to be compiled for the change to take effect. The machine can be changed only as

described in the next section.

How To Start The Interfaces

1) Login into sun114-44 on the cise.ufl.edu network.

2) Run the start. sh script using the command:. /start

3) If servlets are to run on another machine, each reference to the machine sunl 14-
44 in the servlet programs have to be changed to reflect the new machine. The
servlets use static html pages currently hosted at
http://www.cise.ufl.edu/-mc /thesis/SellerSiteShopping/ and
http://www.cise.ufl.edu/-mcl/thesis/Interface/, and these files will become
unavailable when the mc1 account ceases to exist. They would need to be copied
to a fresh location and references to them in the servlet programs have to be
changed to reflect the new location.














CHAPTER 6
IMPLEMENTATION DETAILS: THE CLASSES

The implementation uses Java's net, sql, and swing packages, and programming

features such as synchronized monitors. The following is a discussion of the classes that

compose the various applications, how they relate to each other and what they

accomplish.

TaxML Object Classes

The TaxML object classes hold the data parsed from the TaxML documents. Each

object is designed so as to parallel an XML entity. The attributes of the XML entity

become the corresponding object's primitive data fields. An XML entity that have other

entities ensconced within them are represented as user defined object data fields. For

instance, the object class Tax Inf o is the big wrapper that parallels the outermost entity

in the TaxML document-taxinfo.

version, taxbaseversion and query are attributes to the taxinfo entity which are

reflected by primitive type attributes of the same names in the object class Tax I n fo.

Buyer, Seller, and JurisdictionTaxAggregate are three user-defined

objects that have their own primitive attributes and user defined objects within them

paralleling the TaxML document structure. Figure 6.1 illustrates the parallel mapping

schema.























This translates to an object called TaxInfo as defined below:

class TaxInfo

String version;
String taxBaseVersion;
String type;
Buyer buyer = new Buyer();
Seller seller = new Seller();
JurisdictionTaxAggregate jurisdictionTaxAggregate =
new JurisdictionTaxAggregate();




}



Figure 6.1 XML entities map to respective Java objects

A Tax I n fo object that bears query type information usually has a null

JurisdictionTaxAggregate object. A TaxInfo object that bears reply type

information usually has null Buyer and Seller objects.

The TaxML object classes laid out in Figure 6.2 illustrate their enclosing structure

that parallels the TaxML query and reply type documents. The Buyer and Seller

parts together parallel a TaxML query while the JurisdictionTaxAggregate part

parallels a TaxML reply.









The query type Tax I n fo object is initially assembled by the seller as the customer

makes item choices including quantity, delivery, and use locations for portions thereof of

the quantity. A complete query type TaxInfo object is then converted to a TaxML


Figure 6.2 The TaxML DTD maps to the TaxInfo Java object

query type document and is sent across the network. The CSP receives the TaxML query

type document, parses it, and forms the same query type Tax Info object that initially

existed at the seller's site. Tax is calculated and put together in a reply type TaxInfo

object, which is converted into a TaxML reply type document and is sent across to the


TaxInfo
{
Buyer
{
Item
{
DeliveryLocation
}
}
Seller
{
Transaction
{
MyDate
MyTime
}
}

JurisdictionTaxAggregate
{
TaxItem
{
TaxAmt
{
Notes
}
}
}
}









seller. The seller parses the received document into the same reply type Tax I n fo object

that existed at the CSP. Information is extracted from the reply type Tax I n fo object to

the interface objects servicing the customer. The entire process is illustrated in Figure 6.3

Query type Taxlnfo object Query type Taxinfo object




TaxML 'query' TaxML 'query'


00O
OoOO

SReply type Taxinfo objects
Customer objects


TaxML 'reply' TaxML 'reply'



Reply type Taxinfo object Reply type Taxinfo object


Figure 6.3 Information containers and paths

CSP Site Java Classes

The CSP site is comprised of a collection of classes that perform different

functions. The CSP receives TaxML messages and spawns separate threads to handle

them. Tax is calculated and put together in an out-going TaxML message. It is then sent

to the requesting seller.

StartCSP.java

StartCSP. j ava is the class that starts the CSP on the machine identified in

ConfigData. j ava. The rsh facility is used to start the CSP process remotely from









any computer on the CISE network. A log file called csplog holds progress messages

from the CSP's startup process.

CSPListener

CSPListener initializes a socket listening to the port identified in

ConfigData. j ava. It spawns a CSPExtracterHandler if it receives a TaxML

query document. If it receives an acknowledgement it sets the same in the class

StationHash that maintains a static hash of messages. The CSPListener also has

static methods that send acknowledgements and TaxML documents using the socket

established previously. This arrangement is not scalable. A socket pool from which a

socket is selected based on some criteria (queue on gross load) for sending messages will

scale well as traffic increases.

DataBaseController

The heart of the CSP, the DataBaseController class is given a TaxInfo

object for which all the query type attributes are all filled with data parsed from the

TaxML query document (the reply type attributes are null for the same TaxInfo

object). DataBaseController proceeds to make database accesses collecting tax

and exemption information for the items listed, calculating tax due and storing the same

in objects that will eventually come together in another Tax I n fo object as the reply

type attributes. It creates a log of the final Tax I n fo object created in the database.

TaxDispatcher

Part of the network protocol group of classes, TaxDispatcher receives a reply

type Tax I n fo object that it converts to a TaxML reply document and takes care of









sending it to the seller. It also accesses, updates hashtables that keep track of

acknowledgements and information related to the transactionID being processed.

StationHash

StationHash is a data holder class that maintains static hashtables of

transactionID related information.

CSPExtractorHandler

Activated by the CSPListener on receiving a TaxML query doc as a separate

thread, CSPExtractorHandler proceeds to extract the same to a query type

TaxInfo object, which it passes to a new DataBaseController thread.

Seller Site Java Classes

Station

Station parallels CSPListener from the CSP site. It starts a socket using the

port specified for the seller in ConfigData. j ava. It is used to send TaxML query

type docs to the CSP at the machine and port specified in ConfigData. j ava. On

receiving an acknowledgment to the sent TaxML query doc, it sets the same in the class

Dispatcher that handles message passing. On receiving a TaxML reply document, it

spawns an ExtractorHandler.

ExtractorHandler

This class is given a DatagramPacket received by Station. It extracts the

TaxML reply document into a reply type TaxInfo object, which it sends across to

TransactionManagement that subsequently un-blocks the thread waiting for the

reply.









Dispatcher

Spawned with a query type Tax nfo object, Dispatcher converts it to a

TaxML query document and uses the socket at Station to send it to the CSP.

Dispatcher is part of the messaging protocol group of classes and among other things,

maintains and updates hashtables that enable it to maintain the messaging protocol.

TimeBomb

Once a request is sent, a TimeBomb thread is spawned that ticks down to the

timeout allowed for the round-trip, i.e. from the time of sending the TaxML query to the

time of receiving the TaxML reply. If the TaxML reply is received before timeout, the

TimeBomb thread is interrupted and it stops execution. If the timeout occurs first, then

the thread sets a Boolean value timeout to true and executes another indefinite

wait () It will subsequently be interrupted by TransactionManagement upon

noting the timeout value.

TransactionManagement

Two static hashtables are maintained by TransactionManagement. One is for

holding received reply type TaxInfo objects set by the ExtractorHandler. One is

for holding the TimeBomb objects mapped to transactionId's, ticking down to

their timeouts. A TransactionManagement thread is spawned by the servlet that

processes user interaction: ShoppingCartNew. j ava. The servlet then proceeds to

call, with a transactionID, a synchronized method that checks the TaxInfo hash

and the transactionID's corresponding TimeBomb thread's timeout variable for

the TimeBomb thread belonging to the transactionID. The synchronized method

blocks the thread with either of the checks returning a false. On either arrival of reply









type Tax I n fo object it returns the same to the requesting servlet and interrupts the

TimeBomb thread. On a timeout, it simply interrupts the TimeBomb thread. The

corresponding entries in the TimeBomb has are removed and are automatically garbage

collected.

General Utility Classes

The utility classes are used by many other classes common at both the CSP and the

seller sites. They mainly comprise of the scanner, parser, and the reverse-parser.

Token.java

Token. j ava is a wrapper class representing an individual character of

information in a document.

Scanner.java

Scanner j ava decomposes a document fed to it into tokens.

Extracter.java

Extracter j ava takes a vector of tokens and extracts TaxInfo object (query

or reply) from it.

Converter.java

Converter j ava takes a query or reply type TaxInfo object and creates a

TaxML query or reply type document respectively.

Dgram.java

Dgram. java is a general datagram utility class that creates a Datagram, given

required parameters.









Configuration Files and Classes

ConfigData.java

ConfigData. j ava holds various configuration data as static variables. These

include durations for timeout periods, a back-up federal tax rate to use if a problem is

encountered trying to assess tax on an item, CSP machine and port, seller machine and

port, etc.

Interfaces

The interfaces are all java servlets. Originally written and tested in the TomCat 3.3

server, they now run on the Tomcat 4.1 server.

Seller Interface

SellerInterface.j ava

The Participating States Portal uses a central seller registration system. The

SellerInterface collects information about the seller and makes database entries

that are manually checked for approval.

Shop Interface

The shop interface is divided into two parts: the part that implements the

functionality to handle user interaction and the shopping cart, and the part that

implements the functionality to handle new users.

Shopping cart

ShoppingCartNew.java

The most important interface as far as demonstrating the seller side of the CSP

architecture. It interacts with the user with login, catalog display and selection, and

display of a final invoice with tax information.









New user

NewUser.java

NewUser is used by new users wanting to register with the seller as a customer at

their site.

Buyer Interface

BuyerInterface.j ava

Used by the Participating States Portal, BuyerInterface handles interaction

with buyers seeking exemptions.

Jurisdiction Interface

JurisdictionInterface.j ava

Jurisdictions login into their respective accounts to view or update information

about buyers exempt in their jurisdiction, requests for exemptions, tax base items, etc. As

each jurisdiction has complete control over its tax base, changes made are immediately

noticeable at the CSP. This solves the tedious problem of having a central body keep

track of changes in each jurisdiction.

CSP Interface

CSPInterface.java

The CSP uses this interface to keep track of the various transactions, jurisdictions,

and sellers that interact with it.

Interface Objects

Interface objects hold information for servlets. The data fields are either set either

by interaction with the user or through database access. Interface objects used by the

servlet ShoppingCartNew. j ava (at the sellers site) are at the ends of the process of









sending for and receiving tax information. The toPrint () method present in each of

these classes returns an HTML formatted string of the classes' data fields.

Info

This is the parent class ofUserInfo, TransactionInfo, BuyerInfo,

SellerInfo, JurisdictionInfo, and CSP info. Info has a large number of the

common data items shared by all the inheriting classes.

UserInfo

Used by ShoppingCartNew.java, Us e r I n fo holds all the information about a user

including all his credit cards and delivery locations on file (in the database).

TransactionInfo

Used by the CSP interface, TransactionInfo object holds information about a

transaction. The query date-time, the payment (from seller) date-time, and the payment

remitted (to jurisdiction) date-time among other data items.

BuyerInfo

Used by the BuyerInterface at the Participating States Portal, BuyerInfo

holds information on the exemption request being made by the buyer.

SellerInfo

Used by the Sellerlnterface at the Participating States Portal,

SellerInfo holds information on the seller's industry, website address along with

other information required to process a seller's registration with the PSP.

JurisdictionInfo

JurisdictionInfo is used by the Jurisdictionlnterface to handle

and keep track of buyers approved for exemptions, requests for exemptions it its

jurisdiction, items in its tax base, and the tax due to it from transactions.









CSPInfo

CSPInfo is used by the CSPInterface.

CreditCard

CreditCard abstracts a real world credit card.

Address

Address abstracts a real world address.

Customerltem

Customer Item abstracts an item listed for sale at the seller's site.

Itemlnfo

ItemInfo abstracts an item listed for sale at the sellers site along with tax holiday

information and hashtables to hold quantity based or price based tax slabs.

TaxDue

Roughly paralleling the TaxML class TaxAmt, TaxDue is an interface class used

as a convenience class for holding and producing data for Interfaces that use it.

ExemptionItem

Exempt ion Item holds exemption related data for a particular item.














CHAPTER 7
CONCLUSION AND FUTURE WORK

This work focuses on designing and implementing an architecture for a Certified

Service Provider that can give taxing jurisdictions a flexibility that even the currently in

use customized tax systems do not provide. Jurisdictions have intricate control over their

tax base and can tailor it to fit their needs. Changes made are instantly and transparently

visible to all sellers through the CSP. Exemptions are handled to give better control over

how best to serve a particular community of buyers. Multiple locations for use are

handled, so certain groups of buyers such as corporate offices making purchases for

branch offices are not left out of the loop. Given the nature of the implementation,

jurisdictions should find this architecture beneficial although they would have to give up

customized definitions for items in their current tax base. It is likely that those preferring

a simple, one-rate, or few rate type of tax system would find this architecture leaving far

too much discretion in the hands of jurisdictions (elaborated on page 35). However, the

simplification achieved in centralizing administration, registration, and automating tax

collection should make for a balancing argument in favor of the proposed CSP.

TaxML provides for a smooth interface between the sellers and the CSP. All the

seller's programming staff needs to consider is how to present the data from their

transactions in the TaxML query format and how to extract information from a TaxML

reply. As TaxML evolves, subsequent versions will include additional features and

improvements.









References to future work have been identified within the text of the thesis where

they had contextual significance. The major ideas that future work can accomplish would

be in setting up mirror CSP sites that have local databases. A network file handling

system or protocol must be used to maintain distributed file system goals for replicated

resources (database). After issues in the message passing protocol are addressed, CSPs

should be made capable of handing requests from a pool of available ports. The most

pressing need is to expand upon TaxML to define an entity for conveying error messages

(to the seller) encountered in the tax resolution process. Various procedures in the code

currently catch exceptions which would need to be dealt with by higher routines that log

such errors and convey the same, when relevant, to the seller.














APPENDIX A
TAXML DTD AND DOCUMENT TYPES

TaxML Document Type Definition (DTD).














buyertaxid CDATA #REQUIRED


customersitecode CDATA #REQUIRED
taxbasecode CDATA #REQUIRED
taxbaseversion CDATA #REQUIRED
price CDATA #REQUIRED


zip CDATA #REQUIRED
uselocation CDATA #REQUIRED
quantity CDATA #REQUIRED


sellertaxid ID #REQUIRED


transactionid #REQUIRED










month CDATA #REQUIRED
day CDATA #REQUIRED
year CDATA #REQUIRED


hour CDATA #REQUIRED
minute CDATA #REQUIRED
second CDATA #REQUIRED


transactionid ID #REQUIRED
totaltaxamt CDATA #REQUIRED


customersitecode CDATA #REQUIRED
taxbasecode CDATA #REQUIRED
taxbaseversion CDATA #REQUIRED
taxitemamount CDATA #REQUIRED


deliverylocation CDATA #REQUIRED
uselocation CDATA #REQUIRED
taxamt CDATA #REQUIRED
emptionstatus (approvedlnotapproved) "notapproved" #IMPLIED










TaxML Query

TaxML documents are either queries or replies. A query is sent from the seller to

the CSP requesting tax information on an assortment of items. The reply is the itemized

list of taxes due. The sub-parts for Figures A. 1 and A. 2 are described below the

respective figures.









deiverylocation zip="32609" useication="32609" quantity="1.0" /> /
S
(7) @ (a


"I "













Figure A. 1 TaxML Query.

1) All TaxML documents will conform to the Document Type Definition specified
in taxinfo.dtd. As TaxML evolves, subsequent versions of the DTD released will
bear the same name. The version number itself will be specified as an attribute (to
the taxinfo entity) within the document itself


2) version pertains to the version of the taxinfo.dtd being used for the document.

3) taxbaseversion pertains to the version of the standardized tax base (page. 25)

4) type pertains to whether the particular document is a 'query' or 'reply.'

5) buyertaxid defaults to 12341234ex for all buyers that are not registered for
exemptions, otherwise it is the id that is given to buyers registered at the









centralized exemption registration center maintained at the Participating States
Portal (Appendix F)

6) customersitecode is the code used to identify the item at the sellers location
(page. 25)

7) taxbasecode is the code that that item maps to from the standardized tax base
(page. 25)

8) taxbaseversion is the version of the standardized tax base that was used for this
particular item's mapping. A different version here overrides the global
taxbaseversion being used in (3).

9) price is the price for the sale unit of the item. If the item is standardized in the tax
base for sale in pounds, the price is the price per pound. If it is standardized to be
sold in dozens, then the price is the price per dozen.

10) totalquantity is the number of units of sale.

11) deliverylocation is indexed by zip code as jurisdictions are zip code based (page.
31)

12) uselocation is the location used to assess taxes (page. 31)

13) quantity pertains to the quantity of the item destined to the delivery location
specified in (11). The same item can be delivered to multiple locations in various
quantities.

14) sellertaxid is an id sellers are given by the centralized registration system
maintained at the Participating States Portal (Appendix F)

15) transactionid is an unique id generated by the seller for that transaction. It has a
few standardized requirements that are meant to enforce uniqueness and enable
tracking or retrieval, such as having the seller id included as the last fragment in
the id.


16) Transaction time is tracked to the nearest second.











TaxML Reply









/




/

/notes>




















Figure A.2 TaxML Reply

1) The type attribute specifies that this particular TaxML document is of type reply
sent from the CSP to the seller bearing tax information.

2) The total tax amount due on the transaction has to be rounded according to the
rules specified in the agreement. At the time of the implementation, the rounding
rules were yet to be decided. The next CSP release will have this Figure rounded
appropriately.

3) The attribute totaltaxamount pertains to the total tax due on a particular item
calculated by taking into account all the individual quantities of that item being
delivered to individual jurisdictions.

4) taxamt is the tax due for a certain quantity of an item being delivered to a
jurisdiction.

5) exemption holds the values approved to convey approval for exemptions for the
buyer, for that particular item, for that jurisdiction. A value of not approved






59


coveys the opposite due to various reasons such as having a certificate that has
expired, or cancelled or suspended due to irregularities (page. 35).

6) The entity notes holds details about the exemption status. If approved, it will have
the period for which the certificate is valid, along with, in some cases, other notes
pertaining to the certificate.














APPENDIX B
INTERNET TAX FREEDOM ACT

The Internet Tax Freedom Act (ITFA) passed on October 21, 1998 imposed a 3-

year moratorium on the following

1) Taxes on Internet access unless such taxes were imposed and enforced prior to
October 1st, 1998 and

2) Multiple or discriminatory taxes on electronic commerce.

In essence, the ITFA defined a narrow, tax-exempt service (internet access) and a

few guidelines to guard against choking e-commerce from zealous taxation. One of the

interesting exceptions to the Internet access provision is that it does not cover entities that

engage for commercial profit, in communication of material that can also be accessed by

minors, and is harmful to them, unless safeguards are implemented to restrict access.

The exception does not apply to telecommunication providers such as AT&T; ISPs

such as AOL; search engines such as Yahoo; or web hosting services such as Tripod to

the extent that they are providing their core services. Those entities engaging by any

means, in providing unrestricted access to materials harmful to minors would be partly

taxable [HAR98]. David Hardesty, an adjunct professor of taxation at the Golden Gate

University notes that this can be viewed as congress using the ITFA as a backhanded way

of forcing self-regulation on the Internet community, which has resisted any form of

formal or direct control.

The discriminatory provision prohibits taxes imposed on electronic commerce

transactions that are not generally imposed on equivalent transactions accomplished by









other means. "For example, a state could not impose a tax on access to an online

newspaper where the sale of newspaper from a street corner is free of tax" [HAR98]. It

also prohibits imposition of a higher tax on electronic commerce than on the same

transactions accomplished by other means. "For example, a state could not impose a 7

percent sales tax on sales of flowers via the Internet where it imposes a 5 percent tax on

sales from a local flower shop" [HAR98].

The ITFA also provides provisions that clarify the sales and use tax liability of

online entities. States cannot impose a remote seller to collect sales tax if "the sole ability

to access a site on a remote seller's out-of-state computer server is considered a factor in

determining a remote seller's tax collection obligation..." [HAR98]. For example,

consider a Washington based sports equipment company xsports.com that has its online

shopping web site hosted on its servers located in Washington. The fact that its website is

accessible in Nevada or any other state cannot be used to determine if the company has

nexus in these states. A similar rule applies to ISPs. This concept is central to the

definition of e-commerce taxation. However, the ITFA does not explore the situation

where xsports.com's website is hosted on a server located in Nevada. Presumably,

Nevada can interpret the ITFA to find that xsports.com does have sufficient nexus as a

result of the server [HAR98].

However, one of the only instances that the ITFA's 'discriminatory tax' guideline

was interpreted was in a private ruling made by the Web friendly state of Virginia (home

of AOL), which ruled that "a Web site, hosted on a server in Virginia does not by itself

result in sales tax nexus in that state" [HAROOa].









The ITFA also prevents states from imposing an obligation to collect or pay the tax

on a different person or entity than in the case of equivalent transactions of goods and

services accomplished by other means. For example, owing to xsports.com servers and

administration in the state of Washington, it is deemed that it has nexus in that state.

Consider sports an unrelated specialty company that sports hosts and services on the

same server that it uses. The company sports does not have nexus in Washington.

Though Washington can enforce sports collection of sales and use tax on items exports

sells to Washington residents, it cannot compel sports to collect sales and use tax on

behalf of sports for the sales sports makes to Washington customers.

Perhaps owing to the glamour inherent in its name (Tax Freedom), the ITFA has

been a source of misunderstanding and hype since it's inception. The belief that anything

sold over the Internet is free of sales tax has been perpetuated either intentionally or

unintentionally [HAR01b]. Online companies have always been responsible for "sales

tax" in states that they have sufficient nexus in and therefore have always collected tax

from their in-state customers. As for the states that the online companies did not have

nexus in, the buyers were responsible for filing a 'use tax' to their state's tax authority.

Such a responsibility often imposes a burden on individuals that goes beyond a

reasonable expectation of their diligence, organization, and effort. Most people that shop

on the internet are unaware of this responsibility-partly due to online companies not

stating as much so their products will appear cheaper, but mostly due to non-enforcement

of this requirement.

The ITFA deserves much credit in the establishment of the Advisory Commission

on Electronic Commerce [HAR98].














APPENDIX C
ADVISORY COMMISSION ON ELECTRIC COMMERCE (ACEC)

The advisory commission was to conduct a thorough study of federal, state, local,

and international taxation and tariff treatment of transactions using the Internet. Its report

and recommendations were to be submitted to congress in June 2000. The ACEC, chaired

by Virginia governor James S. Gilmore, III, an anti-tax advocate, submitted its report and

recommendations, well ahead of schedule in April 2000. On perusing the report, it might

be observed that the formal findings and recommendations dealt with safe and broad

issues (privacy, digital divide). The real, industry-changing issues (sales and use tax) that

congress would have needed guidance on, rallied only a "majority vote." Out of the 19

member committee, there were 7 abstentions for each of the majority vote proposals

(listed below). The abstentions could probably be interpreted due to a lack of clear

information on what is essentially an evolving, contentious issue [ADVOO]. The

following is a reproduction of the ACEC's majority vote proposals.

The ACEC's majority vote proposal on Sales and Use Taxes [ADVOO]

1) For a period of five years, extend the current moratorium barring multiple and
discriminatory taxation of e-commerce and prohibit taxation of sales of digitized
goods and products and their non-digitized counterparts;

2) Clarify that the following factors would not, in and of themselves, establish a
seller's physical presence in a state for purposes of determining whether a seller
has sufficient nexus with that state to impose collection obligations:
a. a seller's use of an Internet service provider (ISP ) that has physical presence
in a state

b. the placement of a seller's digital data on a server located in that particular
state

c. a seller's use of telecommunications services provided by a
telecommunications provider that has physical presence in that state
63










d. a seller's ownership of intangible property that is used or is present in that
state

e. the presence of a seller's customers in a state

f. a seller's affiliation with another taxpayer that has physical presence in that
state

g. the performance of repair or warranty services with respect to property sold by
a seller that does not otherwise have physical presence in that state

h. a contractual relationship between a seller and another party located within
that state that permits goods or products purchased through the seller's Web
site or catalogue to be returned to the other party's physical location within
that state; and

i. the advertisement of a seller's business location, telephone number, and Web
site address.

3) Encourage state and local governments to work with and through NCCUSL in
drafting a uniform sales and use tax act within three years after the expiration of
the current Internet Tax Freedom Act moratorium (i.e., by October 21, 2004) that
would simplify state and local sales and use taxation policies so as to create and
maintain parity of collection costs (net of vendor discounts) between remote
sellers and comparable single-jurisdiction vendors that do not offer remote sales,
including providing the following
a. uniform tax base definitions

b. uniform vendor discount

c. uniform and simple sourcing rules

d. one sales and use tax rate per state and uniform limitations on state rate
changes

e. uniform audit procedures

f. uniform tax returns/forms

g. uniform electronic filing and remittance methods

h. uniform exemption administration rules (including a database of all exempt
entities to determine exemption status)

i. a methodology for approving software that sellers may rely on to determine
state sales tax rates









j. a methodology for maintaining revenue neutrality in overall sales and use tax
collections within each state (such as reducing the state-wide sales tax rate) to
account for any increased revenues collected (on a voluntary basis or
otherwise) from remote sales.

4) Formation of advisory commission and reports to congress:
a. Establish a new advisory commission responsible for oversight of the progress
of NCCUSL's efforts to create a uniform sales and use tax act.

b. Within six months after the completion ofNCCUSL s work, the commission
shall transmit to Congress for its consideration a report containing the
following
(i) findings, for the period from 1999 through 2004, regarding the growth of
e-commerce, the impact of e-commerce on traditional retailers, and the
impact of remote sales on state tax revenues

(ii) an assessment of whether the uniform sales and use tax act meets the
standards listed in (3)(a) through (j) above

(iii)an assessment of whether the adoption of the uniform sales and use tax act
would result in equal tax collection burdens (net of vendor discounts)
for remote sellers and comparable single-jurisdiction vendors that do
not offer remote sales

(iv)an assessment of whether requiring all remote sellers to collect and remit
sales and use taxes to those states that adopt the uniform sales and use
tax act would impose any unreasonable burden on interstate commerce
or would otherwise adversely impact economic growth and activity
through remote electronic channels

(v) a recommendation as to whether states that adopt the uniform sales and
use tax act should be permitted to collect sales and use taxes on all
remote sales; and

(vi)any other recommendations as required to address the findings of the
commission's report [ADVOO].

Such an advisory commission was not instated by congress but the states and local

governments moved to independently work on a streamlined sales tax project (SSTP).














APPENDIX D
STREAMLINED SALES TAX PROJECT (SSTP) EXECUTIVE SUMMARY.

The following document is reproduced from the executive summary of the SSTP

available online at the SSTP website:www.strealinedsalestax.org [SST02b].

The Streamlined Sales Tax Project is an effort created by state governments, with

input from local governments and the private sector, to simplify and modernize sales and

use tax collection and administration. The Project's proposals include tax law

simplifications, more efficient administrative procedures, and emerging technologies to

substantially reduce the burden of tax collection. The Project's proposals are focused on

improving sales and use tax administration systems for both Main Street and remote

sellers for all types of commerce.

Thirty-nine states and the District of Columbia are involved in the Project. Thirty-

four states and the District of Columbia are voting participants in the Project because

their legislators have enacted enabling legislation or their governors have issued

executive orders or similar authorizations. Five states are non-voting participants in the

work of the Project because they do not have the formal commitment of the state

executive or legislative branches, but are still participating. Forty-five states and the

District of Columbia impose a sales and use tax.

The Project was organized in March 2000. The Project is conducting its work

through a steering committee with co-chairs, four work groups, and a number of sub-

groups. Project participants are generally state revenue department administrators but

there are also representatives of state legislatures and local governments. Businesses









including national retailers, trade associations, manufacturers, direct marketers,

technology companies, and others have actively participated in the project by offering

expertise and input, reviewing proposals, suggesting language, and testifying at public

hearings.

The goal of the Streamlined Sales Tax Project is to provide states with a

Streamlined Sales Tax System that includes the following key features

Uniform definitions within tax laws. Legislatures still choose what is taxable or
exempt in their state. However, participating states will agree to use the common
definitions for key items in the tax base and will not deviate from these
definitions. As states move from their current definitions to the Project's
definitions, a certain amount of impact on state revenues is inevitable. However, it
is the intent of the Project to provide states with the ability to closely mirror their
existing tax bases through common definitions.

Rate simplification. States will be allowed one state rate. Local jurisdictions will
be allowed one local rate. A state or local government may not choose to tax food
at one rate and all other items of tangible personal property or taxable services at
another rate. State and local governments will accept responsibility for notice of
rate and boundary changes at restricted times.

State tax administration of all state and local taxes. Businesses will no longer file
tax returns with each local government within which it conducts business in a
state. States will be responsible for the administration of all state and local taxes
and the distribution of the local taxes to the local governments. A state and its
local governments will use common tax bases.

Uniform sourcing rules. The states will have uniform and simple rules as to how
they will source transactions to state and local governments. The uniform rules
will be destination/delivery based and uniform for tangible personal property,
digital property, and services.

Simplified exemption administration for use- and entity-based exemptions. Sellers
are relieved of the "good faith" requirements that exist in current law and will not
be liable for uncollected tax. Purchasers will be responsible for paying the tax,
interest, and penalties for claiming incorrect exemptions. States will have a
uniform exemption certificate in paper and electronic form.

Uniform audit procedures. Sellers who participate in one of the certified
Streamlined Sales Tax System technology models will either not be audited or
will have limited scope audits, depending on the technology model used. The
states may conduct joint audits of large multi-state businesses.









State funding of the system. To reduce the financial burdens on sellers, states will
assume responsibility for funding some of the technology models. The states are
also participating in a joint business-government study of the costs of collection
on sellers.

The Project proposes that states change their sales and use tax laws to conform with

the simplifications as proposed by the project. Thus, the simplifications would apply to

all sellers. Participation in the Streamlined Sales Tax System is voluntary for sellers who

do not have a physical presence or "nexus" with a state unless Congress chooses to

require collection from all sellers for all types of commerce. Also, registration by sellers

to voluntarily collect sales and use taxes will not infer that the business must collect

business activity taxes, such as the corporate franchise or income tax.

The Streamlined Sales Tax System will provide sellers the opportunity to use one

of three technology models. A seller may use Model 1 where a Certified Service

Provider, compensated by the states, will perform all of the seller's sales tax functions. A

seller may use Model 2, a Certified Automated System, to perform only the tax

calculation function. A larger seller with nationwide sales that has developed its own

proprietary sales tax software may use Model 3 and have its own system certified by the

states collectively. However, some sellers may choose to continue to use their current

systems and still enjoy the benefits of the Project's simplifications.

The Streamlined Sales Tax Project envisions two components to the legislation

necessary to accomplish the Project's goals. First, states would adopt enabling legislation

referred to as the Uniform Sales and Use Tax Administration Act ("Act"). The Act allows

the state to enter into an agreement with one or more states to simplify and modernize

sales and use tax administration in order to reduce the burden of tax compliance for all









sellers and all types of commerce. The Act does not require any amendments to a state's

sales and use tax law.

Secondly, states would amend or modify their sales and use tax laws to achieve the

simplifications and uniformity required by the participating states working together. The

Project refers to this legislation as the Streamlined Sales and Use Tax Agreement

("Agreement"). Some states will require only minor changes to current law to implement

the requirements of the Agreement. Other states with more complicated sales tax laws

may require significant changes to current law to be in accord with the Agreement.

A certificate of compliance will document each state's compliance with the

provisions of the Agreement and cite applicable statutes, regulations or other authorities

supporting such compliance. Public notice and comment will be provided before a state

becomes part of the interstate Agreement. A state is expected to be in compliance with

the requirements of the Agreement and to never substantially deviate from the

requirements of the Agreement. If a state does substantially deviate, it will not be

accepted into the interstate Agreement or will be expelled by the other participating

states. In a voluntary system, sellers who are voluntarily collecting sales taxes for

participating states may decide to no longer collect for the expelled state. Also, that state

would not have a vote on changes in the Agreement.

As of July 2002, thirty-five states and the District of Columbia have enacted the

Act. These states are considered the "Implementing States" and will control the

provisions of the initial Agreement. Adoption of the Agreement will require an

affirmative vote of three-fifths of the Implementing States. On all other matters (e.g.,

amendments to the Agreement), action is final by majority vote. Matters involving









interpretation of the Agreement may be brought before the Implementing States acting

jointly. The Implementing States acting jointly are empowered to issue an interpretation

of the Agreement, subject to approval by a majority of the states. An advisory council,

including representatives from business, will advise Implementing States.

It is anticipated that states that enact the provisions of the Agreement as approved

by the Implementing States in the summer of 2002 will continue as the governing states

of the interstate Agreement of the future.

The project website is www.streamlinedsalestax.org.














APPENDIX E
NETWORK MESSAGE PASSING SCENARIOS

Figure F.1 illustrates some of the scenarios that the UDP based message protocol

generates. The text below explains the implementation significance of each scenario and

is provided for documentation purposes. Future work includes fixing the problems

identified with a caution note, along with the functionality to report to higher modules

that take alternate courses of action.























Figure E. 1 Scenarios with passing Query and Query-Acknowledgement. A) Ideal world
example: The Query is sent, received, and acknowledged without delays. The
CSP processes the Query and sends across a Reply, which is received and
acknowledged without delay. B) Query lost: Q is sent 5 times before
Dispatcher gives up. Higher module to be notified. C) Q-Ack lost:
Duplicate queries at CSP site area added to the StationHash. sHash, if
one is present already, no harm done. D) Duplicate Q-ACK: Duplicate acks
are inserted into Dispatcher. ackHash as long as
TransactionManagement has the transactionID still active (no
harm done). Caution: ackHash is not cleared. E) Delayed-duplicate Q-ACK:
It is presumed TransactionManagement does not have the
transactionID still alive, the ack is NOT inserted. Caution: ackHash is
not cleared. F) Delayed-duplicate Q: The incoming duplicate Q is counted as a
fresh Q: caution.
















SELLER


delayed
duplicate
R


C. Delayed-duplicate R


D. Duplicate R-ACK


E. Delayed-duplicate R-ACK


timeout


timeout


R-ACK

R-ACK


A. R lost


timeout


R


R-ACK
R


R-ACK


timeout


duplicate R


duplicate
R-ACK


B. Duplicate R


SELLER

























Figure E.2 Scenarios with passing Reply and Reply-Acknowledgement. A) R lost:
Replies are sent by the TaxDispatcher 5 times before giving up. Higher
module to be notified. B) Duplicate R: Duplicate replies are discarded if an
entry with the same transactionID is already present. C) Delayed-
duplicate R: Duplicate replies are discarded as the entry is still available in the
ExtractorHandler. receivedType2DocHash. Caution: The hash
table is not being cleared. D) Duplicate R-ACK: The duplicate ack is inserted
into TaxDispatcher. ackHash: caution. E) Delayed-duplicate R-ACK:
Delayed, duplicate acks are inserted into TaxDispatcher. ackHash













CSP SELLER


0

Q-ACK

R

R-ACK


A. Ideal world example


X




Q-ACK


Stimeout


B. Query lost


SELLER




timeout





duplicate
Q-ACK


D. Duplicate Q-ACK


] timeout






delayed-duplicate
Q-ACK


E. Delayed-duplicate Q-ACK


Q removed ___
from sHash
delayed-duplicate
Q


F. Delayed-duplicate Q


0
Q-ACK



Q-ACK


duplicate Q


Stimeout


C. Q-ACK lost














APPENDIX F
DEFINITIONS OF TERMS

TaxML

XML is used to transfer information about transactions between the CSP and its

clients, the sellers. A DTD defines a standard structure for the query that all sellers must

conform to when requesting tax information from a CSP. The CSP returns information in

another XML document (reply) that conforms to the same DTD. The prescribed DTD is

called the TaxML DTD and documents that conform to it (query and reply) are called

TaxML documents.

Certified Service Provider-CSP

The certified service provider is defined by the Streamlined Sales Tax Project as a

certified third party firm that provides a technological mechanism to enable sellers to

look up taxes for items they are selling, and for consequently transferring the tax

calculated to the CSP's bank. The CSP's tax server that sellers connect to, and are

returned tax information is frequently identified in the text of this report simply as the

CSP. The SSTP agreement states that a CSP will file periodic returns to various

jurisdictions. Tax is remitted after debiting a portion of the collected taxes as a servicing

fee (cost of collection). The sellers are absolved of remitting taxes directly to the taxing

jurisdictions and from audits as long as they have represented the goods they sought tax

information on correctly.









Participating States Portal-PSP

States have come together to participate in the Streamlined Sales Tax Project either

as direct participants or as observers. When five participant states have legislative

approval of the tax simplifications and other mechanisms outlined in the SSTP

agreement, the same goes into effect and is deemed to be binding in these five states. The

agreement outlines a centralized mechanism for some administrative tasks such as having

customers register for exemptions at a central location, or for sellers to register

themselves using a single form etc. The central location where such forms can be found is

at the Participating States Portal. The term PSP is not part of the SSTP terminology but

the recommendation for a centralized mechanism is.















LIST OF REFERENCES


[ADV86] Advisory Commission On Intergovernmental Relations. "State and local
taxation of out-of-state mail order sales." U.S. Government Printing Office,
Washington, D.C.: 1986

[ADVOO] Advisory Commission on Electronic Commerce. "Report to congress."
http://www.ecommercecommission.org/report.htm, 2000. Accessed Feb 21, 2001

[HAR98] Hardesty, David. "Internet Tax Freedom Act."
http://www.ecommercetax.com/doc/102198.htm, Oct 21, 1998. Accessed Feb 21,
2001

[HAR00a] Hardesty, David. "Web server does not create nexus in Virginia."
http://www.ecommercetax.com/doc/073000.htm, Jul 30, 2000. Accessed Feb 21,
2001

[HAROOb] Hardesty, David. "Road rules for the streamlined stales tax."
http://www.ecommercetax.com/doc/123100.htm, Dec 31, 2000. Accessed Feb 21,
2001

[HAR01a] Hardesty, David. "Streamlined sales tax gets
political."http://www.ecommercetax.com/doc/021101 .htm, Feb 11, 2001.
Accessed Feb 21, 2001

[HAR01b] Hardesty, David. "Is it time for congress to act on sales tax?"
http://www.ecommercetax.com/doc/031101.htm, Mar 11, 2001. Accessed Jun 15,
2001

[SST02a] Streamlined Sales Tax Project. "Public-private sector study of cost of
collecting state and local sales and use taxes."
http://www.geocities.com/streamlined2000/.Accessed Sep 10, 2002

[SST02b] Streamlined Sales Tax Project. "Executive summary."
http://www.geocities.com/streamlined2000/. Accessed Sep 10, 2002















BIOGRAPHICAL SKETCH

Manav Chimakurthi was born and raised in India. His schooling from 6th grade

through 12th grade was at Bhavans Gandhi Vidyashram, a small school in the Annamalai

mountain range in South India. He attended the College of Management Studies at

GITAM, Vishakapatnam, where he received a bachelor's in business management in

1995. His received his second degree, a master's diploma in journalism and mass

communication, from Symbiosis, Pune.

His first career as a copywriter in Pune and then in Hyderabad found him work at

advertising agencies and design houses in these cities. While attending the University of

Florida in August, 1997, his growing interest in computer science precipitated a career

shift to the field. He commenced his studies towards a master's in computer science at

Computer and Information Sciences and Engineering Department (CISE) in spring 1999.

Nurturing an interest in technologies that can be applied to find feasible solutions to real

world problems on the Internet, he pursued his current research work. His other interests

lie in the field of delivering educational content over the Internet using interactive

technologies.