Addsum web site and general info

Postings here will focus mainly on Advanced Accounting software updates, tips, and related topics. They will also include general comments relating to troubleshooting PC/Windows/network problems and may also include reference to our other software products and projects including any of our various utilities, or to the TAS Premier programming language. We considered setting up separate blogs for different topics so that users/others could subscribe to topics mostly aligned with their interests, but decided that it would be better to keep things simple since some topics cross over into others. We would nonetheless welcome your feedback/input in this regard. Our web site URL is Call us at 800-648-6258 or 801-277-9240. We also maintain so that older Business Tools users in particular have a greater chance to find us.


We highly recommend that accounting software users "follow" this blog via e-mail (enter your address and click on Submit below) or subscribe to a feed (see also below) as a way to keep current on the latest updates and accounting software news and information. You may also want to whitelist this e-mail address:

Follow by e-mail

Thursday, May 30, 2019

Next TAS Premier 7i release in progress

Even though we just published release 14 of the TAS Premier 7i series early last month, we've already almost added enough new features for a release 15.  Those changes are  now going into further testing and production and the documentation has already been updated.  While we normally don't publish more than one release each year, this year we are planning a second release by October.

Now that our supported xBase option is available as open source (and has been updated for other platforms) and also because we have been increasingly impressed by its performance, more features to support it have been indicated.  CodeBase files are dBase IV compatible and that driver, included with Windows, can be used to query them using SQL (and which is something that we have previously successfully tested with our own SQL query program). We have therefore added a CBDELETED() function which is able to return the total number of deleted records in the DBF format that we support (CodeBase).  This is important because the normal TRC() (total record count) function, unlike in a Btrieve/Pervasive/Actian ("Btrieve") file, includes deleted records, and so code that relies on that function could fail and/or work unexpectedly without a function that can be used to easily determine the actual number of "live" records in a DBF file.  That function has now been tested and implemented and is already in active use in a number of our projects.

Because the maintain database program uses the TRC() function to show active records, we have now been able to enhance it to show the number of deleted records in the event that a DBF or (*.C* file) is opened in that option.  This then allows the user to know what "net" active records are currently contained in the file, something that was not previously available.

Reindexing or "packing" the file can be used to permanently delete records in a DBF file. The DBF header record however is not decremented when a record is deleted. In order to determine the number of deleted records, the entire file does have to be internally scanned (which the CBDELETED() function automatically accomplishes based on the file handle passed to it) to determine the deleted record count. Use of this new function, therefore, involving DBF files with a large number of records has to be used with some level of care if used in an end user program. For this reason, in the maintain database enhancement, we make obtaining the deleted count an end user option rather than to automatically initiate it after the file is opened.

In the case of a Btrieve file, a deleted record takes up space but all of the fields are in essence blanked out (i.e. set to null values) and the active record count is maintained in the header record of the file.  So TRC() returns the active record count.  

In the course of adding the CBDELETED() function, we noticed that the OPEN_FILE_NAME() function was not returning the FILELOC path when a DBF file handle was passed to it, which it now does.  Previously it was only returning the data file name without any path.  When used with Btrieve files, it continues to return the fully qualified path.

And we also noticed that the GET_FILE_TYPE() function was internally being referenced as FILE_TYPE(), inconsistent with the documentation and the cmdtree.txt.  This has been fixed.

We have also reviewed and made minor updates to both the Btrieve and CodeBase reindex utilities which had not been previously reviewed since 2012, and have also updated the globally change utility to make it more intuitive with respect to changes made to it in release 14.

Also of significance, the EXEC_RB() function which loads the report designer has been enhanced so that developers can optionally pass an RTM name as a parameter.  This can include the full path, a relative path, or just the RTM name.   If a file name is passed, the RTM is then automatically loaded without the user having to take any other action to open it for review/editing.

As we continue to work with and test these latest changes, some additional changes may be added before release 15 is officially published later this year.

Friday, April 5, 2019

TAS Premier 7i release 14 published

