Ah yes, taxes/fees, etc. Here in the US, taxes and regulatory fees are interesting to say the least and getting even more on a daily basis...
The current method of implementing the taxes simply does not work. Applying taxes globally at the client level, does not satisfy the needs of any provider in the US. Because of the intricacies of the line items and what taxes apply to each, the global customer level approach doesn't cut it. The taxes need to be applied at the product/services/rates levels.
Basically, I guess I'm looking for say 3 levels of taxes that can be applied to a product. TaxA, TaxB, TaxC. Each of these would be one of the above, say 1 federal, 1 state, 1 local. At the product level we would select TaxA and the State/Local (TaxB/C) ones would change based on the customer's billing location. I don't know if this would work for those of you in other states (we're in Florida), but I think it would for the most part.
Take a look at the monthly report we need for Florida -
http://dor.myflorida.com/dor/forms/2010 ... 6_0110.pdf - it may help.
Here's the way I think it could be implemented, by those much more capable than I...
- Global/Universal Settings
+ Markets - This would allow the users to define what markets each product/service is available in. Market could be US, EU, etc. Maybe a global flag to use or not use would allow those not interested to skip...
+ Tax A - This would be the top level, say Federal Taxes. These would be locked down to the market, so as the products/customers are separated into Markets, the levels would be defined.
+ Tax B - State Taxes - Each State has a communications tax, and this would be assigned at the Customer level.
+ Tax C - Local Taxes - Each of the States is broken down into Local regions. The problem here is that between Tax B and Tax C is a County, or at least in Florida there is and there's 67 of them. Each county needs to be broken down individually when reporting the taxes that were collected.
+ Locations - A Hierarchical structure belonging to Markets that would allow admins to separate customer locations. For example, here in the US, I would want to define the State, County, and City/Municipality. Here in Florida, Miami-Dade County has over 30 different taxing districts (rates) for the Local portion of the tax, Tax C
+ LATAs - This would allow us to define the LATA that each customer is located in. This would allow local calling plans to include free calling in the customer's region. Lata's could be part of the structure above, but LATA's may include portions of counties, and may lead to duplication of counties.
+ The locations/Lata's above would each have a set of "local" prefixes. Some Lata's go down to the Exchange, when an area code is shared.
+ Each Location/Lata would have a "tax" level associated with each, or defined underneath it. These Tax levels (Federal/State/Local)could be defined elsewhere.
+ The tax levels (A-C) should also have start/end date. USF Fees for the second quarter are going up to 15.3 from 14.1. A method similar to the rates with an expiry would work.
+ Prefixes would allow selection of Market/Location/Lata so that reporting could be broken down by any of these.
- Each Customer would need to have:
+ A market/location/lata defined. This would allow the further selection of the location.
+ A tax location defined. The tax location would be the set of taxes that apply to this customer at "local" levels. In our case, the Local would be a State and a Local. This would correspond to a Tax B and Tax C.
+ A set of Local prefixes, so that all other prefixes are considered Long Distance. This would either override or append the Location's local settings.
- Each Product/Service would need to have:
+ A product may also be subject to no tax, as there are certain regulatory fees that can be recovered from the customer that do not incur taxes. So a taxable/non-taxable flag would also need to apply.
+ A set of applicable taxes. Because of the complexity of the taxes, each product would incur one level of Federal Tax, and then the State/Local Tax (if applicable), based on the customer's billing location.
- On the Invoices:
+ Taxes would need to be individually listed at the end of the invoice. Federal Tax, State Comm Tax, Local Comm Tax, USF. We don't need to identify what line items on the invoices they applied to, they just need to be broken down.
- Reports
+ Because the FCC USF fees are based on interstate/international usage based on the customers' billing location, we need to be sure that as a customer's inbound/outbound usage is billed/rated that we can later identify each customer's local/interstate traffic. In order to file the 499-Q forms, we need to know the international/interstate and local traffic for all customers according to each customer's usage.
+ Reports by Location. As VoIP Providers, you need to register to collect tax in each state you send a bill to.
This is going to be fun...
I'm willing to seriously contribute to this (at least $1k USD), if others are interested in "chipping" in, as any provider of interconnected VoIP in the US (Calling cards too) is going to be in a lot of heat, if they don't do taxes properly. Unfortunately, it's not as easy here in the US to slap a2billing together and start making money.
At this time, we are looking at some hosted solutions to import our CDR's and break the bills down for us. The headaches as we grow to manually separate the items out to bill the customers is starting to take up too much time.