Interesting enough there are (at least thirteen; 02861, 42223, 59221, 63673, 71749, 73949, 81137, 84536, 86044, 86515, 88063, 89439 & 97635; anyone has fear of triskaidekaphobia?) zip codes that are multi states in the US!
I remember when I was working for an on-line retail rental place it was fun figuring out how much tax to charge -- some items on rental are taxed while some are not and even within that some line items are taxed (postage is) and some are not (insurance is not). And to add fun to that, within zip codes we had to consult street address because it could be in one county versus another county and then each county had their own process when they updated their tax schedule. The application was wired up to consult a well-known commercial vendor's system for tax calculations but even then the company used to get regular notices from counties on deficient tax remittance. Then there is the online purchase part where tax is based on where the item is delivered and not where it is purchased. This is one item that is better handled distributed by reporting in rather than centralized ... -----Original Message----- From: Michael or Penny Novack <[email protected]> Sent: Sunday, June 18, 2023 9:49 PM To: [email protected] Subject: Re: [GNC] automatically account for gst on random purchases On 6/18/2023 7:43 PM, flywire wrote: >> In looking for/expecting and automated solution you are thinking one >> should > be reasonable. ...I live in the US [which has complex GST] > > Yet surely it is reasonable for the automated GST functionality for > accrual accounting to apply to cash accounting. Even USA GST has > rules, so it could be automated. Yes indeed, sales tax(es) can be computed automatically even here in the US. But this is typically done by a POS system at the register and the result is fed to the general ledger system. Notice that "point" in "point of sales. That's because the correct tax amount depends on the point of sale (the where). The device (that thing that used to be just a "cash register) "knows" where it is. The product code is scanned in (or hand entered) and that is used to determine if taxable and at what rate. that gets sent to general ledger. Also that a widget with that code sold informs the inventory system to deduct one (and also send the "cost of good sold" to general ledger. Let's say you have a business located near Port Jarvis with three shops, one in NY, one in NJ, and one in PA (the three states meet there). The POS sales in each of those shops would be sending DIFFERENT tax amounts to general ledger. You are asking general ledger to do all of this (gnucash is a general ledger system). In that case MORE INFORMATION would be needed as part of each transaction. Not just things like date, amount, etc. but "legal location for this transaction" << for example, the location of the customer if a remote sale* >> Michael D Novack * BTW, I have yet to do business with any remote seller that does this correctly. They tend to use ZIP code, but ZIP code is NOT a reliable indication of the legal location of the address. Postal delivery routes do not respect state boundaries let alone more local political boundaries. My working days were spent in a financial industry where "contract state" WAS collected separately from "mail state" << because it was very important to be sure what state's laws would apply to the contract >> In other words, remote sellers really should "look up on a map" (mapping software) where that mailing address is actually located and not assume must be the same state/city as the PO that delivers mail to that address. _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