Release 14, our 2019 release in the TAS Premier 7i series, is now available.

Addsum TAS Premier 7i r14 about screen

TAS Premier is a fully integrated 4GL programming language designed to work with either Btrieve (more modern versions referred to as Pervasive, PSQL, and/or Actian PSQL) data files or a highly performance optimized xBase derivative.  It includes program, screen and report editors plus data dictionary utilities, data maintenance options, and more.  More information.

The first release of TAS Premier 7i was in 2005.  Since then we have usually released an annual update related to cumulative improvements since the prior release.  This release then marks now some 14 years of 7i series updates.  TAS Premier 7i was in turn based on our 2004 release of TAS Professional 7, building on prior versions released by Business Tools, Inc. including TAS Professional 6 (first released in 2001).  Prior 16-bit versions of the TAS language evolved from Business Tools, Inc. products that date back to 1984.

Release 14 is primarily a maintenance update but includes some important updates and enhancements.

Some of the more notable changes:

The report designer has long had a DisplayFormat option (when right clicking on report objects, most notably numeric objects) which is primarily convenient for end user use (the report designer is a separate executable and can be called from within a licensed runtime).   This option is now available, particularly for numeric format changes; the available numeric and some other formatting options are also displayed and can be selected via the list box (see image below).  Simply click on the desired template (and optionally, manually edit it in the edit text box), click on OK, save the report layout, and then run the report program that uses it to see the results.

TAS Premier 7i r14 report designer

Display Format list box in TAS Premier 7i r14 report designer

The Encrypt File option now "remembers" the last file encrypted as well as the last encryption phase (in the same session and once they are entered the first time).  If the file is successfully encrypted, it no longer provides a "success" confirmation but instead the modal form immediately closes.  

TAS Premier 7i r14 Encrypt File

TP7EXECUTE.EXE has been enhanced and "Runtime" now has two options:  force and not forced.  "Not forced" works the same way as in the past; "forced" will force the runtime to run from the same directory specified and in essence overrides any registry settings (explanatory on-screen help also added);  also, the MRU list of recently chosen directories is now also available under a File menu option that wasn't previously visible, and will remember up to 16 prior entered paths.  For developers with multiple projects/folders, this program saves a significant amount of time, especially as it has now been enhanced.   

TP7EXECUTE.EXE included with TAS Premier 7i r14

The Globally Change utility (Change/Delete Records - called from Utilities then Import File/Globally Change) has been significantly enhanced and now includes record locking support (both when changing and deleting records) and the ability to specify keys and ranges (similar to Export File and Quick Report) allowing for vastly improved data maintenance performance.   Previously, regardless of the filter selected,  both the change/modify and delete options required a scan of the entire file. That is now no longer the case. Other screen enhancements have been made as well.

Other important changes/updates have also been made.

More information and download updates page (for users with a previously installed version)

New installation download (for new users/developers)

Thursday, March 28, 2019

Analyzing cash flows and payments in Advanced Accounting

 One of the financial statements that has long been available in the Advanced Accounting series including its predecessor versions is "Changes in Financial Position (Cash Flow)" sometimes referred to as "Sources and Uses of Cash" (or sometimes the word "Funds" instead of "Cash"), or simply as a Cash Flow Statement.

TAS-Books* 1987

TAS-Books* 1987 manual - Cash Flow Setup

Settings for the cash flow statement have typically followed the same approach as for the other two financial statements (balance sheet and income statement) but with with inclusion of an income/expense and non-cash expense range along with asset and liability sections.  When setting up a GL chart of account, the program has always had a "Non-Cash" flag, the sole use of which is in connection with the cash flow statement.  And this continues to be the case in all versions.

Books 2.0 and Advanced Accounting 3.0 looked and worked substantially the same as in TAS-Books* version, continuing with Advanced 4.0, 5.0 and 5.1. Graphical printing was added in version 6.0.  In 2010 in the 7i version, the suite of financial statements were "re-made" into a fuller graphical version with some additional new features.  The cash flow statement logic however remained basically the same through version 7i.  Starting with Adv 8 (2019 release) however it has been significantly changed.

