We have been using KillBill for many years for our SaaS product.
While it is very nice to own our data, we have had a huge lot of issues with it too.
Beware that this is an "industrial" tool, meaning that it is very complex, written in Java, with a lot of quirks and sharp edges. The core team also seems to mainly work on some closed-source version of it, for some not-very-clear-what big corp(s). They let you know sometimes that there exists a more feature-full closed-source version when asking questions in the support google group or on github issues, but it's not very transparent.
If you are a startup with a small team or small budget and no real Java development skills, you'll probably want to be careful in considering to use it: many custom things you'll want to do will require contracting with one of their partners because it's too complicated to do yourself, and support will be limited, and debugging issues will be hugely complicated if you are not used to that tech stack...
Just this week, we have had a major issue with it: after doing an `apt upgrade`, docker was updated and restarted. It restarted KillBill's docker images fine but KillBill itself restarted only the Stripe plugin, not the Avatax one, for an unknown reason. So the tool happily generated invoices and payments for a few hours without any taxes (!), until we noticed and started the plugin manually from the interface. This is the kind of issues we regularly have to deal with, and while the tool does a good job most of the time, it is mindblowingly annoying sometimes.
> Kill Bill does not support taxes. Instead, we partner with Avalara to outsource tax compliance. Our AvaTax connector provides real-time and on-demand calculationsto prevent overcharging or undercharging tax.
I expected as much. Handling taxes internationally is a major PITA and it changes all the time as politicians get new ideas how to make things even more complicated. I'm pretty sure that many SaaS companies are unknowingly not compliant with all the rules.
No open source community has been able to convince enough programmers and tax lawyers to do such a supermassive amount of tedious and boring work for free. This is also an area where being 99.9% correct isn’t good enough and you’re working with thousands of insane clients who constantly change their APIs and specifications. You practically need to have a government or private business develop such a thing.
Oh, I don't know, if the data-structure was easy to understand (and contribute to) it might be fun to have a comprehensive representation of the tax code to play with. It's also a problem that lends itself to "local first" attempts - I can see an individual might try to encode rules about their local sales tax and property taxes.
Another approach would be to have a programming competition to see who can write the best in-browser, privacy respecting 2022 1040EZ application using nothing but html, css, svg, and javascript[0]. The end product should be capable of saving its state as a single json object, and producing a usable PDF. One might host such an application as a public utility. A good test suite would model the 1040 historically to make sure the app can reach all states characteristic of the problem, and produce the correct result. On macos you might want to bundle it all in an app, include Chrome, the resources, the data and any generated PDFs.
This would be relatively low-effort and could have real impact on, e.g., TurboTax. Heck, I'd use it. I bet a lot of people here would. Here (https://github.com/b-k/1040.js) is one person who took a serious stab at a part of this, the calculations themselves!
It's sales and value added taxes that are the issue. Some places are really easy, others are difficult, the rules depend on your location, your business other potential nexuses, and the location of the customer. Once collected, the taxes must be remitted properly before the due date. You may need a tax account for every nexus. To submit the returns electronically either requires scraping websites or convincing the government to let you send them another kind of method, perhaps using EDI formats or their own XML or other weird formats.
Agreed. I live in Washington DC. Generally, our tax code tries to push more of the burden on to tourists and less on average residents, with business interests falling somewhere in the middle. How we do that gets really complicated.
1040s are much simpler than other taxes. Let's look at sales tax. Imagine you stop by my corner store and pick up a can of Coke, a bottle of beer, a pack of tampons, and a pair of gloves. The respective tax rates will be 8%, 10.25%, 0%, and 6%.
Here’s a fun one - import duties. If we ignore sales taxes for a minute, the real problem with duties isn’t calculating a number, it’s knowing which classification applies. You often have a giant table or spreadsheet of product codes and duties, but the hard part can be figuring out which products have which duties applied. Companies often pick the lowest duty or tax rating they can get away with, but in ambiguous cases, governments can use courts or regulations to insist on a particular interpretation for a particular time period and sometimes the rules even differ based on who is doing the importing for various legal reasons.
Now, the obvious answer then is that for most online stores, somebody picks a product classification at random or relies on a third-party service that matches a product description to a classification. Most of the time, getting it wrong has few consequences unless you’ve been informed of the problematic item and the same government sees a misclassification more than once, or wants to make a point with your shipment vs others. After all, saying others get away with it doesn’t absolve your need to try and get declarations and duties correct.
Now, I’m not going to say that there isn’t room for open source here, I could totally see how making, for example, an AI that can look at product description and product appearance and try to classify it for duties would be amazing work if done in open source. I’m just pointing out that the topic is complicated, especially when considering that the same item might have different duties if manufactured in different locations or sold under different circumstances.
Governments are unbelievably complicated even as their systems still don’t mirror or match the real world correctly.
Import duties don't just depend on the classification in the nomenclature. It also depends on its value and its origin, which also are sometimes really hard to determine. The origin isn't just where the product is shipped from.
As for the classification, it gets complicated. Sometimes it goes beyond what the product is at the moment of the importation. Say you're shipping fruits, well depending on whether they're for eating as-is, or for juicing once imported, the classification (and thus the import duties) will be different. It's also hard to classify a product that's hybrid (like a ceiling fan with a LED light, is it a fan or a pendant light ?) or a brand new kind of product.
If you have a doubt, you can ask the customs to find the right origin or classification for you, though you might not be happy with the duties they apply. But mostly, it takes weeks to get one and I've seen companies doing their declaration just the day before their shipment arrives.
And even then, different customs officers might classify the same products differently even though they work in the same economic union.
> Companies often pick the lowest duty or tax rating they can get away with
I've seen companies picking the highest duty when they have a doubt, thinking they might get less in trouble or at least don't have to pay the difference if they get caught. Because when they do, the customs can audit your whole import history, and make you pay the difference for every product misclassified (iirc they can go back up to five years) and that can be devastating.
In general, from what I've seen, the task of product classification is so hard that no time is spent trying to optimize sourcing or the nature of the product to pay less duties. In a company the department in charge of customs declarations is always seen as a cost center. The only example I know is Converse importing their sneakers as slippers[1].
And not only is the problem complicated, but some of the most important documentation is only available on subscription. The EU has an open-data policy and a most data on duties can be found[2]. But the World Customs Organization makes you pay for a lot of essential information that can't be reproduced[3].
There is no open RSS/XML/API feed you can subscribe to from each country to get an update of their accounting rules. You have to constantly monitor all news from all over the world. This is labor intensive. The only solution is a network of local tax specialists. Like the big-4 accounting firms have.
I mean you have issues with convincing the U.S. government to provide pre-filled easy-taxes for W-2(+401k contribution) employees. I would say that you would find even more pressure in other countries.
Even if the pipe dream of getting all global governments to provide an API to determine taxes appropriately, there's almost certainly still a business niche aggregating and normalising all those APIs that Open Source probably won't scratch well enough to be able to rely on for tax compliance purposes. Just in the US there are more than 50 "gov tax agencies" (state and federal) that won't (without a very strong federal mandate) all use the same API. Now multiply that over all 200+ countries in the world, and try an imagine any open source dev (or team) writing and maintaining something that stays on top of all the individual "gov tax agencies" you might need to comply with?
Hell, even if an open source project _did_ successfully create and set up a community to maintain that, I bet you could make a profitable business on top of it just by insuring/indemnifying enterprise customers who use your version of it as a SaaS offering. (Something Amazon could easily do...)
> So you’re saying we need an open-source Avalara alternative
The problem is not that Avalara costs money. The real issue is that most companies that claim to "deal with tax compliance issues" actually don't. I tried using some in the past, and none worked correctly for my region (EU/Poland).
The second problem is that you can't really "outsource tax compliance", because there is no clear cutoff line that you can point to. Taking my region as an example, I need invoicing with not just correct rates, but also compliant SAF-T export (JPK Faktura) and soon an interface to the electronic invoicing system that is being built by the government (KSeF), and an export to some of the formats used by accounting companies. And compliant invoicing here (especially on VAT issues) is no joke. You really need this to be perfect.
I run a B2B SaaS and I wish I could outsource all of my subscription billing and invoicing. It's causing me tons of pain. But I haven't found a way to do that.
On a side note, I don't even consider doing B2C sales, because VAT compliance on those in the EU is such a nightmare.
Have you looked into a reseller (Paddle being the most well known)? It wouldn't cut your tax fillings entirely but you would be dealing with a single entity, not every business individually.
Yes. But that puts an intermediary between me and my customers, which has many drawbacks. It's "Paddle" they will see on their invoices, not me, and it's "Paddle" that has a billing relationship, not my business.
That's true but the question is whether it actually matters that much. I bought my iPhone from a third party seller and I still know I have a product from Apple. It's the same thing with these reseller invoices - your SaaS will be listed as the item you're buying. In case of Paddle, you can even put your logo on the invoice. Your company name will also be included in card charge statements. So it's not that bad but I understand where you're coming from.
It is much more than paying taxes. There is no standard API to pay taxes even if you can calculate the amount. A lot of countries require weird registrations on weird portals upon crossing different thresholds. A lot of countries have different financial year cycle.
Met with this team probably 8 years ago for consideration on a (at the time) large subscription product. Didn't go with it because of issues in the organization I was working with, but KillBill folks were good people, impressive, good product. Glad to see them still around.
Tried to adopt it about 8 years ago but their very traditional architecture didn’t fit well with the infra we were using. Also some jruby based plugins were buggy
My memory could be wrong I think the issues we had were related to KB callback based apis becoming flaky with our in-house service mesh and proxied dynamic ips. Again, that was such a long time ago, k8 was fresh and exotic back then
I went on a trip to see how hard it would be to fine, and I _sort of_ found it, and it was not obvious.
1. Started at the homepage, clicked "Start Now" at the top right. It lands on a page called /download/.
2. The word download is nowhere to be seen on that page, but, the third box in the row is "On premise", and has a "Select plan" which redirects to https://github.com/sponsors/killbill.
3. We land on the Github sponsors page for the org. The repository is listed below.
But yeah, not emphasizing their GitHub page is an interesting choice, maybe they figure that their audience isn’t developers? Although many of the reviews are from technical people, so that doesn’t make sense either.
Wish i'd known about this before signing up with Recurly and, later Stripe Subscriptions. Now existing subscriptions are locked in and I can't move to other vendors without losing those existing subscriptions.
We manually migrated away over a period of time, letting new subscriptions and card updates happen on the new system, and letting Stripe slowly deplete. No bad experience for users and no loss on our end of revenue. In the end, whether it'
s Stripe or not running the credit payments isn't so important. But they take so much of a cut for 'added value' that it made sense eventually for us to move away.
For anyone reading, do not get stuck in this situation. Use https://www.pci-proxy.com/ which will allow you to switch from Stripe to your own merchant account to any other service you want at any time. This has been a life saver to me when dealing with significant cardholder transactions. They handle all of the PCI-Compliance for you.
Yes this is a proxy tokenizer. This is from the KillBill FAQ: Don’t store sensitive data in Kill Bill. While most plugins have support for directly saving card or bank account numbers for instance, this should only be used for testing purposes or if you use a proxy tokenizer: if you don’t, use a third-party vault.
Encrypt username and passwords in configuration files. https://killbill.io/faqs/
Stripe indeed helped me migrate away to a vendor in a foreign country - they did a one-time encryption of all the raw credit card numbers for my new processor to import.
The trouble was finding a processor that actually knew what it meant to import the raw credit card numbers (because stripe wouldn't send it to me). But I found one and it all worked out.
I recommend Spreedly for things like this - having a card vault that's independent of your processor can massively de-risk operations and allow you to dynamically route specific transactions to different gateways to optimize profitability. While I haven't tried an import with them, they do support this workflow: https://docs.spreedly.com/guides/migrating/one-time/
I used to pay $15 per month for Spreedly. Then they raised the price to $500 per month (plus usage fees) and don't even have published pricing any more. Quite the change. I don't recommend.
If you worked out another system to do the subscription billing, you should be able to migrate the card tokens out to another payment processor. There are a few rules that the other processor needs to adhere to but I've migrated Stripe subscriptions out before.
That'd depend on if they're the same entity as "The Billing Project LLC", that seems to own the "KILL BILL" mark for downloadable software. I hope they are the same.
It’s interesting to see that even though the project seems to boast being about 10 years old it still doesn’t have 1.0 version. For some this might not be important but it does seem to subtly convey a message of instability of the product. I haven’t read much into it but have to wonder what is stopping them from releasing a “stable” 1.0
I mean this only makes sense in a world where everyone uses semantic versioning (and the project doesn't seem to indicate this anywhere). Versioning numbers, per se, don't really have any bearing on application stability.
Interestingly, being `0.y.z` as a major released version (e.g. not in development or a release candidate) does seem to break semver[1], but I do realize it's more of a guideline and no one really cares:
> Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.
Thanks for this gem of a link. I had a good chuckle all around but found this part particularly very funny:
Apache Kafka was named after Franz Kafka, who lived as an author in turn-of-the-20th-century Austria. Like the project named after him, he was slow to start, inconsistent in delivery, and left a mess of unpublished work after a tragically early death.
Man, I really had to search to find which payment gateways they support. I guess it makes their docs evergreen to not mention any, but it's one of the first questions many new users will have. After searching their docs with no luck, I finally just had to look at their github repos for plugins and there you can see some of them: https://github.com/orgs/killbill/repositories?q=plugin
The problem with this is that you still have to calculate the VAT for each customer manually and submit that to your tax agency and transfer those funds.
For now there are ONLY 2 (non stupid) alternatives that do that dirty work for you:
- itch.io for one time products. (you could make manual subscriptions here redirecting your users every month/year)
- gumroad.com for subscriptions.
itch takes down to card fees only.
gumroad takes more but it scales down as you earn more reaching parity at 30 cents + 2.9% per transaction if your lifetime earnings are $1+ million.
I doubt any of the integrations this open-source project offers will be so much better that it makes it worth the global VAT overhead?
Interesting name choice and idea, I may try it out if I can figure out how to run java again. I went with a similar name https://github.com/kingsloi/medical-billkill for an app I'm building to digitise medical bills
If this supported tons of payment gateways through their plugin system out of the box then it would be worth considering. But if you go to the page about payment gateways they don't have a listing of 50 integrations you could easily drop in. Instead they basically say you'll probably have to write the integration yourself:
No thanks - I'll just use a payment processor that has a good API for subscription billing, and a flag on my users table that the subscription is up to date.
FWIW the very vast majority of our users are integrated with either Adyen, Braintree, or Stripe (all open-source plugins).
I know of ~20 integrations with more advanced gateways/processors: these are closed-source plugins, but the overall community wouldn't benefit much from accessing them (e.g. it doesn't make sense for many companies to directly integrate with mastercard APIs).
Yeah I was too negative. Vendor lock-in sucks so I'm glad someone is tackling it and I should have started with that.
But I think people shouldn't hold back criticism either just because something is free or open source. Stability AI (Stable Diffusion) just sold out and took $100 million from investors after being open source. Even if they're providing something altruistically now you never know if that will change after VC, buyout offer, or some other event.
But the open source code is still there, the community is always able to fork and continue development. True, that rarely happens, but does occasionally (e.g. Emby -> Jellyfin).
Yeah that's good sine the vendors get a lot of control for writing the basic API's. This is open source so they let you choose which means not getting everything spoon fed.
We're hunting for a subscription product, but our use case means that we may have to do a few hundred thousand provisioning checks in a few seconds.
Not a lot of products can do this, which means we're going to use redis (or it's ilk) as a cache for subscription information. However, there doesn't seem to be a supported way to subscribe to changes to subscriptions. Is that a roadmap feature or is something that "we should do ourselves?"
I would love to speak with you to learn more. This is a very good use case for something I have been working on. My email is in my bio page if you are interested.
Maybe this is a good place to ask. I'm considering trying a subscription model for some client side software I'm developing as as a side project. I think something like this would be overkill for me. For a single developer project, what would be the easy way here? Using something totally managed like Patreon? Would Patreon even be a reasonable choice?
I typically think of Patreon as a way for content creators to charge folks for "memberships." So, while I think their billing mechanisms may work for you from a mechanical perspective, I'd perhaps look at alternatives for monthly billing for your client side software licensing.
As for Killbill being overkill.. I think that running/managing your own payment/subscription service behind the scenes probably isn't something you want to spend your time doing, nor would your customers want you spending your time on. Search google for "SaaS billing" and you'll find plenty of options to choose from.
Yeah I know what Patreon is typically used for, but I'm still figuring out what will work best for me. It's possible that positioning myself as a content creator would be OK, with the software mostly free, maybe even open source, but a few paid features unlocked by Patreon. Or something. It's a developer tool and I think developers want everything to be free and open source so it will be tough to monetize.
Stripe (and its competitors) solves exactly what you need.
It takes 1 or 2 days to integrate into your app [1] and you more or less never have to deal with it again (i.e. very low maintenance/administration).
I also think it's worth learning just to have an understanding of how online payment works.
--
[1]: 1 day for a basic subscription model, with granting or removing access when the payment succeeded or failed or the period is over and a new payment hasn't been done.
Maybe 2 days if you want to handle different plans (e.g. free, basic, pro) giving access to different features, and also like a 14 days free trial.
Just remember when you run into problems or have a spike they will temp ban and hold your funds so just like paypal.
Depending on your situation the convivence might be worth it though. Do consider pros and cons as it'll be painful later on.
Thanks for the pointer to Paddle. They look like a good option for me. Nearly as managed as Pateron (handling sales tax 100% along with fraud and chargebacks) but cheaper and more customizable. Gumroad seems OK too and very cheap but it looks like they handle US sales tax poorly.
They’re quite different products. For the 5% you pay Paddle, they’ll resell your product and take care of global sales taxes. It requires a lot less paperwork.
Other competitors in that space include Fastspring and Revin.
As much as I dislike Java, I very much appreciate the Kill Bill authors' approach to features -- via plugins. Unfortunately, the plugins mostly need to be written in Java, although I learned on this HN thread that there maybe a gRPC interface, so I'll take another look!
Maybe an uninformed question, but I tool a look at the documentation, the stripe plugin demo, and then looked at what stripe offers. As someone who uses neither but might be interested in subscription + shop type purchases, what do I get with KillBill+Stripe that I don't with just Stripe?
No. Stripe is a bit insidious (that's probably too negative of a characterization) in that way. Once you start using a product, the pricing for that product then gets rated on your bill.
Stripe billing is .5%, Invoicing .4%, Tax .5%, Rev Rec .25%, etc.
Products like Checkout are included in your prevailing rate (2.9% or whatever).
My experience with the product has been that it has made very clear attempts to provide the user ID for SaaS implementations of the payments system.
I first heard of someone who was using stripe to store all user data on the Running in Production podcast, I thought they were nuts.
But then I went to reimplement the services this year due to the deprecation the "legacy" popover modal on Checkoit.
The new version seems more about locking builders to stripe than it is about anti-fraud, checkout UX or developer experience.
It’s subtle but can be discerned from the implementation details and docs or lack thereof. In that way I would suggest the company has made some insidious decisions about the product.
On one hand, it’s hard to blame them, because before their API could be replicated and swapped out like S3.
This sounds like a awesome idea and a great project, and I work with subscription billing. Attempted to try it out for a while, and my first impression is that the UI is terribly ugly, even as I literally could find only 3 buttons to click a side from the Log out button.
It predates Groupon, was actually started at/around Ning (if anyone remembers them). Groupon hired a bunch of the core folks at the time they decided to adopt it.
FYI this is just a managed sandbox, to test things out. We don't offer Kill Bill aaS, as it goes against our value proposition (Kill Bill is a framework to build your own internal subscription billing and payments platform).
Thanks, now I know what it is, why don't you put this piece on top of the repo so everyone visiting know what it is and doesn't waste time with the marketing babble
Say I had an project that produces a file that people will subscribe to get access to said file. Is this what you would use to sell it? Why not say shopify?
The usual suspects are SendOwl, FastSpring, Gumroad (not a big fan of the UX to be honest), or some industry-specific marketplace (music albums, graphics templates, 3d models, etc. all have big ones).
One would hope you'd be decoupled from their rebilling, and therefore could swap vendors more easily.
I actually just ran into the need to bypass Stripe rebill recently. Ultimately a workaround was found, yet sometimes you really just need more control.
It really depends on your usecase, but some benefits:
* Lower cost (just pay for payment processing, not the subscription features)
* Ability to integrate with multiple gateways (to lower cost, support more payment instruments, higher resiliency, etc.)
* More advanced subscription features
* Ability to customize the system through custom code (plugins)
* Data ownership (easier to run analytics reports, since you own the subscription data)
Hi there! I'm one of the tech writers working on the docs - along with the marketing information. ;) We are always looking to improve. Just so I'm clear... do you mean the few paragraphs on the Kill Bill GitHub landing page (https://github.com/killbill)? (There is also a readme on the killbill/killbill repo, which is why I'm asking.)
That's very harsh. If it were a bunch of cobbled together perl and bash scripts I could understand poopooing the software stack, but java for enterprise accounting software is a super common stack and arguably one of the most suitable solution for this type of software.
Or Kotlin. People usually complain about JVM but lots of enterprise software runs on it. Spring boot ecosystem provides lots ready to use libraries. Kotlin can be much easier to use compared to Java.
Yes Go can be better language now, but still lacks lots of library and API support. And Rust, I'd rather code in jvm language fast and ship it fast than building up whole infrastructure that takes way more time to implement.
In my main gig we run on kotlin (fintech/accounting saas) and I absolutely despise it, the overhead is massive. But I wouldn't want to write it in golang, we really need proper OOP. It's also so unbearably slow, it's actually impressive. But it is what it is ¯\_(ツ)_/¯
Also, to be fair, a big part of the slowness is also the tooling, Spring Boot, Hibernate etc. You can mitigate that by using micronaut or exposed/krush, but we only have a microservice running on that. The main business logic is the classic java web stack. Tests, running the app, building takes forever.
It is just my preference. But your right, java is very "enterprise" hence my trepidation. I think there are much better enterprise worthy languages now, like Go. Which are far easier to develop and maintain.
I'm not the OP, but generally JVM applications are very resource hungry under small loads, although I will concede this matters less as load increases, and the extreme OOP style of programming that Java encourages, in my opinion, leads to a lot of faults that require more operational babysitting than I'm ok with.
I don't have any empirical evidence, just experience. As such I'm very biased against it.
Java was great at the time it was created. But now, I think there are several better languages that are more suited for today. Like Go as an example. Easy to develop and easy to maintain. You get very good performance for little effort. It is just my personal preference, but I don't care to maintain Java or JVM anymore. FWIW, I was at the very first every Java One conference. Have used it for many years.
It might make sense to revisit your stance given the most recent JEPs that have been introduced. Java 19 introduced virtual threads and structured concurrency, which will arguably make Java + the JVM a great alternative to Go, etc. Especially since it's very backward compatible.
W/ Graal as well, the AOT compilation comes 90% of JIT performance.
I really think the JVM is an exciting eco-system that has a very bright future if it keeps going the way it is. Brian Goetz' "Paving the on-ramp" discusses how to reduce the boilerplate even further. So these things are definitely a priority for the Java/JVM team[0].
It's GPL with the 'classpath exception' so that you're even exempt from the GPL the you link. Seems pretty good licensing? Do you prefer even more permissive than that?
This is no longer a real reason. It's licensed as GPL with a "classpath exception." That's pretty permissive and this article[0] does a pretty good job of explaining some questions you may have.
I'm sorry I don't have anything further to contribute to the discussion, but this is an amazing name for the project. The double-pun in the logo with the duck is the cherry on the top.
Actually, here's a small contribution: I do not work with web apps or nowhere near this kind of development (yeah, I also wonder why I'm a regular at HN), or have a use to the end product, but the name and logo grabbed my attention enough to click the link, see the discussion and read the front page. There's power to clever branding.
I've built a (proprietary) telecom billing system with the same name back in 2005. I can't claim that as a particularly brilliant pun since the system we were replacing was called "BillGates" so it was kinda obvious.
perverse: adjective (of a person or their actions) showing a deliberate and obstinate desire to behave in a way that is unreasonable or unacceptable, often in spite of the consequences.
Perhaps "ironic" would be a better word. :-)
ironic: adjective, happening in the opposite way to what is expected, and typically causing wry amusement because of this.
Big Ass Fans (https://bigassfans.com/) has what some might consider to be an unacceptable/unprofessional name and they seem to do great. One might argue that they're "unprofessional" name has helped them.
In the UK, "the Bill" is "the old Bill", the police. "Kill the Bill" is a favoured chant by cross anarchists opposing the "Take-Away-You-Freedom bill (2023)", and/or wishing an early demise to the police.
my first thought was the movie. but if you think about it, they're talking about killing billing problems so I'd say that's where the name comes from. (if you check out their website).
a name that makes people go "hmm that's a bit odd" is actually a very efficient way to get people to remember it next time they need them.
While it is very nice to own our data, we have had a huge lot of issues with it too.
Beware that this is an "industrial" tool, meaning that it is very complex, written in Java, with a lot of quirks and sharp edges. The core team also seems to mainly work on some closed-source version of it, for some not-very-clear-what big corp(s). They let you know sometimes that there exists a more feature-full closed-source version when asking questions in the support google group or on github issues, but it's not very transparent.
If you are a startup with a small team or small budget and no real Java development skills, you'll probably want to be careful in considering to use it: many custom things you'll want to do will require contracting with one of their partners because it's too complicated to do yourself, and support will be limited, and debugging issues will be hugely complicated if you are not used to that tech stack...
Just this week, we have had a major issue with it: after doing an `apt upgrade`, docker was updated and restarted. It restarted KillBill's docker images fine but KillBill itself restarted only the Stripe plugin, not the Avatax one, for an unknown reason. So the tool happily generated invoices and payments for a few hours without any taxes (!), until we noticed and started the plugin manually from the interface. This is the kind of issues we regularly have to deal with, and while the tool does a good job most of the time, it is mindblowingly annoying sometimes.