|UFDC Home||myUFDC Home | Help|
This item has the following downloads:
AN ARCHITECTURE FOR A CERTIFIED SERVICE PROVIDER (CSP) TO
COLLECT SALES AND USE TAX FROM ONLINE COMMERCIAL
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
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
A C K N O W L E D G M E N T S ................................................................................................. iv
LIST OF FIGURES .................. ............ ............................. viii
ABSTRACT ........ .............. ............. ...... ...................... ix
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
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
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
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.
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
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.
OVERVIEW OF ONLINE SALES TAX COLLECTION ISSUES, LANDMARKS,
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
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.
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.
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
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].
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
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
been done to move the process from the tax administrators' realm to that of the
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
ARCHITECTURE OF THE CERTIFIED SERVICE PROVIDER (CSP) TAX
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
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.
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.
CSP Certified Service Provider
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.
CSP's Thin Network
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.
TaxML TaxML document
document from CSP
CSP stand-alone module: Database Log
thin network client Transfer
Objects 'XML text'
o'XMLtext to objects
Dispatcher Extractor Handler
TaKInfo Reply Objects:
a ns, tax, exemption
Transaction 1 status and notes Funds Verification
L --. I Transaction
TaxInfo Query Objects:
items, use locations,
User and transaction Seller Site
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
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.
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
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).
ion Obects to 'XML text'
Exemp Q Tax dispatcher
statufrm tc. TaxInfo Reply
| | Objects
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
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
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
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
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.
version Interface for
tags on provided.
Table 4.1 (continued)
Multiple Taxing Tax Caps and Confidentiality
locations of jurisdiction Holidays thresholds
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
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
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
being and audits in
shipped case of
to/used in irregularities.
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
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
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).
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
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
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
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.
Quantity (in cases) Tax Rate
1 600 6%
601 1000 2%
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.
Quantity (in liters) Tax Rate
1 20 2%
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
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
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
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.
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.
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
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
This translates to an object called TaxInfo as defined below:
Buyer buyer = new Buyer();
Seller seller = new Seller();
JurisdictionTaxAggregate 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
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'
SReply type Taxinfo 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. 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 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.
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.
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 is a data holder class that maintains static hashtables of
transactionID related information.
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 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.
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
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.
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.
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
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. j ava is a wrapper class representing an individual character of
information in a document.
Scanner j ava decomposes a document fed to it into tokens.
Extracter j ava takes a vector of tokens and extracts TaxInfo object (query
or reply) from it.
Converter j ava takes a query or reply type TaxInfo object and creates a
TaxML query or reply type document respectively.
Dgram. java is a general datagram utility class that creates a Datagram, given
Configuration Files and Classes
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
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.
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.
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.
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.
NewUser is used by new users wanting to register with the seller as a customer at
Used by the Participating States Portal, BuyerInterface handles interaction
with buyers seeking exemptions.
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.
The CSP uses this interface to keep track of the various transactions, jurisdictions,
and sellers that interact with it.
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.
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.
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).
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.
Used by the BuyerInterface at the Participating States Portal, BuyerInfo
holds information on the exemption request being made by the buyer.
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 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 is used by the CSPInterface.
CreditCard abstracts a real world credit card.
Address abstracts a real world address.
Customer Item abstracts an item listed for sale at the seller's site.
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.
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.
Exempt ion Item holds exemption related data for a particular item.
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
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.
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
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 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
deiverylocation zip="32609" useication="32609" quantity="1.0" /> /
(7) @ (a
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
7) taxbasecode is the code that that item maps to from the standardized tax base
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.
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
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
16) Transaction time is tracked to the nearest second.
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
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
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
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.
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].
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
c. a seller's use of telecommunications services provided by a
telecommunications provider that has physical presence in that state
d. a seller's ownership of intangible property that is used or is present in that
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
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
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
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
(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).
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
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
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.
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.
C. Delayed-duplicate R
D. Duplicate R-ACK
E. Delayed-duplicate R-ACK
A. R lost
B. Duplicate R
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
A. Ideal world example
B. Query lost
D. Duplicate Q-ACK
E. Delayed-duplicate Q-ACK
Q removed ___
F. Delayed-duplicate Q
C. Q-ACK lost
DEFINITIONS OF TERMS
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
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,
[HAR00a] Hardesty, David. "Web server does not create nexus in Virginia."
http://www.ecommercetax.com/doc/073000.htm, Jul 30, 2000. Accessed Feb 21,
[HAROOb] Hardesty, David. "Road rules for the streamlined stales tax."
http://www.ecommercetax.com/doc/123100.htm, Dec 31, 2000. Accessed Feb 21,
[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,
[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
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