Advanced Accounting 3.04 Cash Flow Setup

Advanced Accounting 5.1 Cash Flow Setup
While the Advanced Accounting cash flow statement option historically could be used to help predict cash flows and if run correctly could produce an accurate net cash change, it fell somewhat sort of performing as a true cash flow statement.  Using the so-called indirect method of preparing a cash flow statement is really sort of an upside down balance sheet with a twist:  it involves comparing a set of financial account values to some prior period (usually the immediately prior year, quarter, or month).   This was accomplished in past versions by a from to through month approach, and comparing the difference in the net balances in established ranges from the balances at the end of the from month to the end of the through month provided that the user did not "include beginning balances" but with no "proofing" of the change value computed to the actual increase/decrease in cash.

The idea of a cash flow statement is simply to show the increase or decrease of "cash" accounts (checking accounts, actual cash in a cash drawer or petty cash fund, money market accounts, merchant accounts, deposits in transit not yet delivered to the bank,  certificates of deposit, savings accounts and the like) from one period to the next.

The standard cash flow statement using the indirect method can also be thought of as a sort of a crude accrual to cash conversion starting with net income for a selected prior of time, making adjustments based on the differences in usually a prior balance sheet period, leading ultimately to a computed increase or decrease in cash relating to operating activities.

Cash flows from investing and financing activities are also normally identified in a cash flow statement.   This has not been the case with the Advanced Accounting software cash flow statement option, and we have elected to continue to combine those activities into the operating section for now since these are not normally materially significant activities for most of our users.

Since cash flow statements can be somewhat unintuitive to setup properly and confusing at times to read, we have taken steps to try to simplify the setup and to also make our own changes to the format which we think helps to better focus on understanding the increase/decrease in cash from one period to the next.  Further, now, the user cannot cause erroneous values to be computed if they choose "include beginning balances."  Instead, depending on that selection, the Adv 8 version produces either a "net balance" cash flow analysis as it has in the past (but with a new cash summary at the end with actual beginning and ending balances) or a "full balances" method that compares the difference in balances between two different time periods (the only complication with this approach is that an adjustment for the change in retained/current earnings between the two periods has to be made in order to accurately compute the cash change).

Advanced Accounting 8 Cash Flow Setup

Most users in fact would do well to simply always include in their balance sheet and income statements a "one year past" or similar comparison column with a third column that shows the dollar (and optionally percentage) differences.   Appropriately formatted side-by-side balance/income statements with a third "difference" column that Advanced Accounting has always provided are not only easy to read but include all of the information normally that a financial statement reader might require and if correctly formatted, clearly shows the increase or decrease in cash flows.   To some extent the cash flow statement then becomes largely redundant.

However in order to improve the current option, we have significantly redesigned how it works (but remaining in the same place as it always has been):

  • Income/loss is automatically calculated just like it is when printing a balance sheet and so the income/expense range in the setup option has been eliminated - this also solves issues relating to income/expense accounts not all having been establish in a contiguous range
  • A new "cash account" range in the setup has been added so that a full range analysis with or without detail can be provided at the end of the statement
  • Some additional on-screen help has been provided in the format setup to assist with establishing initial settings
  • When generating a cash flow statement, one of two entirely new report layouts are used that utilize different logic.   As in the past, the user can choose the from/through months and whether to include beginning balances (in older versions, that option should not be selected)
  • A new option allows the user to include detail or not.  Normally a cash flow statement is summarized and doesn't include the detail, so by default, "include account detail" is not checked but can be chosen for a higher level of analysis.  This is different than how the income/balance sheet options normally work (they always provide the detail).
  • Beginning and ending cash and other balances are provided in one of two different formats depending on whether the user is included balance forwards or not.  One of these is in a column presentation similar to how they would be viewed in a side-by-side balance sheet comparison which we believe makes them easier to understand.  The other includes not just beginning and ending balances but also the actual change in each account which can be displayed on a detail basis.
  • In the event the cash flow statement is out of balance (i.e. the net actual cash/increase differs from the cash account range) when choosing include beginning balances, the user is notified at the end of the report with some possible causes for the out of balance
  • We have intentionally, for now, limited the cash flow report to two years' worth of columns (plus a third different column if "Include Beginning Balance" is checked that is automatically generated without user interaction).  Income statements/balance sheets continue to be able to have any desired combinations of current to six year past amounts in up to four columns and the ability to specify a difference column.  In a future release we may provide an option for a 12 month column view/analysis for each of the three available financial statements.
