Well, I am sorry but in my eyes this just shows bad product quality, bad transparance and missing understanding of basic business stuff on the side of the product. The only reason for software to be existing is to NOT mandate users to check stuff manually.
> The only reason for software to be existing is to NOT mandate users to check stuff manually.
Software exists so users don't have to do stuff manually. But people should absolutely check on things periodically. That doesn't mean it's always necessary to check every single transaction, but spot and sanity checking is mandatory diligence, IMO. I pay my CPA to do my taxes so I don't have to do them myself, but of course I sanity-check the end result before signing off on it.
And OP made a huge change to how he was invoicing/taxing his customers, and then didn't verify that things were working properly after making the change? That's just irresponsible.
Stripe's documentation and API could probably stand to improve here, but that's the nature of products and API UX: never perfect. I do think it's pretty lame that Stripe's support and product people were evasive and did a bad job of admitting that the product had some rough edges that need to be improved.
But... c'mon. Not checking something as basic as "are my customer's payments being processed properly" after making a large change to the payment processing pipeline, and only finding out something was wrong, three months later, after an honest customer asked why they weren't being billed? That's pretty bad.
As it happens, I'm reading this thread while taking a break from writing tax handling in a piece of e-commerce software.
It relies 100% on the settings of the application in question, because tax codes and procedures vary greatly around the world, and it's internationally used software. There are even some stores using this software that sell items to and from different countries using the same website, so it can be set up to handle tax differently per product.
Not everything is taxed everywhere, so it will accept it without question if someone sets up a product with the tax class "none", and happily log, process and store an order with 0% tax.
Yes, it's a footgun for the inexperienced to be able to accidentally commit tax fraud, but no, the software can't just override the user input and insist that a 25% VAT should be applied to random things based on ... what? The name? A hunch? MaChInE LeArNiNg?
Manual audits are used to discover human error, be it my error in creating the software, or your error in the data supplied to the software. I can create the logs and make them as easy to read as possible, but if you don't read them for three months, that's on you.
Everything you wrote is correct. But still, if your product does not transparently show and alert such events, overall product quality is in my opinion bad. Dev or lead or product manager should not be ok with this. But this pretty mich reflects current state of software development. Errors and stuff are in way too many cases "ok" to occure.
I think what the poster is saying is that, as far as the software is concerned there IS no event to alert. You live in the US, but setup the taxes as if you live in the Caribbean? You're responsible for the setup, and as a business owner responsible for either setting it up correctly, verifying that someone set it up correctly or paying the auditors to do that for you.
Yeah it sucks, but the more we try to take the accountability out of the humans and put it into the software, the worse both the accountability and the software gets.
Not AI, just statistics and double checks. In the old days that was done by people that knew what they were doing now it's a job for programmers. Having alerts about too many strange entries in the transaction log/inventory is something I've implemented.
I agree 110%!! This is just a miss by developers who do not understand the use case and business impact. I have rarely seen systems that implemented business logic alerting until after the company has been screwed. Perhaps not even then. It is a disconnect between the developers and the business. Stripe should be sending emails/notifications as invoices pile up in the "draft" state. That edge case was never examined. Total miss and prime example of the move fast and break things world we live in now. I view these services like Stripe as cutesy little services because of this and I would never trust my business to them. Diligence is on you but the marketing department sells the opposite to unsophisticated customers.
Just like everything out of silicon valley, creaky bare bones bullshit with meager support and a total hands in the air philosophy when it comes to responsibility.
As a US customer Eventbrite sends me an invoice/receipt in GBP yesterday. I scramble around looking for an invoice in USD and find nothing despite putting all of my information in pointing to the US. It's like doing business with toddlers.
They payment was processed in USD but there is zero mention of exchange rates or anything. My support option? Contact the poor guy trying to make his life easier by using their service. I have come to expect this vapid garbage unfortunately.
No disagreement at all that ERPs are generally garbage, especially for how much they cost. But this comments makes me think you have never dealt with international taxes. The rules are insanely complex, there is no global standard for communicating the tax, multiple systems have to be in sync with each other, and some systems even use different rounding algorithms...
I'm all for blaming the software (which by the way in this case is made by a huge company I am 100% sure you know and costs hundreds of thousands of dollars to operate)... but the real problem here is the complexities of tax (I used Canada as an example but the US is the absolute worst because each state makes their own lows) is not a software quality problem, it is a data and open standards (or lack their of) problem.
But since the lack of standards is not being fixed any time soon, sometimes it "is" the user's fault.
Users should be doing sanity checks of financial transactions on a regular basis. You even want an external party doing audits as frequently as is reasonable.
That doesn’t mean every transaction needs to be manually revived, but major outliers and a random sampling is a good idea.
I tell my clients all the time why I can't just make a "quick change" and I have to manually review the data sometimes and go through a ton of code review. I tell them...
> As a human I can only mess up one or two orders a minute. Computers are uniquely qualified to mess up thousands of orders in seconds.
The existence of audit & compliance responsibilities does not abolish the responsibility of the software to reduce foot-guns. The number of people here arguing the opposite is completely insane.
A re-reading of the remarks suggests to me that they aren't arguing exactly the opposite. I'd put forward, after all, that no-one wants to create footguns, but folks are recognising that footguns are inevitable anyway, so plan accordingly.
As for why they're inevitable, the context is that most enterprise software is off-the-shelf and serves many markets, so configuration becomes the point of weakness. Only bespoke software written for a very narrow sector, or tailored to serve a single business, can really hope to do better.
We might hope things were different, but they're not, and as long as software continues to be developed by the humans, it's likely to remain that way.
None of this is meant to absolve Stripe, however, since in this particular instance they rather appear to have contributed to the fuckup by omitting a key element of auditability, viz. the clear reporting of exceptions.
Quickbooks takes a stab to categorize my books for me. But you better believe, while I’m no CPA, I’m in the books at least once a week making a modicum of effort to understand and work on these things.
I’m far from perfect, and that’s why the CPA comes in after me to check. But if i wait for those quarterly checks to “check in” on quickbooks, that’s on me.
So software is a "guarantee" thing already that people can trust in? I wonder how many software engineers will be out of their jobs if that actually happens, we will see