I do quite a lot of integration with our Point of Sale, directly through it's SQL back-end. Occasionally I represent partial or all inventory in a separate DB which is easier to deal with, isn't subject to their odd schema, and so I can tie it in more directly with lots of other data we've acquired.

Occasionally the owner brings up that maybe we should just write our own POS, to which I very quickly back-pedal and let him know that's not a good idea. As much as the actual inventory tracking isn't that hard compared to what we've done, the accounting portion is not something I want to touch with a ten-foot pole. Let someone else make sure the accounting reports we do our taxes from don't have odd bugs, and spread the gains of bug-testing and fixing across thousands of customers. I've already got plenty on my plate before trying to take on a massive project with huge downsides like that.

> Certainly easier that try to implement the crazy scheme of "discounts" of my customers!

Any billing system that can correctly account for all the various ways businesses and sales departments want to display, link, sell and promote services over time quickly approaches a complexity which is hard to to explain, and without conscious effort also quickly becomes the domain of a few select people that have bothered to actually dive into the mess, leading to silo'd expertise.

Additionally, if you try to make it easy for non-programmers to use, you quickly end up with a DSL which while it may get the job done admirably, is necessarily powerful and expressive enough that you end up having pseudo programmers to write and read them anyway.