Adv 8 GL-G Print Financial Statements - Cash Flow options

Adv 8 GL-G - new option for all statement types if  Edit Columns/Headers or add ending notes is checked

Adv 8 Cash Flow Statement report+ when "include beginning balance" is not checked:  net balances method

Adv 8 Cash Flow Statement report+ when "include beginning balance" is checked: new full balance method

Cash flows and payments can of course be analyzed in other ways.   Besides the obvious options in the general ledger detail for cash receipt and cash disbursement types by posting date or general account, customer payments can be analyzed both in the credit analysis report option as well as in the accounts receivable aging "as of date balance/transaction type history" where the output  can be limited to payments (and in the latest version, pay types can be further limited to one of six different types including checks, credit cards, cash, e-transfers, other and refunds).  Point-of-sale (POS) users of course have the additional POS report options that includes on specifically for payments and that can be narrowed down to not just date but also time and payment type.  On the vendor side, in addition to the accounts payable payment history option (which can include, exclude or only include electronic payments), the AP aging "as of date" option can be used to show only type "P" payments to determine the actual amounts paid to all or a given vendor for a desired date range.

*TAS-Books originated in the United States.  It was co-opted for use overseas and evolved into a completely separate product that was never officially licensed by the original publisher (Business Tools, Inc.).  TAS-Books was developed using the TAS-Plus (TAS+ 2.0) programming language also developed and published by Business Tools, Inc.  Later versions based on the TAS Professional 3.0 language were called Books and Advanced Accounting (which first included multi-location inventory tracking, among other things).   Since version 4.0, the accounting software has been referred to solely under the Advanced Accounting name/trademark but long-time users still sometimes refer to it as "Books."   The data files and program names going back to the TAS-Books version were consistently named starting with the letters "BK" (for example BKSOA.RUN for the sales order runtime program, BKARINV.M for the sales order header data file, later BKARINV.B) referencing the product's early beginnings as "Books."

+The data in the report samples is test data and not based on a real, balanced system, and is being shown solely to show what these reports look like with summarized data.  If the detail option was selected, then the individual account detail within each section would be displayed.

Wednesday, March 13, 2019

Btrieve status code 46

Your users may occasionally experience a Btrieve engine (which here includes the Pervasive and now Actian engines sometimes also referred to as PSQL) status code 46 which indicates that access to a given file ("table") is denied leading to the inability of the software to write to that file.   There are some straightforward reasons for this but also several that are non-intuitive.

A file that is marked as read only whether via user rights or because it was dragged/dropped from media that is read only is the most obvious cause, although usually isn't the cause.  Ensure that the user has both read/write rights (and since in some versions temporary files are created, the user needs delete rights to data folders as well).   Most commonly this happens when a new client PC is added to a network and the user's rights are insufficient.

File forced to be read only and the result when that file is attempted to be written to

Another issue could be an older formatted Btrieve file.  As users move forward to newer versions of the software and deploy newer Pervasive versions, some of their files may be in an older format that starting with Pervasive 9.x (now considered legacy since the latest version currently is v13 released in 2017), Btrieve 5.x and older files can be read but not written to until they are rebuilt (or "reindexed") into a newer format (6.x or above but 9.5 is the usual standard even with later releases).   A rebuild utility is provided with the Actian/Pervasive engines and is the best way to resolve.  Our reindex program, as originally developed by Business Tools, can globally identify the format level of a user's files in a given company.

Older format causing status code 46 format determined via a BUTIL -STAT

Another possibility is the use of an owner name where an incorrect owner name is passed when the file is open.   While the underlying programming language supports owner names, owner names are normally not used in Advanced Accounting programs, and so this cause can normally be ruled out.

A mixture of Btrieve 6.15 and Pervasive/PSQL engines can lead to a status code 46.   The two engines cannot be used to access the same data files simultaneously.    Different PSQL various normally can be used safely together although it is best that all PC's use the same version.

The most difficult situation involves outside applications or processes that may be scanning,  copying or indexing the data files. We previously made brief mention of status code 46 issues with respect to online or live database backups and these are the the most common cause.

This issue has been known for sometime now but can be very difficult to troubleshoot, and it can lead to significant loss of data should it strike.  Typically we have something like four or five support calls every year where the end user has lost data as a result of a status code 46 issue, whether observed as such or not.  

The peculiarity relates to how the Btrieve API reacts to a file that is being copied or scanned and when it then tries to open that file while no other instances of that file are open by anyone.   If the file that is being copied or scanned was already open by the Btrieve engine on some client/workstation prior to initiation of the copying or scanning, there is no issue.   But if no user has the file open, and the copy or scan begins, and then the file is opened through say the accounting sofware, the Btrieve/Pervasive engine opens the file in a read only mode, and  that is not easily detectable.  Only later when typically a record is attempted to be saved to that file will the 46 result and usually in the middle of a posting process.  The user at that point is able to click on OK and continue.  And continue.  And each time OK is pressed, a record in that file is effectively "lost."  And once this starts to happen, a domino effect occurs to other users who try to access the file and write to it, and the 46 status remains until all instances of the file are closed (even though the copying or scanning process may have long since completed).

It is larger files that take longer to copy or scan that are the most vulnerable, and these often are also some of the more important files.  If all files were all opened all of the time, this kind of status code 46 could never  happen (placing all files in continuous operations mode avoids the problem for backup purposes, but places a heavy overhead on a system).  Keeping all of the files open all of the time however is normally very inefficient and isn't what happens in a typical Advanced Accounting program.  Files instead that are needed in a given program option are instead opened at the beginning of that option and they are automatically closed when that individually selected program option ends (or can be closed earlier programmatically).  This normal internal structure combined wiht the behavior of the Btrieve API can, albeit under somewhat rare circumstances,  lead to situations where no files are opened by anyone and then suddenly an online backup or anti-virus scan of some kind starts just before a user than starts a program than opens that same file, and it if is a file that is later written to or deleted (such as in a posting program), status code 46's can result.

Anti-virus software has been suspected of triggering this issue.  Your data file folders should be excluded from real time anti-virus scanning (data files cannot become infected, and  this is something that is desirable in any event because it will improve performance).  In our experience, the 46's have always been tied to some sort of backup or copy operation that was in progress when a user then unknowingly selected a posting program that opened the same file that was being copied, with no prior instances of the file having been opened by a Btrieve engine.

For one user that was having a problem when copying data files off late in the afternoon to laptops and another that was having nighttime backups taking longer and longer and were still running in the early morning hours (including 5.1 versions in fact), we added some logic when records were being saved to detect this issue.  But that doesn't prevent the problem in the first place and further when it happens, the user can't usually easily resolve the problem on their own.  Therefore we have recently implemented some new logic where we test the most exposed/larger files that are going to be written to in advance to detect if the file is being copied or is being accessed in some manner from outside of the software (and if the copy started before the file was opened by any accounting software user).   We have implemented this newer logic in the SO-G posting program in the latest versions of Advanced Accounting, and will be adding it to others. 

Note that when posting sales orders on the fly, the AR invoice header file (BKARHINV) is already open in Advanced Accounting because it is needed to check for previously assigned invoice numbers.  So when that sales order is then posted right after printing or a print preview, a status code 46 would never result but rather only when posting sales orders in a batch (normally a good thing).  The general ledger transaction file (BKGLTRAN) in either case however would still be vulnerable and that is a file that we also "pre-check."

How can you avoid status code 46's in the situation as last discussed above? 

 (1) Exclude data files from being scanned in real-time.   As noted, it can actually be helpful to have other users utilizing the software keep certain files open during posting processes that can, counterintuitively, help with  this access denied status code (although they can create other problems by locking customer or inventory location records).

(2)  Use of continuous operations mode can also help to avoid the issue.  But most importantly, ensure that scheduled backups are taking place well outside of normal operation times and monitor them to ensure they don't start to creep into the early morning hours.

Note: if you are making a manual backup copy of a file on a system that is live and that is fairly large in size and will take more than a few seconds to copy, it is actually safest to first open that file (either in maintain database or in some program that you know opens it)  prior to making the copy.  Otherwise your file copy request, if the file is large enough, could cause a live user to experience a status code 46.

Thursday, February 28, 2019

Screen ghosting and Chrome browser

Recently we started to notice a screen ghosting issue on a Windows 7 Pro 64-bit PC.  The PC has been in use for some time but the issue had started to worsen.  The "ghosting" issue as referred to here relates to an artifact of the prior screen or window remaining visible for some period of time after a screen has been moved or closed.  It might also be described as a "lag" or as a screen display/refresh issue.

Since a Google Chrome browser with the latest updates was normally always loaded and active running in the background on this PC, we didn't have a reason to suspect the browser as the cause, but when closing the browser, we noticed that  the screen ghosting problem stopped.  It also stops we realized when the browser is minimized.

Investigating further, it appeared to be possibly related to a setting in Chrome relating to hardware acceleration.  The specific setting is at (with the browser launched and having focus):

ALT-F (hold down ALT then press F and release - or in the upper right hand corner of the browser window, click on the round button with three dots)


Scroll down and clicked on Advanced

Scroll down to the System section

Slide the Use hardware acceleration when available option to the left to turn it off

Click on Relaunch


Hardware acceleration off

At first it seemed like this resolved the issue on this particular desktop PC.

But no.   We noticed that the "ghosting"  still occurred when the browser window was in the background of another application's window.  Minimize the Chrome browser window behind, and the behavior disappears.

There have been suggestions made elsewhere about also clearing the Chrome cache, and running  ipconfig /flushdns and netsh winsock reset at the command (cmd) line and re-booting.  The Chrome cache is regularly cleared from this PC. Clearing the cache did not change the behavior.   So we then ran the ipconfig and netsh commands (but with low expectations) and re-booted. 

The problem remains and must relate to some other Chrome setting.  

 Knowing that the ghosting problem seems to fully disappear when Chrome is minimized helps help to manage this annoying behavior which we've been unable to duplicate using any other combination of running programs.

Monday, December 31, 2018

2018 year end and upcoming changes

We will be posting information about 2018 year end payroll processing including W-2's, upcoming federal and state changes including the new state of Washington tax for medical/sick leave, 1095 issues and more here shortly.

Friday, November 30, 2018

Colorado and South Dakota sales tax changes likely mean higher costs for all

The Colorado Department of Revenue earlier this month announced changes that would be going into effect December 1, 2018 (but has now provided a grace period through March 31, 2019 for retailers to implement those changes).   South Dakota has implemented new changes as of November 1, 2018 as a result of a recent Supreme Court decision (see more below) relating to sales tax collection by remote sellers.

South Dakota does not have a state income tax, unlike Colorado, and so relies quite heavily on sales tax revenue.   South Dakota, unlike Colorado, has been one of the 24 member streamlined sales tax states.  There are however some 45 states that have state sales taxes.  The current exceptions are Alaska (although some cities/municipalities have their own separate sales tax)Delaware, Montana, New Hampshire, and Oregon.

In the discussion that follows, "in state" is meant to refer to a business that has a physical presence or nexus in that state; "out of state" is meant to indicate a business that conducts business in the state but that does not have a physical presence.

It should be noted that goods shipped regardless of origin to a Colorado or South Dakota reseller remain exempt from sales tax, i.e. nothing has changed in that regard.

Some brief background

In Quill Corp. vs. North Dakota the Supreme Court in 1992 affirmed the longstanding rule that a state could not collect sales taxes from an out of state company that did not have a physical presence in that state.  And that approach has generally continued to be the rule ever since, although some states have made other agreements for sales tax handling  under voluntary agreements.  However just this year in a closely decided Supreme Court case involving this time South Dakota (see links with respect to the Supreme Court decision as reported by various sources at the end of this blog), the position of the court was flipped, and the floodgate has therefore opened for states to attempt to collect sales tax on "retail" sales made by out of state companies without a physical presence (nexus) in their state.

The potential nightmare for businesses

South Dakota had destination based sales tax rules for in-state retailers but Colorado has not.  The recent Supreme Court case emboldened Colorado to implement changes for out of state retailers at the same time as its making changes for in-state retailers.  So Colorado is also now switching to a point of destination concept for sales tax collection like many other states have, and also implementing rules for out of state retailers at the same time. Over 30 states have now changed to destination based sales taxes.

Colorado has historically been known to have notoriously complicated sales tax rules and regulations. The problem for Colorado businesses who either deliver or ship products to a Colorado address however is the sheer number of taxable jurisdictions (almost 700 of them compared to just over 100 for South Dakota).  The tax cannot be calculated based on the county of destination since there are many more tax jurisdictions than counties (even in the much simpler case of South Dakota, it has 40 more taxable districts than their 66 counties).  Zip codes are also largely useless in basing sales tax rates as well.

Sales tax compliance is already heavily burdening business of all sizes and has a significant cost.  Colorado already has one of the more complicated sales tax reporting forms of any state. The new requirement forces businesses to establish sales tax "locations" against which taxable sales and related information will now have to be reported.  

The important exception

Colorado has adopted the same rule as South Dakota for businesses without a physical presence.  Out of state or "remote sellers" that have less than  $100,000 in gross sales in the state AND fewer than 200  transactions, are excused from the requirement.  All others however will now have to follow essentially the same procedure as in-state retailers and procure and pay a small fee for a sales tax license in either state (plus also a small advance deposit in Colorado) and will have to compute sales tax based on the delivery address, charge it to the customer, and account for and remit/report the tax.  

Sellers of lower priced retail goods involving a higher volume of shipments could easily have a problem with the 200 transaction limit in either state.

What about shipping?

Different rules apply to shipping and delivery costs in these two states.  Sales tax applies to freight as a general rule in South Dakota for both in state and out of state businesses.  In Colorado it is a bit trickier.  If the delivery charge is separately itemized, it is exempt from sales tax if the purchaser (i.e. retail customer) could pick up the item at a location within the state (regardless of how inconvenient that might be).   If they can't, then freight/delivery/handling charges are subject to sales tax in Colorado.  This then targets "online shippers" i.e. out of state sellers.

These rules have not changed, but in light of the new rules that impact out of state businesses, they do come into play potentially in a new way.

Good news for local businesses?

Just about everyone is in favor of helping local businesses.  But the devil is in the details and the resulting overall impacts.  

The new changes may help some in-state businesses who compete against out-of-state "retailers" (i.e. companies that ship to retail customers) but the administrative and compliance burdens being placed on some of those same companies with a physical presence within Colorado and South Dakota potentially offsets those benefits. Further Colorado and South Dakota businesses shipping to states outside of Colorado will now have to deal with this same issue in reverse.  For some, the administrative hassle of shipping outside their local area may be a disincentive to do business there, leaving consumers with fewer available resources and less competition.   Some out of state sellers may have products that aren't otherwise readily available locally.

Business are already unpaid tax collectors for federal, state and local governments.  They do their best to meet the myriad requirements constantly being imposed on them and in the process have increased staff and technology costs to try to meet requirements such as those now being imposed by Colorado and South Dakota.  

Good news for consumers?

The pursuit of sales tax revenue from out of state companies leads to the perception that these business aren't paying their fair share. Yet these aren't taxes paid ultimately by business but in fact represent a tax increase on local residents.  It is the local residents of Colorado and South Dakota that are now being levied in essence a tax increase on certain interstate sales   Ingrained buying habits may not lead to any change in the near future in terms of how products are purchased.  The net result is that this is a tax increase and because of requirements being imposed on both in-state and out-state companies, product cost themselves may have to be increased to cover the additional overhead that businesses will incur.

Our preliminary conclusion

We think it may be a mistake to so quickly applaud the recent court decision as some have.  And we do not think that states should immediately start to implement draconian changes at this point with respect to out of state sellers. There could for example be congressional action as a result of the recent Supreme Court case based on the concept similar to taxation without representation, i.e. undue regulation without representation.  

Changes needed to be made, yes.   But was this in the end an efficient, better, streamlined approach?  Probably not.  Will these changes benefit local residents?  No, at least not in the short term.  Will these changes benefit businesses?  It could ultimately benefit some local businesses, however, some of the other changes and complex tax calculations and related reporting requirements will make doing business both for local and out of state "retailers" more costly and that means higher costs for consumers, and it could lead to higher prices even in the distribution/wholesale chain.

We constantly hear about tax simplification and reduction and instead we tend to experience simply the replacement of the old with a new equally convoluted system. 

At the very minimum, if a state imposes complex requirements as is now the case with Colorado, and to a lesser degree South Dakota, that state should provide completely free and simple means for businesses to determine what an applicable sales tax rate should be.  This means that the government agency itself must provide that service, or pay a third party to provide that service and make it available to anyone that does business in that state.   Business should not be forced to not only operate as unpaid tax collectors, meet filing requirements which are in many cases quite onerous, and be subjected to penalties and audits and ALSO be forced into paying for annual or monthly subscriptions to third parties in order to most efficiently and quickly lookup sales tax rates.   Free options with daily or similar limitations are also not acceptable.  

Rather than complicate already complex and in reality quite ugly sales tax collection requirements and systems in what is really a disguised tax increase, states would be better off looking at more uniform and equitable ways to raise revenues from their residents using the simplest possible approaches and in a much more transparent manner.   Sales taxes as currently implemented simply don't work fairly nor efficiently in today's world.

States should not look at themselves as separate countries which seems to be the trend.  We need much more consistent and uniform rules that apply to a country made up of states that should be much more united in their approaches to everything including taxation especially when it involves interstate and related commerce, and the fact that U.S. citizens travel and move quite frequently around the country.

Meanwhile for Advanced Accounting users

In the meantime, what are the options for Advanced Accounting software users?

Nothing changes for your customers that are resellers (unless in the case of Colorado they want non-taxable sales reported based on their six digit location code).  Resellers not normally subject to tax should continue to have their tax flag unchecked in AR-A View Customer Information.  Potential retail customers should continue to be flagged as being subject to tax.  One problematic issue is the tax authority. Ideally the tax authority should match the state's tax jurisdiction and its overall tax.  For businesses that deliver/ship to few locations (which is probably unlikely for most), then create new AR-L-A tax authorities with the appropriate total rate (don't worry about splitting that into districts) and linked to the appropriate vendor code and GL liability.  For customers with potentially many different jurisdictions and rates plus the fact that many customer will not necessarily be repeat customers an/or to efficiently handle new customer orders, a different approach may be needed.   Currently we have in progress several different tools to automatically obtain the sales tax rate based on the delivery address.  This will also have to be linked in a different or alternative way to the appropriate taxable jurisdiction.  It may also be necessary in some cases to allow the user to enter a manual tax rate (normally that is never the case) after the appropriate rate is determined manually on an interim basis.   Users are encouraged to contact us to discuss available options to streamline sales tax handling.

Some South Dakota Supreme Court references:

New York Times:






Colorado Dept of Revenue Sales Tax Basics and links:

South Dakota sales tax references:

Tax guide:

Remote seller bulletin:

Sales tax on shipping/delivery charges


South Dakota: